RFC: Move build tools to Perl5, developer tools to Perl6

Gerd Pokorra gp at zimt.uni-siegen.de
Thu Feb 21 06:25:59 UTC 2013

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.devel at 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

More information about the parrot-dev mailing list