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

Previous Next

Full log

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

From: Philip McGrath <philip <at> philipmcgrath.com>
To: 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>,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>,
 raingloom <raingloom <at> riseup.net>, Attila Lendvai <attila <at> lendvai.name>,
 Malte Gerdes <malte.f.gerdes <at> gmail.com>
Subject: Re: [PATCH v5 00/22] Update Racket to 8.4. Adjust Chez Scheme
 packages.
Date: Sat, 26 Feb 2022 10:36:16 -0500

[Message part 1 (text/plain, inline)]

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.

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.

> > I also managed to split up the update to Racket 8.4 (patch v4 15/15)
> > into a number of smaller steps (or, more precisely, rewrite it now
> > that I knew what the end result would be). I now have the 'racket-
> > minimal*' packages gradually evolve into the corresponding 'racket-
> > vm-*' packages (rather than adding the 'racket-vm-*' stack in
> > parallel), then split the new 'racket-minimal' package
> > out of 'racket'. Hopefully this might be somewhat easier to review.
> > The downside is there are now 22 patches, rather than 15.
> 
> In general, smaller patches = more better.  I really like this series
> so far, there's only some cosmetic nitpicks, although for the record I
> do have to say that I skipped over many things that felt familiar from
> earlier series.

Thanks!

> 
> 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'll now attempt to build racket with this patch and hopefully
> encounter no error as I do.
> 
> Cheers

-Philip

[signature.asc (application/pgp-signature, inline)]

Previous Next

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