Re: Playing with substr()
jerry gay wrote: On Jan 9, 2008 12:08 AM, Cosimo wrote: So question is: would be useful to "port" the substr() test script from Perl5's `t/op/substr.t' also to Perl6? what we ultimately want is tests that cover the spec, which for 'substr' is probably very close to the perl 5 spec. however, my first suggestion is to look in the pugs test suite for tests that cover substr. here's how i'd start: [...detailed track of tasks to do...] hope that didn't scare you off! :) No, not really :-) It is more or less what I'd have expected to do, but I didn't have such detailed information and urls, so thanks for this. I didn't know of spec.pugscode.org at all. Now I'm allocating some of my sleep time to this. :-) -- Cosimo
[perl #36411] New form of 'setattribute' fails when there are multiple inheritance levels
On Tue Jun 28 07:32:02 2005, [EMAIL PROTECTED] wrote: > The following PIR (attached as "script.pir", and also included here) > fails under Parrot 0.2.1 (Fedora Core 3, Intel x86): > > .sub main @MAIN >$P1 = newclass "PARENT_1" >addattribute $P1, "foo"#1 >$P2 = subclass $P1, "PARENT_2" >addattribute $P2, "foo"#2 >$P3 = subclass $P2, "CHILD" >addattribute $P3, "bar" > >$P0 = new "CHILD" > >$P97 = new .String >set $P97, "Hello from attribute foo" >setattribute $P0, "foo", $P97 #3 > >$P98 = new .String >set $P98, "Hello from attribute bar" >setattribute $P0, "bar", $P98 #4 > >$P99 = getattribute $P0, "foo" #5 >print $P99 >print "\n" >end > .end > > This prints "Hello from attribute bar" when it should print "Hello from > attribute foo". > > The bug disappears if line #4 is commented out, suggesting that > "setattribute foo" (line #3) and "setattribute bar" (line #4) are both > storing into the same slot that is retrieved by "getattribute foo". > > The bug also disappears if either line #1 or line #2 is commented out, > suggesting that this bug is exposed by multiple layers of inheritance. > > Here's the inheritance hierarchy: > >PARENT_1 # adds attribute 'foo' > ^ > | >PARENT_2 # adds attribute 'foo', hiding the inherited one > ^ > | > CHILD# adds attribute 'bar' > > Regards, > Roger Browne This code generates the expected answer now (post 0.5.1), once you change @MAIN to :main. Regards.
Re: [perl #48497] [BUILD] Missing opcodes should be an error
James Keenan via RT wrote: > The build tools tests are intended to be run after someone has made > changes in modules such as lib/Parrot/Pmc2cUtils/, Ops2cUtils and > Ops2pmutils/. They're set up to be run after Configure.pl has completed > but before make has been invoked. (In fact, they will generate errors > if make has completed.) You can run them with any of the following: > > perl Configure.pl --test > > perl Configure.pl --test=build > > make buildtools_tests (following Configure.pl) I've added this information to docs/tests. There was one line in the cage cleaners' guide about it, but that didn't really jump out at me. :) > My hunch is that the test file needs a little tweak to match the change > of behavior introduced by your patch. Can you take a look at revising > that test file? Done! -- Timesharing just doesn't work. -K. Thompson, 1982.
[perl #48497] [BUILD] Missing opcodes should be an error
On Wed Jan 09 06:59:41 2008, [EMAIL PROTECTED] wrote: > Fixed in r24703 Unfortunately, it breaks one of the tests we've put in place for testing the build tools (the various .pl files invoked by 'make'). See attached. The build tools tests are intended to be run after someone has made changes in modules such as lib/Parrot/Pmc2cUtils/, Ops2cUtils and Ops2pmutils/. They're set up to be run after Configure.pl has completed but before make has been invoked. (In fact, they will generate errors if make has completed.) You can run them with any of the following: perl Configure.pl --test perl Configure.pl --test=build make buildtools_tests (following Configure.pl) My hunch is that the test file needs a little tweak to match the change of behavior introduced by your patch. Can you take a look at revising that test file? Thank you very much. kid51 [li11-226:parrot] 503 $ prove -v t/tools/ops2pmutils/08-sort_ops.t t/tools/ops2pmutils/08-sort_ops OK: Parrot top directory located 1..87 ok 1 - use Parrot::Ops2pm::Utils; ok 2 - Positioned at top-level Parrot directory ok 3 - changed to temp directory for testing ok 4 - able to make tempdir/src ok 5 - able to make tempdir/src ok 6 - copied .ops file ok 7 - copied .ops file ok 8 - copied ops.num file ok 9 - copied ops.skip file ok 10 - The object isa Parrot::Ops2pm::Utils ok 11 - prepare_ops() returned successfully ok 12 - 'ops' key has been defined ok 13 - load_op_map_files() completed successfully ok 14 - ops.num located after renumbering ok 15 - ops.skip located after renumbering ok 16 - sort_ops returned successfully ok 17 - changed back to starting directory after testing ok 18 - changed to temp directory for testing ok 19 - able to make tempdir/src ok 20 - able to make tempdir/src ok 21 - copied .ops file ok 22 - copied .ops file ok 23 - copied .ops file ok 24 - copied ops.num file ok 25 - copied ops.skip file ok 26 - The object isa Parrot::Ops2pm::Utils ok 27 - prepare_ops() returned successfully ok 28 - 'ops' key has been defined ok 29 - load_op_map_files() completed successfully ok 30 - ops.num located after renumbering ok 31 - ops.skip located after renumbering ok 32 - sort_ops returned successfully ok 33 - changed back to starting directory after testing ok 34 - changed to temp directory for testing ok 35 - able to make tempdir/src ok 36 - able to make tempdir/src ok 37 - copied .ops file ok 38 - copied .ops file ok 39 - copied .ops file ok 40 - copied ops.num file ok 41 - copied ops.skip file ok 42 - copied DEVELOPING file ok 43 - The object isa Parrot::Ops2pm::Utils ok 44 - prepare_ops() returned successfully ok 45 - 'ops' key has been defined ok 46 - load_op_map_files() completed successfully ok 47 - ops.num located after renumbering ok 48 - ops.skip located after renumbering ok 49 - sort_ops returned successfully ok 50 - Got expected warning about experimental ops ok 51 - changed back to starting directory after testing ok 52 - changed to temp directory for testing ok 53 - able to make tempdir/src ok 54 - able to make tempdir/src ok 55 - copied .ops file ok 56 - copied .ops file ok 57 - copied .ops file ok 58 - copied ops.num file ok 59 - copied ops.skip file ok 60 - copied DEVELOPING file ok 61 - The object isa Parrot::Ops2pm::Utils ok 62 - prepare_ops() returned successfully ok 63 - 'ops' key has been defined ok 64 - load_op_map_files() completed successfully ok 65 - ops.num located after renumbering ok 66 - ops.skip located after renumbering # Looks like you planned 87 tests but only ran 66. # Looks like your test died just after 66. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 67-87 Failed 21/87 tests, 75.86% okay Failed Test Stat Wstat Total Fail List of Failed --- t/tools/ops2pmutils/08-sort_ops.t 255 6528087 42 67-87 Failed 1/1 test scripts. 21/87 subtests failed. Files=1, Tests=87, 1 wallclock secs ( 0.21 cusr + 0.01 csys = 0.22 CPU) Failed 1/1 test programs. 21/87 subtests failed.
Re: the future of testing
# from Rafael Garcia-Suarez # on Wednesday 09 January 2008 05:36: >Allison Randal wrote in perl.perl6.internals : >> In the Python test suite, there's a single global location to >> declare a list of test files that are expected to be skipped on a >> particular platform. This has a much cleaner feel than our own >> motley collection of skip and todo markers in various test files. To me, python code generally tends to *feel* cleaner, but on deeper inspection, usually is limited by failed assumptions. I suspect that you've fallen prey to this same seduction in your perusal of their test suite. There may still be something in it -- I'm just adding salt :-D A global skip/todo config would be nice in that it also provides more metadata about the tests, so e.g. running a targetted cross-section of tests becomes easier. >That assumes that tests are skipped per file, which is not always the >case (sometimes you want to skip only one test, sometimes even to work >around an OS bug that appears only in one specific version). But >reorganizing platform-dependent tests might be a good idea. Agreed. Skipping a subtest is very common. Organization would benefit from them being separated, but duplicated setup code would ensue. If tests were broken into methods within the file, you could have the global config and keep the granularity. The "what is a platform?" issue could also make the categorization messy (when you start involving compiler combinations or what-not.) Perhaps something more declarative can be done by providing standard is_foo() functions to reduce the complexity (and/or increase the readability) of the SKIP/TODO conditionals. So, (syntax aside) given foo.t with methods bar, baz, bort, and bob: t/foo.t is_osx(version: 10.0): skip_all: reason: ... is_osx: skip: bar baz bort is_solaris: todo: baz reason: baz needs love is_win32(with => compiler: msvc): todo: bort --Eric -- software: a hypothetical exercise which happens to compile. --- http://scratchcomputing.com ---
Re: Perl 6 new contributor day
On Sunday 06 January 2008 11:15:25 Andy Lester wrote: > With the new contributor day coming up, I'd like to run an article on > Perlbuzz about it. Can anyone supply me some text? Or point me to a > preferred old text that I can adapt? I'm looking at > http://www.oreillynet.com/onlamp/blog/2007/08/parrot_new_contributor_day_th >i.html which is from August, and doesn't discuss what we'll be focusing on. Let's say: 1) help people build Parrot 2) get test results from new platforms 3) help people build Perl 6 on Parrot 4) fix compilation warnings (C skills) 5) remove deprecated features (grep and diff skills) -- c
[perl #49566] [PATCH] PLATFORMS update, solaris 8, gcc, January 2008
# New Ticket Created by Andy Dougherty # Please include the string: [perl #49566] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=49566 > --- parrot-current/PLATFORMSThu Dec 20 11:15:20 2007 +++ parrot-andy/PLATFORMS Wed Jan 9 13:13:43 2008 @@ -32,7 +32,7 @@ linux-x86_64-gcc4.1.2 8 Y-- Y Y YY ? 20070822 openbsd-zaurus-gcc3.3.5 Y-- Y Y Y? ? 20070309 sol8-sparc-ccB--- - - -Y/13*4 ? 20071218 -sol8-sparc-gcc_4.1.0 B--- - - -Y/36*4 ? 20071218 +sol8-sparc-gcc_4.1.0 B--- - - -Y/171 ? 20080109 sol10-sparc-cc_5.8 BY-- Y Y YY/9 ? 20060807 sol10-sparc-gcc_4.0.2BY-- Y Y YY/9 ? 20060807 sol10-x86-cc_5.9 4 --- - - YY ? 20071010 -- Andy Dougherty [EMAIL PROTECTED]
Re: Playing with substr()
On Jan 9, 2008 12:08 AM, Cosimo Streppone <[EMAIL PROTECTED]> wrote: > I'm trying to play with perl6.exe. > I've wandered in the opened tickets for perl6 and > saw this one about `substr()': > > http://rt.perl.org/rt3/Public/Bug/Display.html?id=44321 > > It ends with a patch that enables the 3rd optional > argument for substr(). I gave it a shot, and it seems to > work. > yay! > So question is: would be useful to "port" the substr() > test script from Perl5's `t/op/substr.t' also to Perl6? > > I have looked at the task, and it's not so straightforward > as it seemed at first sight, but I'd like to volunteer for > that, just to learn something along the way. > > Would that be useful? > > Or if you have other suggestions, maybe for Sat 12th :-) , > I'm willing to do "something" for parrot/perl6. > what we ultimately want is tests that cover the spec, which for 'substr' is probably very close to the perl 5 spec. however, my first suggestion is to look in the pugs test suite for tests that cover substr. here's how i'd start: get perl 6 design documents * svn co http://svn.perl.org/perl6/doc/trunk perl6-doc && cd perl6-doc search for synopses that contain 'substr' * ack substr -al open specs in your browser, so you can see smartlinked pugs tests * http://spec.pugscode.org/ search through specs for 'substr' and look for smartlinks for related tests * /substr & ctrl-g etc in firefox refactor these tests in the pugs repo to match the synopses (for example, look at t/spec/ in the pugs repo) once the tests have been refactored, modify t/fetchspec and config/makefiles/root.in to make sure they're run with 'make spectest' the last few steps aren't well defined, and take a bit of work to get right. if you feel you can't attack that just yet, try to take some existing tests, get them passing (or todo the failing ones) and submit a patch for t/00-parrot. patrick or i will soon write some tutorials on test refactoring in the pugs repo, which is something we really need now, and something that almost anyone can do. hope that didn't scare you off! :) ~jerry
Re: [PATCH] probe for gcc -Wxxx only when gcc (well, g++)
Unfortunately I haven't been able to test the patch, however, icc *should* handle -W flags exactly the same as gcc. And if it doesn't, then there is an issue there we (or Intel) should deal with. So, I would update the patch to ask if we have gcc or icc. I agree that -W doesn't apply to some other compilers, so it's a good idea to restrict the warnings checks to those compilers for which it is meaningful. I don't think that's the case. Yes, I believe there's a compatibility mode with GCC or something, but I try not to use it. I'd like to keep compiler warnings specific to the compiler being used, anyway. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: the future of testing
Allison Randal wrote in perl.perl6.internals : > In the Python test suite, there's a single global location to declare a > list of test files that are expected to be skipped on a particular > platform. This has a much cleaner feel than our own motley collection of > skip and todo markers in various test files. That assumes that tests are skipped per file, which is not always the case (sometimes you want to skip only one test, sometimes even to work around an OS bug that appears only in one specific version). But reorganizing platform-dependent tests might be a good idea. I (mostly on behalf on P5P) would find it interesting to see how that turns out to be implemented in parrot's test suite, so we can blatanly copy the good ideas and avoid the pitfalls :) -- The man does not exist who, outside his own specialty, is not credulous. -- Borges
[perl #49558] [PATCH] Note inter::progs ought to be smarter about finding linker
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #49558]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49558 >
This patch just notes a problem area. In order to pick the correct linker
on platforms where there is more than one possibility (e.g. the vendor's
cc and gcc), Configure.pl needs to know which compiler is being used.
Both solaris.pm and dec_osf.pm (assuming my recent patch is applied)
handle this with a callback -- immediately after $cc is set, they run a
test program to see if $cc is really gcc. Duplicating this callback
code in each hints file seems wrong. Configure really ought to do at
least some of that guessing right away.
(The ? can be filled in with whatever tag RT assigns this.)
diff -r -u parrot-current/config/inter/progs.pm
parrot-andy/config/inter/progs.pm
--- parrot-current/config/inter/progs.pm2008-01-02 08:59:40.0
-0500
+++ parrot-andy/config/inter/progs.pm 2008-01-09 08:55:50.0 -0500
@@ -91,6 +91,15 @@
if $ask;
$conf->data->set( cc => $cc );
+# XXX [RT ? ] Configure should do some intelligent guessing here.
+# Which linker to pick may well depend on the compiler chosen.
+# If the user picks 'gcc', then the linker should probably
+# be either 'gcc' or 'g++'.
+# If the user picks 'cc', then the linker should probably be
+# the associated c++ compiler, known as 'c++', 'CC', or 'cxx',
+# or perhaps something else.
+# Currently, solaris and dec_osf handle this with callbacks.
+#
$link = integrate( $conf->data->get('link'), $conf->options->get('link') );
$link = prompt( "How about your linker?", $link ) if $ask;
$conf->data->set( link => $link );
--
Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] probe for gcc -Wxxx only when gcc (well, g++)
On 09/01/2008, chromatic <[EMAIL PROTECTED]> wrote:
> On Monday 07 January 2008 20:09:26 Jarkko Hietaniemi wrote:
>
> > --- config/auto/warnings.pm.dist 2008-01-08 05:51:42.0 +0200
> > +++ config/auto/warnings.pm 2008-01-08 06:01:23.0 +0200
> > @@ -132,17 +132,22 @@
> > $verbose = $conf->options->get('verbose');
> > print "\n" if $verbose;
> >
> > -# add on some extra warnings if requested
> > -push @potential_warnings, @cage_warnings
> > -if $conf->options->get('cage');
> > -
> > -push @potential_warnings, '-Wlarger-than-4096'
> > -if $conf->options->get('maintainer');
> > -
> > -# now try out our warnings
> > -for my $maybe_warning (@potential_warnings) {
> > -$self->try_warning( $conf, $maybe_warning );
> > +my $gcc = $conf->options->get('gccversion');
> > +
> > +if (defined $gcc) {
> > + # add on some extra warnings if requested
> > + push @potential_warnings, @cage_warnings
> > + if $conf->options->get('cage');
> > +
> > + push @potential_warnings, '-Wlarger-than-4096'
> > + if $conf->options->get('maintainer');
> > +
> > + # now try out our warnings
> > + for my $maybe_warning (@potential_warnings) {
> > + $self->try_warning( $conf, $maybe_warning );
> > + }
> > }
> > +
> > return 1;
> > }
>
> I think you're right, however I'd like to hear how the identity-confused ICC
> handles this patch before we apply it. Paul, how does it look?
Unfortunately I haven't been able to test the patch, however, icc
*should* handle -W flags exactly the same as gcc. And if it doesn't,
then there is an issue there we (or Intel) should deal with. So, I
would update the patch to ask if we have gcc or icc. I agree that -W
doesn't apply to some other compilers, so it's a good idea to restrict
the warnings checks to those compilers for which it is meaningful.
Paul
>
> -- c
>
Re: [PATCH] tru64: hints tweaks
On Wed, 9 Jan 2008, Jarkko Hietaniemi wrote:
> --- config/init/hints/dec_osf.pm.dist 2008-01-09 04:57:50.0 +0200
> +++ config/init/hints/dec_osf.pm 2008-01-09 05:23:23.0 +0200
> @@ -43,8 +45,9 @@
> $conf->data->set( linkflags => $linkflags );
> }
>
> -# Required because of ICU using c++.
> -$conf->data->set( link => "cxx" );
> +unless ( $conf->data->get("gccversion") ) {
> + $conf->data->set( link => "cxx" );
> +}
>
But in the normal flow of things, I thought gccversion wasn't set at the
time when the hints are called. For solaris, I handled that with a
callback trigger, something like the patch below. (But then, I also set
--link=gcc on the command line, so I haven't tested this lately.)
Obviously, every platform shouldn't duplicate this code. (A separate
patch noting that fact is coming up next.)
diff -r -u parrot-current/config/init/hints/dec_osf.pm
parrot-andy/config/init/hints/dec_osf.pm
--- parrot-current/config/init/hints/dec_osf.pm 2008-01-09 08:45:11.0
-0500
+++ parrot-andy/config/init/hints/dec_osf.pm2008-01-09 08:45:37.0
-0500
@@ -39,16 +39,42 @@
}
}
+# Callback to be run as soon as the user selects a compiler.
+# If we're going to be using ICU (or any other C++-compiled library) we
+# need to use the c++ compiler as a linker. As soon as the user
+# selects a compiler, we will run the gccversion test. (If we were to
+# wait till it's normally run, the linker question would have already
+# been asked.)
+my $dec_osf_link_cb = sub {
+use Carp;
+my ( $key, $cc ) = @_;
+my %gnuc;
+my $link = $conf->data->get('link');
+$conf->cc_gen("config/auto/gcc/test_c.in");
+
+# Can't call cc_build since we haven't set all the flags yet.
+# This should suffice for this test.
+my $cc_inc = $conf->data->get('cc_inc');
+Parrot::Configure::Utils::_run_command( "$cc -o test test.c $cc_inc",
+'test.cco', 'test.cco' )
+and confess "C compiler failed (see test.cco)";
+%gnuc = eval $conf->cc_run() or die "Can't run the test program: $!";
+if ( defined $gnuc{__GNUC__} ) {
+$conf->data->set( link => "gcc" ); # Or is it g++ ?
+}
+else {
+$conf->data->set( link => "cxx" );
+}
+$conf->data->deltrigger( "cc", "dec_osf_link" );
+};
+$conf->data->settrigger( "cc", "dec_osf_link", $dec_osf_link_cb );
+
my $linkflags = $conf->data->get('linkflags');
if ( $linkflags !~ /-expect_unresolved/ ) {
$linkflags = "-expect_unresolved '*' -O4 -msym -std $linkflags";
$conf->data->set( linkflags => $linkflags );
}
-unless ( $conf->data->get("gccversion") ) {
- $conf->data->set( link => "cxx" );
-}
-
# Perl 5 hasn't been compiled with this visible.
$conf->data->set( has_socklen_t => 1 );
}
--
Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] tru64: hints tweaks
Jarkko Hietaniemi wrote: --- config/init/hints/dec_osf.pm.dist 2008-01-09 04:57:50.0 +0200 +++ config/init/hints/dec_osf.pm2008-01-09 05:23:23.0 +0200 @@ -14,8 +14,10 @@ Jarkko: Our RT system doesn't pick up new submissions that go (only) to [EMAIL PROTECTED] Could you please submit this patch as an attachment to an email to [EMAIL PROTECTED] That way, it will get an RT number assigned. The original submission will be cc-ed to the list. Thank you very much. Jim Keenan
the future of testing
In the Python test suite, there's a single global location to declare a list of test files that are expected to be skipped on a particular platform. This has a much cleaner feel than our own motley collection of skip and todo markers in various test files. Something to consider after the 1.0 release, as we eliminate the dependency on Perl 5, and move forward to Parrot-native testing tools. Allison
Re: A quick NCI question
Sorry, essentially what I'm asking is if i can pass a pir method as a function pointer on a c call. essentially what I'm looking to do is get into the message pump on windows, and I'm trying to keep all of the code within pir. I'm trying to see how many hoops I need to do in order to write a gui setup using coroutines from pir alone. chromatic wrote: On Monday 07 January 2008 09:22:43 robby wrote: With skimming across the past 400 or so messages on this list I'm not exactly sure if this would be the correct list to post this, but I have a quick question regarding NCI's and callbacks. I've read http://www.parrotcode.org/docs/pdd/pdd16_native_call.htm and nci.t and I haven't came up with the answer off hand, so I may be missing something, or it may not be possible in pir. I have a function I'm wanting to call that is long func(long, long, long, callback) and a callback with a sig (long, long, long, long). While doing callbacks, do I *have* to create a wrapper in C in order to use them? In the draft doc noted above it says "However, many callback functions share a common signature, and parrot provides some ready-made functions for this purpose that should serve for most of the callback uses." But I think I may be taking it out of context. I'm trying to tap into the win32 procs and don't know if I can keep it all in pir (which is the goal, because I'd rather port bytecode than c code across platforms) Am I reading the docs wrong, or is there no functionality to do what I'm looking at? As I understand it, the discussion of callbacks in the docs is about callbacks implemented in PIR. The callback you describe looks like a C function, in which case you should be able to get a pointer to it and pass it as a pointer. Apologies if I misunderstood your question though. -- c
[PATCH] tru64: hints tweaks
--- config/init/hints/dec_osf.pm.dist 2008-01-09 04:57:50.0 +0200
+++ config/init/hints/dec_osf.pm2008-01-09 05:23:23.0 +0200
@@ -14,8 +14,10 @@
if ( $ccflags !~ /-pthread/ ) {
$ccflags .= ' -pthread';
}
+if ( $ccflags !~ /-D_REENTRANT/ ) {
+$ccflags .= ' -D_REENTRANT';
+}
if ( $ccflags !~ /-D_XOPEN_SOURCE=/ ) {
-
# Request all POSIX visible (not automatic for cxx, as it is for cc)
$ccflags .= ' -D_XOPEN_SOURCE=500';
}
@@ -43,8 +45,9 @@
$conf->data->set( linkflags => $linkflags );
}
-# Required because of ICU using c++.
-$conf->data->set( link => "cxx" );
+unless ( $conf->data->get("gccversion") ) {
+ $conf->data->set( link => "cxx" );
+}
# Perl 5 hasn't been compiled with this visible.
$conf->data->set( has_socklen_t => 1 );
Playing with substr()
I'm trying to play with perl6.exe. I've wandered in the opened tickets for perl6 and saw this one about `substr()': http://rt.perl.org/rt3/Public/Bug/Display.html?id=44321 It ends with a patch that enables the 3rd optional argument for substr(). I gave it a shot, and it seems to work. So question is: would be useful to "port" the substr() test script from Perl5's `t/op/substr.t' also to Perl6? I have looked at the task, and it's not so straightforward as it seemed at first sight, but I'd like to volunteer for that, just to learn something along the way. Would that be useful? Or if you have other suggestions, maybe for Sat 12th :-) , I'm willing to do "something" for parrot/perl6. -- Cosimo
