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

Sat Feb 23 11:59:23 UTC 2013

Hello.

In the nutshell you are explaining that NQP can't be implemented in NQP.
Sorry, but "bootstrap problem" was already solved. Checking in of generated
C code is equivalent of checking in PIR.

Bacek.
On 23 Feb 2013 15:07, "Christoph Otto" <christoph at mksig.org> wrote:

> **
> The ops2c-necromancy branch reminds me why we felt the way we did about
> ops2c.  Nobody could accuse it of being an elegant or smart tool.  A proper
> compiler based on NQP or Rakudo would generally be preferable but there are
> a few factors that make it less attractive.
>
> The big one is that modern NQP has a non-trivial setting.  Code can't just
> be compiled down to PIR or pbc and treated as a standalone fakecutable that
> links against libparrot.so .  If NQP has to be installed and working before
> Parrot, NQP or Rakudo's ops can be bootstrapped, everyone's toolchain
> becomes much more brittle.  NQP's ops have been changed in 16 commits so
> far this month and pm has stated that we should not assume that
> NQP/Rakudo's ops will remain relatively static.  The ops compiler needs to
> be a tool that works no matter what state the user's system is in.  P5 is a
> better foundation for that purpose because we can safely assume that it's
> installed and working, whether the system it's on has an ancient installed
> Parrot, a broken NQP or no Parrot at all.
>
> The goals are to reduce dependence on a dead-end tool (NQP-rx) and to
> provide a robust ops preprocessor.
>
> Yes, we could decide on a stable-ish NQP version, check in NQP.pir, all of
> NQP's stage 2 PIR and its post-processed dynops (and hope that they're for
> the right Parrot version), then integrate them with our build, then make
> sure that they worked correctly both from Parrot's build and install
> directories, then make sure that they didn't conflict with upstream NQP or
> ancient NQP-rx when installed
> ("/usr/local/bin/parrot-nqp-but-not-the-old-one-that-we-already-install-called-parrot-nqp"?),
> then make sure that they were regularly updated, then the deal with
> upstream NQP changes that break parrot-nqp-not-rx, then subscribe to the
> advil of the month club.  I'd rather not go down that path and it's not
> immediately clear that it'd be in Parrot's interest to even accept such a
> patch, given that we're in a do or die regarding performance.  I'm not
> entirely adverse to leaving opsc as part of the build since ripping it out
> won't lead to an immediate performance gain, but moving to NQP proper isn't
> a good option.
>
> Working on opsc was great but it was a misstep to depend on NQP-rx at the
> time.  It's unfortunate, but progress at this point does mean moving in the
> opposite direction.
>
> Christoph
>
>
> On Fri, Feb 22, 2013, at 4:16, Vasily Chekalkin wrote:
>
> Hello.
>
> Moving opsc back to perl5 is the biggest mistake you can make. Upgrade
> opsc to modern nqp is the way.
>
> Keywords: JIT, compile-time optimisations, PBC emitting, kill PIR with
> fire.
>
> --
> Bacek
>
>
> On Fri, Feb 22, 2013 at 3:11 PM, Christoph Otto <christoph at mksig.org>wrote:
>
>> On Thu, Feb 21, 2013, at 20:02, Brian Gernhardt wrote:
>>  >
>>  > On Feb 21, 2013, at 10:04 PM, Jimmy Zhuo <jimmy.zhuo at gmail.com> wrote:
>>  >
>>  > > Well, the original front is not written by PIR, it's by C.
>>  >
>>  > And whiteknight rewrote it in Winxed because it was clearer and faster.
>>  >
>>  >
>> http://whiteknight.github.com/2011/01/20/parrot_in_parrot_new_frontend.html
>>  > http://whiteknight.github.com/2011/08/08/frontend_parrot2.html
>>  > http://irclog.perlgeek.de/parrot/2011-08-19#i_4300881
>>  >
>>  >
>>  > I don't think the frontend is _the_ reason to keep Winxed around.  The
>>  > reason to keep it in core is so that I never have to write a single
>> line
>>  > of PIR again.
>>  >
>>  > ~~ benabik
>> That's the biggest thing winxed has going for it and the reason why
>>  there's no reason for it to go away.  Its runtime requirements are much
>>  less complicated than full nqp and it can compile code down to (mostly)
>>  standalone PIR.  If you've ever written straight PIR, you'll know why
>>  that's a good thing.  I'm not saying that its use should be expanded,
>>  largely because the path to a Parrot that continues to exist 24 months
>>  from now involves cutting things out rather than adding them, but winxed
>>  isn't hurting anything and could potentially help us later if we're able
>>  to boost Parrot's performance sufficiently.
>>
>>  I'm looking at much of the current work as a warm-up before the main
>>  event.  Ripping out opsc will reduce Parrot's dependence on nqp-rx but
>>  the real speed gain is profiling and optimizing, especially in improving
>>  pcc (as has been mentioned).  Other things are easier to do and
>>  relatively harmless, but only profiling and optimizing for nqp are what
>>  will get Parrot into an attractive state.
>>
>>  Christoph
>>  _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20130223/d6b50b99/attachment.html>