Howdy,<br><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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></blockquote><div><br>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.<br>
<br>Duke <br><br>[0] frontend/parrot2/prt0.winxed<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div>
<div>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><br></div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><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></div></div><span class="HOEnZb"><font color="#888888">-- <br>Will "Coke" Coleda
</font></span></div>
<br>_______________________________________________<br>
<a href="http://lists.parrot.org/mailman/listinfo/parrot-dev" target="_blank">http://lists.parrot.org/mailman/listinfo/parrot-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Jonathan "Duke" Leto <<a href="mailto:jonathan@leto.net" target="_blank">jonathan@leto.net</a>><br>Leto Labs LLC <a href="http://labs.leto.net" target="_blank">http://labs.leto.net</a><br>
209.691.DUKE <a href="http://dukeleto.pl" target="_blank">http://dukeleto.pl</a>