On 31 July 2013 16:47, Chris Muller <asqueaker at gmail.com> wrote:
> Hi Frank,
>
>> Yes, but the stripping out part is manual. Well, it's scripted [1],
>> and when a new package becomes unloadable I add it to the script, run
>> ... snip ...
>
> I was thinking about something.  Your Stripping script, and any
> external ".st" script for that matter, should be a one-liner simply to
> call one single method, rather than having any sort of code with
> implementation details.  One reason for this is so that browsing
> senders will miss as little as possible due to being externalized in
> an .st script.

I'm prepared to be argued over to agreeing with you, which means that
at the moment I don't :). The reason is that I don't see a car factory
inside my car: the car factory assembles a bunch of bits and gives me
a car. (This is one of the things that annoys me about Metacello: I
don't want to see ConfigurationOfs in my image.)

> But another reason is because Stripping should be regarded *as
> valuable* a use-case as Assembling.

Definitely at the moment. Much later, I expect people to not be doing
much Stripping because there simply won't be much call for it.

Or, put another way, with a strongly modular image you could easily
build a near minimal custom image. If you needed to minimise that,
sure, you could reach for other tools.

> There are two scenarios for deploying a minimal production image.  The
> "conventional" way, used by other languages, is to develop the code
> base in a rich fat image and, when its ready, version it all up and
> Assemble it manually into a brand new SqueakTrunk image, sans all the
> richness.

No. The usual mainstream approach is the opposite: it builds an
application up from a bunch of libraries together with your own code
to produce a binary. That binary doesn't have an IDE in it, or a
debugger, or anything else that I'd expect from a rich fat image.

Stripping is _hard_. Just look at all the Self literature. (My brief
Googling has failed me, but I did read an interesting approach in
connection with abstract interpretation.) Well. It's very easy to
remove things from an image. The problem is removing only the bad bits
and leaving the good bits.

> The other way, supported only by Smalltalk, is where I start with a
> ReleaseSqueakTrunk image (rich and fat) and develop my code and
> objects until I'm ready to deploy.  Instead of being required to
> hand-assemble a new image I simply Strip the image I'm in and deploy
> that.
>
> (As I type this e-mail, the merits of Spoons approach continue to woo
> me.  Craig?!)

As Eliot put it, Spoon and my packaging work are pushing two different
things: Spoon produces _minimal_ images, while I'm trying to produce
_modular_ images. If you think of the two processes as vectors,
they're _broadly_ in the same direction, but they're not parallel.

frank