On Thu Jun 05 22:21:47 2008, coke wrote: > On Sun Jul 29 18:21:48 2007, [EMAIL PROTECTED] wrote: [snip] > > > > 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 > > The only reference I see to its use is in the book. It appears to be > run by a user once you > have built parrot so you can see what PMCs 'inherit' from each other. > > I would tend to recommend removing it. > >
Well, I figured we could salvage the code by moving it to a more appropriate location. So I moved print_tree() out of Parrot::Pmc2c::Pmc2cMain and into a subclass, Parrot::Pmc2c::PMC::PrintTree, which inherits from Parrot::Pmc2c::Pmc2cMain. Similarly, I eliminated the --tree option from tools/build/pmc2c.pl and moved its functionality to a new program, tools/dev/pmctree.pl -- the presumption here being that this is a Parrot developer's tool rather than something to be invoked by 'make'. And that meant that one of the build tools tests had to be moved to a different test file as well. Please let me know if this poses any problems. I'll do some POD touch-ups and resolve the ticket over the next few days. Thank you very much. kid51
