I applied a bandaid to this wound today in r20318, but the patient still
needs to be referred to a specialist.
The "deep recursion" noted in the error message came from this code in
lib/Parrot/Pmc2c/Pmc2cMain.pm:
for my $f (@files) {
my $class = $self->read_dump($f);
print " " x $depth, $class->{name}, "\n";
for my $k ( @{ $class->parents } ) {
$self->print_tree(
{
depth => $depth + 1,
files => [ lc("$k.pmc") ],
}
);
}
}
In the case that failed yesterday, $class->{name} was always 'default'.
But, for reasons that are unclear, 'default' was also an element of @{
$class->parents }. So there was never a limiting case to the inner call
to print_tree(). I applied the patch attached, which wraps the inner
call to print_tree() with an 'unless ($k eq $class->{name})' test.
While this stopped the hemorrhaging, it's not a cure. The point at
which the error occurred was basically unchanged from when this package
was called Parrot::Pmc2c::Utils and was only slightly changed from when
it was all in pmc2c.pl. The real question is how 'default' became its
own parent.
Side Note:
All of the above having been said, I think what I wrote as a Comment in
the POD for this method back in December is still valid:
"The purpose of this method is unclear. (1) It is not called by
Makefile. (2) Since internally calls read_dump(), a .dump file must
already exist for this method to generate meaningful output. But since
.dump files do not exist prior to calling make, this can only be viewed
as an attempt at a utility method to be called after make has run. That
might be useful. It would be responding to a request such as, "Given
these .dump files, reconstruct the inheritance trees of their ancestral
.pmc files." But that's a very different purpose from the other methods
in this program, whose point is to go from .pmc to .c
files."
Does anyone actually use Parrot::Pmc2c:Pmc2cMain::print_tree()?
kid51
