[PROPOSAL] include nqp-rx PIR files in Parrot core distribution

Sat Oct 31 16:07:32 UTC 2009

Howdy,

On Fri, Oct 30, 2009 at 11:04 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> Several people are asking about the possibility of making
> the nqp-rx libraries and new NQP compiler available in the
> core Parrot distribution.  Generally I think doing this will
> make things much easier for HLL developers, but I can also
> envision that we might want to treat it entirely as an
> external library.

I am of the opinion that if NQP-rx has no detectable regressions, i.e.
we can drop it in Parrot core right now and our entire test suite
passes, then we should.

I am the author of the first pure-Parrot test harness, which currently
lives in the Plumage repo [0]. Another great test would be to see
if Plumage still passes it's entire test suite while using NQP-rx. I
suspect it will or come close to it. Testing it on a few other HLL's
which heavily use NQP would also be a great idea. Can you make public
some simple instructions for HLL developers and Parrot developers
about how to test their code with the new NQP-rx? That would quickly
get us the data we need.

[snip]

>
> * At this time I don't have any intent to merge the full
>  nqp-rx source code repository into the Parrot source repository.
>  Parrot may of course choose to incorporate nqp-rx sources via the
>  Artistic License, but for the foreseeable I view NQP's mainline
>  development as being outside of the Parrot repo.

I am not quite sure why it is that you want to keep them separate. Can
you describe to us what factors contributed to your decision to be a
separate repo? I can understand the fact that Rakudo/NQP-rx use git
and Parrot is in subversion, so that you would be forced to use
multiple VCS's and it would generally make life slightly more
complicated for you. If Parrot where using Git, we would use the
canonical NQP repo as a git submodule, which can be pegged to a
certain revision, and save many, many human hours of fighting software
instead of writing it. Parrot will definitely revisit the issue of
converting to git after the 2.0 release, but I digress.

[snip]

>
> Fortunately, including all of these components as part of Parrot
> can be fairly straightforward.  Inside the nqp-rx repository,
> each of the four .pbc libraries above are compiled from a
> generated .pir file that has no dependencies beyond what
> already exists in Parrot.
>

This is great to hear!

> So, my proposal would be to periodically grab copies
> of the generated .pir files from the nqp-rx repo into a
> compilers/nqp-rx/ directory in Parrot, and add commands to
> Parrot's build subsystem to compile the .pirs to .pbcs and
> install them in the appropriate directories.  (nqp.pbc would
> likely be installed as nqp-rx.pbc for a time, to avoid conflicts
> with the existing nqp.pbc.)
>
> We can also include copies of nqp-rx's test suite into the Parrot
> repository, so that NQP and Parrot developers can determine
> that changes to NQP and/or Parrot aren't causing regressions
> for end-users.
>
> Parrot can control the timing of NQP updates into its
> repository, consistent with Parrot's release and support
> policies.  There's no need for it to keep up with NQP's
> bleeding edge.  That said, based on our recent experience with
> nqp-rx I don't foresee NQP as having a significant bleeding
> edge or issues with backwards compatibility.  Earlier today
> Jonathan was able to switch Rakudo from using the old NQP
> to the new one with only very minor (and easily documented)
> changes to Rakudo's existing code base.  It turns out that
> nqp-rx is surprisingly compatible with what went before.
> And again, as mentioned above, I'm not proposing that we
> immediately replace the existing PCT/PGE/NQP libraries,
> but rather to live in parallel for a while to give HLL
> developers an opportunity to migrate to the new toolset
> at whatever pace works best for them.
>
> I will note that the new toolset is significantly improved
> over what we have now, with more improvements to come
> (especially performance).  So I expect HLL and library developers
> to migrate to the new toolset quickly.

>From the point of view of a Parrot core developer and an HLL/Plumage
developer, we want your new stuff! It rocks!

>
> If Parrot core chooses not to ship with the nqp base libraries,
> then it essentially means that every installation will need
> a mechanism to obtain the libraries from the nqp-rx repo or
> some other source.  I grant that in the general case packagers
> can do the work of managing and bundling the needed library
> .pbcs, but for HLL and library developers it's much more
> straightforward if there's already versions of the files
> directly available from the Parrot repo.

Although Plumage could help people easily install NQP-rx as a "better"
replacement for a standard NQP, this does not seem to be the optimal
solution in this case. The optimal solution is that NQP-rx becomes
part of Parrot core, because it is a better replacement for the NQP
that we have now.

I will of course volunteer my time to add more coverage to the NQP-rx
test suite if someone can point me in the right direction.

>
> If I hear general approval for this proposal, I'll quickly
> incorporate nqp-rx into the Parrot repository (this is
> fairly straightforward and not at all complicated).  If
> there's general rejection of the proposal, then we'll
> start building tools for independently downloading, installing,
> and maintaining appropriate NQP versions in a parrot installation
> (this is quite a bit more complex, which is why I'm writing
> this in hopes of avoiding the complexity).

Can we have the new NQP-rx in Parrot core, pretty please?

>
> Comments and questions welcomed, and thanks!

As always, you have produced solid, amazing work in a short time. pmichaud++

>
> Pm
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

Duke

-- 

Jonathan Leto
jonathan at leto.net
http://leto.net