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 ms0.migadu.com with LMTPS id UI7/Ekr5DWL5egAAgWs5BA (envelope-from ) for ; Thu, 17 Feb 2022 08:29:14 +0100 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 gDxHEEr5DWJyAAEA9RJhRA (envelope-from ) for ; Thu, 17 Feb 2022 08:29:14 +0100 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 B49A0FE83 for ; Thu, 17 Feb 2022 08:29:13 +0100 (CET) Received: from localhost ([::1]:44338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKbE0-0004HH-6j for larch@yhetil.org; Thu, 17 Feb 2022 02:29:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38494) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKb9y-00013U-Rg for guix-patches@gnu.org; Thu, 17 Feb 2022 02:25:06 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:56075) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nKb9y-0000rS-3U for guix-patches@gnu.org; Thu, 17 Feb 2022 02:25:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nKb9x-0006tW-OI for guix-patches@gnu.org; Thu, 17 Feb 2022 02:25:01 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#53878] [PATCH 04/11] gnu: chez-and-racket-bootstrap: Add utilities for Chez machine types. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 17 Feb 2022 07:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53878 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Philip McGrath , 53878@debbugs.gnu.org Received: via spool by 53878-submit@debbugs.gnu.org id=B53878.164508269226482 (code B ref 53878); Thu, 17 Feb 2022 07:25:01 +0000 Received: (at 53878) by debbugs.gnu.org; 17 Feb 2022 07:24:52 +0000 Received: from localhost ([127.0.0.1]:49972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nKb9n-0006t4-A8 for submit@debbugs.gnu.org; Thu, 17 Feb 2022 02:24:51 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:23410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nKb9X-0006sb-6A for 53878@debbugs.gnu.org; Thu, 17 Feb 2022 02:24:50 -0500 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4JzmY54c80z3wCX; Thu, 17 Feb 2022 08:24:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1645082665; bh=pOAaC5bx7eDOl9mANas8M/i4XMtgOHuYO9FknFu8mDc=; h=Subject:From:To:Date:In-Reply-To:References; b=Iv4/E9D498rllX9akhBqtmvRJQI3OQ9y5rT9IqJo7s//xI9/IyLogmSntOhmSRgyY MZ8y/1j0jir13XngDQwyA2inLhfl7/G/YcgjnhxDu3wNDPRafCqUh/HZPok2e1R+Nm 1mBK2LaeKu2X/XtnOdluDQ5l6auyfiV1u73yQYU0= Message-ID: From: Liliana Marie Prikler Date: Thu, 17 Feb 2022 08:24:24 +0100 In-Reply-To: <220923bf-f243-8760-a0cf-1c77a26023cf@philipmcgrath.com> References: <20220213215127.218952-1-philip@philipmcgrath.com> <20220213215127.218952-5-philip@philipmcgrath.com> <20ade6d2f82b20f25d0eb1c8b2b5c409c189d05a.camel@ist.tugraz.at> <220923bf-f243-8760-a0cf-1c77a26023cf@philipmcgrath.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 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-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1645082953; 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=pOAaC5bx7eDOl9mANas8M/i4XMtgOHuYO9FknFu8mDc=; b=CSko3UIsPEfhQ5VJukxvYiFWtxviw6e+t00G8JRqC0gVojnqZ2W8r9e82KKqfAY2gWfG/Y sbBjTfGe0EksK1BqyfzJSyv0cc3GFMxelZEXL2v3EpfGCNk++EnjynHEroKvU1cRjv/uwq z8LZCPXPvbiZg5mgmIuNv3RzGHWp1wjUBTFj3lMg6HfwuEwLZ5xqqMB2ap5OUSuIFud/VI 6/Q+s9LQPUjTwyftUdic04PG7gqNNuLwdnq+3e8J+uN7V+5pbGfnNbaeW5f868E57IZOd3 ek4z1dhlLROH8mM8z0xXrEkZh+KMSsaMFeHTZwZSps6Sbp5uwxhXo3feXziq/w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1645082953; a=rsa-sha256; cv=none; b=AhYESCgvEyL9ElkXzimNPDm+FcyYtrXVsLI9x7je+rENsGI00v6T9bbps5B3d9TUBqgnSP uRk07aV83lH6nAe7NTkPVo6/tIeM9NBrsnBBroUYoP+SLqIVtaZ91nQ9oKjL6y6Mbtr99v jNtWi/nCM3KgYK4OAmNXDc8gJZipJLKxcA7k8YGPsWe2Xwq2fTqcIussnKEpPwlSrJn3BF YzqD0CeWdkNSmNGVqV6F/x4zOmgbAGlOYIwyjbjJlDtYbt9o+q7GtHZ2OaRkquzEqCWNw/ Id4P6KcWvVJeT//WS6Q/ddisXmTrQZtvs4MbYmjiRXfJlZkxeA3iJ1PMLG8sHA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b="Iv4/E9D4"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=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: -2.23 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b="Iv4/E9D4"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=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: B49A0FE83 X-Spam-Score: -2.23 X-Migadu-Scanner: scn1.migadu.com X-TUID: ZPVX5U0dtR1t Hi, Am Mittwoch, dem 16.02.2022 um 17:54 -0500 schrieb Philip McGrath: > > > +See @code{chez-machine->nix-system} for more details about > > > acceptable values > > > +for MACH." > > > +  (let ((mach (chez-machine->unthreaded mach))) > > > +    (cond > > > +     ((string-prefix? "arm64" mach) > > > +      'no-support) > > > +     ((string-prefix? "arm32" mach) > > > +      (if (string-suffix? "le" mach) > > > +          'no-threads > > > +          'no-support)) > > > +     ((string-prefix? "ppc32" mach) > > > +      (if (string-suffix? "le" mach) > > > +          #f > > > +          'no-support)) > > > +     (else > > > +      #f)))) > > -> is a conversion operator, not an "accessor". > > I thought of this as a conversion more than an accessor. Conversion follows the lines of "is (roughly) a", whereas this is a "has a" relation, which would imply accessing things. > > "upstream-restriction" sounds rather negative, I'd rather have > > (chez-machine-features), which yields #f if the machine is > > unsupported and a (possibly empty) list of features otherwise, such > > as '(threads). > > > > I'm also not quite sure what the point is behind using chez > > machines here.  Why not simply test the systems with the predicates > > we already have, i.e. target-arm64?, target-arm32?, target-linux?, > > target-ppc32?, > > ... > > I agree that the name of this procedure should avoid sounding > negative: 'restriction' was the best I'd come up with so far. I > think I like 'chez-machine-features' somewhat better, but with a few > reservations. > > Using predicates like 'target-arm32?' makes some sense overall, and > I'll try it. One subtly (sic) is that systems supported by neither > upstream nor Racket are currently handled by `and=>` in clients. > > Also, I guess it's odd to have this function operate on Chez Scheme > machine types anyway, since a machine type specifies threaded or > unthreaded. Not sure how to deal with these reservations or what they'd imply, so following along. > I'm currently thinking something like: > > --8<---------------cut here---------------start------------->8--- > (define* (chez-upstream-features-for-system #:optional >                                              (system (or > (%current-target-system) >   > (%current-system)))) >    (cond >     ((not (nix-system->chez-machine system)) >      #f) >     ((target-arm64? system) >      #f) >     ((target-arm32? system) >      (and (target-linux? system) >           '())) >     ((target-ppc32? system) >      (and (target-linux? system) >           '(threads))) >     (else >      '(threads)))) > --8<---------------cut here---------------end--------------->8--- Haven't tested this, but LGTM. > Alternatively, there could be an argument called something like > "variant", where the default would be 'upstream or maybe #f, and > supplying 'racket would always return '(threads). (Racket CS requires > the threaded version of Chez Scheme, so the chez-scheme-for-racket > has consistently added thread support immediately upon adding any new > target.) I don't think delegating to racket this soon is a good idea. > > And as a minor pet peeve, you ought to spell out machine. > > > > Ok, will do. > > > > > > +(define* (nix-system->chez-machine #:optional (system (%current- > > > system)) > > This should have been (or (%current-target-system) (%current- > system)). > > > > +                                   #:key (threads? 'always)) > > > +  "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. > > > + > > > +When THREADS? is @code{'always} (the default), the threaded > > > variant > > > of the > > > +machine type will be returned: note that the package returned by > > > +@code{chez-scheme-for-system} will always support native > > > threads. > > > When > > > +THREADS? is @code{#f}, the unthreaded machine type will be > > > returned.  If > > > +THREADS? is @code{'upstream} (the default), the threaded variant > > > of > > > the > > > +machine type will be returned if and only if it is supported by > > > upstream Chez > > > +Scheme (see @code{chez-machine->upstream-restriction}).  If > > > THREADS? > > > is any > > > +other value, an exception is raised." > > What's the point in having THREADS? 'always?  In any case, assuming > > chez-machine-features is to be exported, this can easily be checked > > -- > > even if not, we can add the check internally by writing > >    #:key (threads? (chez-supports-threads? system)) > > > > > +  (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)) > > > +         (mach (and chez-arch chez-os (string-append chez-arch > > > chez- > > > os)))) > > This series of let-bindings should probably be done in a separate > > function called nix-system->chez-machine. > > On the one hand, the result of 'chez-scheme-for-system' will always > support threads, so being threaded by default is convenient. On the > other hand, it looks like I've reduced the use of this function (by > searching for files rather than coding in the machine type directory) > enough that it doesn't have a big impact either way. It will be more > important when we support cross-compilation, and I think we should > keep these functions internal and defer as much as possible of their > API design until then. > > For now, I think I'll say that it's unspecified whether the result is > a threaded or unthreaded machine type and add > `chez-machine->{un,}threaded` as needed. I think you can keep (chez-supports-threads? system) hidden even when using it to instantiate defaults. I currently don't see the relation between chez-scheme-for-system and nix-system->chez-machine, so if that's relevant, you'd have to clarify. Cheers