From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 yNwYGuS/fGLAdQAAbAwnHQ (envelope-from ) for ; Thu, 12 May 2022 10:05:56 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 6FHUGeS/fGI5XwEAauVa8A (envelope-from ) for ; Thu, 12 May 2022 10:05:56 +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 DE22B1EE54 for ; Thu, 12 May 2022 10:05:55 +0200 (CEST) Received: from localhost ([::1]:37672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1np3pa-0004mx-II for larch@yhetil.org; Thu, 12 May 2022 04:05:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1np3ol-0004kv-2D for guix-patches@gnu.org; Thu, 12 May 2022 04:05:08 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45564) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1np3oj-00023t-UI for guix-patches@gnu.org; Thu, 12 May 2022 04:05:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1np3oj-0005Hn-PJ for guix-patches@gnu.org; Thu, 12 May 2022 04:05:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#55248] [PATCH v3 8/9] gnu: chez-scheme-for-racket: Fix supported systems. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 12 May 2022 08:05:01 +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: Philip McGrath , 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.165234267820270 (code B ref 55248); Thu, 12 May 2022 08:05:01 +0000 Received: (at 55248) by debbugs.gnu.org; 12 May 2022 08:04:38 +0000 Received: from localhost ([127.0.0.1]:39459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1np3oL-0005Gq-Ti for submit@debbugs.gnu.org; Thu, 12 May 2022 04:04:38 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:8051) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1np3oJ-0005Gh-Ty for 55248@debbugs.gnu.org; Thu, 12 May 2022 04:04:37 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4KzPSc1MfMz3wbn; Thu, 12 May 2022 10:04:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1652342672; bh=cVJV9DG8ycs4KFa2Yo/JqwRUhfavxmjdIyqJx2CRlEk=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ImbEiiKwP64e6MZpxqtR13TZtfc08hCWE4lEc74HbPcD/QJH2HIr6ysF6FiTVmpQk 6WcuUNOqY8rxrRzbTCtU2roFhOt7rXII1AUZOoJEEkHnnPL9j7ChecGdWiMn6VXdVq GyDJ5W0fLL2ftYpeaT+oeNzJZnd55ASn6M3kcSIc= Message-ID: From: Liliana Marie Prikler Date: Thu, 12 May 2022 10:04:31 +0200 In-Reply-To: <885eb0ab-e5a5-fa20-3aeb-ade167775a28@philipmcgrath.com> References: <1328772b3ccb2d3909f8bca6fe14659e04434e3e.1652075689.git.philip@philipmcgrath.com> <1e7cf69aa12c81effaf2eb1ceff0997faca1cab2.camel@ist.tugraz.at> <7e8f385e-d2b5-6f38-fe4b-030748519574@philipmcgrath.com> <77ff7763a7c87424e7195e9f8624dbdd2a26193c.camel@ist.tugraz.at> <885eb0ab-e5a5-fa20-3aeb-ade167775a28@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-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=1652342756; 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=cVJV9DG8ycs4KFa2Yo/JqwRUhfavxmjdIyqJx2CRlEk=; b=D3a3KSJNU8KN1a6/x0FsFCnYliZ0Fz4reWEXAzNF9z0gRbHraOtcuxUQBXNvdn3/4FfX2O 1cJ6yxNwHGZ6Ds3peFh/WBM4P9702H1nDTa5B/n8FqZYs8GlBvaZ/HSmO8yGJmVNFW21V/ vv8vrxpxrbpCza0T6L6W32zNGG755aiR/RdQgU2MbDsf2+dX9mcv9UdRI7votB4xD+o6cp Ga/CVawRX8xCwwNOZHA8IrGUkkpDi44z1R4USh4yiVKHZqchygoXIVUZfz/YiDJSDI0xzS t7PQqCYZpmt37yYDjBR4N+GlhE0cctMW/wvBCq/leRbs4R4zeleMeTeQ1hH7VA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1652342756; a=rsa-sha256; cv=none; b=twgfoKRM6Fb+NfX3l1VxcIj4t8r2NbUcbBhaiG1Q2CFE9L277tD2p44efkxmVtWGlZ9oPY X4lNNO2ADkeiE3Em5LOQpWil9OEK01HsZ42YSwxbc1s2aXe+r+d0vjkfFrpRixoZzmuAzQ IeJ+JfFvk19EvmZKRXA7dsLYrg9S+RF0xm5KUL3SE8vqUcClB0psJafNKbQqsIlZxjkd18 v2ZdEQknCZy93MC5Xfo34ZOmSAC3lCWmC7dU2Dydv2HlpUxszrD4QyiFml7et2+P2o7biV Rzfps1t67FleADWUhmxVJfCZVAt5OHoiR7JLFWawaE8vbT4ONhliDfsqahu1zQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=ImbEiiKw; 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: 6.49 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=ImbEiiKw; 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: DE22B1EE54 X-Spam-Score: 6.49 X-Migadu-Scanner: scn0.migadu.com X-TUID: PvL/22gRWjD9 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