From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id CEBJHgyBDWKYzAAAgWs5BA (envelope-from ) for ; Wed, 16 Feb 2022 23:56:12 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id WPQ3FwyBDWKikwAAG6o9tA (envelope-from ) for ; Wed, 16 Feb 2022 23:56:12 +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 B962C3BCC9 for ; Wed, 16 Feb 2022 23:56:11 +0100 (CET) Received: from localhost ([::1]:50700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKTDW-0005MJ-Ks for larch@yhetil.org; Wed, 16 Feb 2022 17:56:10 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40990) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKTDO-0005Ir-C4 for guix-patches@gnu.org; Wed, 16 Feb 2022 17:56:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:55788) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nKTDO-0004vb-27 for guix-patches@gnu.org; Wed, 16 Feb 2022 17:56:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nKTDO-00006a-2Y for guix-patches@gnu.org; Wed, 16 Feb 2022 17:56:02 -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: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 16 Feb 2022 22:56:02 +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: Liliana Marie Prikler , 53878@debbugs.gnu.org Received: via spool by 53878-submit@debbugs.gnu.org id=B53878.1645052109313 (code B ref 53878); Wed, 16 Feb 2022 22:56:02 +0000 Received: (at 53878) by debbugs.gnu.org; 16 Feb 2022 22:55:09 +0000 Received: from localhost ([127.0.0.1]:49685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nKTCW-00004y-OC for submit@debbugs.gnu.org; Wed, 16 Feb 2022 17:55:09 -0500 Received: from mail-qk1-f169.google.com ([209.85.222.169]:37578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nKTCU-0008WE-O9 for 53878@debbugs.gnu.org; Wed, 16 Feb 2022 17:55:07 -0500 Received: by mail-qk1-f169.google.com with SMTP id v5so697161qkj.4 for <53878@debbugs.gnu.org>; Wed, 16 Feb 2022 14:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=message-id:date:mime-version:user-agent:from:subject:to:references :content-language:in-reply-to:content-transfer-encoding; bh=RiWC+nZS8gp9oVClTgh1UrV0XoLJ0Te4Di48ELScWCE=; b=MMRKDahPZHgaICu4nboSmzp2g3RxW6WMl2kK3VMmltVygevwZEJKfBxQnh2Hpfv71f ZX2Ob3uof5I39klbA3RztIh7FCwQYGJXAW/BOjp7S7hEy/JJ84dvMPVhC8njqETl3Kj7 zn2Vx981F3FKMlZ8FtdjVYa1AgZjiKhomDZ/n653hMb7Vt9qMU6Ck2OmusrG9pvpC7ZU VtSPoqm6ehETHdpct35a+qt5EUbrijiaPNzrSG259DDx+mP4GfYUbaemCYzDvjBs0aaU RlIZBKGjRZukAtraOTY9poRY6k43YF1f8LtLQrcTyaHKs2ac5VZ2ytrICRlcyS19ibdd W6HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:references:content-language:in-reply-to :content-transfer-encoding; bh=RiWC+nZS8gp9oVClTgh1UrV0XoLJ0Te4Di48ELScWCE=; b=wOM9pqgpaksuj1Y8OdcFDjN5oF/E2FU4CmiWgIsqaA9Qp2j6Gw8bGoFYJHEidl8AiS m31gYQ6g5/U/oqZ4fnu+bPwTQRrd/U7sd0AGcxE/fR8jtVISWHTmUsiXUze1AKSMHOjd LaXeT4MNZj/7GLciswLPa+7Ly6v2gKPul/hob0MN9JF/FE+OTzBNwALI+kw0o838P3Ep hlxklhP0KJSEov79ZY6550mSX2OpeK2Wstv82GHuMFI6qlAwMefTB01X/IvkIIVsd0m4 TONsILWmbdLVuTiZZUJfL4XGPudrtiAxaB/AjrPmllY/WVsFh42BmRiE0kXPMy4iWPE0 t8Tw== X-Gm-Message-State: AOAM5339PbuWNzXURX9r9GBTzlArF/8bc8yAJ2nLyS7Vd1kJ0IGtrnRA 2+GbNKcCirilGgarnCYop3L+BoKnTyjm1Da73VQ= X-Google-Smtp-Source: ABdhPJz9768dVPmEKnZrTa7l9nA6lVQhPk3IsnpXtGlg/5ia+ECbq1DIXM01fuIE/NoEmr38SIOZrA== X-Received: by 2002:a37:e217:0:b0:508:b8a5:5713 with SMTP id g23-20020a37e217000000b00508b8a55713mr56504qki.618.1645052101123; Wed, 16 Feb 2022 14:55:01 -0800 (PST) Received: from [192.168.45.36] (c-73-125-98-51.hsd1.fl.comcast.net. [73.125.98.51]) by smtp.gmail.com with ESMTPSA id i12sm20721386qkn.83.2022.02.16.14.54.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Feb 2022 14:55:00 -0800 (PST) Message-ID: <220923bf-f243-8760-a0cf-1c77a26023cf@philipmcgrath.com> Date: Wed, 16 Feb 2022 17:54:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 From: Philip McGrath References: <20220213215127.218952-1-philip@philipmcgrath.com> <20220213215127.218952-5-philip@philipmcgrath.com> <20ade6d2f82b20f25d0eb1c8b2b5c409c189d05a.camel@ist.tugraz.at> Content-Language: en-US In-Reply-To: <20ade6d2f82b20f25d0eb1c8b2b5c409c189d05a.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-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1645052171; 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=RiWC+nZS8gp9oVClTgh1UrV0XoLJ0Te4Di48ELScWCE=; b=eTTjgafqjuVAWUpD/SyRzz+E2e8/U/crTicKPf162oIgJacvNgRc1wgHfp1AgmsEzLKDVn ijBDg2wxGzNXVcJ0V1oLLMCDigt+mT+2RzRNPHmKx+FJaWzyTJxIvL5WBZbMkmZTbbztT1 YULuYK5lBzH2OuHFY8vQ/y7/fwHNI+fZBI0Qc8nVYNDwDly7kv2cZ+cTpH0dzx7iMZJkQD uScpuMsZ5M1CDhpe/kJCvyzjmgF5g9hpeJJ6UO42Cer6SeP9+j/zduaQqvOMGFpAd9/ka+ akBNQF1vDDgB0mTZMKd/rB/LFmojom6sM4vXBh4ziVbfTTkO+1kwpL98XuN6ng== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1645052171; a=rsa-sha256; cv=none; b=RMnetGFQN4sXHQEBhWDaX5vbkK86mqdxDfMxXjPICa3VMK3gukKdI/CA72k/WLOw7Tcu5A QqhG5t9Mw06wRT9P9eJDZMZgBw8c89tv5cYAeTQLON4ljTMmYpRKU0jI7cyO6HULtPcJBD ZpYwg1tvq8UXqY1Fae9BvSDCpMft3S10rPeKVzdghqB79Vwt5DEwAlkRz5ZHWAyMOgKDV4 q2lGyTWkQ7bnRjekY5prbEsVvZ3jALqrYAQqhDCCJzWbzJ0TizjfSicULAEQq+42tjyunN QsapwJz3Q/0bUMZPR+580/rJ3xwupSMYPsJXHtA0vibA1CTCS3GFsSmANkdm4Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=MMRKDahP; 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: -2.93 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=MMRKDahP; 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: B962C3BCC9 X-Spam-Score: -2.93 X-Migadu-Scanner: scn0.migadu.com X-TUID: zDxk+weB8/yM Hi, On 2/14/22 09:34, Liliana Marie Prikler wrote: > Hi, > > Am Sonntag, dem 13.02.2022 um 16:51 -0500 schrieb Philip McGrath: >> [...] >> +(define (chez-machine->upstream-restriction mach) >> +  "Given a string MACH naming a Chez Scheme machine type, returns a >> symbol >> +naming a restriction on the upstream Chez Scheme implementation >> compared to >> +the Racket variant, or @code{#f} if no such restriction exists.  The >> +restriction is reported for the architecture--OS pair, regardless of >> whether >> +MACH specifies a threaded or an unthreaded variant. >> + >> +Possible restrictions currently include: >> +@itemize @bullet >> +@item >> +@code{'no-threads}: Support for native threads is not available >> upstream. >> +@item >> +@code{'no-support}: The upstream release doesn't claim to support >> this >> +architecture--OS combination at all. >> +@end itemize >> + >> +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. > "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 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. 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--- 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.) > > 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. -Philip