From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id AD6ECwSf9GAeOAAAgWs5BA (envelope-from ) for ; Sun, 18 Jul 2021 23:37:08 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id gEcTBwSf9GBCTgAA1q6Kng (envelope-from ) for ; Sun, 18 Jul 2021 21:37:08 +0000 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 53A562CFCD for ; Sun, 18 Jul 2021 23:37:07 +0200 (CEST) Received: from localhost ([::1]:39584 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5ETC-0006qp-Cw for larch@yhetil.org; Sun, 18 Jul 2021 17:37:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5ET8-0006qh-38 for guix-patches@gnu.org; Sun, 18 Jul 2021 17:37:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45988) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m5ET7-00007O-Ra for guix-patches@gnu.org; Sun, 18 Jul 2021 17:37:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m5ET7-0001Ka-Nd for guix-patches@gnu.org; Sun, 18 Jul 2021 17:37:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#49280] [PATCH 0/4] gnu: racket: Add racket-next. Bootstrap from C. Resent-From: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 18 Jul 2021 21:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49280 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 49280@debbugs.gnu.org Received: via spool by 49280-submit@debbugs.gnu.org id=B49280.16266441665051 (code B ref 49280); Sun, 18 Jul 2021 21:37:01 +0000 Received: (at 49280) by debbugs.gnu.org; 18 Jul 2021 21:36:06 +0000 Received: from localhost ([127.0.0.1]:57534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5ESD-0001JP-R2 for submit@debbugs.gnu.org; Sun, 18 Jul 2021 17:36:06 -0400 Received: from mail-qk1-f178.google.com ([209.85.222.178]:33768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5ESC-0001Iv-B1 for 49280@debbugs.gnu.org; Sun, 18 Jul 2021 17:36:04 -0400 Received: by mail-qk1-f178.google.com with SMTP id 23so14874317qke.0 for <49280@debbugs.gnu.org>; Sun, 18 Jul 2021 14:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3V6+ktDyKbzbZxhpPTJTR09o/LWtiVUK6TWiorfjXPQ=; b=QDXUls7Y9HLndgfzIebGOamzAGA5CctftwAvUn3idZmMKviUft64Cy8SuPbgg6lM9k Std7J1fMubVFoHhtBVqmtUsx9tHjS7ftrNkbM05IWUkQjq5Ro3RX76xrUIr6MiZ+IQwM fd7KtS9OOkx/48u5iYSKGysHE23JiRa3E0RcazkCdiCRSFoD/EKlGGJbbQQk3Px/Bowv mmSIPZSHKEf7ZWEPMacXpjzEt/an9m4qRrrzlwkoy42UuHa+HVtz2GFuqNK12kX9nZKE uoPfTqPXW1phQoGguJaiBeknhMejYN815YwDGW98ttuUW91PEJPyWtbGHC8pnYjXdiek jIjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3V6+ktDyKbzbZxhpPTJTR09o/LWtiVUK6TWiorfjXPQ=; b=M6hrhgP/Un24bqYx8D99bv11lzHWPiykIIzDuzhq6eYyIFydFtiyBbdOES+1AIdd8N WKG9WMzow/a2rvH4oAze2wBy+ZChEXJIVMlDH8kgiUNS2mtKtmYxNAIh6mXG+eQ4KAYc 7AtUfzzio6yREayXw0+X+4WnYj4iaVLQDjnRefP5R28h2uLEVLleoG0wTO+ODlkb0HqM 7HkRkWLvj6/TtC5EWEchSAallK6lypkIWtKj31HnHLRfH0tX2uxm8Wx/AFqq7PEgLoIt CXymkeGKq7iSu4byzcFT5w2n/5r/UW3HYQcashzPQQD84uiQ8RMdqSiN+iXeqLY7BOAf 9YeQ== X-Gm-Message-State: AOAM533OpIqrmI+UZ5a1voXbya02khLPP5uxxsStcSFz6e3kLCto1Q0W qBr9x6Hzlu4pq0K/CMxfZfb1EAydUWeQ3LgJiuw= X-Google-Smtp-Source: ABdhPJz3uD9iydIuqQZkng4FQAhTbogQ8by/jNO6WeGJTYx2/j1eEq7sjnXKcG8J4Aq2eJV7E/M6sg== X-Received: by 2002:a37:f506:: with SMTP id l6mr21271976qkk.468.1626644158549; Sun, 18 Jul 2021 14:35:58 -0700 (PDT) Received: from Sapientia.local (c-73-125-89-242.hsd1.fl.comcast.net. [73.125.89.242]) by smtp.gmail.com with ESMTPSA id o186sm7330658qke.44.2021.07.18.14.35.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Jul 2021 14:35:58 -0700 (PDT) References: <20210629215255.3110238-1-philip@philipmcgrath.com> <20210629215742.3112654-1-philip@philipmcgrath.com> <20210629215742.3112654-2-philip@philipmcgrath.com> <87lf6gjy5l.fsf_-_@gnu.org> From: Philip McGrath Message-ID: <270db91e-24f6-2754-7164-d0406aeebc60@philipmcgrath.com> Date: Sun, 18 Jul 2021 17:35:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <87lf6gjy5l.fsf_-_@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1626644227; 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=3V6+ktDyKbzbZxhpPTJTR09o/LWtiVUK6TWiorfjXPQ=; b=nU0KbNrXzI1EFuaWI7oYveybaAu5XdGwr8SDreKIOv4UdR3RdDJZ9yW6JojbsMvNsjmPOj 2kxe7FtkxGgQrbLbbVKyIB1m7tzeRmM87r/8pgSrQl8TIIZ7FY2HJziwBtAYZFY3Kk63+d +kjT9on7Kw/T+52u9mU69seQx0RvawWVEDEK9P6IKmvjPvEWKBxWDLQhkygICEsZeqpBaw 3xb+jpRsLqUATJSHeeNcCQvkXswurKAeleMkphsLoPmNS06SyVPivGKz+rf8RRDKf6mKXu /tyAvSzImfEzT2y+135rVi37G9Vhl2JI4tZagU4lVykAgHobNBrwnBPDsYT61Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1626644227; a=rsa-sha256; cv=none; b=EmNqNHHwgOT8OpQzxCSpWdkpIymYoKEbHdb3cCzDP+ZhVpgNp8iM7CdaYapYdP0z8SOZWp vB33Y6HA3F62/8shPra5mTtkk3H1hoWV4gNqmv4BBX+UA7PMrgVHApZe798iAQFaW0z6Ns QTmnQFFCWm6zxcG2qJ8bSTo5fi7ExqyGpUL8WX7RekWSgMJpl5rfRK/miEcfGixylGOWr6 9Ugat2q0Nio++eRMG9PCcHOve2gaSFH1TLyeN3XxkC91znmoTLjvhQ+0T8Aup7kYAK5WBy qgXozj+SIeuNeBrvd65HQNRNL1lmR9MY+2DN7QfRbpl7CCYgAwHPLrbg3kVgIQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=QDXUls7Y; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -1.41 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=QDXUls7Y; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 53A562CFCD X-Spam-Score: -1.41 X-Migadu-Scanner: scn0.migadu.com X-TUID: 4WoNQ95irMfX Hi! I've been mostly offline for a bit, and Racket 8.2 was released today (a little ahead of schedule), so I will rework this patch series to just update to 8.2 and not deal with adding "-next" variants for now. I'll respond to here, though, to keep the discussion together. On 7/8/21 5:25 PM, Ludovic Courtès wrote: > Philip McGrath skribis: > >> * gnu/packages/racket.scm (racket-next-minimal,racket-next): New variables. > > [...] > >> +++ b/gnu/packages/racket.scm >> @@ -23,6 +23,7 @@ >> #:use-module ((guix licenses) >> #:select (asl2.0 expat lgpl3+)) >> #:use-module (guix packages) >> + #:use-module (guix base16) > > Leftover? Yes, thanks! >> +;; - `racket-pkg-` should probably be the prefix for Racket packages >> +;; available as Guix packages, once we're able to build those. >> +;; More specifically, it should correspond >> +;; to packages registered in the catalog at https://pkgs.rackat-lang.org. >> +;; This is a social convention to manage the namespace, not a technical >> +;; limitation: Racket can use other catalogs (e.g. for pre-built packages >> +;; or packages pinned to specific versions), unregistered package source >> +;; urls, or purely local packages. But we also need a convention to >> +;; manage the namespace, so we should use this one. In practice, >> +;; all generally useful libre Racket packages are registered there. >> +;; We probably will need a clever encoding scheme to deal with the fact >> +;; that Racket package names can contain [A-Za-z_-], i.e. including "_", >> +;; which is not allowed in Guix package names. > > For this there’s already a documented convention (info "(guix) Package > Naming"), although part of it is undocumented. The prefix would rather > be “racket-” to match what we do with other packages–“ghc-”, “ocaml-”, > “guile-”, and so forth. I wrote these as statements in the hope of eliciting any disagreement :) The problem I see with using just “racket-” as the prefix is the potential for collisions, especially because Racket uses a lot of the namespace: for example, "_" is a useful example package for testing package issues, and I maintain the "_-exp" package. There don't seem to be Racket packages named "minimal" or "next" right now, but they seem reasonably likely to be used in the future, and Guix likewise may want to add packages that don't correspond directly to a single Racket-level package. (In fact, I think this may be necessary to build Racket packages with mutually recursive dependencies.) Other Racket package names that I think might be less confusing if prefixed with “racket-pkg-” include "base", "racket-lib", "unstable", "profile", "make", "data", "images", "compiler", "compatibility", "pkg-build", and "main-distribution". But we don't need to resolve this now, and maybe actually implementing that support will clarify what issues really do or don't exist. I will just remove this whole comment for now, since I don't need to make a choice between "racket-next-minimal" and "racket-minimal-next". >> +(define %pre-release-installers >> + "https://pre-release.racket-lang.org/installers/") >> + >> +(define-public racket-next-minimal >> + (package >> + (inherit racket-minimal) >> + (name "racket-next-minimal") >> + (version "8.1.900") >> + (source >> + (origin >> + (inherit (package-source racket-minimal)) >> + (sha256 >> + (base32 >> + "0dm849wvlaxpfgz2qmgy2kwdslyi515rxn1m1yff38lagbn21vxq")) >> + (uri (string-append %pre-release-installers >> + "racket-minimal-src.tgz")))))) >> + >> +(define-public racket-next >> + (package >> + (inherit racket) >> + (name "racket-next") >> + (version (package-version racket-next-minimal)) >> + (source >> + (origin >> + (inherit (package-source racket)) >> + (sha256 >> + (base32 >> + "0ysvzgm0lx4b1p4k9balvcbvh2kapbfx91c9ls80ba062cd8y5qv")) >> + (uri (string-append %pre-release-installers >> + "racket-src.tgz")))))) > > Do I get it right that *-src.tgz are not versioned? That they’re > updated in place regularly? > > In that case, we cannot refer to them in a package definition since the > hash is bound to become stale. > > What we could do is refer to, say, > . > However, I suspect this file would vanish fairly quickly from the web > site, which is not okay either. > > I’m not sure what a good solution would be. WDYT? > > It may be that > ‘--with-source=https://pre-release.racket-lang.org/installers/racket-src.tgz’ > would do the job for those who’re into that. This is also a good catch! For now, I will avoid the problem by just not dealing with "-next" variants. For posterity: while working on this patch series before the release, I faced a similar issue, because the "snapshot" builds explicitly are not retained indefinitely. As a work-around, I based my work on snapshots from Northwestern University (as opposed to the University of Utah), because they retain one snapshot per week for a few months. For the longer term, rather than using the tarballs directly, I used them to produce patch files, which I checked into Guix. Since minimal Racket could be build from Git, I could restrict the patch to main-distribution Racket package sources, which kept the size manageable. Something analogous would probably work for release candidates, but the right long-term solution is for Guix to be able to build Racket packages directly, so we don't have to rely on particular snapshot bundles. On 7/8/21 5:43 PM, Ludovic Courtès wrote: > I’d find it clearer like this: > > (add-before 'configure 'change-directory > (lambda _ > (chdir "racket/src"))) Ah, that's nice. > >> + (add-after 'install 'remove-pkgs-directory >> + ;; otherwise, e.g., `raco pkg show` will try and fail to >> + ;; create a lock file >> + (lambda* (#:key outputs #:allow-other-keys) >> + ;; rmdir because we want an error if it isn't empty >> + (rmdir (string-append (assoc-ref outputs "out") >> + "/share/racket/pkgs")) >> + #t))))) > > Please write full sentences with a bit more context (“Remove package > directory, otherwise ‘raco pkg show’ …”). Will do. >> +(define-public racket-next-minimal-bc-3m >> + (hidden-package >> + (package/inherit racket-next-minimal >> + (name "racket-next-minimal-bc-3m") > > This is “-next” because it’s targeting 8.1, which is not released yet, > right? Correct, but 8.2 (8.1 was released in May). Now that it's been released, the name would be "racket-minimal-bc-3m". > Since it’s only used for bootstrapping, perhaps use ‘define’ instead of > ‘define-public’ and remove the call to ‘hidden-package’. In addition to bootstrapping, there are three reasons I know of to want Racket BC: 1. The BC and CS implementations have different C APIs, so some low-level code may support BC but not CS. But this isn't usually a good reason. Racket packages should support both implementations. Embedding applications ideally would also be portable: if it's only feasible to support one implementation, it should be CS. 2. Comparing the BC and CS implementations can be useful for testing and debugging, both for packages that use the FFI and when hacking on the Racket runtime system itself. 3. Most importantly, BC supports some architectures that CS does not. In particular, Racket CS does not (yet) support ppc64le, which Racket BC does support. The recommendation to packagers, and what Debian does, is to explicitly use BC on platforms without CS support: https://github.com/racket/racket/issues/3773#issuecomment-832935403 I'm not sure what the most idiomatic way to do this is in Guix. (Just for the record, Racket CS also supports platforms which Racket BC supports only partially---without the JIT, places, or futures---or does not support at all. One motivation of Racket CS was to make porting easier in general.) > > It should also be (package (inherit …) …) rather than (package/inherit > …). The latter is only useful when defining variants of a package (same > version, same code) where the same security updates would apply. I don't think I understand this very well. Setting aside “-next”-related issues, a given commit in the Racket source repository will be used to build CGC, 3M, and CS (the default) variants with the same version---at least in the Racket senses of “version” and “variant”. It's possible that there could be a VM-specific security issue, but usually a bug in Racket, security-related or otherwise, will affect all three variants. >> + (inputs >> + `(("libffi" ,libffi) ;; <- only for BC variants >> + ,@(filter (match-lambda >> + ((label . _) >> + (not (member label >> + '("zlib" "zlib:static" >> + "lz4" "lz4:static"))))) >> + (package-inputs racket-next-minimal)))) > > Please use this more common idiom: > > ,@(fold alist-delete (package-inputs racket-next-minimal) '("zlib" …)) Thanks, I was looking for something like `alist-delete` but didn't find it. >> +This packackage is the normal implementation of Racket BC with a precise garbage collector, 3M (``Moving Memory Mana > ^ > Typo here, and lines too long (here and in other places). :-) Thanks, usually I have Emacs set up to catch that. >> + (license (package-license chez-scheme))))) > > You cannot do that since here since potentially we could end up with > circular top-level references from these two modules. > > Instead, restate what the license is. Ok, I'd been lulled into complacency by the implicitly thunked fields. - Philip