From: Leo Famulari <leo@famulari.name>
To: Philip McGrath <philip@philipmcgrath.com>
Cc: help-guix@gnu.org, Xinglu Chen <public@yoctocell.xyz>
Subject: Re: How to add /bin/sh to the build environment
Date: Tue, 9 Nov 2021 20:41:59 -0500 [thread overview]
Message-ID: <YYsjZ/AcdLk1aLbM@jasmine.lan> (raw)
In-Reply-To: <8433ab7e-1540-37ff-e647-8e8da01e07fb@philipmcgrath.com>
On Mon, Nov 08, 2021 at 08:36:08PM -0500, Philip McGrath wrote:
> Mostly I wanted to follow up to say that, from my perspective, SML/NJ is a
> very noteworthy and influential language implementation. Perhaps the most
> familiar example for Guix folks would be that Guile's fibers are based on
> Concurrent ML, which is an SML/NJ extension:
> https://wingolog.org/archives/2017/06/29/a-new-concurrent-ml
Thanks for sharing your knowledge. I stand corrected!
> Personally I've only read ML, not written it, but from a Debian bug I found
> through searching online
> (<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220046>), it appears
> that there are no known Standard ML implementations that avoid this
> bootstrapping problem. SML/NJ, in addition to being one of the most
> important implementations in its own right, is apparently capable of
> bootstrapping at least one other implementation, MLton. (Unlike some on that
> thread, I don't consider the 5x slowdown for the bootstrap build to be
> prohibitive: bootstrapping Chez Scheme via Racket has a 10x slowdown.)
>
> It is very valuable that Guix maintains such high standards for
> bootstrapping from source. However, Guix does still contain some compilers
> that have bootstrapping limitations. SML/NJ is no worse that Chez Scheme in
> this respect, and comparably important. (One difference is that there is a
> path to backporting the bootstrap simulation from Racket's fork to the
> upstream variant, which would remove the problem---but I don't that wasn't
> true when Chez Scheme was first added to Guix.) The status quo is that no
> Standard ML language implementation at all seems to be in Guix. I think
> including SML/NJ would be better than waiting for someone to write a
> hypothetical Standard ML compiler in a host language with a better
> bootstrapping story.
I see. Maybe it's worth attempting to patch the binary to use /tmp/sh
while bootstrapping, in that case. Or maybe there *is* some way to add
/bin/sh to the build environment for just this package, without
having to make the change for all packages, which would be undesirable.
next prev parent reply other threads:[~2021-11-10 1:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 9:25 How to add /bin/sh to the build environment Foo Chuan Wei
2021-11-08 16:54 ` Xinglu Chen
2021-11-08 20:19 ` Foo Chuan Wei
2021-11-08 22:23 ` Leo Famulari
2021-11-09 1:36 ` Philip McGrath
2021-11-09 3:51 ` Foo Chuan Wei
2021-11-10 1:41 ` Leo Famulari [this message]
2021-11-08 22:58 ` Philip McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YYsjZ/AcdLk1aLbM@jasmine.lan \
--to=leo@famulari.name \
--cc=help-guix@gnu.org \
--cc=philip@philipmcgrath.com \
--cc=public@yoctocell.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).