Message ID | d62e2b56-b929-4f0f-f819-4075ff48680f@gmail.com |
---|---|
State | Accepted |
Headers | show |
Series | None | expand |
Hi, Am Mittwoch, dem 23.02.2022 um 13:55 -0500 schrieb Philip McGrath: > To try to be concrete, I made the patch below as a mock-up of part of > your earlier suggestion (IIUC): > > On 2/20/22 04:03, Liliana Marie Prikler wrote: > > Inside chez-and-racket-bootstrap, define (make-<package>) > functions for > > the following: > > - chez-bootstrap-bootfiles, chez-for-racket-bootstrap-bootfiles: > > Taking version and origin. > > - racket-vm-cgc: Taking version and origin. > > - racket-vm-bc: Taking racket-vm-cgc. > > - racket-vm-cs: Taking racket-vm-bc. > > > Inside racket, define %racket-version, %racket-origin, racket- > minimal > > and racket. It'd also be good if you made local definitions > > (define racket-vm-cgc (make-racket-vm-cgc %racket-version %racket- > > origin)) > > (define racket-vm-bc (make-racket-vm-bc racket-vm-cgc)) > > ... > > in this file. > > This applies on top of v4, or I've put it at > < > https://gitlab.com/philip1/guix-patches/-/commit/982fe7cfb4d33103ee611acc310e3225ccf35852 > > > if that's easier for anyone: To be fair, the issue here is with my proposal, which doesn't completely thunk through. I clarified later on that it would need another pair of brackets or – if that's easier for you – commented on the commit you've linked. > Overall, I certainly agree that duplicating the definition of > `%racket-version` is not ideal. I'd be glad for you or anyone to > improve the situation, and I'll try to get my head around Maxime's > email about the underlying semantics. > > But I am confident that v4 of this series is at least not broken, if > perhaps not maximally beautiful. Especially given that I, for one, > have tried things that initially seemed correct only to discover > subtle problems later, I think it would be better for any refinements > to come in follow-on patches later. I can understand the sentiment, but there are some things that still don't feel right for me – for instance the fact, that seemingly unrelated modules now have to pull in racket bootstrap sounds like a recipe for trouble. The final patch in the series also still does too much for me to wrap my head around, which makes it difficult to audit. Therefore, one question I have w.r.t. updating Racket is whether we could theoretically bump the version while keeping the old bootstrap, and then adjust the bootstrap by adding all the packages you've made. It does seem to be an all or nothing deal when doing the bootstrap first, but that need not necessarily hold for bootstrap second. Also, accepting for a moment that we might have to move chez-scheme and other important things into chez-scheme-and-racket-bootstrap (even though I'm not really content with it), I still wonder if we could introduce chez-scheme-for-system first (defined as simply chez-scheme initially) and adjust the callers, then move chez-scheme while keeping the function in chez.scm and finally do the magic with making it either chez or racket. I know I have a tendency towards being overly cautious when it comes to pushing big changes, so if that's the case I'd be happy if someone else were to take over. That said, I do feel somewhat lonely at the moment despite the many people specifically mentioned in "To:" and "Cc:", so I'm somewhat content with moving slowly for now. Cheers
Hi Liliana, Thanks Philip for these large series. > I know I have a tendency towards being overly cautious when it comes to > pushing big changes, so if that's the case I'd be happy if someone else > were to take over. That said, I do feel somewhat lonely at the moment > despite the many people specifically mentioned in "To:" and "Cc:", so > I'm somewhat content with moving slowly for now. Sorry, I am running out of time and the series is quite large; the changes are not really atomic. ;-) On Wed, 23 Feb 2022 at 21:31, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote: > > But I am confident that v4 of this series is at least not broken, if > > perhaps not maximally beautiful. Especially given that I, for one, > > have tried things that initially seemed correct only to discover > > subtle problems later, I think it would be better for any refinements > > to come in follow-on patches later. > > I can understand the sentiment, but there are some things that still > don't feel right for me – for instance the fact, that seemingly > unrelated modules now have to pull in racket bootstrap sounds like a > recipe for trouble. The final patch in the series also still does too > much for me to wrap my head around, which makes it difficult to audit. I understand both sentiments. I also have some difficulties for auditing the series. Well, it needs some time to sit down, fill the coffee pot and careful review. :-) I cannot promise but I will try to give a look next week; for what my reviewing eyes are worth. Cheers, simon
diff --git a/gnu/packages/chez-and-racket-bootstrap.scm b/gnu/packages/chez-and-racket-bootstrap.scm index b779099fb3..ea10f7fe92 100644 --- a/gnu/packages/chez-and-racket-bootstrap.scm +++ b/gnu/packages/chez-and-racket-bootstrap.scm @@ -47,6 +47,7 @@ (define-module (gnu packages chez-and-racket-bootstrap) #:use-module ((guix licenses) #:prefix license:) #:export (chez-scheme-for-system + make-racket-vm-cgc racket-vm-for-system)) ;; Commentary: @@ -199,6 +200,9 @@ (define-module (gnu packages chez-and-racket-bootstrap) ;; ;; Code: +(define (make-racket-vm-cgc a b) + 42) + (define* (chez-scheme-for-system #:optional (system (or (%current-target-system) (%current-system)))) diff --git a/gnu/packages/racket.scm b/gnu/packages/racket.scm index c2854f84e8..08e437a722 100644 --- a/gnu/packages/racket.scm +++ b/gnu/packages/racket.scm @@ -58,6 +58,9 @@ (define %racket-version "8.4") ; MUST match "chez-and-racket-bootstrap.scm" (define %racket-commit (string-append "v" %racket-version)) +(define fake-racket-vm-cgc + (make-racket-vm-cgc 1 2)) + (define (extract-package-source origin spec) "Extract the source for a Racket package specified by SPEC from