I brought this up at this week's #ps, but I wanted to make sure there were no objections.
Bacek wants my GSoC branch either merged into trunk or moved to an external project. He was probably concerned about having to wait for my branch to merge trunk whenever any change occured in trunk that PIRATE needs. I know Moritz has been bitten by this when he's been working on testing optimizations for Rakudo using my branch, as well. At #ps, particle raised concerns about merging a GSoC branch into a supported release halfway through GSoC. Allison and Whiteknight both seemed to prefer moving it to its own repository, as do I. Whiteknight suggested it be include in ext/ for 2.6. I don't have an opinion on that. If that is done, however, it should definitely be marked experimental. The API is still not totally stable, and its capabilities are still changing as I learn better what is useful in such a project. I'm going to begin working on extracting my project to an external repository(probably on github), using distutils.pbc for a build system, today. If all goes well and no one objects, I plan to do the rest of my development of it in the git repo instead of in the gsoc_past_optimization branch of Parrot's subversion repository. Once this is done, it will be able to be installed without any Parrot. I'll also speak to japhb about getting its metadata into Plumage to make it even more convenient to install. -- Tyler Curtis _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
