<div dir="ltr">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.<div><br>
</div><div style>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).</div><div style><br></div><div style>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).</div>
<div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 15, 2013 at 6:45 AM, Gerhard R. <span dir="ltr"><<a href="mailto:gerd.r.devel@googlemail.com" target="_blank">gerd.r.devel@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Howdy.<br>
<br>
Right now, the toolchain is written in a mix of Perl5, PIR, NQP and<br>
Winxed. I don't think I need to elaborate why this is not an ideal<br>
situation.<br>
<br>
I propose moving build tools to Perl5 and developer tools to Perl6,<br>
where a build tool is a program that gets run when an end-user checks<br>
out the codebase and wants to install Rakudo, whereas a developer tool<br>
only needs to be run after changes to the codebase have been made.<br>
<br>
The most immediate concern would be ops2c. It is run during the build<br>
process to parse dynop definitions and according to policy the old P5<br>
implementation should be resurrected.<br>
<br>
However, I don't see a problem with moving it to the dev tools<br>
category and porting the NQP-rx codebase to P6: Right now, the<br>
generated files for core ops are checked-in, and I believe this could<br>
be done for dynops as well.<br>
<br>
Rakudo devs should weigh in here as it would affect their development<br>
process as well (a P6 ops2c would need to be run after dynop changes<br>
instead of as a part of regular builds), but I believe the benefits<br>
would be worth this hopefully minor inconvenience (dynops change<br>
rarely, correct?).<br>
<br>
So why choose P6 instead of NQP as the implementation language for dev<br>
tools? Because NQP is not the user-facing product - P6 is. I'm not<br>
aware of any policy governing the stability of NQP, and the migration<br>
from NQP-rx to NQP would be a case in point.<br>
<br>
Thoughts?<br>
<br>
-- gerdr<br>
_______________________________________________<br>
<a href="http://lists.parrot.org/mailman/listinfo/parrot-dev" target="_blank">http://lists.parrot.org/mailman/listinfo/parrot-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Will "Coke" Coleda
</div>