Smalltalk › Squeak › Squeak VM

[OpenSmalltalk/opensmalltalk-vm] Support for OpenBSD (#413)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

NorbertHartl

Re: [OpenSmalltalk/opensmalltalk-vm] Support for OpenBSD (#413)

Am 14.08.2019 um 11:54 schrieb Craig Latta <[hidden email]>:

Norbert writes:

Pharo since version 7.0 is bootstrapped on every build. And it is surely the best way to get a
reliable artifact.

The approach you cited uses a plethora of external tools processing source code. That's composition, but not bootstrapping (something building itself, or "pulling itself up by its own bootstraps“).

You are of course welcome to put your own definition of bootstrapping. But why is this better? So bootstrapping should mean no operating system, no interpreter (like a shell) in between? Where is the defined border? I’ve never compiled a C compiler without having an assembler and C compiler, a shell and shell scripts at hand. So I’m really interested where it is defined exactly.

Pharo constructs in an image another image from nothing, then it loads some binary packages until the point it has a compiler. I’m not sure at the moment if the compiler recompiles everything again. I think you can call that bootstrapping

Whether you consider the essence of the system to reside in that source code or in machine instructions, reliability comes from being able to explain why each bit in the resulting artifact is there. I think that process is most understandable, and most effectively verified, when the space of those external tools is smallest. This is why I prefer systems that actually do bootstrap.

I agree that the set of external tools should be small. By using the term „reliable“ it was regarding the artefact produced a.k.a the image. In the sense of being able to produce a bit identical artefact you can reason about. Maybe I should have used reproducible to make it more clear. But then we are not speaking my native language, you know?

Norbert

-C
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Support for OpenBSD (#413)

In reply to this post by David T Lewis

This thread, while quite interesing, is going off-topic.

I invite you all to continue the discussion over at vm-dev (or its nabble mirror).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Support for OpenBSD (#413)

In reply to this post by David T Lewis

Closed #413.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Support for OpenBSD (#413)

In reply to this post by David T Lewis

Argh, that is what I thought I did. I‘m getting old 😀

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Support for OpenBSD (#413)

In reply to this post by David T Lewis

No problem. All issues here are mirrored at vm-dev.
But lets focus on issues present here at github and keep the general discussion over at vm-dev.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Craig Latta

Re: bootstrapping (was "Support for OpenBSD (#413)")

In reply to this post by NorbertHartl

Hi Norbert--

> > > Pharo since version 7.0 is bootstrapped on every build. And it is
> > > surely the best way to get a reliable artifact.
> >
> > The approach you cited uses a plethora of external tools processing
> > source code. That's composition, but not bootstrapping (something
> > building itself, or "pulling itself up by its own bootstraps“).
>
> You are of course welcome to put your own definition of bootstrapping.

Heh; unsurprisingly, I assert that it's your usage that departs
from the traditional meaning. :)

> But why is this better?

Something building itself is better because it minimizes the
cognitive load on the human attempting to understand it, by not
involving so many external tools whose compositions and interactions
must also be understood. It presents a more concise statement of what
the system is.

For me, this makes working on the system more fun, faster, and
easier to teach. I also find the resulting systems are less brittle,
because there are fewer independently evolving components which can
break things.

> So bootstrapping should mean no operating system, no interpreter (like
> a shell) in between? Where is the defined border?

As much as possible, sure. In this case I'd use an operating system
only as much as I needed to run a virtual machine. (Bootstrapping the
virtual machine is a large area of this conversation, as yet unentered. :)

> I’ve never compiled a C compiler without having an assembler and C
> compiler, a shell and shell scripts at hand. So I’m really interested
> where it is defined exactly.

I think the nature of the resulting artifact influences how
relevant bootstrapping is. When building a C compiler, you probably
don't care how it was that the existing C compiler you're using came to
be. And developers using the built C compiler are usually much less
concerned with dynamic behavior and self-reflection than Smalltalk
developers are.

The example I would use is of a germinating seed. I think it's
appropriate to allow special behavior earlier, leading to the existence
of seeds, that is repeated less often later. We should minimize that
part. Most of the work is then done by the seed operating upon itself,
not by outside things operating upon it.

> Pharo constructs in an image another image from nothing, then it loads
> some binary packages until the point it has a compiler. I’m not sure
> at the moment if the compiler recompiles everything again. I think you
> can call that bootstrapping.

I don't. That's one Pharo system composing another one, according
to a plan which exists in the union of the first system and a bunch of
external scripts fed to external tools. The plan is the interesting
thing, and it's far from nothing.

> I agree that the set of external tools should be small. By using the
> term „reliable“ it was regarding the artifact produced a.k.a the
> image. In the sense of being able to produce a bit-identical artifact
> you can reason about.

Right, that's what I understood you to mean.

> Maybe I should have used reproducible to make it more clear.

I think reproducible composition is actually what you're
discussing. One can achieve it with bootstrapping, and also with what
Pharo is doing. :) The two are not synonymous, so I don't think it's a
matter of being more clear, or which natural language we're using here.

Certainly reproducibility is a crucial quality; reflectivity and
minimalism are as well. The object memory composition Pharo does is a
very useful step, but there's more to do before achieving bootstrapping,
and the specification and comprehension benefits that come with it.

-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31 6 2757 7177
+ 1 415 287 3547