Can I say again that I think it's cheating that python has tests directly in
t/ , so leo notices breakage there sooner? =-)
Attached is a patch that allows "(cd languages/tcl && make test)" to work
again. Looks like an unguarded access in MRO. Didn't self apply so Leo could
poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl.
> Can I say again that I think it's cheating that python has tests directly in
> t/ , so leo notices breakage there sooner? =-)
Feel free to cheat and append tcl tests to "make test".
> Attached is a patch that allows "(cd languages/tcl && make test)" to work
> again. Looks like an unguarded access in MRO. Didn't self apply so Leo could
> poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl.
Hhm. Why does that PMC type (which one) not have a vtable?
leo
> Attached is a patch that allows "(cd languages/tcl && make test)" to work
> again. Looks like an unguarded access in MRO. Didn't self apply so Leo could
> poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl.
The C<TclObject> is defined as an abstract class, i.e. it has no VTABLE.
Per convention, such abstract classes should be lower case.
Is there a specific reason that it's an abstract PMC?
I tried to get rid of "abstract noinit" in that PMC, which produced
these failing tests:
cmd_break.t 1 256 2 1 50.00% 2
cmd_continue.t 1 256 2 1 50.00% 2
cmd_linsert.t 4 1024 5 4 80.00% 1 3-5
cmd_string.t 6 1536 35 6 17.14% 26-27 29-31 34
leo
Committed the change to tclobject, removed my local hack to src/pmc.c, passes 100% now.
Regards.
> Switching tclobject seems to work fine here. I suspect you might have
> something else going on.
I don't have any diffs WRT CVS. Strange.
leo