chip's Journal http://use.perl.org/~chip/journal/ chip's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:04:43+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 chip's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~chip/journal/ Post-OSCON Thread http://use.perl.org/~chip/journal/30455?from=rss <p>Greetings, fellow primates!</p><p>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 <a href="http://feather.perl6.nl/~chip/oscon06/OSCON06-ParrotEvolutionV2.pdf">my presentation</a>.</p><p>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.</p> chip 2006-07-28T00:51:03+00:00 journal Onward &amp; Upward: New Assignments http://use.perl.org/~chip/journal/30136?from=rss <p>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: </p><p>I'm pleased to announce that Allison Randal is taking over as architect of Parrot, and I'm being promoted to pumpking. </p><p>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. </p><p>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.<nobr> <wbr></nobr>:-) So, to me, this is a promotion. </p><p>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. </p><p>Onward &amp; upward! <i>Squawk</i>!</p> chip 2006-07-01T18:38:59+00:00 journal YAPC 05 Hackathon Day 1: PDDs, PGE, and Testing http://use.perl.org/~chip/journal/30096?from=rss Writing from beautiful(?!) Chicago where the incredible Josh McAdams and Pete Krawczyk have herded all us cool cats through <a href="http://yapcchicago.org/">YAPC::NA '06</a>. Not enough can be said about their yeoman service, so I won't try. Suffice to say: "Great job, and thank you." <p>Links to many YAPC speaker slides are <a href="http://yapcchicago.org/wiki/index.cgi?YAPCSlides">on the YAPC wiki</a>. </p><p>And the hackathon begins... </p><p>I'm about to document the new <tt>dynamic_scope</tt> mechanism in a PDD. Meanwhile, Patrick Michaud, Will Coleda (coke) and Jerry Gay (particle) are here hacking on PGE, testing, and stuff. </p><p>In order to understand Parrot <tt>dynamic_scope</tt>, you should understand continuations. If you don't know about continuations, start by checking out <a href="http://en.wikipedia.org/wiki/Continuation">the Wikipedia article on continuations</a> and <a href="http://www.federated.com/~jim/schintro-v14/schintro_141.html">this introduction to continuations in Scheme</a>. Extra credit for reading about Scheme's <tt>dymamic-wind</tt>.</p> chip 2006-06-29T17:05:48+00:00 journal Hackathon Days 4+5: Report http://use.perl.org/~chip/journal/25234?from=rss 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. <p>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.) </p><p>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.) </p><p>([*] 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.) </p><p>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 <i>not allowed</i> 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.<nobr> <wbr></nobr>:-, </p><p>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: </p><ul> <li>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".</li> <li>Opcode names should never be quoted and have parens in the style of named subroutines.</li> <li>Named subroutines must never be unquoted in the style of opcodes.</li> <li>Binding operations should be spelled ":=" rather than "="; "P1 = new Integer" followed by "P1 = 1" is just too visually confusing to live.</li> <li>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 <i>is</i> an output result.</li> <li>And finally, <i>PIR must never seg fault</i>. Error handling is, if anything, <i>more</i> important in infrastructure like Parrot than in normal applications code.</li> </ul><p>Finally, I appreciate the feedback I've gotten on the model users document. Please remember the mantra of open source projects everywhere: "Patches welcome!"</p> chip 2005-06-16T13:56:21+00:00 journal Hackathon Days 2+3: Report http://use.perl.org/~chip/journal/25182?from=rss As I suspected, things quieted down for me quite a bit over the last two days<nobr> <wbr></nobr>... they've gone from insane to merely busy. While Autrijus has been releasing Pugs, Leo and I have been designing things and considering priorities. <p>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<nobr> <wbr></nobr>... well, read <a href="http://svn.perl.org/parrot/trunk/docs/pdds/pdd03_calling_conventions.pod">my update of PDD03</a> 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...) </p><p>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. </p><p>Actually, that's one class of user: the Magpie. ("Oooh! Shiny!") I've modelled the Parrot users I could think of in <a href="http://svn.perl.org/parrot/trunk/docs/req/model_users.pod">the Parrot Model Users document</a>. 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. </p><p>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. </p><p>The short version of the situation with continuations is: </p><ul> <li>Parrot will support full continuations, not just escape continuations. That is, continuations will <i>not</i> be limited to jumping up the current call stack.</li> <li>Parrot continuations will <i>not</i> require any new save and restore operations to work properly. One of the advantages of a <i>virtual</i> machine is that its state is always already saved. Right there in, you know, <i>memory</i>. Invoking a continuation is pretty much just switching your "current activation record" pointer.</li> <li>Parrot's register allocator <i>will</i> 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.</li> <li>Finally, most PMC operations (except function call, of course) are guaranteed <i>not</i> 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.</li> </ul><p> And that's all the news from Herrnbaumgarten. Guten Nacht.</p> chip 2005-06-13T21:05:05+00:00 journal Hackathon Day 1: Report http://use.perl.org/~chip/journal/25158?from=rss APW was great. I talked about the Parrot project, and its goals and priorities. Please read it, either the <a href="http://feather.perl6.nl/~chip/Chip_APW.sxi">OpenOffice version</a> or the <a href="http://feather.perl6.nl/~chip/Chip_APW.pdf">PDF export version</a>. <p>Yesterday was the first day of the post-APW hackathon, and it was quite a day<nobr> <wbr></nobr>... it started off with heavy design discussion and ended with me wandering around in a daze. Not that that's unusual, really. </p><p> <b>Variable-length register frames</b> were an early topic. Register spillage is inevitable when you have a limited number of registers in your machine. However<nobr> <wbr></nobr>... and work with me on this<nobr> <wbr></nobr>... Parrot is a <i>virtual</i> machine. We <i>don't</i> have a limited number of registers, unless we want to, and I'm pretty sure we don't. </p><p>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. </p><p>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. </p><p>(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.) </p><p> <b>Calling conventions</b> 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". </p><p> <b>Opcode count and policy</b> 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.<nobr> <wbr></nobr>:-, </p><p> <b>Lexical implementation</b> was actually a topic before we got to Leo's<nobr> <wbr></nobr>... 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)). </p><p>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. </p><p>Share and enjoy!</p> chip 2005-06-12T12:21:15+00:00 journal Hackers, hackers everywhere... http://use.perl.org/~chip/journal/24071?from=rss As <a href="http://use.perl.org/~autrijus/journal/24058">autrijus enthusiastically observes</a>, I'm looking forward to attending the <a href="http://conferences.mongueurs.net/apw2005/index.html">Vienna Perl Workshop</a> and hanging around for a few days of hacking afterwards, soon to be followed by a few days of hacking before <a href="http://yapc.org/America/">YAPC::NA</a>. 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 &amp; paper). chip 2005-04-08T15:11:07+00:00 journal PMC implementations are hard to read http://use.perl.org/~chip/journal/23908?from=rss 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:<blockquote><div><p><nobr> <wbr></nobr><tt>/*<br> <br>=item C&lt;static PMC* undef(Interp* interpreter)&gt;<br> <br>Returns a C&lt;PerlUndef&gt; PMC.<br> <br>=cut<br> <br>*/<br> <br>static PMC* undef(Interp* interpreter)<br>{<br>&nbsp; &nbsp; return pmc_new(interpreter, enum_class_PerlUndef);<br>}</tt></p></div> </blockquote><p>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:</p><blockquote><div><p> <tt>=method undef<br>=returns a C&lt;PerlUndef&gt; PMC.<br>{<br>&nbsp; &nbsp; return pmc_new(interpreter, enum_class_PerlUndef);<br>}</tt></p></div> </blockquote><p>Everything else that's omitted here is, or should be, available elsewhere<nobr> <wbr></nobr>... every implementation of the given vtable method must have the same signature, so why make every implementor spell it out? </p><p>If we want people to help us finish the PMCs, why not make their job a little more pleasant?</p> chip 2005-03-29T17:31:31+00:00 journal Perl6: I want to use this language http://use.perl.org/~chip/journal/23895?from=rss Writing Perl6::Subs has given me a glimpse of the power of the dark side. er, I mean, of Perl 6.<blockquote><div><p> sub foo ($x: $i of Int where { $_ &gt; 0 }, Foo +$j is required) {<nobr> <wbr></nobr>... }</p></div> </blockquote><p>That kind of power gives a guy motivation to help make it happen.</p> chip 2005-03-28T21:39:22+00:00 journal Cheep Thrills http://use.perl.org/~chip/journal/23894?from=rss 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. <p>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<nobr> <wbr></nobr>... and not even in his absence, as he's going to hang around as much as Real Life obligations permit. Thanks, Dan, for everything. </p><p>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 <i>everybody</i> these days has one of those new-fangled "web browsers". So here goes....</p> chip 2005-03-28T21:36:10+00:00 journal From under the hood to behind the wheel http://use.perl.org/~chip/journal/17291?from=rss I never realized until I got my current day job just how much I've been working <i>on</i> Perl instead of working <i>with</i> it. But now I'm out from under the hood, and I'm sitting behind the wheel instead. And I'm loving it. <p>I've been writing a lot of Perl lately. My current job is a good problem domain for Perl--lots of parsing--but that's not the point. The point is that I'm not hacking the Perl core any more, at least not often. I hardly work in C lately. It's all Perl and shell. </p><p> <i>DAMN</i> this is a fine language! Whenever I think of an abstraction, a rearrangement, a generalization, a feature, even sometimes just a vague concept<nobr> <wbr></nobr>... Perl has a way. It's not always a pretty way, and it's sometimes inefficient or dangerous or even silly; but Perl doesn't stop me. It gives me all the rope I want, even if I want to shoot myself in the foot with it. </p><p>Of course, knowing how the core works is still remarkably useful. It removes the need for cargo cult or just-in-case programming practices; I don't have to worry whether something will really work the way I want if I know how it's implemented, down to the C function names. Whether this indicates something weak about Perl or is just a normal consequence of a complex system implemented on top of another system, I don't know. I suppose I should learn to hack the core of Python, or a JVM, so I can be sure.... </p><p>Nah. I've got code to write. Now how can I factor out this expression here? Oh, that was easy.</p> chip 2004-02-09T03:19:40+00:00 journal