GNU bug report logs - #53878
[PATCH 00/11] Update Racket to 8.4. Adjust Chez Scheme

Previous Next

Full log

View this message in rfc822 format

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Philip McGrath <philip <at> philipmcgrath.com>, 53878 <at> debbugs.gnu.org, zimoun <zimon.toutoune <at> gmail.com>, Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: Ludovic Courtès <ludo <at> gnu.org>, Maxime Devos <maximedevos <at> telenet.be>, Attila Lendvai <attila <at> lendvai.name>, Malte Gerdes <malte.f.gerdes <at> gmail.com>, raingloom <raingloom <at> riseup.net>
Subject: [bug#53878] [PATCH v5 00/22] Update Racket to 8.4. Adjust Chez Scheme packages.
Date: Sat, 26 Feb 2022 17:14:38 +0100

Hi,

Am Samstag, dem 26.02.2022 um 10:36 -0500 schrieb Philip McGrath:
> Hi,
> 
> On Saturday, February 26, 2022 10:08:30 AM EST Liliana Marie Prikler
> wrote:
> > Am Samstag, dem 26.02.2022 um 08:02 -0500 schrieb Philip McGrath:
> > > I realized that, if we just pass the origin some other way than
> > > as the 'source' field, we can avoid adding the
> > > "chez-and-racket-bootstrap.scm" file
> > > altogether: patch v5 10/22 does the core of that.
> > 
> > I did miss that nugget when I skimmed it first; is there a reason
> > to prefer overloading unpack and redirecting it to (package-source
> > racket-vm-bc) over doing the same, but using simply #$%racket-
> > origin?
> > 
> 
> I like this:
> 
> > > +            (replace 'unpack
> > > +              (lambda args
> > > +                (unpack #:source #$(or (package-source this-
> > > package)
> > > +                                       (package-source racket-
> > > vm-bc)))))
> 
> rather than:
> 
>     (unpack #:source #$(package-source racket-vm-bc))
> 
> to make it easier for a user to provide an alternate source.
Hmm, to be fair this would probably respect --with-source, which I was
missing, but I'm not sure how deep into the bootstrap we could inject
this.  Sadly, we can't make chez-scheme-for-racket itself a
transformation.

> My concern with:
> 
>     (unpack #:source #$(or (package-source this-package) %racket-
> origin))
> 
> is less strong, but if `(gnu packages racket)` exports `%racket-
> origin`, it 
> seems like it would be very tempting to put it in a `source` field,
> but of course that would cause problems. My hope was that having to
> write `(package-source racket-vm-bc)` might prompt a little more
> thought.
Hmm.  And what if we go my earlier route of defining this as a
procedure in chez and instantiating it inside racket.scm?  We should
not get a cycle triggered by chez-scheme-for-system if we do, but we
might get one if we attempt to bind it to a variable in racket.scm.

That aside, there is also the possibility of using a gexp promise as
source, as is done for example in the case of linux-libre.  If we wrap
the chez side in a promise, that ought to resolve the cycle as well.

> > 
> > BTW for the record, if you're dropping one of my mails from the
> > CCs, please make sure to include the gmail account rather than my
> > institute mail.  This one is technically supposed to be for work
> > and I'm using a rather loose interpretation of "ensuring that
> > software is up-to-date" as part of my work when I do comment on
> > Guix issues from it.
> 
> Will do, sorry! (I've been experimenting with MUAs recently and not
> getting everything right—you may have noticed I sent mail earlier
> from an address I wasn't intending to use.)
I haven't noticed, but thanks for pointing this out.  If a commit from
the wrong address does make it into our git history, please do point
that out; I'll be happy to adjust the mailmap for you.

> 
Cheers

Previous Next

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