From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id cMWxMeI2dGJnEAAAbAwnHQ (envelope-from ) for ; Thu, 05 May 2022 22:43:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id yD7MMeI2dGKBGAEA9RJhRA (envelope-from ) for ; Thu, 05 May 2022 22:43:14 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B56C12A3C0 for ; Thu, 5 May 2022 22:43:13 +0200 (CEST) Received: from localhost ([::1]:42424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmiJc-00009M-NG for larch@yhetil.org; Thu, 05 May 2022 16:43:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44086) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmiJS-00005H-DO for guix-patches@gnu.org; Thu, 05 May 2022 16:43:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52704) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nmiJS-0003mR-3z for guix-patches@gnu.org; Thu, 05 May 2022 16:43:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nmiJS-0007iE-22 for guix-patches@gnu.org; Thu, 05 May 2022 16:43:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#55248] [PATCH 7/7] gnu: chez-scheme-for-system: Adjust support logic. Resent-From: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 05 May 2022 20:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55248 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler , 55248@debbugs.gnu.org, Maxime Devos Received: via spool by 55248-submit@debbugs.gnu.org id=B55248.165178336329621 (code B ref 55248); Thu, 05 May 2022 20:43:02 +0000 Received: (at 55248) by debbugs.gnu.org; 5 May 2022 20:42:43 +0000 Received: from localhost ([127.0.0.1]:46601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmiJ9-0007hg-0D for submit@debbugs.gnu.org; Thu, 05 May 2022 16:42:43 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:41625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmiJ7-0007hR-5A for 55248@debbugs.gnu.org; Thu, 05 May 2022 16:42:42 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id E514B3200645; Thu, 5 May 2022 16:42:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 05 May 2022 16:42:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= philipmcgrath.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1651783354; x=1651869754; bh=ijyASzVAQT1Jdx7Zpv6Jiye3H C0vHhssWPmVE+3CCQk=; b=I9TrVprrLnoFY+MwHzvQSzacoAuquzeN0AU2HVGKW MGcsqgy00lZYVy7FKSRG5ELe6ygLRrndwcOZsm3CR4woS/DEJchEPMhu+DMERXTh k6mIWBWtlXXAt8CW276S0Pyjpk1i5O7djNsFm9JeYkcnRNCDoBo6NOIrM3W0Utdm kdIwGVrUYbFRfJBo9N3ZGWRNnaUJdX6J4sljVfokTizPkxUYf3md28NeVHSP1i2w URRrXP3QtqJoHI+zkd7dnWkQhD7HVDVaZSelA6GDXD5HVPajqah1ZKRVP9OimfeS Iph7jNXRgF2Ji9+9X1YCK6dfK13uahcF37nEJyMeytUZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1651783354; x=1651869754; bh=ijyASzVAQT1Jdx7Zpv6Jiye3HC0v HhssWPmVE+3CCQk=; b=br3zeZjpo75tTrXDgoIe8LH0zWSx8liz1ID3Mj983E1f pC92V+h4V+z3PkX3BZlAJqGkb/yZW0IXlxA35wuuJW4cfYKkyWH00UGFQNv3+NAP wDfvs2w3jem5UKflFJrwSSW6MSI40OJwdwPplj9YRFoPHa3xleuI67NKKPN2rkkA CkWujMzf03JsioLoGs5k2ZK93XFawj4GbBc3iCiF6+T7d/X/x+zLE7MVYjmo6Q4I CTUPX0dH83TGxMr4XJvJvq7edCn8UiVmav/7rW9rDs3tXVwb+ueYzgYcRwiq/1ts oqCeLLB36H6FA/Z1ThZgsjvWxpi8a6XLz2qFtoxakA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedugddugeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheprfhhihhl ihhpucfotgfirhgrthhhuceophhhihhlihhpsehphhhilhhiphhmtghgrhgrthhhrdgtoh hmqeenucggtffrrghtthgvrhhnpedvudfhheelveegleetfedvgfetgedugfdtiedttdef ffeuheeiveduieffgeefgfenucffohhmrghinhepghhnuhdrohhrghdpghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep phhhihhlihhpsehphhhilhhiphhmtghgrhgrthhhrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 May 2022 16:42:33 -0400 (EDT) Message-ID: <770e2e49-e27c-dbfb-ee03-e2886df94f42@philipmcgrath.com> Date: Thu, 5 May 2022 16:42:32 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US References: <9ba89b23f86a163679047f113e3524b4352df55d.1651594312.git.philip@philipmcgrath.com> <1dc114e6acd0320c553837e1d9f5d94e4e8c800d.camel@ist.tugraz.at> From: Philip McGrath In-Reply-To: <1dc114e6acd0320c553837e1d9f5d94e4e8c800d.camel@ist.tugraz.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1651783394; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ijyASzVAQT1Jdx7Zpv6Jiye3HC0vHhssWPmVE+3CCQk=; b=lNBJoRe6eWyYHb4ELPWtJtw/TuZzD2sdxbghaLc89U4KQs6Pdhar59ke/sibjwwPujD0Zo BIDznrzVriGMc53vpxQH8qN4CYAOYcobHry9d0iJwp+ON+VH6dN+L+aZAWGkxWIwwh9Jnu fKSnewc28YScJvrWrDRhofJbEE8WYqbvtKdqefaIi0V7xqbc9ver5YIqx5BG4TP02I871U QfzeEbp0u7q2GJ8/R5eAQz3YyGAZzVONucLxE9l6Kjlcjnszy88Eu/qU1McdcSwxaCkqWE rfMigHdveMLBa27FQOdq5WLHYOZd6O2qVGE9WGd7KxQgUZjl1joYD95RMWXcTg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651783394; a=rsa-sha256; cv=none; b=j70SfyQlgXpxCT/eW7oIelQX4RaMvyz5p8rY9QJw+4rZYkWs/vcusvp+RkqftzB1vyuu+3 qx7X/nyI0XL2CGYM1VQh11hNinwxMDaQ8W+OwZGbKIJa7JUs9F8W57Nc6jQ7rCJ+YIpMHf vZFNYhs0xxpQ4TtZEUxv2My5Qlz7TRezoGCymXm+v933fz5SLYptVT7cas66hxx8kLUj// E6sQIEwUgpPLXPJcaXGtvoqbYb8fO4NDUoz+qmBGwt5vShfoWJrAemh2vQeKszY4ag+oGS PJjTjXXPBLtGDQwap1Zqn1Ie+4A4zjDbOth3T2+09hZHJsYWAbK8Tki55ottAg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=I9TrVprr; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=br3zeZjp; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 0.91 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=I9TrVprr; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=br3zeZjp; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: B56C12A3C0 X-Spam-Score: 0.91 X-Migadu-Scanner: scn1.migadu.com X-TUID: 9ZoiSNo3LLuJ Hi, On 5/4/22 03:21, Liliana Marie Prikler wrote: > Am Dienstag, dem 03.05.2022 um 14:33 -0400 schrieb Philip McGrath: >> This is a follow-up to commit >> b8fc9169515ef1a6d6037c84e30ad308e5418b6f: >> see . Thanks to Liliana Marie >> Prikler for pointing out various issues, e.g. that being able to >> represent a Nix system as a Chez Scheme machine type does not >> necessarily mean the system is supported! > The issue in that commit is a different one: nix-system->chez-machine > can fail if there's no conversion. Anyway... > The issue fixed in the commit is different, but this issue hadn't occurred to me until you wrote in : > I pushed that definition upstream, but a rewrite is still needed. I > also think this logic should be a little decoupled from the question of > whether or not a given nix-system is supported. While surely this > function returning #f means it's not, there are still other questions > to consider. >> [...] >> ;; Commentary: >> @@ -73,96 +71,17 @@ (define* (chez-scheme-for-system #:optional >>                                               (%current-system)))) >>    "Return 'chez-scheme' unless only 'chez-scheme-for-racket' >> supports SYSTEM, >>  including support for native threads." >> -  (if (or >> -       ;; full support upstream >> -       (and=> (chez-upstream-features-for-system system) >> -              (cut memq 'threads <>)) >> -       ;; no support anywhere >> -       (not (nix-system->chez-machine system))) >> +  (if (and=> (chez-upstream-features-for-system system) >> +             (lambda (features) >> +               (every (cut memq <> features) >> +                      '(threads >> +                        ;; We can cross-compile for platforms >> without >> +                        ;; bootstrap bootfiles, but we can't self- >> host >> +                        ;; on them short of adding more binary >> seeds. >> +                        bootstrap-bootfiles)))) >>        chez-scheme >>        chez-scheme-for-racket)) > Does it make sense to require 'threads always? > I guess there are a few notions of "always". In 'chez-scheme-for-racket', yes, because Racket CS needs thread support for "futures" and "places". (Racket BC had a notion of platforms where those features were not available, but AFAIK there isn't support for a non-threaded configuration of Racket CS.) For 'chez-scheme', every distribution I'm aware of packages the threaded version (only) on platforms where thread support is available. The only reason to use the nonthreaded version is if you know for sure that your application doesn't use threads---IIRC, that may even include any FFI libraries not using threads internally---AND the small performance gain from not implementing thread safety internally makes a difference. For 'chez-scheme-for-system', I don't have a strong view, but the fact that I think the benefits of thread support are significant makes me lean that way. Concretely, the answer to this question only affects armhf-linux, so I think we should not change this at least until we re-enable it in upstream Chez's 'supported-system'. >> -(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: when the distinction is relevant, use >> -@code{chez-machine->nonthreaded} or @code{chez-machine->threaded} to >> adjust >> -the result." >> -  (let* ((hyphen (string-index system #\-)) >> -         (nix-arch (substring system 0 hyphen)) >> -         (nix-os (substring system (+ 1 hyphen))) >> -         (chez-arch (assoc-ref %nix-arch-to-chez-alist nix-arch)) >> -         (chez-os (assoc-ref %nix-os-to-chez-alist nix-os))) >> -    (and chez-arch chez-os (string-append chez-arch chez-os)))) >> - > The replacement code should go here for readability imho. At the very > least I was confused why this was first above and now below. > Happy to move things. Specifically, do you want 'target-chez-arch' and 'target-chez-os' (and '%chez-features-table'?) before 'chez-upstream-features-for-system' and 'racket-cs-native-supported-system?'? >> + > For the sake of completeness, we might want to still have nix-system- >> chez-machine (with a threaded? argument) defined in terms of target- > chez-arch and target-chez-os. See 6/7 for motivation. > Eventually, I imagine we will want to have a function like 'nix-system->chez-machine', but I think it would be better to wait until we have a concrete use-case. In particular, what I'd written here: >> -Note that this function only handles Chez Scheme machine types in >> the >> -strictest sense, not other kinds of descriptors sometimes used in >> place of a >> -Chez Scheme machine type by Racket, such as @code{\"pb\"}, >> @code{#f}, or >> -@code{\"racket\"}. (When using such extensions, the Chez Scheme >> machine type >> -for the host system is often still relevant.)" is no longer necessarily true, thanks to the improvements in the "portable bytecode" backends. >> >>  ;; >>  ;; Chez Scheme: >> @@ -365,14 +414,9 @@ (define-public chez-scheme >>                    ((pth) >>                     (symlink pth >>                              "csug.pdf"))))))))) >> -    ;; Chez Scheme does not have a  MIPS backend. >> -    ;; FIXME: Debian backports patches to get armhf working. >> -    ;; We should too. It is the Chez machine type arm32le >> -    ;; (no threaded version upstream yet, though there is in >> -    ;; Racket's fork), more specifically (per the release notes) >> ARMv6. >>      (supported-systems >>       (delete >> -      "armhf-linux" ;; <-- should work, but reportedly broken >> +      "armhf-linux" ;; XXX is this still broken? > I'd say "XXX: reportedly broken, needs checking" That seems better, particularly given e.g. : > > it is likely musl-related since I assume that arm32le is well tested > in conjunction with glibc > > That's probably not the best assumption... arm32le is not tested in > GitHub automation, and the last work that I know for sure was done on > it was for a project that is now defunct. I'm sure it was working and > tested at some point, but bit rot may have set in. > > All in all, the individual logic of this patch seems fine, but overall > it appears as though it's doing three separate things (chez-scheme-for- > system, chez features, racket-cs stuff). IMO it would make sense to > split this patch according to those lines. WDYT? > I don't think I'm picturing what you have in mind. The way I've been thinking of this patch is replacing the Chez features and machine type functions based on '%chez-features-table', then updating other things accordingly. I guess there is a distinguishable change to the behavior of 'chez-scheme-for-system' for systems with no native-code backed. I could separate that, if you want. On the other hand, it continues to return a package that can't actually be built for the specified system, so the change seems mostly theoretical. In terms of "racket-cs stuff", 'racket-cs-native-supported-system?' seemed better than any name I could come up with based on 'chez-scheme-for-racket', but the answer is based only on Racket's variant of Chez scheme. The old version based on 'nix-system->chez-machine' was just wrong (it would falsely claim to support e.g. "powerpc-w64-mingw32"), and we didn't have a way to implement a correct function until adding the information in '%chez-features-table'. -Philip