Proposal for using NQP-rx

Andrew Whitworth wknight8111 at
Mon Nov 2 13:34:05 UTC 2009

I think what I would really like to see is some sort of overview of
what NQP-RX is, and what it does, that's different from our current
NQP. I've heard that it improves regular expressions, but I don't know
anything more specific than that. Assuming there are no regressions on
functionality, and only a series of improvements, I'm generally in
favor of this.

The one thing I do worry about is the proposed timing. It seems like a
week before the release isn't enough time if we have a major breakage
somewhere and NQP needs to be updated again. What this would do,
essentially, is enact a de facto feature freeze on changes that might
affect NQP the week before every release. I'm not saying this is a bad
thing, just pointing it out.

--Andrew Whitworth

On Sun, Nov 1, 2009 at 1:18 AM, Jonathan Leto <jaleto at> wrote:
> Howdy,
> I would like to propose that we upgrade NQP in Parrot core to NQP-rx
> [0]. I have talked with pmichaud++ about this, and he is all for it.
> Rakudo devs say that they would love to see NQP-rx in Parrot core as
> soon as we are comfortable doing it. Of course, we need to consider
> our deprecation policy. If there are no regressions, then the
> deprecation policy does not come into effect, right? How does the
> Parrot deprecation policy effect NQP? If we drop NQP-rx in as a
> replacement, and "make fulltest" passes, as well as the entire Plumage
> configure+build+test, I would call that "No detectable regressions."
> We may want to test a few NQP-heavy HLL's, but I digress.
> Currently parrot installs plain old NQP as a parrot_nqp binary. The
> new NQP-rx installs itself as an 'nqp' binary. All we need to do is
> point our paths at the nqp binary and use that.
> Proposal: If the 'nqp' binary exists, prefer using that over
> 'parrot_nqp' in all Parrot core that uses NQP. We obviously need
> Configure-support for this.
> pmichaud++ prefers to keep NQP-rx as an external dependency, so
> merging into Parrot core directly is not an option. He said that he is
> fine with NQP-rx being used as an git submodule, for when we migrate
> to git, or pulled into our current svn repo in some way. It uses the
> Artistic License 2. He mentioned that he plans to release NQP-rx each
> month the week before the Parrot monthly release.
> Duke
> [0]
> --
> Jonathan Leto
> jonathan at
> _______________________________________________

More information about the parrot-dev mailing list