Will Coleda wrote: > > In Parrot_integer_multi_cmp_DEFAULT, invoked with two TclInts, the > original code: > > const INTVAL selfint = SELF.get_integer(); > > seems to always set selfint to be 0, so the cmp is always -1, so islt > is always true. Changing that line to: > > const INTVAL selfint = VTABLE_get_integer(INTERP, SELF); > > to mirror the following valueint line causes the problem to go away, > and tcl's test suite continues past this test with no problem. > > While the updated version is passed through to the .c with no changes, > the original version is converted to: > > pmc->real_self->vtable->get_integer(interp, pmc->real_self); > > This change has no impact on t/pmc/integer.t, though I didn't run the > full test suite against it. > > Thoughts?
Well, that's just plain wrong. 'SELF.get_integer()' should do exactly the same thing as 'VTABLE_get_integer(INTERP, SELF)'. I don't know when it was edited to do otherwise, but I've fixed it now. (I actually fixed it by deleting a few lines of code, because it was immediately followed by a few lines that did the right thing, which were never called because the 'SELF.other_method()' syntactic sugar was already transformed to the wrong thing. Which makes me suspect that the problem was an artifact of an incomplete change or bad merge on the PMC branch a while back. That's when we ripped out most of the real_self hackery.) It looks like t/cmd_expr.t is getting a float-ish value where it expects an int-ish value (which could be a multi dispatch to the wrong variant). The failure in t/cmd_lsort.t appears to be unrelated to MMD (is that something you reported elsewhere? it seems familiar). Otherwise, all Tcl tests pass. Thanks for the report, Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
