[bug#70065] [PATCH 4/6] gnu: chez-scheme: Update to 10.0.0.

[Philip McGrath <philip@philipmcgrath.com>]

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