Slash Boxes
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 ]

particle (3326)

  (email not shown publicly)

Journal of particle (3326)

Tuesday November 18, 2008
04:54 PM

Parrot Developer Summit 2008 Recap

Much of my volunteer time over the past few weeks has been devoted to the organization of Parrot Foundation's first Parrot Developer Summit, which took place this past weekend in Mountain View, CA. Our primary objective was to write a roadmap to the release of Parrot 1.0 and beyond. Secondary objectives included review and discussion on support and release policies, updates on parrot subsystems and milestones, review of Parrot Foundation topics, and knowledge transfer between attendees.

To achieve these goals, we brought together Parrot Foundation directors, core Parrot developers and high-level language designers to spent two days in conference. During the meetings we used a number of agile techniques, and achieved amazing results. You can find our vision outlined in chromatic's journal, and further discussed in this parrot-dev mailing list thread.

Notably, a roadmap for Parrot has been made available on the wiki, which will be updated as work progresses. This roadmap is a detailed and organized description of tasks which must be completed to achieve our goals, and it serves as an excellent place to judge the Parrot team's progress against release milestones. This document is a first for Parrot, and I hope it shows the maturity of the project team, and our commitment to meeting our published milestones. It allows our contributors to focus on the tasks remaining, and is an invaluable communication tool for the community.

Without the sponsorship of our advisory board members, the facilites provided by Google, and the support of the Parrot Foundation membership, this summit would not have been possible. Thanks all for your contributions, enthusiasm, and support.


Friday February 01, 2008
02:51 PM

[rakudo] new perl6doc executable

i want very much for rakudo to feel like perl, as soon as possible. therefore, i've been concentrating on adding command-line options and utilities that perl programmers expect. yesterday, i added a first approximation of 'perl6doc'.

view the patch here:

it's far from complete. however, it should provide a start to folks interested in hacking the POD grammar. jeff horwitz would like to work on a pod2html mod_parrot handler. what would you like to see? we need your help.

you can create a perl6doc from a parrot working copy with the following commands, after compiling parrot:

    cd languages/perl6 && cd src/utils && make perl6doc
    # that's probably 'perl6doc.exe' if you're on windows

try running it on some of the files under languages/perl6. see what you find. ask questions. fix what's broken. get involved!

related links:

Synopsis 26 - Documentation:

Perl6::Perldoc on CPAN:

Saturday January 12, 2008
01:56 PM

[perl6]: implement evaluation of one-liners

since my previous commit enabled one-liners for all compilers based on PCT, this extremely simple commit adds '-e' to the list of switches that perl6 allows, and documents the switch syntax in the help message.

view the patch here:

so begins the age of the perl6 JAPH.

01:54 PM

[pct]: implement one-liners for compilers

since evaluating one-liners is a popular option for compilers, i've implemented it in the Parrot Compiler Toolkit.

view the patch here:

the first difference adds '-e' as a valid command line option.

the next set of differences refactors argument processing out of the 'command_line' method into its own method, 'process_args'. this should allow greater flexibility for compilers based on PCT::HLLCompiler.

the last two differences process the '-e' option: if the option was set, the 'eval' method is called to process the line of code that was passed.

Friday January 11, 2008
04:29 PM

Perl 6 Test Suite Refactor - new compiler directives

in my last journal entry, i described the file and directory naming for the official Perl 6 specification tests. this will make it easier for Perl 6 implementors to find tests related to the pieces of the compiler under construction, and will encourage what i like to call "specification-driven development" -- write the spec first, then the tests, then the implementation.

here i'll address a critical bit of infrastructure necessary to write a test suite destined to be run by multiple implementations. since the various implementations of Perl 6 will be sharing the same test suite, we can't mark tests that are todo or should be skipped as done in a typical CPAN module. each implementation will need to classify its own set of failing tests that should be skipped or marked todo. here's a list of our guiding principles:

~ the skip/todo classification should be as close to the test as possible.
    we'd like to avoid a situation where there's one big file that has a list
    of skip/todo. this is fragile, because as tests are modified, maintained,
    and refactored, it will be quite difficult to keep this solution working--
    especially across multiple implementations.

~ compilers should recognize only the directives that impact them.
    we need to be sure that kp6 doesn't run directives intended for pugs, etc.

~ the directives may be used for purposes outside the realm of testing.
    although testing Perl 6 is the driving requirement for this solution,
    and we have no other plans for these compiler directives at this time,
    we recognize that it's likely that they'll be useful elsewhere.
    therefore, we're designing it in from the start.

various bits of syntax were offered, but we've settled on the following:

~ compiler directives will look like a comment to all other compilers
    in order to achieve this, we've settled on a prefix of '#'.

~ compiler directives are conditional by design (they're complier-dependent)
    we append a '?' to the prefix to better reflect their conditional nature.

~ a compiler token must be specified
    compilers need a token to know which directives are intended specifically
    for them. we've chosen the compiler name.
    (e.g. 'perl6', 'kp6', or 'pugs')

~ the marker should be visually offset from the body
    purely for humans to make it a little easier to see, we've put a colon (':')
    after the compiler name.

~ any Perl 6 term can follow a compiler directive
    we don't have any need for multi-line directives at the moment,
    so we haven't invented any syntax to support it.

putting it all together, the compiler directives look like this, shown inside a simple test file:

    use Test;
    plan 3;

    #?perl6: todo( 'not yet implemented', 1 );
    #?pugs: todo( 'feature', 3 );
    #?kp6: skip( 'does not parse', 2 );
    ok( 0, 'foo' );
    ok( 1, 'bar' );
    is( 1, 1, 'baz' );

given those directives, perl6 will mark the first test todo, pugs will mark all three tests todo (which should result in two bonus todo tests passing,) and kp6 will skip the first two tests. running these tests will result in all tests passing for each of these three implementations.

i've implemented this compiler directive syntax in the perl6 compiler, as well as these forms of 'todo()' and 'skip()'. i've included links to those commit diffs below.

i'll follow up soon with more information about the forms of 'todo()' and 'skip()' shown above, as well as two new test directives that will take advantage of this compiler syntax to mark blocks of tests.

related links:

Perl 6 Test Suite Refactor - file and directory naming:

perl6 grammar:

[perl6]: support compiler directives with syntax '#?perl6: '

[perl6]: add todo() to

12:47 PM

Perl 6 Test Suite Refactor - file and directory naming

after conversations with larry and patrick, including a mailing list thread linked below, we've decided on a strategy for file and directory naming for the official Perl 6 specification tests currently stored in the pugs repository.

the directory structure looks like this:

            relational.t ...

please note the following:

~ the root directory for all specification tests is 't/spec/'
~ the top level directories under the root are named after the synopsis number
    and the section of the synopsis to which the contained test files correspond
~ top level directories may contain subdirectories
~ test file names reflect the subject being tested

i'll follow up soon with information about migrating tests to this new structure, and about new compiler directives allowing these tests to be used across Perl 6 implementations.

related links:

mailing list thread: 4b8f5/ed748490f030da2f?tvc=1&q=Proposal%3A+refactor+the+test+suite+according+to+ synopsis#ed748490f030da2f

pugs repository tests:

Wednesday January 09, 2008
07:04 PM

[perl6]: implement syntax checking (-c)

similar to previous entries on adding command line options to perl6, here i'm adding a syntax check option, '-c'. in order to do this, i've added a custom syntax checking stage to the compiler stages after the abstract syntax tree has been generated. this ensures that 'BEGIN' and 'CHECK' blocks have been executed before syntax is checked, which matches Perl 5's behavior.

view the patch here:

the first difference takes the attribute values that were previously inherited directly from 'PCT::HLLCompiler' and moves them into 'Perl6::Compiler', so i can modify them. i've added a new stage called 'check_syntax' after the 'past' stage, and added the 'c' option to the list of command line options.

the next difference adds usage text for '-c'.

the last difference implements the 'check_syntax' compiler method. like other compiler stages (found in 'PCT::HLLCompiler', 'check_syntax' has two formal parameters: 'source' is the object that is expected as input, and 'adverbs' is a hash containing options passed in to that compiler stage.

q{ $I0 = adverbs['c'] } tells me if the '-c' option has been passed to perl6. if it hasn't been passed, then return and move on. if '-c' has been passed, then we're checking syntax. now here's a big cheat, because if i've made it to the 'check_syntax' method, i must have generated valid PAST already, which means syntax checks out OK. so, i print out a nice message and exit gracefully. if there has been a parsing error, a previous compiler method ('parse' or 'past') would have complained and displayed the errors with backtrace info to the user.

this isn't quite perfect, but it's a good first approximation--indeed good enough to be useful, and a simple example of adding a compiler stage to a compiler built with PCT.

related links:

PCT::HLLCompiler source:

06:31 PM

[perl6]: subclass PCT::HLLCompiler

as the perl6 compiler grows, it needs more and more customization. in order to make it easier to customize, today i decided that rather than having 'Perl6::Compiler' be an instance of 'PCT::HLLCompiler', it was time to make it a subclass. this was incredibly easy.

view the patch here:

previously all the initialization code in perl6.pir ran during library load. a 'PCT::HLLCompiler' object was created, attribute values were assigned, etc. now, we'll generate a subclass at library load time, and inside the 'init' method of the subclass we'll deal with attribute assignment and the like.

the first difference is in the 'onload' subroutine. i load the 'Protomaker' bytecode, which allows me to work with parrot protoobjects. first, i get the 'Protomaker' protoobject and stash it in the virtual register $P0. next, i get the 'PCT::HLLCompiler' class, and then i call the 'new_subclass' method on Protomaker to create a new subclass of 'PCT::HLLCompiler' named 'Perl6::Compiler'. that ends the 'onload' subroutine, and initialization continues in the 'init' vtable method.

in the next differences, there are two things going on. firstly, i remove the call to create a new PCT::HLLCompiler, since 'Perl6::Compiler' is now a subclass. secondly, inside parrot methods 'self' is automatically defined, so the remaining differences are simply to replace the virtual register '$P0' with the keyword 'self'.

Saturday January 05, 2008
07:49 PM

[perl6]: implement usage message (-h, --help)

my last entry ( described how i added support to the Parrot Compiler Toolkit to support a '--help' command line option for compilers. my next commit enables this option for perl6.

view the patch here:

since i laid the foundation for implementing usage messages in PCT, it was easy to customize it for perl6. i'll walk through it briefly.

the first difference is in the 'onload' subroutine, which is run when the perl6 bytecode is loaded by parrot. after a new HLLCompiler object has been created, i create a new String PMC using a parrot heredoc containing the help text for the command line options specific to perl6. since @larry hasn't written S19, the synopsis on the perl 6 command line interface, these options are likely to change.

the second difference implements the 'usage' method that HLLCompiler calls when the '-h' or '--help' option is passed. if an argument is not passed for the optional parameter 'name', it is defaulted to 'perl6'. a usage message is printed containing the contents of 'name' and the '$usage' attribute of the HLLCompiler object as set above, and the program exits.

based on the techniques i've used to implement '--help', it should be straightforward to implement similar command line options for the perl6 compiler.

related links:

perl 6 synopses:

05:03 PM

[pct]: implement usage messages for compilers

there are certain features that many compilers share, and one of them is a command line interface. andy lester has started entering tickets for perl 6 features in the perl6 request tracker, and after thinking about implementing this for perl6, patrick and i decided that many compilers will want this functionality, so it makes sense to make it available in the Parrot Compiler Toolkit (PCT) HLLCompiler object.

the HLLCompiler object provides an interface for common high-level language compiler tasks. it allows you to implement a command line interface, compile from a file, and gives you an interactive compiler mode which evaluates standard input one line at a time.

HLLCompiler also allows you to set the transformation stages used to produce something executable from your source code. for perl6, that's source code -> parse tree -> abstract syntax tree (PAST) -> object syntax tree (POST) -> parrot intermediate representation (PIR). PIR is fed to parrot's intermediate code compiler (IMCC) to be executed. HLLCompiler's 'compile' method sets the process in motion.

although HLLCompiler offers a generic method for compilers invoked from command line, there are some options common to most compilers (indeed most programs) that would be helpful to add; '--help' is one of these options, and the subject of this patch.

view the patch here:

this patch does four basic things: refactors a hardcoded list of command line arguments into an attribute; adds an attribute containing usage text; handles processing of the '--help' option; and adds a usage method called from '--help'.

the first difference in the report adds two attributes to the HLLCompiler object, '@cmdoptions' and '$usage'. the names of the attributes are listed in a space separated string, which is an argument to parrot's 'split' operator. 'split' returns a PMC of type 'ResizableStringArray', which is stored in a virtual register named $P1. the list of attributes in $P1 is flattened and passed to the 'new_subclass' method of a 'Protomaker' object, which generates a parrot protoobject of type 'PCT::HLLCompiler' that includes a list of attributes with the names passed in. all this occurs when the HLLCompiler bytecode is loaded.

the next difference is in HLLCompiler's 'init' vtable function (and method), which is executed when a HLLCompiler protoobject's 'new' method is called. here, i've added values to the new attributes, '@cmdoptions' and '$usage'. '@cmdoptions' contains an array of command line options in getopts syntax. '$usage' contains a text prelude, followed by a header for the options section, and then a list of the command line options in '@cmdoptions' appended one per line.

the third difference removes the previously hardcoded list of command line options passed to the getopts object (via parrot's 'push' opcode), and replaces it with code that gets the array from '@cmdoptions' and passes each item in the array iteratively.

the fourth and fifth differences appear in the 'command_line' method of HLLCompiler, and process the '-h' or '--help' command line options. if either option is found via getopts and stored in the 'adverbs' hash, the 'usage' method is called, passing the program name (stored in the register named 'arg0'.)

the sixth and final difference defines the new 'usage' method. 'usage' takes an optional parameter which prints it's value if passed. then 'usage' prints the contents of the '$usage' attribute stored in HLLCompiler, and exits.

so, this patch provides a simple (however ugly) help text for any compiler implemented with the PCT, and allows these compilers to override the default behavior and implement a customized (and hopefully more useful) help message.

related links:

perl6 request tracker:'perl6'

submit requests to the perl6 request tracker by mail:

parrot object model design document (PDD15):