On 31 July 2013 16:47, Chris Muller asqueaker@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