2.2 Parrot Development
Parrot development is the productive
Organization of the Parrot project is lightweight but efficient. It's a meritocracy ”people who make
2.2.1 Development Cycles
The cycles in Parrot development center on "point releases." A point release is a version change, such as 0.0.8 to 0.0.9. The pumpking decides when point releases happen and what features are included. Usually one or two solid new features trigger a release.
Development proceeds at a steady pace of bug
Typically, a few days before a release the pumpking declares a feature freeze and all development efforts center on bug squashing. This periodic cleanup is one of the most valuable aspects of a release.
2.2.2 Getting Involved
Just like design work, the first step to participating in Parrot development is joining the list. The topics on p6i tend to stick to practical matters: bug reports, patches, notifications of changes committed to CVS, and questions on coding style. Occasionally there are discussions about how to implement a particular feature. In general, if you have a question about syntax or a speculation about whether Perl 6 should support a particular feature, that question belongs on the language list rather than the internals list.
184.108.40.206 Use the source
The second step to participating in Parrot development is to get a copy of the source code. If you just want to try it out ”experiment with a few features and see how it feels ”you're probably best off downloading a tarball. For the most stable copy, grab the latest point release from CPAN. The sure way to get the most recent release is to search on http://search.cpan.org for "parrot" in "Distributions." If you want something a little more cutting edge than the packaged release, a new snapshot of the CVS repository is created every eight hours. The most recent snapshot is always available at http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz.
If you plan to get involved in development, you'll want to check out the source from the CVS repository.
cvs -d :pserver:email@example.com:/cvs/public login cvs -d :pserver:firstname.lastname@example.org:/cvs/public checkout parrot
There's also a web interface for viewing files in the repository at http://cvs.perl.org/cvsweb/parrot/.
Now that you've got the source, take a moment to look around. The code changes constantly, so a detailed description of every file is
The most important top-level directory is docs/ . The content isn't always up to date, but it is a good place to start. parrot.pod provides a quick overview of what is in each documentation file.
The languages/ directory contains the code that implements various language compilers: Perl 6, as well as Python, Ruby, Scheme, Befunge, BASIC, etc. Most are in various stages of partial completion. If you have a language you're particularly interested to see implemented on Parrot, you might take a peek to see how far along it is.
The lib/ directory contains Perl 5 classes currently used in developing Parrot. The classes/ directory contains the C source code for Parrot classes (PMCs, which you'll read more about in Chapter 6). examples/ contains some example Parrot assembler code, as well as benchmarks.
For instructions on building Parrot, see Chapter 6.
220.127.116.11 Patch submission
Parrot development is a continuous stream of patches. Patches are the currency of exchange in the project ”the unit of work. They fix
While anyone is free to submit a patch, a small number of people have access to commit changes to the CVS repository. This system works well. It means the project can harness the efforts of a large group, but still keep the same high quality as a small
Every submitted patch is automatically forwarded to the p6i list where it's subject to peer review. Patches spark little debate. Parrot developers
Submitting a patch is
First off, create your patches from a checked-out CVS repository, not from a tarball, so your diff is running against the latest version of the files. Then, make sure the paths listed in the patch match those in the repository. There are two
diff -u parrot/README parrot_changed/README
Either method is fine, and both are equally common on p6i. Your working style and the types of changes you make ”small and modular versus large and sweeping ”will influence which method you choose.
make clean perl Configure.pl make make test
Then consider the people who will review and apply your patch, and try to make their jobs easier. Patch filenames should be as descriptive as possible: fix_readme_typo.patch is better than README.patch . An attached file is better than a diff pasted into an email, because it can be applied without manual editing. The conventional extension for patch files is .patch .
In the email message, always start the subject with "[PATCH]", and make the subject as clear as possible: "[PATCH]
Here is a good example of a patch submission using the CVS diff method (an actual patch from p6i). It's short, sticks to the point, and clearly expresses the problem and the solution. The patch filename and the subject of the message are both descriptive:
Subject: [PATCH] Pointers in List_chunk not initialized From: Bruce Gray On Win32, these tests are segfaulting due to invalid pointers in List_chunk structs: t/op/string.t 97-98 t/pmc/intlist.t 3-4 t/pmc/pmc.t 80 The problem is caused by list.c/allocate_chunk not initializing the pointers. This patch corrects the problem. -- Hope this helps, Bruce Gray
With the attached file list_chunk_initialize.patch :
Index: list.c = == == == == == == == == == == == == == == == == == == == == RCS file: /cvs/public/parrot/list.c,v retrieving revision 1.23 diff -u -r1.23 list.c --- list.c 27 Dec 2002 09:33:11 -0000 1.23 +++ list.c 28 Dec 2002 03:37:35 -0000 @@ -187,6 +187,10 @@ Parrot_block_GC(interpreter); chunk = (List_chunk *)new_bufferlike_header(interpreter, sizeof(*chunk)); chunk->items = items; + chunk->n_chunks = 0; + chunk->n_items = 0; + chunk->next = NULL; + chunk->prev = NULL; Parrot_allocate_zeroed(interpreter, (Buffer *)chunk, size); Parrot_unblock_DOD(interpreter); Parrot_unblock_GC(interpreter);
18.104.22.168 Bug tracking
Bug reports go to the same address as patch submissions (email@example.com). Similar conventions apply: make the subject and the message as clear and descriptive as possible. There's no set convention on subject lines, but you can't go wrong starting off with something like "[BUG]" or "[P6C BUG]" to make it immediately obvious what the message is about.
If you want to track a bug or patch you've submitted, the current queue of bugs and patches is