From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id UFI+H9uF9WIOfwAAbAwnHQ (envelope-from ) for ; Fri, 12 Aug 2022 00:42:35 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id sE8nH9uF9WJqEAEA9RJhRA (envelope-from ) for ; Fri, 12 Aug 2022 00:42:35 +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 C0B0C332CA for ; Fri, 12 Aug 2022 00:42:34 +0200 (CEST) Received: from localhost ([::1]:36636 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMGsq-0001MC-0K for larch@yhetil.org; Thu, 11 Aug 2022 18:42:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37102) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMGsL-0001L1-VN for guix-patches@gnu.org; Thu, 11 Aug 2022 18:42:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:37178) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMGsL-0005fk-N4 for guix-patches@gnu.org; Thu, 11 Aug 2022 18:42:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oMGsL-0004FW-Ih for guix-patches@gnu.org; Thu, 11 Aug 2022 18:42:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#57050] [PATCH v2 05/13] gnu: racket: Update to 8.6. Resent-From: "Philip McGrath" Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 11 Aug 2022 22:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57050 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: "Liliana Marie Prikler" , 57050@debbugs.gnu.org Cc: Liliana Marie Prikler , Thiago Jung Bauermann Received: via spool by 57050-submit@debbugs.gnu.org id=B57050.166025766216267 (code B ref 57050); Thu, 11 Aug 2022 22:42:01 +0000 Received: (at 57050) by debbugs.gnu.org; 11 Aug 2022 22:41:02 +0000 Received: from localhost ([127.0.0.1]:55160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMGrM-0004Ds-8O for submit@debbugs.gnu.org; Thu, 11 Aug 2022 18:41:02 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:56365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMGrH-0004Db-6V for 57050@debbugs.gnu.org; Thu, 11 Aug 2022 18:40:59 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B105A3200A23; Thu, 11 Aug 2022 18:40:48 -0400 (EDT) Received: from imap52 ([10.202.2.102]) by compute4.internal (MEProxy); Thu, 11 Aug 2022 18:40:49 -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=1660257648; x=1660344048; bh=WdtRMxbM8H ayqnOJQiKLVCKnzm6QqGLLW/iyOt4OOtU=; b=sJ8SAD9u8hNxAV+uZzVyuYqJxO JMg4C9MQFMewx21VHOFFQ2PZE4lKKRJkDDFBtXt6MjAg7EM3AeO2HRoN2lVsou6g 5DeQh6t08Lzbz56UYDYf+ZBpgHAKxPEOvpPCipDnjMT9Jm2dnolhm776COQqXqP2 5TrhPLHdFA+XIgODJhjoJLfD6PHofxWGhg/u1U1CVII0d8SufY8kQcZ+KLYB8lAp mDD0dzSiOYsb4QKGTP9VS3WloZx9iQR+jevJP9pdgjhwPtR8SpeOiWQhS4sJxsto aOuMhcVfIsRAKhgUh0lSubDbNVYjg3nVBSiDqgMEM5bS2VXGuqGjczoiKLQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id: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=1660257648; x= 1660344048; bh=WdtRMxbM8HayqnOJQiKLVCKnzm6QqGLLW/iyOt4OOtU=; b=d mBQcUNmFx3L7MfJ6Y1xXizrjY/flgP+gEv2qS6vCjfcQCjoX0LiJMKGFKWigmRFo zeEFcdbrlCi+odOgiog5AB66AR4h1gTmixmMUrl1FXTWu1qqMaJXTt/Zc+tHnQ2d S5LLUnGfWT4p7hlWiCxt7ydAdsa0KYpFtQ0wXy3aa0tSGZWAPougLasDJ3IYeN5i YW9EzrgjFGiZMiQyht9Vo77vUsOFH0EYvQayZ16T57g06U86F4xnZDP5E9cNwdBE pxYqBpdvhVWhqb1VO1VajhraFSl7u3ffdo88LpXXxNuWKNVMAHbqy2cGsRBbZKqS 1rMS29f0onabJQ0EFqIzw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdeghedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdfr hhhilhhiphcuofgtifhrrghthhdfuceophhhihhlihhpsehphhhilhhiphhmtghgrhgrth hhrdgtohhmqeenucggtffrrghtthgvrhhnpeeuvdethfehudeuieeutdehudeffeevtdei lefhjeevgedtuedvgeejjeeftdefudenucffohhmrghinhepghhithhhuhgsrdgtohhmpd guvggsihgrnhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehphhhilhhiphesphhhihhlihhpmhgtghhrrghthhdrtghomh X-ME-Proxy: Feedback-ID: i2b1146f3:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 93A8AC6008B; Thu, 11 Aug 2022 18:40:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-811-gb808317eab-fm-20220801.001-gb808317e Mime-Version: 1.0 Message-Id: <9c26881e-fbeb-4910-bf56-e27d9dc77359@www.fastmail.com> In-Reply-To: References: <5e784e0d35bf5b342bd7df77c4fa137deb942e47.1660215295.git.philip@philipmcgrath.com> Date: Thu, 11 Aug 2022 18:40:26 -0400 From: "Philip McGrath" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=1660257755; 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=WdtRMxbM8HayqnOJQiKLVCKnzm6QqGLLW/iyOt4OOtU=; b=IDsNDVnEHdcf9XUiV4Lu5B94Py2wg19hL7tqYakzCcNAo/L3B2X3n5XHADeLoQhtAr9p0A ERK5d90/t9WjBNUo2FFFcTZo0V4OEu3WCdM/4lnRobgnI2aU6uRAYwYtGdBMFcoAulP5a1 W7AjCJI4U5Xia+LkZ1zpkJ4r6UzyEMYFwv/EOIWZ5QC47cnfRjnrG9H6dhs0q4jfQbXT4l YX+VagIjNsy/0V/YHsJpA9SlnGcZzGh8bfzFhR137Y9Xn4P+XW2aTRgzk7R+ThjpezCjb+ T3ca1/zOtQofVjoMuS/jOmjvUSNlFELhNmtovwQj7vOJXb+kSwg4bEPUNsOqvA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660257755; a=rsa-sha256; cv=none; b=ZytTqpEyD93iqV5/fLvCso3eh1eR4b6fuZNefEg1JeVd0+S289lxVvdzmKafQ9CfBJi5ws YDRc19vEGUsgGrwec0SC+/Q0Nx6eAcmWqdMovOSYXKB+7IzmUsC+nTce8bentFdnT4mvYO oJeD4Mxkgl2e74dE1FfO09OEm2YCDntd4K8eDgolsJsD4PQOVbhXdM4Q9eliMpR6Xi7ll7 iAoM9rnGmd9dzRCrfPI4CFINCCW/+UeWL1dnYPQA1ZmfuJFZLpxoyWm9iHx2P8kvz+GZmm GKIzsYdjXA34IqmKMbAWdi5mTXyTeF0Zqvan5gq50lnJ58FKLTjnpr+5+ux+ig== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=sJ8SAD9u; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b="d mBQcUN"; 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.83 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=sJ8SAD9u; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b="d mBQcUN"; 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: C0B0C332CA X-Spam-Score: 2.83 X-Migadu-Scanner: scn0.migadu.com X-TUID: nRH+duuaD6IE Hi, On Thu, Aug 11, 2022, at 7:44 AM, Liliana Marie Prikler wrote: > Am Donnerstag, dem 11.08.2022 um 07:08 -0400 schrieb Philip McGrath: >> Also, update 'chez-scheme-for-racket' to 9.5.9.2. > As with Zuo, can this be split into a separate patch? If not, why does > it get mentioned here as something noteworthy rather than just being > part of the ChangeLog? > This absolutely should not be split into more patches. While I split out= Zuo as you requested, I continue to believe that it was better as a sin= gle patch. More broadly, I hope to put together a 'racket-build-system' before the = 8.7 release. Whenever that happens, it will mean turning the inputs of t= he 'racket' and 'racket-minimal' packages into, last I counted, 203 addi= tional packages. I think it would be bad for everyone=E2=80=94patch writ= ers, patch reviewers, users, and people reading the history later=E2=80=94= to break Racket releases into a deluge of little patches, many of which = would leave the Racket universe as a whole in states no one had ever bui= lt or tested, because Racket has combinations of technical and social me= chanisms to make certain potentially problematic states difficult to fal= l into. A Racket release is an update to a family of packages that are developed= and released together. Like a TeX Live update (cf. ee25e3fcab9d2e24c282= 6b771b52d797c152193b) or the KDE Frameworks libraries (cf. 9d3965edca29f= 80667374da45214cc6f22a85be4), the contents of a Racket release should be= updated together. I wouldn't insist on one commit in all imaginable cir= cumstances, but I think it should be the norm. That's all the more true = of Racket components that share a canonical Git repository, for which Ra= cket tools take steps to warn you if not fail if you have mismatched ver= sions. I also want to emphasize that splitting up patches is not free. Splittin= g/rebasing v2 of this series took hours of work. Even specifically in sp= litting off Zuo, I made a (trivial) error in my first version of this pa= rticular patch and had to amend the commit and rebuild. Splitting this a= ny further would get farther away both from how I actually wrote and tes= ted this patch series over the past four months and from the way Racket = is developed and released. It would take a non-negligible amount of effo= rt, all to produce a result that I believe would be worse. I mention the version number for 'chez-scheme-for-racket' because it sho= ws up relatively prominently in Guix tooling and even e.g. in the path o= f the package documentation. I don't know why it would be a problem to d= o so, but I would vastly prefer to remove the mention than to split the = patch, if it really has to be a choice. The Racket release notes don't m= ention the corresponding version of Chez Scheme. >> [...] >> @@ -448,18 +456,52 @@ (define-public chez-scheme-for-racket >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (delete "libx11" "util-lin= ux:lib"))) >> =C2=A0=C2=A0=C2=A0=C2=A0 (native-inputs >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (modify-inputs (package-native-inputs = chez-scheme) >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (append zuo) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (replace "chez-scheme-boot= strap-bootfiles" >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 chez-scheme-fo= r-racket-bootstrap-bootfiles))) > Prefer prepend over append. > Why? >> =C2=A0=C2=A0=C2=A0=C2=A0 (arguments >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (substitute-keyword-arguments (package= -arguments chez-scheme) >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((#:out-of-source? _ #f) >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #t) >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((#:tests? _ #t) >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; FIXME: There have been= some flaky test failures. Some have >> been >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fixed upstream post-re= lease but have proven non-trivial to >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; backport; at least one= issue remains. Re-enable tests once >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; https://github.com/rac= ket/racket/issues/4359=C2=A0is fixed. >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #f) > Rather than skipping tests altogether, skip just the flaky ones. > If I knew how to do that, I absolutely would. Well, short of making the = `process` function silently fail to run `/bin/sh` again, maybe. If you l= ook at the linked issue, you'll see that I've been chasing down failures= for the last month. For a while I had cherry-picked 153ff9acb7ad63717a5= 0bb26cd5aaa053870c666, which fixed the only issue with the implementatio= n (a race condition in one mode of the garbage collector), but it didn't= seem worth carrying the patch when things were still failing. The other= issues seem to be problems with running the test suite. Probably they a= ppeared now because we hadn't actually been running as much of it as we = seemed to be. So far, I haven't had failures building with current maste= r, but there aren't any commits touching anything obviously related, and= Unicode 14 and grapheme cluster support have landed since the release b= ranch, so it wouldn't be reasonable to just sweep in all the changes ind= iscriminately. Further, it's at least possible that I may just have been= winning the race recently and that the actual problem might still be th= ere. The Chez test suite takes an hour to run (maybe more), and I haven'= t been able to reproduce the failures outside of Guix, so it's not exact= ly rapid iteration. All in all, I don't know any change to make other th= an turning off tests that I can feel confident will work reliably for Gu= ix users. For what it's worth, difficulty running the Chez tests is not unique to = Guix. In the course of adding Zuo, Matthew Flatt commented, "After this = conversion, I was able to run the Chez Scheme test suite on Windows for = the first time; it must have been possible before, but I never quite got= the right tools installed in the right way to make it work." [1] AFAICT= Debian skips the Chez test suite unless it is specifically requested [2= ]: I don't know why, maybe just because it takes so long. [1]: https://github.com/racket/racket/pull/4179#issuecomment-1094137092 [2]: https://salsa.debian.org/scheme-team/chezscheme/-/blob/fbfa9c35db18= 4f5b22ac6c0058d754e1a45f5f68/debian/rules#L66-69 >> @@ -130,12 +132,12 @@ (define-module (gnu packages racket) >> =C2=A0;; output. The function 'racket-vm-for-system' returns the >> recomended Racket >> =C2=A0;; VM package for a given system. >> =C2=A0;; >> -;; The file 'racket.scm' builds on these packages to define 'racket- >> minimal' >> -;; and 'racket' packages. These use Racket's support for ``layered >> -;; installations'', which allow an immutable base layer to be >> extended with >> -;; additional packages. They use the layer configuration directly >> provide >> -;; ready-to-install FHS-like trees, rather than relying on the built >> in >> -;; ``Unix-style install'' mechanism. >> +;; We then define the packages 'racket-minimal' and >> +;; 'racket'. These use Racket's support for ``layered >> installations'', which >> +;; allow an immutable base layer to be extended with additional >> packages. >> +;; They use the layer configuration directly provide ready-to- >> install FHS-like >> +;; trees, rather than relying on the built in ``Unix-style install'' >> +;; mechanism. >> =C2=A0;; >> =C2=A0;; Bootstrapping Racket: >> =C2=A0;; --------------------- > This is a leftover from 8.6, but do the "FHS-like" installations > actually adhere to the FHS or just to the bit that says "opt means we > can do whatever we want =F0=9F=98=8E=EF=B8=8F"? > The 'racket' and 'racket-minimal' packages follow FHS. (Pedantically, be= cause compiled Racket code may or may not be architecture specific, and = used to always be architecture-independent, some configuration modes put= things in "share" that belong in "lib", but the current upstream "Unix-= style" defaults and out packages do not do that.) Here's a comparison of the hierarchy of our non-VM Racket packages vs. a= n in-place Racket installation, with the bracketed numbers indicating ho= w the two match up: /gnu/store/xyz-racket-8.5/ =E2=94=9C=E2=94=80=E2=94=80 bin/ [1] =E2=94=9C=E2=94=80=E2=94=80 etc/ =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 racket/ =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 config.rktd [2] =E2=94=9C=E2=94=80=E2=94=80 lib/ =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 racket/ [3] =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 links.rktd =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 mans.rktd =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 pkgs/ [4] =E2=94=94=E2=94=80=E2=94=80 share/ =E2=94=9C=E2=94=80=E2=94=80 applications/ [5] =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 drracket.desktop =E2=94=9C=E2=94=80=E2=94=80 doc/ =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 racket/ [6] =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 index.html =E2=94=9C=E2=94=80=E2=94=80 man/ [7] =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 man1/ =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 racket.1.gz =E2=94=94=E2=94=80=E2=94=80 racket/ [8] =E2=94=94=E2=94=80=E2=94=80 infocache.rktd /gnu/store/xyz-racket-vm-cs-8.5/opt/racket-vm/ =E2=94=9C=E2=94=80=E2=94=80 bin/ [1] =E2=94=9C=E2=94=80=E2=94=80 collects/ [would be share/racket/collects, b= ut not duplicated in layers] =E2=94=9C=E2=94=80=E2=94=80 doc/ [6] =E2=94=9C=E2=94=80=E2=94=80 etc/ =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 config.rktd [2] =E2=94=9C=E2=94=80=E2=94=80 include/ =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 chezscheme.h =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 racketcsboot.h =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 racketcs.h =E2=94=9C=E2=94=80=E2=94=80 lib/ [3] =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 libracketcs.a =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 petite.boot =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 racket.boot =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 scheme.boot =E2=94=9C=E2=94=80=E2=94=80 man/ [7] =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 man1/ =E2=94=94=E2=94=80=E2=94=80 share/ [8] =E2=94=9C=E2=94=80=E2=94=80 applications/ [5] =E2=94=94=E2=94=80=E2=94=80 pkgs/ [4] >> =C2=A0;; >> -;; Code: >> +;; Zuo is notably *not* a problem for bootstrapping. The >> implementation is a >> +;; single hand-written C file designed to build with just `cc -o zuo >> zuo.c`, >> +;; even with very old or limited compilers. (We use the Autoconf >> support for >> +;; convienience.) >> +;; >> +;; CODE: > Is that something that needs be mentioned? > Some people have asked whether the Zuo implementation does or should sha= re things with Racket and/or Chez Scheme. It seemed worth noting that it= intentionally does not, for the sake of bootstrapping. -Philip