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 #56 received at 70065 <at> debbugs.gnu.org (full text, mbox):

From: Skyler Ferris <skyvine <at> protonmail.com>
To: Philip McGrath <philip <at> philipmcgrath.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: Sun, 31 Mar 2024 14:35:28 +0000

On 3/30/24 15:49, Philip McGrath wrote:
> 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.

So, I started poking at this and ran into something strange. I removed 
the surrounding parentheses from chez-scheme-for-system in loko.scm, and 
it gave me the expected error about an invalid package, where the value 
was a procedure rather than a package. Which sounds like what I would 
expect if it was working, except that it didn't work with the 
parentheses. Then, after adding the parentheses back it stopped giving 
me the error, even after running make again.

I haven't worked with define-deprecated before. It's a macro, and I know 
that the guile compiler misses recompiling macro dependencies sometimes, 
so maybe it was a problem on my end with having mismatching build 
artifacts. I'll try a clean build with these patches and a simulated 
guix pull within the next couple of days (hopefully today), and if those 
both work then the definition is probably correct.... but I'd be more 
comfortable if we could explain exactly why that error occurred. I'll 
also look more at the definitions, but I think it will be a little 
difficult to be confident in any explanation if I can't reproduce the 
error. Here's the full error output, in case it's helpful to anyone:

Backtrace:
In ice-9/boot-9.scm:
   1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In guix/ui.scm:
     485:6 18 (_)
In guix/scripts/build.scm:
     711:5 17 (_)
In srfi/srfi-1.scm:
    673:15 16 (append-map #<procedure 7fef052ecdc0 at guix/scripts/b…> …)
    586:17 15 (map1 ("x86_64-linux"))
In guix/scripts/build.scm:
    713:21 14 (_ _)
In guix/store.scm:
   1382:11 13 (map/accumulate-builds #<store-connection 256.100 7fef…> …)
    1300:8 12 (call-with-build-handler #<procedure 7fef06f90990 at g…> …)
In guix/scripts/build.scm:
    667:16 11 (_ #<package loko-scheme <at> 0.12.0 gnu/packages/loko.scm:3…>)
    656:24 10 (_ #<package loko-scheme <at> 0.12.0 gnu/packages/loko.scm:…> …)
In guix/packages.scm:
   1378:17  9 (supported-package? #<package loko-scheme <at> 0.12.0 gnu/p…> …)
In guix/memoization.scm:
     101:0  8 (_ #<hash-table 7fef036b2120 0/31> #<package loko-sche…> …)
In guix/packages.scm:
   1356:39  7 (_)
   1618:16  6 (package->bag _ _ _ #:graft? _)
   1722:47  5 (thunk)
In gnu/packages/loko.scm:
     77:11  4 (native-inputs #<package loko-scheme <at> 0.12.0 gnu/package…>)
     77:11  3 (native-inputs _)
In ice-9/boot-9.scm:
   1685:16  2 (raise-exception _ #:continuable? _)
   1685:16  1 (raise-exception _ #:continuable? _)
   1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type to apply: #<syntax-transformer chez-scheme-for-system>

Previous Next

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