GNU bug report logs - #70065
[PATCH 0/6] gnu: Update to Racket 8.12, Chez Scheme 10, and Zuo 1.9.

Previous Next

Full log

Message #53 received at 70065 <at> debbugs.gnu.org (full text, mbox):

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Skyler Ferris <skyvine <at> protonmail.com>, 70065 <at> debbugs.gnu.org
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70065] [PATCH 4/6] gnu: chez-scheme: Update to 10.0.0.
Date: Sat, 30 Mar 2024 18:49:11 -0400

Hi Liliana and Skyler,

On 3/30/24 10:28, Skyler Ferris wrote:
>
>> Is there a good reason to do it this way?  Or could we build racket
>> with regular chez-scheme afterwards?
>
> I believe this is addressed by this comment from patch 6/6; we can't
> rely on chez-scheme being the correct version to use for racket. But
> please correct me if I misunderstood Philip!
>
>> Since the pre-releases for Chez Scheme 10.0.0, all of Racket's 
changes have
>> been merged upstream, and development will be kept in sync going
>> forward. However, there is no plan to align the Chez Scheme and Racket
>> release cycles. For the near fulture, a given released version of Racket
>> will continue to depend on a specific pre-release version of Chez 
Scheme as
>> part of Racket CS's "ABI". See upstream discussion at
>> <https://racket.discourse.group/t/2739/3>.
>

That's right. In the linked thread, Matthew Flatt specifically confirmed 
that we should not try to build Racket with our chez-scheme package.

On 3/30/24 10:39, Skyler Ferris wrote:
> On 3/28/24 22:18, Philip McGrath wrote:
>> -(define* (chez-scheme-for-system #:optional
>> -                                 (system (or (%current-target-system)
>> -                                             (%current-system))))
>> -  "Return 'chez-scheme' if it fully supports SYSTEM, including support for
>> -bootstrapping and native threads.  Otherwise, return
>> -'chez-scheme-for-racket'."
>> -  (if (and=> (chez-upstream-features-for-system system)
>> -             (lambda (features)
>> -               (every (cut memq <> features)
>> -                      '(threads
>> -                        ;; We can cross-compile for platforms without
>> -                        ;; bootstrap bootfiles, but we can't self-host
>> -                        ;; on them short of adding more binary seeds.
>> -                        bootstrap-bootfiles))))
>> -      chez-scheme
>> -      chez-scheme-for-racket))
>> +(define-deprecated (chez-scheme-for-system #:optional system) chez-scheme
>> +  "Returns 'chez-scheme'."
>> +  chez-scheme)
> As mentioned in the reply to the cover letter, it looks like this broke
> loko-scheme from gnu/pcakages/loko.scm.
> 
> In particular, I get a "wrong type to apply" error in its use of
> "chez-scheme-for-system". I ran into this problem when running the
> following command:
> 
> ```
> ./pre-inst-env guix refresh --list-depedent zuo -e '(@ (gnu packages
> racket) racket-vm-cs)' racket chez-scheme chez-scheme-for-racket
> ```
> 

Thanks, I had forgotten about loko-scheme!

On 3/30/24 10:28, Skyler Ferris wrote:
> (I think the deprecation definition might need an
> update, because IIUC the syntax is supposed to be backwards-compatible
> until it is removed).
>

I still don't understand why the deprecation definition isn't working. I 
expected the expansion at the repl, and (chez-scheme-for-system) 
expanded to (%chez-scheme-for-system/deprecated), which was defined by 
the expansion of define-deprecated as:

  (define %chez-scheme-for-system/deprecated
    (begin
      (lambda () chez-scheme)
      (lambda* (#:optional (system #f)) chez-scheme)))

I guess, unless I figure something out or someone has a better 
suggestion, I could just remove chez-scheme-for-system without 
deprecation, but that seemed less friendly.

> 
> As before, my experience with autotools is limited so my review of the
> build changes should be taken with a grain of salt. It looks like some
> of the patched code is fixing bugs rather than adapting for guix so they
> should be upstreamed, but I assume Philip is already on top of that.
> 

Chez Scheme actually doesn't use autotools. (Racket does use autoconf, 
only.) All of the patches for configure have already been accepted 
upstream: in fact, the second patch in the file is a follow-up from 
Matthew Flatt, one of the maintainers of Racket and, more recently, Chez 
Scheme.

On 3/30/24 03:56, Liliana Marie Prikler wrote:
> As usual for these large rackets (pun intended), I do wonder whether
> it'd be possible to split the commits into more reviewable hunks.  For
> instance, I don't think chez-scheme-for-system would need to be
> adjusted yet – it could simply return chez-scheme and then in the next
> commit be deprecated or dropped.

Since there's a problem with the deprecation anyway, I will split this 
out. Overall, dividing up this series as much as I did has been 
especially arduous. If you noticed that the authored dates on the 
patches are a month ago, that's mostly the time it took me to reorganize 
these commits.

Thanks,
Philip

Previous Next

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