Planet Parrot

Perl on Google's App Engine

2008-07-23T06:56:39+00:00

Artur Bergman discusses Perl on Google's App Engine, while Brad Fitzpatrick announced Perl on App Engine. The important information is that Google will support the project only if the Perl community does most of the hard work. (This position seems reasonable to me; gift horses and all that.)

HLL configuration directives live!

2008-07-21T19:43:09+00:00

mod_parrot now has support for HLL configuration directives! They're still a bit tedious to configure since everything is in PIR and I'm missing a few Apache constants, but it works! I committed a proof-of-concept directive for mod_perl6 called, well, what else, Perl6ResponseHandler. So this works now:

<Location /foo>
    SetHandler perl6-code
    Perl6ResponseHandler Foo::Bar
</Location>

The only caveat is that you have to use ParrotLoadImmediate to load the perl6 HLL layer, since ParrotLoad doesn't start the interpreter until after the configuration phase. mod_perl has a similar setup with PerlLoadModule. Eventually the loading of HLL layers will be automatic, or at least in their own config file so you don't have to worry about it.

Now for the interesting bits. As I noted in my previous post, I got a proof-of-concept working where I was able to create and load a module at runtime, complete with custom directives; I just needed to refactor it for mod_parrot. It actually wasn't that bad, except for one minor thing. Unlike modules written in an HLL which implement their own directives and modify their own configs, the directives implementing the HLL itself need to modify mod_parrot's configuration. In other words, one module needs to modify another's configuration! This was painful to implement, especially for the directory configuration, but I did it in about 2 days without doing anything shady, and it works.

Here's what Perl6ResponseHandler looks like in the perl6 HLL layer:

.sub __onload :anon :load

    # [skip perl6 initialization code]
 
    # register apache directives
    .local pmc add_module, cmds

    load_bytecode 'Apache/Module.pbc'

    cmds = new 'Array'
    cmds = 1
    $P0 = new 'Hash'

    $P1 = new 'String'
    $P1 = 'Perl6ResponseHandler'
    $P0['name'] = $P1
    $P1 = new 'Integer'
    $P1 = 1 # TAKE1
    $P0['args_how'] = $P1
    $P1 = get_hll_global 'cmd_perl6responsehandler'
    $P0['func'] = $P1
    $P1 = new 'Integer'
    $P1 = 8 # OR_AUTHCFG
    $P0['req_override'] = $P1
    $P1 = new 'String'
    $P1 = "usage: Perl6ResponseHandler handler-name"
    $P0['errmsg'] = $P1
    cmds[0] = $P0

    add_module = get_hll_global [ 'Apache'; 'Module' ], 'add'
    $P1 = add_module("modparrot_perl6_module", cmds)
.end

.sub cmd_perl6responsehandler
    .param pmc args
    .local string handler
    handler = args[0]
    $P0 = get_hll_global ['Apache'; 'Module'], 'modparrot_dircfg_handler'
    $P1 = $P0('perl6', handler)
.end

Of course it will be a bit prettier in the future when I work out the Apache constants and get this working in Perl 6 instead of PIR, but you get the picture. With this major milestone out of the way I can focus on exposing more of the Apache internals and really start kickin' the tires!

They Call This a Softball Question in Interviews

2008-07-21T04:48:56+00:00

Recently there has been a feeling of growing discontent: how could Ruby — which felt so new and liberating two years ago — get saddled with so much negative baggage, so quickly?

— Pete Forde, We are RubyFringe

Take your pick of the aggressively dismissive attitude toward other approaches, vigorous and self-congratulatory messianic zeal, egocentric and deliberate misunderstanding of the rest of the world of software development, verbose and willful discussion of, despite baffling ignorance of, other programming languages, misunderstanding of MVC and the Active Record pattern, booing Dave Thomas at RailsConf 2007 for questioning why it was necessary to create a "Women of Rails" website featuring pictures of attendees, cheering at RailsConf 2007 when Chad Fowler said "People call us arrogant" when his point is that that's a bad thing, and the baffling fourteen year old boy sensibilities of the Rails Envy commercials, including my personal favorite, comparing the V in MVC to a drunken prom date.

I can understand arrogance from Olympians or research scientists who've just cured cancer. It seems out of place for people writing CRUD applications, even if they're all shiny with rounded corners and Ajax fade ins.

The Difference Between Jazz and Programming

2008-07-20T07:50:52+00:00

The modern jazz small ensemble is built upon the rhythm section -- piano, bass, and drums.
The easiest parallel to programming is libraries, frameworks and patterns. These are the building blocks upon which we code. A well-designed library makes your work as a programmer easier and more enjoyable in the same way a solid, experienced rhythm section complements a soloist.

— Nick Sieger, Jazzers and Programmers

One important difference between programming and music is that in programming, correctness often supersedes aesthetics. It's not that aesthetics are unimportant, or that there can or should be no joy in programming -- but if your code doesn't work, it doesn't matter how much of a punk fringe rock star you consider yourself.

Color me (what, two nods to my pseudonym in two paragraphs?) uninspired. I doubt improv will pass my test suite. See Dabblers and Blowhards for a deeper debunking of similarly silly comparisons.

Anonymous classes and meta-class stuff

2008-07-18T23:01:39+00:00

Today was this week's Rakudo day, and I spent it continuing my work on the S12 (objects) implementation. The biggest new addition this week is that you can now write anonymous classes.

my $c = class { has $.x; method foo { say "OH HAI" } }; my $obj = $c.new(x => 42); # Instantiate it $obj.foo; # OH HAI say $obj.x; # 42

I've got tests written for anonymous classes with attributes and methods; you should be able to inherit and compose roles too, but I didn't get tests for those done yet. Anyone who feels like writing such tests, please do feel free - they go in S12-classes/anonymous.t (in the t/spec, in the Pugs repository).

We've been able to write multi-dispatch subs where the dispatch was type rather than arity based for a little while. As I start to think about implementing the real Perl 6 multiple dispatch algorithm soon, I wanted to make sure that multi-methods worked with the current Parrot algorithm. I'd never thought to try it, but it occurred to me that there wasn't really any good reasons why it wouldn't work either. It turns out it didn't work, but the fix wasn't hard either. So, I did what was needed and now you can write multi methods in classes. Arity based dispatch should be fine; type based has all the issues multi-subs do until I get the real Perl 6 multi-dispatch algorithm in place that knows about roles, constraints and so forth.

After that, I set about adding the .^ method call operator. This means "call on the meta-class". S12 changed recently to make things a bit saner here. Before it was specified that you would be able to write things like:

my @methods = $obj.HOW.methods();

To introspect the methods of the object $obj. However, this doesn't quite work out, since you are invoking "methods" on the meta-class, and there's no promise that just one class will have one meta-class; the meta-class may be shared amongst many classes, depending on your meta-model. So now you have to pass in the object to introspect as the first parameter to methods on the meta-class.

my @methods = $obj.HOW.methods($obj);

Which is a bit of a mouthful, which is why there is the .^ operator, allowing you to write the above like this:

my @methods = $obj.^methods();

This operator sorts out getting the meta-class by calling HOW, and inserting $obj as a parameter to the meta-class method. Note that "methods" on the meta-class isn't implemented yet, though it's probably not far off being done. Today I modified our existing meta-class methods to match the new S12 changes, then implemented the .^ operator. So this gets us on the way towards more introspection support. While I was in that area of the code, I moved the auto-vificiation (WHENCE) stuff out of the P6Object code (which is meant to be more generic than what Rakudo needs) and put it into the Rakudo code, which should make some upcoming refactors pmichaud has planned on P6Object a tad easier.

I also looked at starting to get a few other things in place to flesh objects out. One of them is .WHERE, which simply returns the memory address of an object. That didn't take long. Then I read up on .WHICH, which returns an object's identity value, which is what will allow us to implement value type semantics to go with the "===" comparison operator. For normal objects, it just returns the memory address of the object; I put this in place. Next us is to override it in the value types, and then the "===" operator can be added. This is probably fairly low hanging fruit for anyone who fancies digging into Rakudo some, by the way.

In other bits, I've applied a patch from Carl Masak during the day, and this evening helped Chris Fields, who has happily implemented transliteration for us and is now working on .match on strings, to debug a rather subtle Rakudo bug. I got to the bottom of what's wrong, but resolution is to be discussed. But hopefully we have one soon and then we can have .match defined on strings - another piece in the S05 puzzle! We've a long way to go yet, but bit by bit, day by day, Rakudo is coming together. And last but not least, I'd like to thank to Vienna.pm for funding my weekly Rakudo day.

Parrot 0.6.4

2008-07-15T11:17:32+00:00

On behalf of the Parrot team, I'm proud to announce Parrot 0.6.4 "St. Vincent Amazon." Parrot is a virtual machine aimed at running dynamic languages.

Parrot 0.6.4 is available via CPAN (soon), or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on our source code repository to get the latest and best Parrot code.

Parrot 0.6.4 News:

- Documentation + removed a lot of old information from the FAQ + improved function level documentation - Configuration + removed the configuration item 'has_gnu_m4' + refactored ICU-detection - Languages + ChitChat - improved the Smalltalk implementation + Pipp - renamed Plumhead to Pipp - support for a lot of builtin functions. - Pipp now uses PHP specific data types. - converted from PCT with TGE to PCT with NQP actions - improvements in the PCT variant by using optok parsing - start of object support + pir - simple assignments work + json - added a PCT-based implementation of JSON parsing + lolcode - improved handling of symbols - added support for block handling - added support for globals + Lua - more tests + Rakudo - updated Range implementation - added enums - added generic type declarations (::T) - added runtime mixing of roles with 'does' and 'but' - added generic type declarations - fixed handling of implicit lexicals ($_, $!, and $/) - fixed implicit method calls on $_ - improved complex math builtins, added Complex - moved many builtins to class Any - declaration of lists of variables now work - improved test infrastructure - 910 additional passing spec tests since last release - more convergence with STD.pm grammar - added named 0-ary parsing and ops - Compilers + PCT: - allowed subroutine and method names to be a PAST tree that produces the name - Improved lexical handling - Tools + pbc_disassemble renamed from disassemble - Implementation + allowed .macro_const in PIR + added the flag :lexid(...) for subroutines + made multiple dispatch work for sub types + fixed garbage collection bug related to the metadata attached to a PMC_EXT structure + added a warning when using deprecated opcodes + simplified the stacks implementation + fixed C++ build + improved closure and lexical support + improved IMCC register allocator + added cache for all runtime-constant strings, reducing memory usage - Miscellaneous + improved OpenGL/GLU/GLUT bindings + added a standard profile for Perl::Critic coding standard testing + added support for smoke testing with Smolder + enabled use of Test::Harness 3.0 if available, but don't require it for 'make test' + added the executable 'parrot_config' to query Parrot configuration

Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next release is 19 Aug 2008.

Enjoy!

HLL Configuration Directives

2008-07-12T16:31:18+00:00

For the first time in a long while I have copious amounts of free time over the weekend. So I decided to look at what I had long considered the most difficult part of mod_parrot: HLL configuration directives. Turns out they're not so hard after all.

What is an HLL configuration directive? Well, consider what you have to do now to declare a Perl 6 response handler (in httpd.conf):

<Location /foo>
  SetHandler parrot-code
  ParrotLanguage perl6
  ParrotHandler My::Handler
</Location>

These directives violate one of the goals of mod_parrot: stay invisible. But with HLL configuration directives, we could have something like this:

<Location /foo>
  SetHandler perl6-code
  Perl6ResponseHandler My::Handler
</Location>

This makes configuration much simpler, more familiar to current mod_perl developers, and completely hides mod_parrot from view.

One Apache module implements this functionality, and that's mod_perl2, where you can add custom Apache directives from your modules. I did a lot of research on how this is accomplished, and it's actually quite simple:

Write a thunking layer for the various configuration signatures to pass configuration info from Apache to the HLL
Create a new Apache module dynamically at runtime
Create a command_rec structure containing your directives and pointers to the thunking layer
Associate the command_rec with the new module
Register the module with Apache

Of course the actual implementation is the difficult part, but today I was able to write a simple proof-of-concept. It creates a new module at runtime and adds a directive that writes to the error log when it's encountered in the configuration. Hard part done!

What's next? I have to refactor everything I've done to make it extensible and callable from Parrot. Then I can write the PIR interface for HLLs to add their directives. And if I'm careful about the design, modules like mod_perl6 will be able to reuse the interface to add directives for their own handlers, like mod_perl2 does today. My goal is to have this in a usable state by OSCON. My fingers are crossed!

Enums and the "but" operator

2008-07-10T23:19:33+00:00

This week's Rakudo day (Tuesday was catching up last week's) came around and this time I worked on some more high level, visible stuff. A while ago I quickly implemented the anonymous enum constructor, which essentially is a hash constructor on steroids. This week I got a lot of progress in on the (rather more advanced) named enums. This means that you can now write things like:

enum Day <Mon Tue Wed Thu Fri Sat Sun>; say Mon; # 0 - the underlying value say Day::Wed; # 2 - the underlying value

Notice how the names lie under the Day namespace, but are also imported into the current namespace too (and if you have an enum from some external library in the future, and you import that, the same thing will happen). There are some subtleties relating to symbol collisions that we aren't handling yet (we need a type name registry in Rakudo first). You can also use pairs to set the starting values or the values at any point in the enum too, as with the anonymous ones. A cool thing is that we evaluate the list at compile time to get the set of values, and then can construct the role/class and so forth at compile time too, rather than having to work that all out at runtime.

One of the trickier bits of enums is working out what they actually are. You are in fact introducing a role named Day in the above example, and that means you can mix it into anything else using "does" or "but". The "but" keywords a like "does", but it knows how to take one member of an enumeration and generalize it to the enumeration role, then mix than it. Additionally, it operates on a copy of the original value rather than being destructive. So we can do things like:

enum Maybe <No Yes>; my $x = 0 but Yes; say $x; # 0 say $x.Maybe; # 1, since it's Yes say $x.No; # 0, because $x.Maybe is not 0 say $x.Yes; # 1, because $x.Maybe is 1

Note here that .No and .Yes return true only if .Maybe (the property, which you can also assign to) matches that value.

enum Maybe <No Yes>; my $x = 0 but No; say $x; # 0 say $x.Maybe; # 0, since it's No say $x.No; # 1, because $x.Maybe is 0 say $x.Yes; # 0, because $x.Maybe is not 1

Note that you can use the "but" operator whenever you would use "does" but want a copy of the value operated on rather than the original (the expression as a whole evaluates to the copy that had the mixin applied). The "but" operator actually is implemented in terms of the "does" operator under the hood.

Also note that "0 but True" doesn't quite work yet, or at least isn't affecting the outcome of if statements. This isn't a problem in the enumerations implementation, but rather seems an inconsistency in the spec. Hopefully a mail to perl6-language will get that cleared up - I'll write it tomorrow, when I've got some sleep.

In other minor happenings today, I found and fixed a segfault in Parrot, helped trace a couple of other Parrot issues and fixed the Rakudo "does" operator bug where it lost the association with the proto-object in the modified object. Yesterday, I had some quite long and detailed discussions with both Larry and Patrick over signatures. I think we've got the spec side of things, where it wasn't completely clear before, worked out. However, we still have some details of the implementation left to completely work out (basically, issues about how data-ish and how procedural-ish signatures really are). I'm hopeful we can resolve these in the next week, so I've got a good base to start building the Perl 6 MMD implementation on top of.

As usual, thanks to Vienna.pm for funding my Rakudo hacking.

Signature Objects

2008-07-08T22:57:34+00:00

The first of this week's two Rakudo days (as I catch up from not having one last week) was today, and I dedicated it to working on signature objects. These are something I need to implement MMD, but also come into play in various other situations. For example, if you write something like:

my ($a, $b);

Then this is constructing a signature object on the left hand side, which you can bind to; assignment to it will also work at some point in the future (but not yet). Signatures also appear, of course, on methods and subs, and we've had those working in some form for quite a while in so far as you could pass parameters, get them type-checked and so forth. We weren't constructing real signature objects, however. And to provide the rich information about the signature and the types that an implementation of Perl 6 MMD needs, we need to start constructing them. This will also allow you to introspect the signatures of subs amd methods at runtime (it's not a lot more work to get that in place from what I've got done today).

While a lot of todays work was beneath the surface - actually constructing the signature objects rather than using them - there is some visible stuff. For one, you can now write declarations like this:

my ($a, $b, $c); # declares all three variables class Foo { has ($.x, $!y); } # declare both attributes

Note that you can't do assignment to many things at once just yet - that's part of list assignment. It's high on Patrick's todo list, so we should have that soon. I'll probably get some parts of it in (implementing assignment to the signature) next Rakudo day.

I also implemented the :(...) syntax which parses what is between the parens as a signature and creates a signature object. This works now, though not all signature syntax is parsed yet.

Finally, you can get hold of the constructed Signature object by doing something like &foo.signature, though at the moment you can't do much at all with it. Well, I guess you can "say &foo.signature.WHAT" and see that it's a Signature object. The introspection interface isn't fully specified, but I asked about it on list and Larry provided an idea as to what he expects to see, so I'll use that to guide my implementation.

Signatures can be incredibly powerful; once we get a full implementation, you will be able to unpack trees nodes right there in a signature and all sorts. For now, I just want to get an initial implementation that builds signature objects holding all the information needed to get on with an MMD implementation, though I'm sure things like smart-matching against them and the more advanced features of them will follow in the not too distant future too.

Thanks to Vienna.pm for funding today's work, and also for knowing a really nice Mexican restaurant to go to after their tech meet last night. Good food, good beer, good fun. I like living in a city with a Perl Mongers group, and just an hour down the road from Vienna, which also has a good, active one. :-)

Lexical Fixes

2008-07-02T23:47:30+00:00

First of all, sorry that it has taken me so long to write up last week's Rakudo day. Normally I write the report at the end of the day, but I stayed up debugging and fixing stuff until I was too tired to do anything, but sleep. I'd also been having some insomnia over that week, and had been down with some virus (as in, me personally, not my computer) around the start of last week, so by the time the weekend arrived I just wanted to rest. I'm happy to say that I'm now in much better shape, so there's nothing to worry about. The last couple of days have just been full of catching up with $DAYJOB stuff I couldn't do at the start of last week.

Second, I'm sorry to have nothing much exciting to speak of. Thursday was one of those days spent doing needed stuff rather than fun stuff. Patrick had discovered various issues with Parrot's lexicals implementation that were in the way of making progress on various things in Rakudo. Since getting that right was important in getting some fairly fundemental stuff fixed, and given I have Parrot internals knowledge, I took the day away from doing the cool stuff and focused on these issues. Along the way I fixed at least one other long-standing issue. With some additional contributions from chromatic++ and NotFound++, I think we are now free of the issues that were blocking things.

One of the issues I solved was that methods were unable to see lexicals in enclosing scopes. That is now resolved at a Parrot level, and Patrick did the changes in PCT too and thus it should be resolved in Rakudo. The more serious issue was that outer scopes weren't being identified uniquely enough in the emitted code. This was mostly seriously an issue for multi-subs, but also could be exposed when multiple namespaces were used in one file (a common occurence). This is now resolved.

I also started laying the foundations for getting us to be able to identify Subs, Blocks and Methods as different types, and having somewhere to attach signatures. I'm not completely there with this just yet, and have an uncommitted patch that does some work on this (there is checked in some initial work on it too that sort of works, but not entirely). Getting signatures attached is working towards mutli-method dispatch, which I will be working on this month.

This week I'm overseeing the launch of a fairly big project for one of my clients, and won't get a good day's peace this week for Rakudo hacking. So, rather than having a Rakudo day this week where I keep getting distracted, I'll push it to next week and have two then. I will also be working on the MMD grant this month, so after the slow start to the month this week I will be working on Rakudo two days a week throughout the rest of the month and probably into August too. I will also be at YAPC::Europe::2008.

Welcoming Pipp

2008-07-02T15:26:03+00:00

The PHP on Parrot implementation used to be called Plumhead, after the Plum-Headed Parakeet. As this name is somewhat goofy, a new name was sought. Some more or less sane variants were discussed, http://www.perlfoundation.org/parrot/index.cgi?plumhead_renaming.

And the winner is Pipp.

Thanks to Christoph Otto for getting this rolling.

Where's the goal line?

2008-07-01T16:41:33+00:00

From a comment on rakudo.org:

dstar said:
One thing I'm not clear on -- Rakudo is passing 1100 tests out of how many? IE, where's the goal line?

Well, the "goal line" is by definition a moving target. There's not a hard number we can cite -- even in Perl 5 the size of the test suite constantly changes as new features are added and new bugs are found. There will be a point at which we declare a particular set of tests as being the "official test suite" for Perl 6.0.0, but we're really not close to that point yet. Here's what I can say about the test suite thus far:

The "official test suite" is being built from the test suite that was created for Pugs -- the Pugs test suite has approximately 19,000 tests in it. But, the Pugs suite itself was somewhat disorganized and thus difficult to determine test coverage. It also has many tests that are incorrect, either because the language specification has changed since they were written or because they were incorrect in the original.

Thus, Adrian Kreher (mentored by Moritz Lenz and Jerry Gay) is in the process of conducting a complete review and reorganization of the Pugs test suite into the "official test suite", or what we call the "spectests" (in t/spec/ of the Pugs repository). We estimate that about 5,000 (25%-30%) of the tests in Pugs have been reviewed and migrated into t/spec/. And just because a test appears in t/spec/ doesn't mean it's necessarily correct -- we continue to find places where the test doesn't exactly match the language specification (or the language specification is ambiguous and needs clarification in the test).

Within the 5,000 or so spectests, there's a subset of 75 test files (~1,500 tests) that have been identified as the "spectest regression suite" for Rakudo. These are test files that we expect Rakudo to pass at any given moment in time, such that someone can do "make spectest_regression" and get back "All tests successful." The developers also use this to make sure that any changes to Rakudo don't break existing functionality. Of course, the spectest_regression suite is itself a rapidly moving target as Rakudo acquires more features and as the test suite evolves. For example, at the beginning of June there were 52 files (892 tests) in the spectest regression suite, today (July 1) we have 75 files (1522 tests) in the regression suite.

And beyond all of this have been comments from Larry and others that eventually the official test suite will likely be double or triple the current size of the Pugs suite -- I think I've heard estimates of 40,000-50,000 tests in the suite when we're "finished".

So, return to the original question of "Where's the goal line?", you can see that there's not really a straightforward answer. This is why I haven't been saying things like "passing 1100 out of N tests", because the exact value of N depends on what's being measured to depend on what one considers important, and until more of the official test suite is ready any useful N doesn't really correspond to the "goal line" of a released Perl 6. So, the number I tend to focus on at the moment is the absolute rate of increase in passing tests -- currently it's about 100 new passing tests per week. I expect that trend to continue or improve in the coming months. As long as the number of passing tests is increasing, we're making progress.

An obvious intermediate goal is to have Rakudo passing at least the tests in the Pugs test suite. This depends not only on Rakudo development progress, but also progress in reviewing the Pugs tests and migrating them into t/spec/ . This is also why the Perl 6 developers are constantly inviting and encouraging people to help with building and reviewing the test suite. As mentioned above, only about 25%-30% of the Pugs test suite has made it into t/spec/, and many of those have been simply moved into t/spec/ without significant review or verification against the Synopses. Once we have most of the Pugs test suite migrated to t/spec/ I'll probably start reporting passing tests relative to the size of overall suite. (But I'll also continue reporting the passing rate increase as well.)

Lastly, this is a good place for me to repeat an invitation I made at YAPC::NA: For those who are interested in helping with the test suite but don't know where to start, I suggest "adopting" a particular Perl 6 feature or Synopsis section and saying "I'm going to develop the tests for that feature." This doesn't require learning all of Perl 6, it only requires learning those parts of Perl 6 that are necessary for testing that particular feature. It also gives a sense of ownership for a part of Perl 6, as in "I did that part of the test suite".

I'll undoubtedly add more information about Perl 6 testing in the near future, as it's an area where many hands can help make light work.

Thanks to dstar for asking the question that prompted this post. :-)

Rakudo (Perl 6 on Parrot) progress report

2008-07-01T04:59:40+00:00

This is the third "monthly" report for my development grant from the Mozilla Foundation and The Perl Foundation. As regular readers will have surmised by now, the definition of "month" has been stretched a bit for a variety of reasons, but as this report and the other reports will show, it's not been a hindrance to our progress.

To review, the primary goals of this grant are:

To have a Perl 6 on Parrot implementation that supports commonly-used Perl 6 constructs;
Improvements to the Perl 6 test suite;
To substantially complete the Parrot Compiler Toolkit, including documentation;
Increased community participation in Perl 6 and Parrot development, including development efforts on other languages utilizing Parrot and the Parrot Compiler Toolkit.

It's now clear that the work under this grant has been (or otherwise shortly will be) successful in meeting all of the above goals. As before, in this report I'll highlight the major events and milestones that have been reached since the previous report, and let my other article postings provide increased details.

Progress, April 2008 to June 2008

* Of course, one of the biggest news items is that in May 2008 The Perl Foundation received a $200,000 philanthropic donation from Ian Hague, roughly half of which will be used to support further development of Perl 6 and to build upon the work performed under this grant.

* In addition, Jonathan Worthington received a grant from Vienna.pm to continue his work on developing Rakudo; this grant led to implementations of type checking, multimethod dispatch, regex and grammar support, public and private methods, Ranges, scalar variables, runtime role composition, enums, and a lot more.

* During this period we continued to improve the documentation for the Rakudo (Perl 6 on Parrot) compiler, although more focus in this area is definitely needed. In April we published a list of Rakudo milestones as a basic "road map" to guide continued development. We also generated numerous articles and blog postings that describe the various features of the compiler and how it's all being put together.

* In May we started measuring progress on Rakudo by the number of passing tests from the official test suite. As of June 30, Rakudo Perl is passing 1126 tests from the official test suite, and we're averaging 100 new passing tests per week. I'm hoping this trend will continue.

* To facilitate development Moritz Lenz and Jerry Gay refactored the test harness to provide a "make spectest_regression" target. Now Rakudo developers can verify that changes to the compiler are not breaking any tests that were previously passing. Based on this we're able to to maintain a spectest-progress file, and Moritz created an excellent utility to display the progress as a graph:

http://www.pmichaud.com/perl6/rakudo-tests-2008-06-30.png

* Work on refactoring, improving, and updating the Perl 6 test suite is being handled by Adrian Kreher, Moritz Lenz, and Jerry Gay under a Google Summer of Code grant, along with test contributions and suggestions from many others. We now have a better process in place for reviewing and updating tests; this has enabled progress in other areas to also proceed more rapidly.

* Many of the basic Perl 6 statement types and constructs are now in place -- the primary notable exception being list assignment and lazy list operations. Implementing list assignment properly will require some modifications to the underlying grammar engine -- that work is expected to occur later this summer. Lazy lists and operators are awaiting some improvements to Parrot's exception subsystem (expected in early July).

* The Parrot Compiler Toolkit (PCT) and Not Quite Perl (NQP) tools developed in the first months of this grant continues to demonstrate its power and effectiveness. Most of the HLL translators for Parrot have either adopted or are planning to using PCT/NQP for their underlying code generation. In particular, both the Ruby and PHP implementations (Cardinal and Plumhead) have made significant progress by using the Parrot compiler tools. PCT now has support for basic "return" control exceptions -- other types of control exceptions will be added shortly.

* We continue to gather more active contributors to Parrot and Rakudo Perl. There has been a substantial increase in patch submissions -- so much so that we've held discussions about how we might improve our ability to respond to code contributions more quickly. I've given presentations about the recent improvements at FOSDEM 2008, The Texas Open Source Symposium, DFW Perl Mongers, and YAPC::NA 2008. Each of these presentations have increased participation and enthusiasm about Rakudo Perl and Parrot. More presentations about the project will be made at OSCON 2008 and YAPC::Europe 2008.

* At YAPC::NA 2008 Jim Keenan, Will Coleda, and others on the Parrot team organized a "Perl 6 and Parrot Workshop", in which we helped approximately 20 people download and build Parrot and Rakudo Perl and run through the basic test suite. This has further increased interest in the project; indeed, some of the participants came across some bugs (and filed bug reports and/or patches), and many are planning to hold similar workshops in their local user groups. We plan to repeat the workshop at other venues, including the Pittsburgh Perl Workshop, YAPC::EU, and likely other workshops and user groups.

* All of the "specific tasks" targeted in the end of the last grant report have been achieved.

Where things are headed next

The goal for the next few weeks will be to continue (and perhaps improve) the excellent development momentum achieved during the past couple of months. In particular, we will continue improving the test suite and Rakudo's ability to pass tests from the suite. In addition, as some new Parrot features become available (e.g., improved exception and lexical variable handling) we will be able to take advantage of them in the compilers and compiler toolkits. We will also begin identifying the specific individuals and tasks to be engaged under grants from the Ian Hague donation.

Specific tasks for the remainder of this grant:

Continue improving the official test suite
Develop a more complete implementation of Perl 6's exception model
Implement basic lazy lists and operators
More refactoring of basic operators, functions, and classes according to recent changes in the language specification
Allow compiler and builtin library components to be written in Perl 6
Continue convergence efforts with other Perl 6 implementations
Write the final grant report, documenting the work performed, quantifying results achieved, and outlining the next phases of development

As things stand today, I expect to publish the final report for this grant sometime around OSCON 2008 (July 2008). Of course, I will continue to post articles at use.perl, rakudo.org, and parrotblog.org.

Thanks for reading!