GNU bug report logs - #55248
[PATCH 0/7] gnu: Update Racket to 8.5 and Chez Scheme to 9.5.8.

Previous Next

Full log

View this message in rfc822 format

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>, 55248 <at> debbugs.gnu.org
Cc: Maxime Devos <maximedevos <at> telenet.be>, Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: [bug#55248] [PATCH v3 8/9] gnu: chez-scheme-for-racket: Fix supported systems.
Date: Mon, 9 May 2022 03:55:15 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.