[bug#55248,v3,8/9] gnu: chez-scheme-for-racket: Fix supported systems.

This commit fixes the treatment of systems like "powerpc-w64-mingw32",
where the combination of architecture and kernel is not supported, even
though both are supported in other combinations. The build failure fixed
in b8fc9169515ef1a6d6037c84e30ad308e5418b6f highlighted this problem:
see also <https://issues.guix.gnu.org/54292#6>. The correct support
status is specified by '%chez-features-table', which was added to
improve 'chez-upstream-features-for-system': this commit uses it to fix
the repair.

Once the issues in <https://racket.discourse.group/t/950> are resolved,
'chez-scheme-for-racket' and 'racket-vm-cs' will be able to run even on
systems for which native code generation is not supported. It's not
clear what behavior would be useful from 'nix-system->chez-machine':
since the current implementation is flawed and easy to misuse, we remove
it for now, replacing the remaining uses with
'racket-cs-native-supported-system?'.

* gnu/packages/chez.scm (nix-system->chez-machine): Remove it.
(racket-cs-native-supported-system?): New variable.
(chez-scheme-for-racket)[supported-systems]: Use it.
* gnu/packages/racket.scm (racket-vm-for-system): Likewise.
---
 gnu/packages/chez.scm   | 32 +++++++++++++++++---------------
 gnu/packages/racket.scm |  7 +++++--
 2 files changed, 22 insertions(+), 17 deletions(-)
  

Am Montag, dem 09.05.2022 um 02:02 -0400 schrieb Philip McGrath:
> Once the issues in <https://racket.discourse.group/t/950> are
> resolved, 'chez-scheme-for-racket' and 'racket-vm-cs' will be able to
> run even on systems for which native code generation is not
> supported.  It's not clear what behavior would be useful from 'nix-
> system->chez-machine': since the current implementation is flawed and
> easy to misuse, we remove it for now, replacing the remaining uses
> with 'racket-cs-native-supported-system?'.
I think you're again making a wrong assumption here.  nix-system->chez-
scheme has purposes outside of solving supported-system.  

> +(define* (racket-cs-native-supported-system? #:optional
> +                                             (system
> +                                              (or (%current-target-
> system)
> +                                                  (%current-
> system))))
> +  "Can Racket's variant of Chez Scheme generate native code for
> SYSTEM?
> +Otherwise, SYSTEM can use only the ``portable bytecode'' backends."
> +  (let ((chez-arch (target-chez-arch system))
> +        (chez-os (target-chez-os system)))
> +    (and (and=> (assoc-ref %chez-features-table chez-os)
> +                ;; NOT assoc-ref: supported even if cdr is #f
> +                (cut assoc chez-arch <>))
> +         #t)))
I think this should rather be explicit in %chez-features-table.  You
can prefix features that only work inside racket with 'racket-.  Then,
this can be solved with memq just as with chez-scheme's supported-
systems in 7/9.


Cheers
  

Hi,

On 5/9/22 02:34, Liliana Marie Prikler wrote:
> Am Montag, dem 09.05.2022 um 02:02 -0400 schrieb Philip McGrath:
>> Once the issues in <https://racket.discourse.group/t/950> are
>> resolved, 'chez-scheme-for-racket' and 'racket-vm-cs' will be able to
>> run even on systems for which native code generation is not
>> supported.  It's not clear what behavior would be useful from 'nix-
>> system->chez-machine': since the current implementation is flawed and
>> easy to misuse, we remove it for now, replacing the remaining uses
>> with 'racket-cs-native-supported-system?'.
> I think you're again making a wrong assumption here.  nix-system->chez-
> scheme has purposes outside of solving supported-system.
> 

Concretely, there are no other uses in Guix.

I do not know a robust, correct way to use 
'nix-system->chez-machine'---certainly not without it growing many 
additional features, like maybe computing endianness for pbarch backends 
when we are able to build them. For example, if we continued using it as 
we did in 'stex', you couldn't build a package graph for nonthreaded 
Chez simply by applying a package transformation to remove '--threads' 
from its '#:configure-flags', because that would change the machine type 
without updating the uses of 'nix-system->chez-machine'.

>> +(define* (racket-cs-native-supported-system? #:optional
>> +                                             (system
>> +                                              (or (%current-target-
>> system)
>> +                                                  (%current-
>> system))))
>> +  "Can Racket's variant of Chez Scheme generate native code for
>> SYSTEM?
>> +Otherwise, SYSTEM can use only the ``portable bytecode'' backends."
>> +  (let ((chez-arch (target-chez-arch system))
>> +        (chez-os (target-chez-os system)))
>> +    (and (and=> (assoc-ref %chez-features-table chez-os)
>> +                ;; NOT assoc-ref: supported even if cdr is #f
>> +                (cut assoc chez-arch <>))
>> +         #t)))
> I think this should rather be explicit in %chez-features-table.  You
> can prefix features that only work inside racket with 'racket-.  Then,
> this can be solved with memq just as with chez-scheme's supported-
> systems in 7/9.
> 

I don't understand this.

The presence of an entry in '%chez-features-table' explicitly means that 
'chez-scheme-for-racket' can generate native code.

The idea is that the "portable bytecode" backends should work, including 
thread support, on any system with a reasonably capable C compiler.

There are no other "features" that vary among systems for 
'chez-scheme-for-racket'. It doesn't rely on pre-built bootfiles for 
bootstrapping. Since the initial fork at the beginning of 2017, when 
support for new systems has been added, native threads have been 
supported immediately. Racket regularly merges all changes from upstream 
Chez (which has not added any supported systems during that time---not 
even the systems added already in Racket's variant). These conditions 
are documented in the comments on '%chez-features-table'. If they ever 
ceased to hold, it would mean that the relationship between 
'chez-scheme-for-racket' and upstream 'chez-scheme' had changed 
significantly, and we would probably need to reevaluate more broadly 
which variant to use where.

-Philip
  

Hi,

Am Montag, dem 09.05.2022 um 03:55 -0400 schrieb Philip McGrath:
> Concretely, there are no other uses in Guix.
> 
> I do not know a robust, correct way to use 
> 'nix-system->chez-machine'---certainly not without it growing many 
> additional features, like maybe computing endianness for pbarch
> backends when we are able to build them. For example, if we continued
> using it as we did in 'stex', you couldn't build a package graph for
> nonthreaded Chez simply by applying a package transformation to
> remove '--threads' from its '#:configure-flags', because that would
> change the machine type without updating the uses of 'nix-system-
> >chez-machine'.
True, you would have to change the machine type, but I think I already
noted that we might want to use this machine type as a distinguishing
factor in packages built on top of chez (and later chez-build-system
perhaps).  You could do this the other way round by deriving flags from
the given machine-type, e.g. stex for threaded chez machine is given --
threads, otherwise it's not.  Since we have named symbols for these
features, we could have a "package-with-chez-features" or similar
transformer.  Being able to specify this machine is a strength, not a
weakness.

> The presence of an entry in '%chez-features-table' explicitly means
> that 'chez-scheme-for-racket' can generate native code.
That is not explicit at all.  There might be an explicit comment
stating so somewhere, but in terms of actual code, it's super implicit.

> The idea is that the "portable bytecode" backends should work,
> including thread support, on any system with a reasonably capable C
> compiler.
The idea.  In practice, what racket deems reasonably capable can change
over time and might result in them dropping some architectures
currently supported.  What do you do then?

> There are no other "features" that vary among systems for 
> 'chez-scheme-for-racket'. It doesn't rely on pre-built bootfiles for 
> bootstrapping.  Since the initial fork at the beginning of 2017, when
> support for new systems has been added, native threads have been 
> supported immediately. Racket regularly merges all changes from
> upstream Chez (which has not added any supported systems during that
> time---not even the systems added already in Racket's variant). 
I'd still make "supported-by-racket" or however else you decide to name
that feature an explicit part of that table rather than an implicit
one, or use a separate "table" for platforms supported by racket.  Note
that none of the racket-vm packages appear to currently carry
supported-systems, which seems dubious.

> These conditions are documented in the comments on '%chez-features-
> table'. 
See above.


Cheers
  

Hi,

On 5/9/22 05:36, Liliana Marie Prikler wrote:
> Hi,
> 
> Am Montag, dem 09.05.2022 um 03:55 -0400 schrieb Philip McGrath:
>> Concretely, there are no other uses in Guix.
>>
>> I do not know a robust, correct way to use
>> 'nix-system->chez-machine'---certainly not without it growing many
>> additional features, like maybe computing endianness for pbarch
>> backends when we are able to build them. For example, if we continued
>> using it as we did in 'stex', you couldn't build a package graph for
>> nonthreaded Chez simply by applying a package transformation to
>> remove '--threads' from its '#:configure-flags', because that would
>> change the machine type without updating the uses of 'nix-system-
>>> chez-machine'.
> True, you would have to change the machine type, but I think I already
> noted that we might want to use this machine type as a distinguishing
> factor in packages built on top of chez (and later chez-build-system
> perhaps).  You could do this the other way round by deriving flags from
> the given machine-type, e.g. stex for threaded chez machine is given --
> threads, otherwise it's not.  Since we have named symbols for these
> features, we could have a "package-with-chez-features" or similar
> transformer.  Being able to specify this machine is a strength, not a
> weakness.
> 

I can imagine something like this might be useful eventually. My problem 
is that, right now, 'nix-system->chez-machine' is an attractive 
nuisance: it sounds useful, but I don't know any way of using it that 
wouldn't be subtly wrong. I don't even feel certain even about what 
cases 'nix-system->chez-machine' would need to cover to be correct and 
useful: a fair amount seems to depend on what turns out to be necessary 
for cross-compilation and the portable bytecode architectures (which I 
hope to work out by July).


>> The idea is that the "portable bytecode" backends should work,
>> including thread support, on any system with a reasonably capable C
>> compiler.
> The idea.  In practice, what racket deems reasonably capable can change
> over time and might result in them dropping some architectures
> currently supported.  What do you do then?
> 

I mean, "over time", at the extreme, anything "might" happen, but I 
don't think that's worth worrying about. Racket has an extremely strong 
commitment to backwards compatibility. To pick one example, support 
libraries for racket/draw and racket/gui are still maintained for 
ppc-macosx, which the vendor hasn't released any software for in a 
decade or more (depending on how you prefer to count). The C code 
deliberately does not require C99 support.

 >> The presence of an entry in '%chez-features-table' explicitly means
 >> that 'chez-scheme-for-racket' can generate native code.
 > That is not explicit at all.  There might be an explicit comment
 > stating so somewhere, but in terms of actual code, it's super
 > implicit.
 >

>> There are no other "features" that vary among systems for
>> 'chez-scheme-for-racket'. It doesn't rely on pre-built bootfiles for
>> bootstrapping.  Since the initial fork at the beginning of 2017, when
>> support for new systems has been added, native threads have been
>> supported immediately. Racket regularly merges all changes from
>> upstream Chez (which has not added any supported systems during that
>> time---not even the systems added already in Racket's variant).
> I'd still make "supported-by-racket" or however else you decide to name
> that feature an explicit part of that table rather than an implicit
> one, or use a separate "table" for platforms supported by racket.

I really don't understand how this would be helpful. I don't think it 
would make sense for a list returned by 
chez-upstream-features-for-system to include a symbol 
supported-by-racket, which has nothing to do with *upstream* features. 
Aside from that, we would be adding this symbol to every single entry in 
%chez-features-table. That would imply turning all of the #f entries 
into (supported-by-racket), and then we would need some other solution 
for identifying platforms with no support upstream.

>  Note
> that none of the racket-vm packages appear to currently carry
> supported-systems, which seems dubious.
> 

The only constraint on the systems supported by 'racket-vm-cs' is from 
'chez-scheme-for-racket'---i.e., the trouble with `configure` for 
systems without a native-code backend, which should be fixed by the next 
release, if not before. I expect the fact that the 
'chez-scheme-for-racket' input is not supported to work as an 
alternative to duplicating the filtering in its supported-systems field 
(which I think would create a cyclic dependency issue).

AFAIK, 'racket-vm-cgc' and 'racket-vm-bc' should work everywhere (though 
possibly without the JIT, futures, and/or places) except that support 
for aarch64-macosx is prohibitively poor (IIUC due to W^X issues), which 
is fairly irrelevant for Guix.

-Philip
  

Hi,

Am Donnerstag, dem 12.05.2022 um 01:26 -0400 schrieb Philip McGrath:
> > True, you would have to change the machine type, but I think I
> > already noted that we might want to use this machine type as a
> > distinguishing factor in packages built on top of chez (and later
> > chez-build-system perhaps).  You could do this the other way round by
> > deriving flags from the given machine-type, e.g. stex for threaded
> > chez machine is given -- threads, otherwise it's not.  Since we have
> > named symbols for these features, we could have a "package-with-chez-
> > features" or similar transformer.  Being able to specify this machine
> > is a strength, not a weakness.
> > 
> 
> I can imagine something like this might be useful eventually. My
> problem is that, right now, 'nix-system->chez-machine' is an attractive
> nuisance: it sounds useful, but I don't know any way of using it that
> wouldn't be subtly wrong. 
Your 6/9 patch imho erases a use that wouldn't have been wrong. 
Certainly not if we add extra features to it or use inference at build
time.

For instance
(let* ((base-system #$(nix-system->chez-machine 
                       (or (%current-target-system) 
                           (%current-system))))
       (threaded? (member "--threads" configure-flags))
       (portable-bytecode? [however you would determine that])
       (actual-machine (string-append ...)))
  [code that uses actual-machine])
would be an alternative if you want actual-machine inferred by compile
options rather than earlier on.

> I don't even feel certain even about what cases 'nix-system->chez-
> machine' would need to cover to be correct
> and useful: a fair amount seems to depend on what turns out to be
> necessary for cross-compilation and the portable bytecode
> architectures (which I hope to work out by July).
From my POV it is already enough if we can do the basic translation
with nix-system->chez-machine.  Additional features like threads or
portable bytecode would be nice to have, but if you feel that it'd be
"subtly wrong" to add them (or not to add them), you can feel free to
add or omit them as you like.

> > I'd still make "supported-by-racket" or however else you decide to
> > name that feature an explicit part of that table rather than an
> > implicit one, or use a separate "table" for platforms supported by
> > racket.
> 
> I really don't understand how this would be helpful. I don't think it
> would make sense for a list returned by 
> chez-upstream-features-for-system to include a symbol 
> supported-by-racket, which has nothing to do with *upstream*
> features. 
For one, that procedure would be free to filter features as it needs so
that it doesn't return racket-specific symbols, but more importantly if
you do feel that using this table to report racket support explicitly
is abuse, how is it not abuse if you report it implicitly?

> Aside from that, we would be adding this symbol to every single entry
> in %chez-features-table. That would imply turning all of the #f
> entries into (supported-by-racket), and then we would need some other
> solution for identifying platforms with no support upstream.
If I read this table correctly, there is no entry, that does not have
either 'threads or 'bootstrap-bootfiles.  So null? after filtering
racket features would work.  If this is ever violated, e.g. we find an
arch that has neither bootstrap nor threads, but is still supported by
upstream, we could add an explicit 'basic-upstream-support feature to
the table.

> > Note that none of the racket-vm packages appear to currently carry
> > supported-systems, which seems dubious.
> 
> The only constraint on the systems supported by 'racket-vm-cs' is
> from 'chez-scheme-for-racket'---i.e., the trouble with `configure`
> for systems without a native-code backend, which should be fixed by
> the next release, if not before. 
Let's just assume that to be true.  Even if so, why is "supported by
racket" the condition for which we check rather than "not supported by
upstream"?  Seems kinda counterintuitive if racket supposedly supports
all arches while chez itself does not.

> I expect the fact that the 'chez-scheme-for-racket' input is not
> supported to work as an alternative to duplicating the filtering in
> its supported-systems field (which I think would create a cyclic
> dependency issue).
You might want to rephrase that sentence.  I have no idea what you're
trying to get across here.


Cheers