If parrot should be trimmed down and pge and tge should removed than the file runtime/parrot/library/Tcl/Glob.pir is the first that has to been rewritten. It is the last thing in a chain that depend on PGE. Should it be rewritten with parrot-nqp or with the HLL API?
-- Gerd Am Freitag, den 15.02.2013, 10:26 -0500 schrieb Will Coleda: > My plans for the sixparrot branch currently include: switching build > steps that rely on parrot-nqp and winxed back to their original perl5 > scripts (if possible), and removing pge, tge, and parrot-nqp. > > > It's possible I may end up keeping winxed, but killing parrot-nqp is > definitely on the list (and I don't intend to replace it with current > nqp). > > > I'm not sure what dev tools you're referring to. NQP isn't using much > of anything once parrot itself is built that isn't already used by > parrot. (e.g. ops2c); I still plan on supporting conversion of .ops > to .c without having to have anything other than current parrot deps > installed (e.g. perl5 is fair game, but not perl6). > > > > > > > On Fri, Feb 15, 2013 at 6:45 AM, Gerhard R. > <gerd.r.de...@googlemail.com> wrote: > Howdy. > > Right now, the toolchain is written in a mix of Perl5, PIR, > NQP and > Winxed. I don't think I need to elaborate why this is not an > ideal > situation. > > I propose moving build tools to Perl5 and developer tools to > Perl6, > where a build tool is a program that gets run when an end-user > checks > out the codebase and wants to install Rakudo, whereas a > developer tool > only needs to be run after changes to the codebase have been > made. > > The most immediate concern would be ops2c. It is run during > the build > process to parse dynop definitions and according to policy the > old P5 > implementation should be resurrected. > > However, I don't see a problem with moving it to the dev tools > category and porting the NQP-rx codebase to P6: Right now, the > generated files for core ops are checked-in, and I believe > this could > be done for dynops as well. > > Rakudo devs should weigh in here as it would affect their > development > process as well (a P6 ops2c would need to be run after dynop > changes > instead of as a part of regular builds), but I believe the > benefits > would be worth this hopefully minor inconvenience (dynops > change > rarely, correct?). > > So why choose P6 instead of NQP as the implementation language > for dev > tools? Because NQP is not the user-facing product - P6 is. I'm > not > aware of any policy governing the stability of NQP, and the > migration > from NQP-rx to NQP would be a case in point. > > Thoughts? > > -- gerdr > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > > > > > -- > Will "Coke" Coleda > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
