Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chip (65)

chip
  chip@pobox.com

Pumpking Emeritus for Perl 5.4 and Parrot

Journal of chip (65)

Thursday July 27, 2006
07:51 PM

Post-OSCON Thread

Greetings, fellow primates!

I've just presented version two of "Parrot: Evolution" at OSCON 2006, and this is the URL I offered to the attendees. If you didn't see the talk, or you want to re-live that astonishing afternoon, please enjoy my presentation.

If you're interested in helping with Parrot, or if you want it to do something it doesn't do (which is also helpful), please post here, and we'll figure out the next step.

Saturday July 01, 2006
01:38 PM

Onward & Upward: New Assignments

YAPC is, among other things, a wonderful opportunity to meet and talk face-to-face about things that concern us. This YAPC, one topic was how to get Parrot development on track to make it the VM we all believe it can be. One outcome of these discussions is a bit of a personnel shuffle, to wit:

I'm pleased to announce that Allison Randal is taking over as architect of Parrot, and I'm being promoted to pumpking.

Allison, of course, needs no introduction; as architect, she will flesh out the vision of a virtual machine for dynamic languages, that's been her primary interest from the beginning.

I, on the other hand, am very happy to be diving back into the code where I've learned I'm the happiest. Writing specs and writing code are similar; but when you're done with code, there's a "go" button, and lights flash and wheels turn. It's the best toy set in the world. :-) So, to me, this is a promotion.

Both Allison and I thank Leo Toetsch for his service as pumpking. He's done a yeoman's job getting parrot releases regular and stable. We're very pleased that Leo is staying on to continue improving parrot internals. Now that I'm going to carry the release cycle burden, he'll have more opportunity to respond to language implementors' issues, making Parrot better for all.

Onward & upward! Squawk!

Thursday June 29, 2006
12:05 PM

YAPC 05 Hackathon Day 1: PDDs, PGE, and Testing

Writing from beautiful(?!) Chicago where the incredible Josh McAdams and Pete Krawczyk have herded all us cool cats through YAPC::NA '06. Not enough can be said about their yeoman service, so I won't try. Suffice to say: "Great job, and thank you."

Links to many YAPC speaker slides are on the YAPC wiki.

And the hackathon begins...

I'm about to document the new dynamic_scope mechanism in a PDD. Meanwhile, Patrick Michaud, Will Coleda (coke) and Jerry Gay (particle) are here hacking on PGE, testing, and stuff.

In order to understand Parrot dynamic_scope, you should understand continuations. If you don't know about continuations, start by checking out the Wikipedia article on continuations and this introduction to continuations in Scheme. Extra credit for reading about Scheme's dymamic-wind.

Thursday June 16, 2005
08:56 AM

Hackathon Days 4+5: Report

Greetings from beautiful NiederOesterreich. Yes, this is Lower Austria, even though it's right up against Austria's northern border. I guess being close to the Alps gives the term "lower" a more concrete meaning.

The last two days' activities included discussion of the detailed requirements of the lexical subsystem. So far I see no reason not to like most of Perl 5's model. Its one weakness was how it shoehorned names pulled in from outer subroutines into the same list with names that were locally declared. (Non-subroutine scopes scopes, i.e. nested blocks in a single subroutine, are relatively easy.)

In Perl 5, the lexical thing that doesn't work well looks like this: While compiling inner subs that reference outer lexicals, the compiler actually grabs a pointer to the outer value at compile time.[*] This works great if the outer scope is one-shot (e.g. the top level of a compilation unit, or a BEGIN block), but it totally doesn't work when a named sub contains another named sub. (Ever see the "variable won't stay shared" warning? No? Then you've never hit the resulting bug. It's there, though.)

([*] But when the sub is anonymous, it's treated as a closure, which captures the current value at runtime, rather than constructing an alias at compile time. Which is why Perl's closures work when they're anonymous, but not when they're named. But anyway.)

Perl 6 has some truly nasty multi-sub resolution semantics. I wouldn't want Parrot to handle it all, not that it could, but Parrot does need one adjustment to help: multi-dispatch can't be a one-shot operation. MMD lookup for Perl 6 will have to be a process of successive approximation, under the control of HLL logic. Some resolution can't be done until the sub parameters are evaluated (e.g. a where clause on parameter #2 that references value #1), but lazy parameters mean that Perl 6 is not allowed to evaluate them until it's absolutely necessary. So MMD resolution has to be tried first based on the compile-time-known types, but if that's not enough to know what to call, then the lazy parameters can be evaluated in order to get a more specific result. If this sounds incredibly fiendish, it is. And if that surprises you, then you've never listened to Larry, Allison, and Damian. :-,

PIR, the high-level Parrot assembler, has some problems in clarity and implementation. Autrijus has been able to make PIR dump core fairly regularly, which is not acceptable. He's also brought up some confusing aspects of its parsing, which also are not acceptable. Some limited PIR language reform, along with armor-plating the implementation, seems appropriate at this point. For example:

  • Type names should always be specified with a leading dot when they're known at compile time, with no exception for e.g. "new Integer".
  • Opcode names should never be quoted and have parens in the style of named subroutines.
  • Named subroutines must never be unquoted in the style of opcodes.
  • Binding operations should be spelled ":=" rather than "="; "P1 = new Integer" followed by "P1 = 1" is just too visually confusing to live.
  • The assignment syntax must be tightened up. "P1 = print" as a synonym for "print P1" is just incredibly evil; the use of "=" for opcodes must be limited to opcodes where the first operand really is an output result.
  • And finally, PIR must never seg fault. Error handling is, if anything, more important in infrastructure like Parrot than in normal applications code.

Finally, I appreciate the feedback I've gotten on the model users document. Please remember the mantra of open source projects everywhere: "Patches welcome!"

Monday June 13, 2005
04:05 PM

Hackathon Days 2+3: Report

As I suspected, things quieted down for me quite a bit over the last two days ... they've gone from insane to merely busy. While Autrijus has been releasing Pugs, Leo and I have been designing things and considering priorities.

Candy first. Leo came up with a sane call/return convention for Parrot. After some discussion with Autrijus and me, Leo has now implemented a useful working subset of the final feature. The new call/return convention involves some new opcodes, does automatic type conversion and array flattening and ... well, read my update of PDD03 for yourself. (Yes! There are docs! A PDD even! And I've updated it! OMG! PDD! WTF?! If there's a fellow Parrot user near you, check to see if he needs resussitation...)

I've also been pondering priorities, and otherwise putting thought into the least hacker-like and yet most crucial Fearless Leader task: Pondering who Parrot should serve, and how. I'm not planning to live in Cloud City -- I'm a troglodyte hacker at heart -- but making design decisions where there is no clear right answer requires a usable utility metric. Otherwise you just end up floundering around and chasing cool things.

Actually, that's one class of user: the Magpie. ("Oooh! Shiny!") I've modelled the Parrot users I could think of in the Parrot Model Users document. Check it out. Who have I left out? Who matters the most? Don't worry about getting the right answer on those questions. There probably isn't one.

And boy have I learned a lot about continuations. Autrijus has been diving deeply into the literature on this for a while, and I've been picking his brain at every opportunity. (You can pick your friends, and you can pick their brains, but you can't pick your own brain. Or something like that.) The p6i discussion on the subject has been, well, mixed, not least because I've taken a few mail exchanges to figure out exactly what we need and want.

The short version of the situation with continuations is:

  • Parrot will support full continuations, not just escape continuations. That is, continuations will not be limited to jumping up the current call stack.
  • Parrot continuations will not require any new save and restore operations to work properly. One of the advantages of a virtual machine is that its state is always already saved. Right there in, you know, memory. Invoking a continuation is pretty much just switching your "current activation record" pointer.
  • Parrot's register allocator will have to be changed to allow for the extra flows of control produced by continations. Essentially, no register assigned to a pseudo-register that is used across a function call boundary can be aliased to any other pseudo-register. This would have been a problem if not for the register expansion we already agreed to implement. Now it's no big deal.
  • Finally, most PMC operations (except function call, of course) are guaranteed not to invoke full continuations. They can do the escpae continuation thing (i.e. throw an exception), but that's all. This is a requirement for two reasons: First, if those functions invoke Parrot code, they do so in a separate run loop, which makes the full continuation implementatin a real pain; but second, because we don't want to send the register allocator totally around the bend by making every PMC operation a boundary like function calls already are. This implies that if you want to invoke a continuation, you can't do it in your TiedArray::FETCH function. I don't think we'll get a lot of complaints about that.

And that's all the news from Herrnbaumgarten. Guten Nacht.

Sunday June 12, 2005
07:21 AM

Hackathon Day 1: Report

APW was great. I talked about the Parrot project, and its goals and priorities. Please read it, either the OpenOffice version or the PDF export version.

Yesterday was the first day of the post-APW hackathon, and it was quite a day ... it started off with heavy design discussion and ended with me wandering around in a daze. Not that that's unusual, really.

Variable-length register frames were an early topic. Register spillage is inevitable when you have a limited number of registers in your machine. However ... and work with me on this ... Parrot is a virtual machine. We don't have a limited number of registers, unless we want to, and I'm pretty sure we don't.

PIR users will never notice the difference when register frames go all variable, since $P pseudo-registers were always infinite anyway. But things should get faster, and solving the problems of register allocation should be somewhat easier.

This is not a big deal to change, BTW. We even worked out how the JIT can handle it without loss of efficiency. Grabbing variable-sized hunks of memory is also basically a solved problem, what with, you know, strings and all.

(BTW, we have a new rule: PIR should be relatively stable, but it's OK to change pasm at any time, because humans should never write it. And fortunately it's not against the law to abuse silicon-based life forms.)

Calling conventions were the next topic. We'll have more specifics soon, but one thing Leo and I agree on is that the current convention is unnecessarily complex and an excessive burden on coders targeting Parrot. We're looking at abstracting it away from users so that all you have to write is "here are the arguments for the call I'm about to make" and "please put my incoming arguments in these registers".

Opcode count and policy was briefly discussed. The discussion was brief because Leo and I agree that the current opcode list is excessively broad. You don't make opcodes for all your IO and math and POSIX operations, for example. That's what libraries are for. So many opcodes will be migrating to standard libraries. Again, if you write PIR we can probably shield you from this change. PASM? You're on your own. :-,

Lexical implementation was actually a topic before we got to Leo's ... I totally missed watching the Austrian countryside as I explained the Perl 5 lexical implementation to Leo and Autrijus. Turns out that Perl 5 is actually an improvement on Parrot right now: Perl 5 knows that lexicals' names and scopes are known at compile time, so it compiles them then and never revisits them. Parrot, in contrast, actually builds and destroys the list of lexicals at runtime. Silly, isn't it? Well, that'll change. We'll have separate data structures for the names and scopes of lexicals (static) and their values (dynamic, created at subroutine entry (probably)).

Well, today won't be nearly so high-powered, I'm sure. I'm focussing on documentation and the mailing list, and I'm going to get some details out of Leo on how we can implement these keen ideas, and how soon.

Share and enjoy!

Friday April 08, 2005
10:11 AM

Hackers, hackers everywhere...

As autrijus enthusiastically observes, I'm looking forward to attending the Vienna Perl Workshop and hanging around for a few days of hacking afterwards, soon to be followed by a few days of hacking before YAPC::NA. These hackathons are a fantastic idea, and I'm thrilled to be able to participate. It'll be great to do Parrot development with low-latency multicast wireless communications (i.e. talking) and shared graphical design tools (pencil & paper).
Tuesday March 29, 2005
12:31 PM

PMC implementations are hard to read

I think PMC method implementations should be easier to read (and write) than they currently are. PMC methods as they are currently written are almost compilable with a C compiler, modulo some magic words like "SELF", and that makes them highly redundant. Even a little simple filtering should let us kill all those blank lines and pod text up against the left margin. And there's a lot of cross-file redundancy we can kill with some vtable knowledge. Where now we have:

/*

=item C<static PMC* undef(Interp* interpreter)>

Returns a C<PerlUndef> PMC.

=cut

*/

static PMC* undef(Interp* interpreter)
{
    return pmc_new(interpreter, enum_class_PerlUndef);
}

Look at all the redundancy there. And consider all the vtable methods that have multiple implementations across many PMCs. Making programmers type the same thing over and over is just mean; it all the fun out of the coding. Something like this would be a lot better:

=method undef
=returns a C<PerlUndef> PMC.
{
    return pmc_new(interpreter, enum_class_PerlUndef);
}

Everything else that's omitted here is, or should be, available elsewhere ... every implementation of the given vtable method must have the same signature, so why make every implementor spell it out?

If we want people to help us finish the PMCs, why not make their job a little more pleasant?

Monday March 28, 2005
04:39 PM

Perl6: I want to use this language

[ #23895 ]
Writing Perl6::Subs has given me a glimpse of the power of the dark side. er, I mean, of Perl 6.

sub foo ($x: $i of Int where { $_ > 0 }, Foo +$j is required) { ... }

That kind of power gives a guy motivation to help make it happen.

04:36 PM

Cheep Thrills

[ #23894 ]
Well. To my great surprise, I've been drafted as Fearless Leader of the Parrot project. So much has been done by so many, and now it's time for me to catch up with all those cool things and have intelligent things to say about them. It's quite the responsibility, and I hope to live up to it.

Dan Sugalski has done wonderful work as Parrot architect, and I really can't say that I'm replacing him so much as carrying on ... and not even in his absence, as he's going to hang around as much as Real Life obligations permit. Thanks, Dan, for everything.

Keeping a blog is not really my lifestyle; I'm more of a mail guy. But I've learned to include IRC, so why not yet another medium? It does seem that just about everybody these days has one of those new-fangled "web browsers". So here goes....