How I came to contribute to Perl 6

[kyle]

This is the story of how I came to be a Perl 6 contributor—not a major contributor, but a contributor nonetheless. My message of hope to monks the world over is this: You too can contribute to Perl 6! You may think yourself insufficiently awesome, but I disagree. You too can contribute to Perl 6! Let me tell you how I did it so as to make your own path clear.

Background

The Perl 6 project has several parts you may have heard of.

• The Pugs repository (http://www.pugscode.org/) is a Subversion repo containing the official Perl 6 spec, the test suite that confirms a particular implementation conforms to the spec, Pugs (one of those implementations) and other stuff.
• Parrot (http://www.parrot.org/) is a virtual machine designed to run dynamic language (including Perl 6).
• Rakudo (http://www.rakudo.org/) is an implementation of Perl 6 on Parrot.

Before I go on, I should mention that I decided early on that I would help with testing. In Getting Involved with Perl 6 - 2009, moritz suggests that this is a good way to get involved. You may consider my story here a demonstration of that assertion.

Step 1: Get a commit bit

I showed up on the #perl6 of irc.freenode.org one day and asked for a commit bit for the Pugs repository. Within 15 minutes TimToady had asked me for my email address and preferred svn nick. I got an email to finish the process, and that was it. The traditional first commit is to add one's name to the AUTHORS file to confirm access, which I did.

Step 2: Look for something to do.

This is actually easy.

The go-to place for ideas is spec/TODO. In it you'll find:

• A list of changes to the spec which require corresponding changes to the spec tests.
• A list of areas that still need tests, broken down by spec section.
• More general tasks for the entire test suite.

There is a lot to do! Not only that, there are things to do that require very little expertise. The first thing I did was convert some old style deprecated testing code into its more accepted analog. This was a very mechanical search and replace style of operation.

Step 3: Join mailing lists

The next thing I did was join the perl6-language and perl6-compiler lists. From one of those I started receiving bug reports that were going into the RT queue.

Low hanging fruit!

I had a look through the perl6 queue in RT at Perl.org. I've always thought that every bug one finds should have a test that shows its presence or absence. With this in mind, I set about testing the bugs in the queue.

This is easy because code is provided. Whoever wrote the bug included code and their expectations for it. It's straight forward to convert that code to tests. The hardest part, usually, is to figure out where to put the test. Whenever I have time, I can go browsing for a bug, see if I can find a test for it, and write one if there isn't one. (If there is a test, I note that in the ticket before moving on.)

Step 4: Settling in

A lot of the "action" is on the IRC channel. There are robots there for sending a message to someone who's not present. There's a robot there that will pass Perl 6 code to different implementations and report the results. Most importantly, there are people who know more than I do about the topic at hand.

The people on IRC are very monk-like in their patience and helpfulness. In particular, moritz has offered me testing wisdom on many occasions. I've learned things like:

• DDT is great, but we usually don't use it because not every Perl 6 is ready for it (so tests fail for unrelated reasons), and it's hard to "fudge" for different implementations of Perl 6.
• It's better to write "ok $x ~~ undef, ..." than "is $x, undef, ..." because the latter causes a warning, and sometimes $x.defined doesn't work.
• git-svn is goodness.

My only word of warning is that when the spec is not clear on some subject, the members of the IRC channel are not always more clear. More than once I have asked questions and found the (many) answers even more perplexing. A question along the lines of "what should this code do" can lead to a design discussion and dizziness.

Step 5: ?

Step 6: Profit!

It's been almost a month since I got that commit bit in "Step 1". I've learned a lot about Perl 6 and semi-related topics in that time, and I've been able to add a little bit to the effort to bring the next Perl into the world. You can too!

[Limbic~Region]

kyle,
My only word of warning is that when the spec is not clear on some subject, the members of the IRC channel are not always more clear.

I would like to point out, that these very questions are what help bring the perl 6 specification closer to Christmas. While you may not personally benefit immediately from the mind twisting discussion that follows, the net result to everyone in the end is benificial. If the spec isn't clear or hasn't been thought through it may not be obvious to the folks that are eating this stuff for breakfast (forest for the trees).

Here are two more ways you can contribute to perl 6.

First, write perl 6 code. Every time valid perl 6 code is written that doesn't work because of unimplemented features or because of bugs, a Rakudo (and presumably other implementations) ticket can be written. Rakudo hackers like to fix bugs and implement features that make users like you happy and their programs run. Seriously.

Second, help write perl 6. Wait a minute, isn't that what you said first? Not exactly. Rakudo is the perl 6 implementation on Parrot. Like any self-respecting language that will hopefully bootstrap itself, it wants to write as much of itself in itself as it can. Rakudo has gotten to the point where you don't really need to know how to code for Parrot in order to hack on Rakudo. There are still places where writing in PIR (parrot not perl 6) is helpful but you can pick what you want to work on. If there is some feature not yet implemented (built-in functions would probably be easiest) that you want to see - go ahead and write it (pmichaud is always looking for help). See steps to create a patch and http://rakudo.org/ for more details.

[moritz]

I have to agree with Limbic~Region - we do try to give helpful answers if the answer is already specced and/or well understood. As it is the nature with evolving languages that's not always the case.

If there is some feature not yet implemented (built-in functions would probably be easiest) that you want to see - go ahead and write it

I'd like to point out that (since June 25th) you can also implement operators in Perl 6 in Rakudo, with only marginally more effort. To get the right precedence and associativity you should still register it in src/parser/grammar-oper.pg, but the actual implementation can be done in pure Perl 6.

[JSchmitz]

When I read the first line of this post I thought it was a Kevin Raymer special! = ) cheers -