Package: guix-patches;
Reported by: Philip McGrath <philip <at> philipmcgrath.com>
Date: Tue, 8 Feb 2022 15:14:01 UTC
Severity: normal
Tags: patch
Merged with 53997
Done: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Bug is archived. No further changes may be made.
Message #91 received at 53878 <at> debbugs.gnu.org (full text, mbox):
From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at> To: Philip McGrath <philip <at> philipmcgrath.com>, 53878 <at> debbugs.gnu.org Subject: Re: [PATCH 08/11] gnu: Add chez-scheme-for-racket. Date: Mon, 14 Feb 2022 16:18:49 +0100
Hi,
Am Sonntag, dem 13.02.2022 um 16:51 -0500 schrieb Philip McGrath:
> [...]
> * gnu/packages/chez-and-racket-bootstrap.scm (racket-vm-cgc):
> (racket-vm-bc):
> (racket-vm-cs):
> (chez-scheme-for-racket-bootstrap-bootfiles):
> (chez-scheme-for-racket): New variables.
One patch per package is probably better.
> [...] One way of thinking about the
> +;; bounary between the Racket VM and Racket programs is that the VM
> implements
boundary.
> +;; the primitives accessed by the 'ffi/unsafe/vm' library. Another
> perspective
> +;; is that DrRacket's ``Open defining file''/``Jump to definition''
> features
> +;; can navigate into Racket programs, including into the
> implementation of
> +;; 'racket/base', but can not jump into the implementation of the
> Racket VM
> +;; itself. A third, related perspective is that Racket code is
> usually
> +;; installed with source files alongside compiled code (though this
> is not
> +;; mandatory), whereas the Racket VM is installed only in compiled
> form.
> [...]
> +;; output. The function 'racket-vm-for-system' returns the
> recomended Racket
> +;; VM package for a given system.
This is a very long comment. Consider how much of it is actually
necessary and how much of it is not (do I really need to know about the
capabilities of DrRacket for instance?)
> +;; Bootstrapping Racket:
> +;; ---------------------
> +;;
> +;; Here's how bootstrapping Racket works:
> +;;
> +;; - Racket BC [CGC] can be built with only a C compiler (except
> for
> +;; one caveat discussed below).
> +;; - Racket BC [3M] needs an existing Racket to run "xform",
> +;; which transforms its own C source code to add additional
> annotations
> +;; for the precise garbage collector.
> +;; - Racket CS needs (bootfiles for) Racket's fork of Chez Scheme.
> +;; It also needs an existing Racket to compile Racket-
> implemented
> +;; parts of the runtime system to R6RS libraries.
> +;; - Chez Scheme also needs bootfiles for itself, but Racket can
> simulate
> +;; enough of Chez Scheme to load Racket's fork of the Chez
> Scheme compiler
> +;; purely from source into Racket and apply the compiler to
> itself,
> +;; producing the needed bootfiles (albeit very slowly).
> +;; Any variant of Racket since version 7.1 can run the
> simulation.
> +;;
> +;; So, we build CGC to build 3M to build bootfiles and CS.
This block I'd consider necessary, but again slightly on the verbose
end.
> +;; (Note: since the CGC variant is basically only for bootstrapping,
> we
> +;; often use "BC" to mean "3M", consistent with `(banner)` and the
> +;; suffixes used on executables when more than one variant co-
> exists.)
> +;;
> +;; One remaining bootstrapping limitation is that Racket's reader,
> module
> +;; system, and macro expander are implemented in Racket. For Racket
> CS,
> +;; they are compiled to R6RS libraries as discussed above. This note
> from the
> +;; README file applies to all such subsystems:
> +;;
> +;; The Racket version must be practically the same as the
> current Racket
> +;; verson, although it can be the Racket BC implementation
> (instead of
> +;; the Racket CS implementation).
> +;;
> +;; Unlike Chez Scheme boot files, the files generated in
> "schemified"
> +;; are human-readable and -editable Scheme code. That provides a
> way
> +;; out of bootstrapping black holes, even without BC.
> +;;
> +;; However, other Racket subsystems implemented in Racket for Racket
> CS
> +;; use older C implementations for Racket BC, whereas the reader,
> expander,
> +;; and module system were completely replaced with the Racket
> implementation
> +;;
> +;; For Racket BC, the compiled "linklet" s-expressions (primitive
> modules)
> +;; are embeded in C as a static string constant. Eventually, they
> are further
> +;; compiled by the C-implemented Racket BC bytecode and JIT
> compilers.
> +;; (On platforms where Racket BC's JIT is not supported, yet another
> compiler
> +;; instead compiles the linklets to C code, but this is not a
> bootstrapping
> +;; issue.)
> +;;
Again, you want to be brief and understandable. What does this mean in
practise? Do we have racket bootstrapped yet or is there still some
magic hidden within?
> ;; Code:
>
> (define (chez-machine->unthreaded mach)
> @@ -189,19 +330,19 @@ (define* (nix-system->chez-machine #:optional
> (system (%current-system))
> (chez-machine->threaded mach)))))))
>
> ;;
> -;; Chez Scheme:
> +;; Chez auxiliary G-expressions:
> ;;
>
> (define unbundle-chez-submodules
> #~(begin
> (use-modules (guix build utils))
> (for-each (lambda (dir)
> - (when (directory-exists? dir)
> - (delete-file-recursively dir)))
> - '("stex"
> - "nanopass"
> - "lz4"
> - "zlib"))))
> + (when (directory-exists? dir)
> + (delete-file-recursively dir)))
> + '("stex"
> + "nanopass"
> + "lz4"
> + "zlib"))))
As in one of your previous patches, you're mixing cosmetic changes with
non-cosmetic ones. This one could be prevented by correctly indenting
it in the patch that introduces it.
> (define unpack-nanopass+stex
> #~(begin
> @@ -216,6 +357,234 @@ (define unpack-nanopass+stex
> ;; otherwise, it will try to download submodules
> (display "# to placate ../configure")))))
>
> +;;
> +;; Racket VM:
> +;;
> +
> +(define (racket-vm-common-configure-flags)
> + ;; under a lambda extraction to avoid evaluating bash-minimal too
> early
> + #~`(,@(cond
> + ((false-if-exception
> + (search-input-file %build-inputs "/bin/libtool"))
> + => (lambda (libtool)
> + (list (string-append "--enable-lt=" libtool))))
> + (else
> + '()))
> + ,@(cond
> + ((false-if-exception
> + (search-input-file %build-inputs "/opt/racket-
> vm/bin/racket"))
Did we have /opt/racket... before? We should probably avoid such
paths.
> + => (lambda (racket)
> + (list (string-append "--enable-racket=" racket))))
> + (else
> + '()))
> + ,(string-append "CPPFLAGS=-DGUIX_RKTIO_PATCH_BIN_SH="
> + #$(file-append bash-minimal "/bin/sh"))
> + "--disable-strip"
> + "--enable-origtree")
For the record, why do you need double quoting here? Would ungexp-
splicing extract this too soon?
> +(define-public racket-vm-cgc
> + ;; Eventually, it may make sense for some vm packages to not be
> hidden,
> + ;; but this one is especially likely to remain hidden.
> + (hidden-package
> + (package
> + (name "racket-vm-cgc")
> + (version "8.4")
> + ;; ^ Remember to also update the version of
> + ;; chez-scheme-for-racket-bootstrap-bootfiles
> + (source
> + (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url "https://github.com/racket/racket")
> + (commit (string-append "v" version))))
> + (sha256
> + (base32
> "1vpl66gdgc8rnldmn8rmb7ar9l057jqjvgpfn29k57i3c5skr8s6"))
> + (file-name (git-file-name "racket" version))
> + (patches (search-patches "racket-minimal-sh-via-rktio.patch"
> + ;; Remove by Racket 8.5:
> + "racket-enable-scheme-
> backport.patch"))
> + (modules '((guix build utils)))
> + (snippet
> + #~(begin
> + ;; Unbundle Chez submodules.
> + (with-directory-excursion "racket/src/ChezScheme"
> + #$unbundle-chez-submodules)
> + ;; Unbundle libffi.
> + (delete-file-recursively
> "racket/src/bc/foreign/libffi")))))
> + (inputs (list ncurses ;; <- common to all variants (for
> #%terminal)
> + bash-minimal ;; <- common to all variants (for
> `system`)
> + libffi)) ;; <- only for BC variants
> + (native-inputs (list libtool)) ;; <- only for BC variants
> + (outputs '("out" "debug"))
> + (build-system gnu-build-system)
> + (arguments
> + (list
> + #:configure-flags
> + #~(cons "--enable-cgcdefault"
> + #$(racket-vm-common-configure-flags))
> + ;; Tests are in packages like racket-test-core and
> + ;; main-distribution-test that aren't part of the main
> + ;; distribution.
> + #:tests? #f
> + ;; Upstream recommends #:out-of-source?, and it does
> + ;; help with debugging, but it confuses `install-license-
> files`.
> + #:modules '((ice-9 match)
> + (ice-9 regex)
> + (guix build gnu-build-system)
> + (guix build utils))
> + #:strip-directories #~'("opt/racket-vm/bin"
> + "opt/racket-vm/lib")
> + #:phases
> + #~(let ()
> + (define* ((wrap-racket-vm-outputs phase) . args)
> + (apply
> + phase
> + (let loop ((args args))
> + (match args
> + ((#:outputs outputs . args)
> + `(#:outputs
> + ,(let loop ((outputs outputs))
> + (match outputs
> + ((("out" . out) . outputs)
> + `(("out" . ,(string-append out
> "/opt/racket-vm/"))
> + ,@outputs))
> + ((other . outputs)
> + (cons other (loop outputs)))))
> + ,@args))
> + ((arg . args)
> + (cons arg (loop args)))))))
Why?
Cheers
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.