| Message ID | 1328772b3ccb2d3909f8bca6fe14659e04434e3e.1652075689.git.philip@philipmcgrath.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | gnu: Update Racket to 8.5 and Chez Scheme to 9.5.8. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
Am Montag, dem 09.05.2022 um 02:02 -0400 schrieb Philip McGrath: > Once the issues in <https://racket.discourse.group/t/950> are > resolved, 'chez-scheme-for-racket' and 'racket-vm-cs' will be able to > run even on systems for which native code generation is not > supported. It's not clear what behavior would be useful from 'nix- > system->chez-machine': since the current implementation is flawed and > easy to misuse, we remove it for now, replacing the remaining uses > with 'racket-cs-native-supported-system?'. I think you're again making a wrong assumption here. nix-system->chez- scheme has purposes outside of solving supported-system. > +(define* (racket-cs-native-supported-system? #:optional > + (system > + (or (%current-target- > system) > + (%current- > system)))) > + "Can Racket's variant of Chez Scheme generate native code for > SYSTEM? > +Otherwise, SYSTEM can use only the ``portable bytecode'' backends." > + (let ((chez-arch (target-chez-arch system)) > + (chez-os (target-chez-os system))) > + (and (and=> (assoc-ref %chez-features-table chez-os) > + ;; NOT assoc-ref: supported even if cdr is #f > + (cut assoc chez-arch <>)) > + #t))) I think this should rather be explicit in %chez-features-table. You can prefix features that only work inside racket with 'racket-. Then, this can be solved with memq just as with chez-scheme's supported- systems in 7/9. Cheers
Hi, On 5/9/22 02:34, Liliana Marie Prikler wrote: > Am Montag, dem 09.05.2022 um 02:02 -0400 schrieb Philip McGrath: >> Once the issues in <https://racket.discourse.group/t/950> are >> resolved, 'chez-scheme-for-racket' and 'racket-vm-cs' will be able to >> run even on systems for which native code generation is not >> supported. It's not clear what behavior would be useful from 'nix- >> system->chez-machine': since the current implementation is flawed and >> easy to misuse, we remove it for now, replacing the remaining uses >> with 'racket-cs-native-supported-system?'. > I think you're again making a wrong assumption here. nix-system->chez- > scheme has purposes outside of solving supported-system. > Concretely, there are no other uses in Guix. I do not know a robust, correct way to use 'nix-system->chez-machine'---certainly not without it growing many additional features, like maybe computing endianness for pbarch backends when we are able to build them. For example, if we continued using it as we did in 'stex', you couldn't build a package graph for nonthreaded Chez simply by applying a package transformation to remove '--threads' from its '#:configure-flags', because that would change the machine type without updating the uses of 'nix-system->chez-machine'. >> +(define* (racket-cs-native-supported-system? #:optional >> + (system >> + (or (%current-target- >> system) >> + (%current- >> system)))) >> + "Can Racket's variant of Chez Scheme generate native code for >> SYSTEM? >> +Otherwise, SYSTEM can use only the ``portable bytecode'' backends." >> + (let ((chez-arch (target-chez-arch system)) >> + (chez-os (target-chez-os system))) >> + (and (and=> (assoc-ref %chez-features-table chez-os) >> + ;; NOT assoc-ref: supported even if cdr is #f >> + (cut assoc chez-arch <>)) >> + #t))) > I think this should rather be explicit in %chez-features-table. You > can prefix features that only work inside racket with 'racket-. Then, > this can be solved with memq just as with chez-scheme's supported- > systems in 7/9. > I don't understand this. The presence of an entry in '%chez-features-table' explicitly means that 'chez-scheme-for-racket' can generate native code. The idea is that the "portable bytecode" backends should work, including thread support, on any system with a reasonably capable C compiler. There are no other "features" that vary among systems for 'chez-scheme-for-racket'. It doesn't rely on pre-built bootfiles for bootstrapping. Since the initial fork at the beginning of 2017, when support for new systems has been added, native threads have been supported immediately. Racket regularly merges all changes from upstream Chez (which has not added any supported systems during that time---not even the systems added already in Racket's variant). These conditions are documented in the comments on '%chez-features-table'. If they ever ceased to hold, it would mean that the relationship between 'chez-scheme-for-racket' and upstream 'chez-scheme' had changed significantly, and we would probably need to reevaluate more broadly which variant to use where. -Philip
Hi, Am Montag, dem 09.05.2022 um 03:55 -0400 schrieb Philip McGrath: > Concretely, there are no other uses in Guix. > > I do not know a robust, correct way to use > 'nix-system->chez-machine'---certainly not without it growing many > additional features, like maybe computing endianness for pbarch > backends when we are able to build them. For example, if we continued > using it as we did in 'stex', you couldn't build a package graph for > nonthreaded Chez simply by applying a package transformation to > remove '--threads' from its '#:configure-flags', because that would > change the machine type without updating the uses of 'nix-system- > >chez-machine'. True, you would have to change the machine type, but I think I already noted that we might want to use this machine type as a distinguishing factor in packages built on top of chez (and later chez-build-system perhaps). You could do this the other way round by deriving flags from the given machine-type, e.g. stex for threaded chez machine is given -- threads, otherwise it's not. Since we have named symbols for these features, we could have a "package-with-chez-features" or similar transformer. Being able to specify this machine is a strength, not a weakness. > The presence of an entry in '%chez-features-table' explicitly means > that 'chez-scheme-for-racket' can generate native code. That is not explicit at all. There might be an explicit comment stating so somewhere, but in terms of actual code, it's super implicit. > The idea is that the "portable bytecode" backends should work, > including thread support, on any system with a reasonably capable C > compiler. The idea. In practice, what racket deems reasonably capable can change over time and might result in them dropping some architectures currently supported. What do you do then? > There are no other "features" that vary among systems for > 'chez-scheme-for-racket'. It doesn't rely on pre-built bootfiles for > bootstrapping. Since the initial fork at the beginning of 2017, when > support for new systems has been added, native threads have been > supported immediately. Racket regularly merges all changes from > upstream Chez (which has not added any supported systems during that > time---not even the systems added already in Racket's variant). I'd still make "supported-by-racket" or however else you decide to name that feature an explicit part of that table rather than an implicit one, or use a separate "table" for platforms supported by racket. Note that none of the racket-vm packages appear to currently carry supported-systems, which seems dubious. > These conditions are documented in the comments on '%chez-features- > table'. See above. Cheers
Hi, On 5/9/22 05:36, Liliana Marie Prikler wrote: > Hi, > > Am Montag, dem 09.05.2022 um 03:55 -0400 schrieb Philip McGrath: >> Concretely, there are no other uses in Guix. >> >> I do not know a robust, correct way to use >> 'nix-system->chez-machine'---certainly not without it growing many >> additional features, like maybe computing endianness for pbarch >> backends when we are able to build them. For example, if we continued >> using it as we did in 'stex', you couldn't build a package graph for >> nonthreaded Chez simply by applying a package transformation to >> remove '--threads' from its '#:configure-flags', because that would >> change the machine type without updating the uses of 'nix-system- >>> chez-machine'. > True, you would have to change the machine type, but I think I already > noted that we might want to use this machine type as a distinguishing > factor in packages built on top of chez (and later chez-build-system > perhaps). You could do this the other way round by deriving flags from > the given machine-type, e.g. stex for threaded chez machine is given -- > threads, otherwise it's not. Since we have named symbols for these > features, we could have a "package-with-chez-features" or similar > transformer. Being able to specify this machine is a strength, not a > weakness. > I can imagine something like this might be useful eventually. My problem is that, right now, 'nix-system->chez-machine' is an attractive nuisance: it sounds useful, but I don't know any way of using it that wouldn't be subtly wrong. I don't even feel certain even about what cases 'nix-system->chez-machine' would need to cover to be correct and useful: a fair amount seems to depend on what turns out to be necessary for cross-compilation and the portable bytecode architectures (which I hope to work out by July). >> The idea is that the "portable bytecode" backends should work, >> including thread support, on any system with a reasonably capable C >> compiler. > The idea. In practice, what racket deems reasonably capable can change > over time and might result in them dropping some architectures > currently supported. What do you do then? > I mean, "over time", at the extreme, anything "might" happen, but I don't think that's worth worrying about. Racket has an extremely strong commitment to backwards compatibility. To pick one example, support libraries for racket/draw and racket/gui are still maintained for ppc-macosx, which the vendor hasn't released any software for in a decade or more (depending on how you prefer to count). The C code deliberately does not require C99 support. >> The presence of an entry in '%chez-features-table' explicitly means >> that 'chez-scheme-for-racket' can generate native code. > That is not explicit at all. There might be an explicit comment > stating so somewhere, but in terms of actual code, it's super > implicit. > >> There are no other "features" that vary among systems for >> 'chez-scheme-for-racket'. It doesn't rely on pre-built bootfiles for >> bootstrapping. Since the initial fork at the beginning of 2017, when >> support for new systems has been added, native threads have been >> supported immediately. Racket regularly merges all changes from >> upstream Chez (which has not added any supported systems during that >> time---not even the systems added already in Racket's variant). > I'd still make "supported-by-racket" or however else you decide to name > that feature an explicit part of that table rather than an implicit > one, or use a separate "table" for platforms supported by racket. I really don't understand how this would be helpful. I don't think it would make sense for a list returned by chez-upstream-features-for-system to include a symbol supported-by-racket, which has nothing to do with *upstream* features. Aside from that, we would be adding this symbol to every single entry in %chez-features-table. That would imply turning all of the #f entries into (supported-by-racket), and then we would need some other solution for identifying platforms with no support upstream. > Note > that none of the racket-vm packages appear to currently carry > supported-systems, which seems dubious. > The only constraint on the systems supported by 'racket-vm-cs' is from 'chez-scheme-for-racket'---i.e., the trouble with `configure` for systems without a native-code backend, which should be fixed by the next release, if not before. I expect the fact that the 'chez-scheme-for-racket' input is not supported to work as an alternative to duplicating the filtering in its supported-systems field (which I think would create a cyclic dependency issue). AFAIK, 'racket-vm-cgc' and 'racket-vm-bc' should work everywhere (though possibly without the JIT, futures, and/or places) except that support for aarch64-macosx is prohibitively poor (IIUC due to W^X issues), which is fairly irrelevant for Guix. -Philip
Hi, Am Donnerstag, dem 12.05.2022 um 01:26 -0400 schrieb Philip McGrath: > > True, you would have to change the machine type, but I think I > > already noted that we might want to use this machine type as a > > distinguishing factor in packages built on top of chez (and later > > chez-build-system perhaps). You could do this the other way round by > > deriving flags from the given machine-type, e.g. stex for threaded > > chez machine is given -- threads, otherwise it's not. Since we have > > named symbols for these features, we could have a "package-with-chez- > > features" or similar transformer. Being able to specify this machine > > is a strength, not a weakness. > > > > I can imagine something like this might be useful eventually. My > problem is that, right now, 'nix-system->chez-machine' is an attractive > nuisance: it sounds useful, but I don't know any way of using it that > wouldn't be subtly wrong. Your 6/9 patch imho erases a use that wouldn't have been wrong. Certainly not if we add extra features to it or use inference at build time. For instance (let* ((base-system #$(nix-system->chez-machine (or (%current-target-system) (%current-system)))) (threaded? (member "--threads" configure-flags)) (portable-bytecode? [however you would determine that]) (actual-machine (string-append ...))) [code that uses actual-machine]) would be an alternative if you want actual-machine inferred by compile options rather than earlier on. > I don't even feel certain even about what cases 'nix-system->chez- > machine' would need to cover to be correct > and useful: a fair amount seems to depend on what turns out to be > necessary for cross-compilation and the portable bytecode > architectures (which I hope to work out by July). From my POV it is already enough if we can do the basic translation with nix-system->chez-machine. Additional features like threads or portable bytecode would be nice to have, but if you feel that it'd be "subtly wrong" to add them (or not to add them), you can feel free to add or omit them as you like. > > I'd still make "supported-by-racket" or however else you decide to > > name that feature an explicit part of that table rather than an > > implicit one, or use a separate "table" for platforms supported by > > racket. > > I really don't understand how this would be helpful. I don't think it > would make sense for a list returned by > chez-upstream-features-for-system to include a symbol > supported-by-racket, which has nothing to do with *upstream* > features. For one, that procedure would be free to filter features as it needs so that it doesn't return racket-specific symbols, but more importantly if you do feel that using this table to report racket support explicitly is abuse, how is it not abuse if you report it implicitly? > Aside from that, we would be adding this symbol to every single entry > in %chez-features-table. That would imply turning all of the #f > entries into (supported-by-racket), and then we would need some other > solution for identifying platforms with no support upstream. If I read this table correctly, there is no entry, that does not have either 'threads or 'bootstrap-bootfiles. So null? after filtering racket features would work. If this is ever violated, e.g. we find an arch that has neither bootstrap nor threads, but is still supported by upstream, we could add an explicit 'basic-upstream-support feature to the table. > > Note that none of the racket-vm packages appear to currently carry > > supported-systems, which seems dubious. > > The only constraint on the systems supported by 'racket-vm-cs' is > from 'chez-scheme-for-racket'---i.e., the trouble with `configure` > for systems without a native-code backend, which should be fixed by > the next release, if not before. Let's just assume that to be true. Even if so, why is "supported by racket" the condition for which we check rather than "not supported by upstream"? Seems kinda counterintuitive if racket supposedly supports all arches while chez itself does not. > I expect the fact that the 'chez-scheme-for-racket' input is not > supported to work as an alternative to duplicating the filtering in > its supported-systems field (which I think would create a cyclic > dependency issue). You might want to rephrase that sentence. I have no idea what you're trying to get across here. Cheers
diff --git a/gnu/packages/chez.scm b/gnu/packages/chez.scm index 41f083e0ac..cae17580f8 100644 --- a/gnu/packages/chez.scm +++ b/gnu/packages/chez.scm @@ -48,7 +48,7 @@ (define-module (gnu packages chez) #:use-module (srfi srfi-1) #:use-module (srfi srfi-26) #:export (chez-scheme-for-system - nix-system->chez-machine + racket-cs-native-supported-system? unpack-nanopass+stex)) ;; Commentary: @@ -132,19 +132,6 @@ (define* (target-chez-os #:optional (system (or (%current-target-system) (else #f))) -(define* (nix-system->chez-machine #:optional - (system (or (%current-target-system) - (%current-system)))) - "Return the Chez Scheme machine type corresponding to the Nix system -identifier SYSTEM, or @code{#f} if the translation of SYSTEM to a Chez Scheme -machine type is undefined. - -It is unspecified whether the resulting string will name a threaded or a -nonthreaded machine type." - (let* ((chez-arch (target-chez-arch system)) - (chez-os (target-chez-os system))) - (and chez-arch chez-os (string-append chez-arch chez-os)))) - (define %chez-features-table ;; An alist of alists mapping: ;; os -> arch -> (or/c #f (listof symbol?)) @@ -233,6 +220,19 @@ (define* (chez-upstream-features-for-system #:optional (and=> (assoc-ref %chez-features-table chez-os) (cut assoc-ref <> chez-arch)))) +(define* (racket-cs-native-supported-system? #:optional + (system + (or (%current-target-system) + (%current-system)))) + "Can Racket's variant of Chez Scheme generate native code for SYSTEM? +Otherwise, SYSTEM can use only the ``portable bytecode'' backends." + (let ((chez-arch (target-chez-arch system)) + (chez-os (target-chez-os system))) + (and (and=> (assoc-ref %chez-features-table chez-os) + ;; NOT assoc-ref: supported even if cdr is #f + (cut assoc chez-arch <>)) + #t))) + ;; ;; Chez Scheme: ;; @@ -459,7 +459,9 @@ (define-public chez-scheme-for-racket (add-after 'unpack 'chdir (lambda args (chdir "racket/src/ChezScheme")))))))) - (supported-systems (filter nix-system->chez-machine + ;; TODO: How to build pbarch/pbchunks for other systems? + ;; See https://racket.discourse.group/t/950 + (supported-systems (filter racket-cs-native-supported-system? %supported-systems)) (home-page "https://github.com/racket/ChezScheme") ;; ^ This is downstream of https://github.com/racket/racket, diff --git a/gnu/packages/racket.scm b/gnu/packages/racket.scm index 8438945ba0..f010cf3aa4 100644 --- a/gnu/packages/racket.scm +++ b/gnu/packages/racket.scm @@ -190,8 +190,11 @@ (define-module (gnu packages racket) (define* (racket-vm-for-system #:optional (system (or (%current-target-system) (%current-system)))) - "Return 'racket-vm-cs' if it supports SYSTEM; 'racket-vm-bc' otherwise." - (if (nix-system->chez-machine system) + "Return 'racket-vm-cs' if we are able to build it for SYSTEM; 'racket-vm-bc' +otherwise." + ;; Once we figure out the issues in https://racket.discourse.group/t/950, + ;; we can use 'racket-vm-cs' everywhere. + (if (racket-cs-native-supported-system? system) racket-vm-cs racket-vm-bc))