[squeak-dev] Stripping vs. Assembling

Frank Shearar frank.shearar at gmail.com
Thu Aug 1 19:40:27 UTC 2013


On 1 August 2013 17:07, Chris Muller <asqueaker at gmail.com> wrote:
>>>> 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.)
>
> Good luck with that car company.  :)  A factory with no development
> tools, and no visibility from the "car", I predict a crash at some
> point in the near future (pun intended).   :)
>
> I guess I regard the the image as both car AND factory.  We're dealing
> with a car that has the ability to mutate from a Cadillac into a
> Prius, why shouldn't that capability be visible and managed under the
> same powerful dev tools as everything else?
>
>>> 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.
>
> That's exactly what I said.  "Assemble".

Right, sorry. I saw the "develop the code base in a rich fat image"
part, and didn't properly register the rest of the sentence.

>> 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.
>
> "Strip" is not a good word because it evokes all the complicated
> graph-traversal stuff like deploying a "stripped" image from
> VisualAge.  I'm simply talking about large-grained "unloading
> extranneous packages", which have no bearing on an app, just as you do
> with your .st script, for the purpose of running in production with a
> smaller image.

Come to think of it, I'm not stripping anything. I'm unteasing
packages and, when they have no higher level packages depending on
them, I'm adding them to the recipe that builds the image.

> But, I want to be able to TEST my application with a...  let's call it
> "Reduced" image without having to version all code and re-Assemble it
> into an entirely new image first.  Smalltalk embraces the idea of live
> and continuous evolution of software, and so Reduce will be needed
> much more often than Assemble.

Well, of course, you need to do precisely that, and for good reason:
how can you otherwise be confident that the thing you _think_ you
built is the thing you _intended_ to build?

Live and continuous evolution of software is orthogonal to modularity.
You can get far without it. And having it doesn't mean you stop
evolving.

>>> 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.
>
> Maybe you could help me understand -- what is the benefit of
> "modularity" at the package level?
>
> We all grok the benefit of *functional* modularity -- where individual
> methods do one and only one thing and individual classes embody a
> coherent and limited group of related behaviors.  This allows programs
> to be more understandable and upgradeable.
>
> But what is the benefit of *package* modularity?  To me, it relates to
> _image size_ and little else.  Less code is easier to understand than
> more code, it takes up less memory, and probably runs faster.

It relates to libraries. Think of a package as providing some kind of
library, like openssl does. Do you care about openssl's internal
architecture? Of course not. But without packages you can't even tell
where one thing starts and another ends. Initially independent systems
grow roots into each other until they become inseparable. Once they're
inseparable, they're less useful, because you can't choose one or the
other.

> But besides that, more packages complicates Assembly.  And Reduced
> images are less capable of dealing with bugs due to lack of IDE tools.

More packages complicates assembly? Maybe, but at a sublinear rate:
you don't care about the parts that make up my package.

I don't intend for people to _work_ in reduced images. That's why I've
taken such pains to have a ReleaseSqueakTrunk so people still get the
big box of toys. It's just that the toys are actually separable.

> So, I guess I don't know what a "modular" image is or why I would want
> one.  My use-cases are I want Rich for development, and Reduced for
> production.  Both Spoon and your "modularisation-of-packages" work
> seem equally aimed at the latter goal.  If not, then for what do I
> want Modular?

So perhaps an analogy. The Squeak image is a bowl of ramen. It has
bits of pork (because that's my favourite kind of ramen), noodles,
soup, leaves. How do you know where one noodle starts and another
ends? They're tangled together. You pull on an ingredient, and hope
(because this is a highly dynamic, highly reflective environment) that
when you start pulling on that loose noodle end you don't end up
trying to cram the entire bowlful of ramen in your mouth.

Spoon's approach is to use a bunch of chopsticks, spear the pork, tape
the chopsticks to the side of the bowl, and upend the bowl. Only the
speared bits stay behind. You have a minimal bowl.

What modularity does is not give you a bowl of ramen. It gives you a
collection of bowls, each of which holds one of the ingredients. If
you don't like pork, you don't put any pork in the bowl. (Perhaps a
helpful restaurant will pre-assemble these ingredients into a
selection of tasty meals!)

Modularity lets you put fences (to switch analogies) around parts of
the code such that you can understand the system as a whole that much
more simply. "This uses Tools, and System, and Collections. And
Kernel, of course."

So modularity exposes the high level structure of the image. Knowing
that is very useful in understanding the image!

> Thanks.

Sure! I hope I've shed some light on the issue.

frank


More information about the Squeak-dev mailing list