From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id YBGcLrWafGLHDQAAbAwnHQ (envelope-from ) for ; Thu, 12 May 2022 07:27:17 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id +MOILrWafGKpVwEA9RJhRA (envelope-from ) for ; Thu, 12 May 2022 07:27:17 +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 BF3EA1B1F7 for ; Thu, 12 May 2022 07:27:16 +0200 (CEST) Received: from localhost ([::1]:44930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1np1M3-0002nx-CZ for larch@yhetil.org; Thu, 12 May 2022 01:27:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1np1Lv-0002ld-8E for guix-patches@gnu.org; Thu, 12 May 2022 01:27:09 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45289) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1np1Lq-0004LC-Bu for guix-patches@gnu.org; Thu, 12 May 2022 01:27:06 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1np1Lq-0006V7-95 for guix-patches@gnu.org; Thu, 12 May 2022 01:27:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#55248] [PATCH v3 8/9] gnu: chez-scheme-for-racket: Fix supported systems. Resent-From: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 12 May 2022 05:27: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 Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Maxime Devos , Liliana Marie Prikler Received: via spool by 55248-submit@debbugs.gnu.org id=B55248.165233320524957 (code B ref 55248); Thu, 12 May 2022 05:27:02 +0000 Received: (at 55248) by debbugs.gnu.org; 12 May 2022 05:26:45 +0000 Received: from localhost ([127.0.0.1]:39186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1np1LZ-0006UT-As for submit@debbugs.gnu.org; Thu, 12 May 2022 01:26:45 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:35307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1np1LY-0006UF-1k for 55248@debbugs.gnu.org; Thu, 12 May 2022 01:26:44 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ED81A5C01C7; Thu, 12 May 2022 01:26:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 12 May 2022 01:26:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= philipmcgrath.com; h=cc: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=1652333198; x=1652419598; bh=GZr1DBgDyr IyJBeA9Ad1k4SobmhMJUz5YQifmtwrfT0=; b=nU5ToBMAGJupCofTJz0gtKW2WZ 3cfdNS2XRhCL4W72ihEfLFmqKD3e+xPx4yiQM58BcWhd72PktHMEbbAI3E7X1qID KOYNPz5/fovZuw9wEuTbbLdeml0OLMIi4Hh0hVsVzHxy0JrqGRsv6i15nsVuTeiy HXbf+Bf1ywguWgHcE2bIjnwHGEbmErGTl4Rj5RVtH4Jx30mp0VxDDke3xFUMhmpm yzvPYJYtzqL3WWVLDhS89qvSgyWyUxszGbKoFEGuPXXRF8zA+57KDQAuJ7+lQ1fj K7dZGuyTzyVZGImiDQVAVWzf9hsrs29ke6u/pj58MNeTb0ynCHDwZx1HMBOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=1652333198; x=1652419598; bh=GZr1DBgDyrIyJ BeA9Ad1k4SobmhMJUz5YQifmtwrfT0=; b=X50Dp5EyzLRvY1BJHLvx8u5VO+FWO zV5uyFtrRHCvDkfHLJVJbe8Gq6dwJd1u8QbLCZ/CyAvq7FG79vxJL4KyPmfphnJi 7P+1oUeBEeMx6o/vuLl79Ws2q+vCC5F+h99Ye1TwJQW72aPsUXmBTYnma/nuXVEx C6KQMMEl+yPS/QBZtveIhwI8CiUBIPbjGyURh0OPwZRkUIIuJatgMz551P0ZgN+Z 38VqJLIcLyyuZ5NQ/k9GCFiYERfBmOI52Nf8Q+g6MDkeH6yILpBdOOjprAUvWN27 vRfWOMp81a7AfTxc08FUM5nT4zCKIvG8eqdvW3Py6E4KI9Ju6emSzjMsg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgeeigdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomheprfhhihhl ihhpucfotgfirhgrthhhuceophhhihhlihhpsehphhhilhhiphhmtghgrhgrthhhrdgtoh hmqeenucggtffrrghtthgvrhhnpefgtdfgtefhveetheegjeffgfeltdfgvddvueevleel gedtieelhfdtgfeiueeileenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehphhhilhhiphesphhhihhlihhpmhgtghhrrghthhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 May 2022 01:26:38 -0400 (EDT) Message-ID: <885eb0ab-e5a5-fa20-3aeb-ade167775a28@philipmcgrath.com> Date: Thu, 12 May 2022 01:26:36 -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: <1328772b3ccb2d3909f8bca6fe14659e04434e3e.1652075689.git.philip@philipmcgrath.com> <1e7cf69aa12c81effaf2eb1ceff0997faca1cab2.camel@ist.tugraz.at> <7e8f385e-d2b5-6f38-fe4b-030748519574@philipmcgrath.com> <77ff7763a7c87424e7195e9f8624dbdd2a26193c.camel@ist.tugraz.at> From: Philip McGrath In-Reply-To: <77ff7763a7c87424e7195e9f8624dbdd2a26193c.camel@ist.tugraz.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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=1652333237; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=GZr1DBgDyrIyJBeA9Ad1k4SobmhMJUz5YQifmtwrfT0=; b=A1YoW1736T63wupd+53lOXKQFqvnWGmIXOYv4G0E2O6jvv+Nmf7fofIioeFY2+FpwHhKM4 rjOILX61NHBD3xndlpvF1IZTTx07Wb0DA8lF6sMJp3sTiLXYEQJ3z1cx+vg8ZQAHihWAix /NaYP7ykVqYLgkJWWqmPpIz1/FOD9w4wBUl0Y1tZa9eKJD9QSynrYL7ofatPY+SBcZqgl8 5Sfo1Ssh6HVp9EQZukVzpveueJcxgUGc0KrYta4fSaAPs3aJcjFoMtqk05OFLRMCewS290 DpRJUffjS6jw1Z/n2E1gG/e/R6hAXZTrbZBZlYTb7uZi24As+a9jQeJIkHjBdQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1652333237; a=rsa-sha256; cv=none; b=gxOBEq5RY1bCmiXpyOHadXuRIZUDr7ud00SSwhi+PX3u+HvvHFGiCB9aC1xT4t8hjM3z+v A9TVqzHiKwsW1/cPUilLtaobfuiVU955MnbNdHKm7KoBro5tOjZrmiuNb3m/Nevh/UqXMR Du48vpYmFteKtQ+J8vnAe5K4EI0cPa+XehIYGjJRaFBZW7sFelfUP4Kk740mGGxEIn1/O3 +UfmXrKEjJ/bdAsVRLYnzB42lBQkVM4QnQyOYtHmdL8VdrIAeHrKU88ndLdBItwzJ/AMj+ IZzOz8N9EUMsBdzotpQzHR4bIdMM58ASqQ/uMCcUEZ4/WA1+M2Z28GyMPoMz+Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=nU5ToBMA; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=X50Dp5Ey; 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: 1.59 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=nU5ToBMA; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=X50Dp5Ey; 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: BF3EA1B1F7 X-Spam-Score: 1.59 X-Migadu-Scanner: scn0.migadu.com X-TUID: tODjQOuKkpxR 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