On Wed, May 27, 2009 at 01:46:38PM -0400, Will Coleda wrote: > On Thu, May 21, 2009 at 12:11 AM, Patrick R. Michaud <[email protected]> > wrote: > > I've added the C<root_new> opcode as of r39007. > > When the test program above is rewritten to use C<root_new>, > > it requires ~0.049s on my system regardless of the HLL > > in effect. > > I have noticed that the [namespace children] test (show all the child > namespace of the top level tcl namespace, which is really the top > level 'tcl' namespace in parrot) is now failing. [...] > If I replace the explicit calls to "new 'CodeString'" with "root_new [ > 'parrot'; 'CodeString' ]", then that namespace drops off the list > above. But I can't replace all of these, because I'm not explicitly > instantiating all of these. (i.e. NCI, Sub, MultiSub) > > When did this behavior change? Is it possible that root_new is a just > a bandaid here and we really should make 'new' work the way it used > to?
We still need root_new as an easy way to create PMCs from classes in foreign namespaces -- it's not just a bandaid. And based on many discussions with Allison I'm pretty sure that "new 'CodeString'" from a non-parrot-HLL shouldn't result in a ['parrot';'CodeString'] PMC. The problem you're experiencing seems to be something subtly different. If what you're saying is correct, then at some point in Parrot's past the creation of PMCProxy's wasn't occurring in HLL namespaces other than 'parrot', and one or more of the recent changes to Parrot_oo_get_class() or Parrot_oo_get_class_str() has caused it to start doing that. That needs to be fixed (for the Sub/MultiSub/NCI cases you cite above), regardless of what happens with 'new' and/or 'root_new'. I'll see if I can narrow down the point at which the Parrot behavior seemed to change. Pm _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
