Howdy,
> 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). > Since the current Parrot frontend uses Winxed [0], that seems a bit overkill. I have no problems with removing our elderly and bitrotten fork of nqp, but I consider Winxed as one of the shinier parts of Parrot and would be very -1 to seeing it leave core. Duke [0] frontend/parrot2/prt0.winxed > 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 > > -- Jonathan "Duke" Leto <jonat...@leto.net> Leto Labs LLC http://labs.leto.net 209.691.DUKE http://dukeleto.pl
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
