I would suggest two general principles in regards to the "normal execution" runcores:
1) Any runcore which isn't portable won't likely be used for external applications like embedding apps, fakecutables, etc. Since Parrot is not really intended to be used by itself (instead it supports applications further up the chain) a runcore which isn't used by applications on Parrot won't be used almost at all. 2) Any runcore which is not used by default will not be properly tested or maintained. These two principles in mind I suggest we cut the CGoto, CGP, Switch, and Slow runcores. Actually, it may be worthwhile to do some serious benchmarking to see whether Switch or Fast runcore is faster. This is likely to be platform dependent, so maybe we keep both and add a system to intelligently pick one or the other depending on compiler and CPU. As for the special-purpose runcores, I think the Trace, Profiling, and GCDebug cores all have significant value to developers and power users, so they are fine to keep. The Bounds runcore can probably go. --Andrew Whitworth On Tue, Apr 13, 2010 at 6:12 PM, Allison Randal <[email protected]> wrote: > One of the topics raised in the virtual developer summit and today's > #parrotsketch was the possibility of deprecating some of our current runcore > options. > > Opening the floor for discussion, which runcores would people like to keep, > which can we safely drop? > > Allison > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
