[bug#57491] patch series: Update Raku ecosystem

Hi all,

I am working on updating Guix's version of the compiler/related tools
for the Raku programming language.  The current versions are from March
of 2019, which makes them pretty out-of-date given Raku's monthly
release cadence.

This first patch is for MoarVM (the virtual machine that Raku runs on)
which is a dependency for later packages.  I note that, unfortunately,
the output of this package is currently non-deterministic; however, the
same is true of the 2019 version so that non-determinism isn't a
regression.

This is my first Guix package so I'd welcome any feedback you might
have.  I will follow up shortly with three additional patches that
Guix needs in order to provide an up-to-date Raku compiler.

Thanks in advance!

Best,
Daniel


From 18919edeb7ba1f3e3a18e710a715eec899f1910c Mon Sep 17 00:00:00 2001
Message-Id: <18919edeb7ba1f3e3a18e710a715eec899f1910c.1661876717.git.daniel@codesections.com>
From: Daniel Sockwell <daniel@codesections.com>
Date: Tue, 30 Aug 2022 12:23:21 -0400
Subject: [PATCH] Update moarvm 2019.03->2022.07

---
 gnu/packages/perl6.scm | 88 +++++++++++++++++++++---------------------
 1 file changed, 45 insertions(+), 43 deletions(-)

> -@item Great Unicode support, with strings represented at grapheme level
> +@item Unusually strong Unicode support enabled by strings represented at
> +grapheme level and an embedded copy of the Unicode Character Database

IIUC, this means that previously, it didn't include a copy, and now it 
does? If so, that's bundling, which is to be avoided in Guix such that 
there is only a single copy to keep up-to-date. From (guix)Submitting 
Patches:

>   8. Make sure the package does not use bundled copies of software
>      already available as separate packages.
>
>      Sometimes, packages include copies of the source code of their
>      dependencies as a convenience for users.  However, as a
>      distribution, we want to make sure that such packages end up using
>      the copy we already have in the distribution, if there is one.
>      This improves resource usage (the dependency is built and stored
>      only once), and allows the distribution to make transverse changes
>      such as applying security updates for a given software package in a
>      single place and have them affect the whole system—something that
>      bundled copies prevent.

(If this was already the case in the previous version, that's still bad, 
but then it can be left for later, being independent of this patch.)

I noticed you removed the mention of the garbage collector, is this 
intentional? Seems a useful feature to me ...

On nqp-configure: Are you sure that 'bin' should be installed in 
'.../bin'? Looking at the Git repository, make.nqp does not have a 
shebang and can hence not be directly run, maybe you should add a shebang?

Also, is there appear to be some tests in 't', why aren't they run?  
There is a 'rakudo-build-system', maybe this rakudo-build-system can 
properly build this package (including tests, maybe it even adds a 
shebang for the make.nqp)?

On nqp: why the switch from downloading the source code from the 
apparent official site "rakudo.perl6.org" to GitHub?

> +             (substitute* "t/09-moar/01-profilers.t"
> +               (("ok.*\\$htmlpath" html-test-text)
> +                (string-append "todo \"harness5 fails to write html profile\";"
> +                               html-test-text)))))
What's the issue here? Is it a limitation of the Guix packaging, or 
could it perhaps be an upstream bug? If the latter, upstream needs to be 
informed such that they can fix the bug.

On the new package description: everything in Guix is free software, the 
"open source" is superfluous. The information on who designed it is 
interesting from a historical perspective, but I don't think it is 
useful information for package descriptions. It's getting close to 
marketing phrases (see (guix)Synopses and Descriptions) with 
"prioritizes expressiveness", "optimised for fun" and "superpowers", 
"linguistically inspired" (I mean, doesn't every new language try to 
gain those properties, and how would you objectively-ish verify those 
compared to other languages (ignoring C and assembly and such), and what 
does "linguistically inspired" even mean?).  The other things can stay I 
suppose.

I've noticed the environment variable changed (PERL6LIB -> RAKULIB), but 
(guix build rakudo-build-system) hasn't changed PERL6LIB to RAKULIB.  
Can you verify that our various perl6-... libraries still build, and 
that when doing, say, "guix shell rakudo perl6-json-name -- 
whatever-rakudos-binary-name-is", you can still use perl6-json-name in 
whatever is rakudo's name for a REPL?

You add some patches, but they need to be registered in gnu/local.mk as 
well, please do so.
On the patch file name: it looks a little suspect, perhaps if you run 
the linter on the packages it will have a comment about the file names.

On commit messages: they don't follow our conventions.  Running "git 
log" will result in plenty of examples, also see 
<https://www.gnu.org/prep/standards/html_node/Change-Logs.html>. (They 
tend to be a bit terse, but you can always add additional information to 
them even when not strictly required.)

A new copyright line can also be added.

Greetings,
Maxime.

Thanks so much for the feedback. I've answered a few questions inline 
below and I'll follow up with revised patches in the next few days.

September 7, 2022 5:56 PM, "Maxime Devos" <maximedevos@telenet.be> wrote:
> IIUC, this means that previously, it didn't include a copy [of the 
> Unicode Character Database], and now it does?

No, it did previously as well; the description just didn't mention it

> (If this was already the case in the previous version, that's still bad,
> but then it can be left for later, being independent of this patch.)

Understood.  I'll put that on the to-do list for future patches (though 
pinning specific versions of MoarVM/Rakudo to specific versions of the UCD
is important, so unbundling might mean including more up-to-date versions
of the UCD, unless Guix already stays very current there).

> I noticed you removed the mention of the garbage collector, is this 
> intentional? 

I cut the GC from the list of features in an effort to stay within Guix's 
length guidelines for descriptions (and because having a GC doesn't do much
to distinguish Raku from Perl/Python/nearly all Lisps/JS, etc.)  But the GC
is very much still present :)

> On nqp-configure: Are you sure that 'bin' should be installed in '.../bin'? 
> Looking at the Git repository, make.nqp does not have a shebang and can hence
> not be directly run, maybe you should add a shebang?
> 
> Also, is there appear to be some tests in 't', why aren't they run? There is a
> 'rakudo-build-system', maybe this rakudo-build-system can properly build this 
> package 

I'll double check the above.

> On nqp: why the switch from downloading the source code from the apparent official site
> "rakudo.perl6.org" to GitHub?

The Rakudo site no longer hosts NQP, just Rakudo.  See https://rakudo.perl6.org/downloads


>> + (substitute* "t/09-moar/01-profilers.t"
>> + (("ok.*\\$htmlpath" html-test-text)
>> + (string-append "todo \"harness5 fails to write html profile\";"
>> + html-test-text)))))
> 
> What's the issue here? Is it a limitation of the Guix packaging, or could it perhaps
> be an upstream bug? If the latter, upstream needs to be informed such that they can 
> fix the bug.

I'm honestly unsure.  I can't understand why it would be a Guix-specific issue, but I've
also never had that test fail when building from source on other distros.  More investigation
is called for.


> On the new package description: ... It's getting close to marketing phrases

Thanks.  I could tell I was getting a bit close to that line and guess I let my enthusiasm 
carry me away a bit; I'll rein it in.

> Can you verify that our various perl6-... libraries still build, and that when doing, say, 
> "guix shell rakudo perl6-json-name -- whatever-rakudos-binary-name-is", you can still use
> perl6-json-name in whatever is rakudo's name for a REPL?

Will do.  (Everything *should* be backwards compatible, but it's 100% worth checking)

> You add some patches, but they need to be registered in gnu/local.mk as well, please do so.

Will do.

> On the patch file name: it looks a little suspect, perhaps if you run the linter on the 
> packages it will have a comment about the file names.

I ran the linter and its only comment was that patches need to start with the package name.
Is there another rule?

> On commit messages: they don't follow our conventions. ... A new copyright line can also be added.

Will fix.
 
> Greetings,

Thanks!  I'm glad to be able to help with a small corner of Guix :)

On 08-09-2022 04:18, Daniel Sockwell wrote:
> (If this was already the case in the previous version, that's still bad,
>> but then it can be left for later, being independent of this patch.)
> Understood.  I'll put that on the to-do list for future patches (though
> pinning specific versions of MoarVM/Rakudo to specific versions of the UCD
> is important, so unbundling might mean including more up-to-date versions
> of the UCD, unless Guix already stays very current there).
If having a specific version (and not just a sufficiently recent version)
is important, you can look at the 'ucd-next' package and make a similar
package variant, except for whatever version MoarVM and Rakudo need
>> I noticed you removed the mention of the garbage collector, is this
>> intentional?
> I cut the GC from the list of features in an effort to stay within Guix's
> length guidelines for descriptions (and because having a GC doesn't do much
> to distinguish Raku from Perl/Python/nearly all Lisps/JS, etc.)  But the GC
> is very much still present :)
OK.
>> On nqp-configure: Are you sure that 'bin' should be installed in '.../bin'?
>> Looking at the Git repository, make.nqp does not have a shebang and can hence
>> not be directly run, maybe you should add a shebang?
>>
>> Also, is there appear to be some tests in 't', why aren't they run? There is a
>> 'rakudo-build-system', maybe this rakudo-build-system can properly build this
>> package
> I'll double check the above.
>
>> On nqp: why the switch from downloading the source code from the apparent official site
>> "rakudo.perl6.org" to GitHub?
> The Rakudo site no longer hosts NQP, just Rakudo.  See https://rakudo.perl6.org/downloads
>
OK.
>>> + (substitute* "t/09-moar/01-profilers.t"
>>> + (("ok.*\\$htmlpath" html-test-text)
>>> + (string-append "todo \"harness5 fails to write html profile\";"
>>> + html-test-text)))))
>> What's the issue here? Is it a limitation of the Guix packaging, or could it perhaps
>> be an upstream bug? If the latter, upstream needs to be informed such that they can
>> fix the bug.
> I'm honestly unsure.  I can't understand why it would be a Guix-specific issue, but I've
> also never had that test fail when building from source on other distros.  More investigation
> is called for.
OK, I suppose it isn't a blocker.
>> On the new package description: ... It's getting close to marketing phrases
> Thanks.  I could tell I was getting a bit close to that line and guess I let my enthusiasm
> carry me away a bit; I'll rein it in.
>
>> Can you verify that our various perl6-... libraries still build, and that when doing, say,
>> "guix shell rakudo perl6-json-name -- whatever-rakudos-binary-name-is", you can still use
>> perl6-json-name in whatever is rakudo's name for a REPL?
> Will do.  (Everything *should* be backwards compatible, but it's 100% worth checking)
I meant, the rakudo-build-system expects PERL6LIB, but the package now has a
RAKULIB search path instead.
>> You add some patches, but they need to be registered in gnu/local.mk as well, please do so.
> Will do.
>
>> On the patch file name: it looks a little suspect, perhaps if you run the linter on the
>> packages it will have a comment about the file names.
> I ran the linter and its only comment was that patches need to start with the package name.
Possibly it expects the package name to be followed by a - instead of a .
> Is there another rule?
Patches should have a comment at the top explaining what they are for, 
but you already did that.

Greetings,
Maxime