Andrew Whitworth wrote: > Very interesting, all. However, I have two questions: > > 1) What's the benefit to passing around all these C function pointers > (which, I notice, aren't properly parsed in ATTR definitions yet),
Yeah, aren't they beautiful? I can't actually use the typedefs for the attr types either, because the typedef lines don't show up in the autogenerated header file. I created TT #544 for pmc2c naivety and will get back to that stuff later. > above creating a subclass of ManagedStruct to use > executable-code-specific clone() and destroy() methods? Asked a > different way, how many different configurations do we forsee having, > and are they enough to justify tacking this kind of ability onto the > ManagedStruct PMC? Apparently, yes. I think chromatic wants to make this stuff generally available to NCI bindings, and possibly other places. Please see http://irclog.perlgeek.de/parrot/2009-04-07#i_1045352 for the (rather disorganized, spread out and entangled) design discussion. > 2) Is ManagedStruct really the best thing to be holding JIT-related > code pages? I can think of other jobs that a real JITBuffer PMC could > be used for eventually besides simply holding, cloning, and freeing > code pages. I've no idea. At the time, we looked at ManagedStruct (which has the benefit of being what nci jit was already using), CPointer, subclasses of those, and entirely new PMCs. It's also possible to argue against the complexity of ManagedStruct directly: http://irclog.perlgeek.de/parrot/2009-04-07#i_1045886 So I dunno. I've done a fair amount of work on this, but I'm certainly still open to ideas. :) Mark _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
