Re: Digest module and Q:PIR blocks

[Cosimo Streppone]

On Wed, 09 Jun 2010 03:52:03 +0200, Will Coleda <w...@coleda.com> wrote:

Here's my best guess:

sub test (Str $test) {
    my $result = Q:PIR {

# This loads into the /current/ HLL, but should probably load into

        # the /parrot/ HLL.
        load_bytecode 'Digest/MD5.pbc'
        .local pmc md5sum, md5hex, test
        md5sum = get_root_global ['parrot'; 'Digest'], '_md5sum'
        md5hex = get_root_global ['parrot'; 'Digest'], '_md5hex'
        test = find_lex '$test'
        %r = md5sum(test)
        %r = md5hex(%r)
    };
    return $result;
}

test('hi');

... but this also fails with the 'signature' issue - note that Digest
doesn't have anything called 'signature'

I think this is related to the recent dynop issues - recent changes in
parrot moved a lot of opcodes into dynamic opcode libraries - stepping
through this, it dies in the invocation of the 'rot' opcode, which is
recently moved to the dynamic 'bit' ops. I'm guessing that when this
is invoked, it's actually invoking some perl6 opcode and going south.

Once this bug is fixed (it's related to loading opcode libraries in a
different order in the perl6 and Digest PBCs), this should work.

Can I do something to help with this fix?

Patrick, should we have (maybe we have already?) a test
script in the sanity tests to catch these regressions?

--
Cosimo