Re: GC problem in OrderedHash?

[Bob Rogers]

   From: chromatic <[EMAIL PROTECTED]>
   Date: Mon, 12 Nov 2007 13:58:51 -0800

   . . .

   If someone reading this (not just Bob or me) cares to write up some basic 
   tests and can make a failure case, I'm very happy to debug and fix the 
   problem.  I'm out of town for a couple of days and may not get to the tests 
   for a while, but I will fix the problem unless someone beats me to it.

Does this fit the bill?  This fails reliably on my laptop (SUSE 10.1,
gcc 4.1.0) using Parrot r22785 or r22817, but works on my desktop (SUSE
9.0, gcc 3.3.1, also r22817), so who knows what kind of mileage you'll
get?  Also, it doesn't match the original problem description for a
number of reasons, not least of which is that it doesn't require either
PIR file to be compiled.  But, unless I'm doing something really stupid,
there is still a bug here, on which is at least similar if not the same.

   The way HLL directives work with PBC is that each Parrot interpreter keeps a 
   PMC around to map HLL information and types . . .

   I didn't see any good freeze/thaw tests for any of our PMCs, and the code in 
   OrderedHash looked a little weird, so that's why I think there's at least 
one 
   bug lurking there.

   -- c

Thanks for the beta.  Freeze/thaw testing sounds like it will require
another Parrot::Test API function . . .

                                        -- Bob


## .HLL 'any', ''

.namespace ['FOO-BAR']

.sub test_fn
        print "test_fn\n"
.end

.sub main :main
        load_bytecode 'hll-dumper-test.pir'
        $P40 = get_hll_global ['FOO-BAR'], "hll_dumper_test"
        $P40()
        print "Done.\n"
.end

## .HLL 'any', ''

.namespace ['FOO-BAR']

.sub hll_dumper_test
        $P40 = get_hll_global ['FOO-BAR'], "test_fn"
        $P40()
        $P0 = new 'FixedPMCArray'
        $P0 = 5
.end