[squeak-dev] The Inbox: CommandLine-fbs.3.mcz

Frank Shearar frank.shearar at gmail.com
Tue Dec 31 21:00:47 UTC 2013


On 31 December 2013 20:26, Chris Muller <asqueaker at gmail.com> wrote:
>>> One of the traditional challenges with code in .st scripts is that
>>> it's external to the IDE, so it rots a lot more quickly.
>>
>> Code rot happens because some Foo isn't used very often, and then the
>> things that Foo use change. You only find out that Foo's broken when
>> next you (very occasionally) run Foo and realise that you have to
>> change stuff.
>
> With the .st script code compiled in the image, you would discover Foo
> when you browsed senders while making your changes, long before you
> run Foo.
>
> By maintaining chunks of Smalltalk in external editors, you didn't
> even know you had a _syntax error_ until after an hour or something
> whatever you said..
>
>>> Which is why I ensure my .st scripts essentially fall into the pattern
>>> of sending just ONE message wrapped inside a Smalltalk run: (or
>>> variant).  e.g., myscript.st would have, very simply:
>>>
>>> Smalltalk run:
>>>   [ : commandLineArg1 : arg2 : arg3 |
>>>   SomeClass
>>>        doWith: commandLineArg1
>>>        with: arg2
>>>        with: arg3 ]
>>>
>>> That way they're so simple that syntax errors are never really an
>>> issue.  Plus, as much of the code as possible is managed the IDE and
>>> Monticello.
>>
>> ... and you pollute the image state with a bunch of scaffolding. This
>> is the biggest beef I have with Metacello: I don't want to assemble an
>> image containing Metacello. Nor do I want to assemble an image
>> containing the details of the script I want to run: it's just not
>> interesting.
>
> I'm just talking about having clean entry-points from the OS
> command-line into the Smalltalk system.  And, not a "bunch."  Just 1
> short method per script.  The format of the method is like this:
>
>    scriptName
>        ^ './vm/bin/squeak -mmap 1000m -vm display=none my.image
> scriptName.st $1 $2 $3 $4 >> scriptName.log 2>>scriptName.err' ->
>             [ Smalltalk runAndQuit:
>                         [ : source : target : user : pw | SSRepository
>                                copyAllFrom: source
>                                to: target
>                                user: user
>                                password: pw ] ]
>
> I write this method in the image in a particular category and run
> #exportLinuxScripts causes two files to be written.  One called
> 'scriptName' which contains that command-line, the other called
> "scriptName.st", which contains the code inside that block.
>
> So, it documents, "how the hell do I run this sucker?" right in the
> image (including how much memory to allocate for the VM!), exposes it
> to the IDE, and allows deployment of up-to-date set of scripts by
> merely only deploying a new image.
>
>>> Very recently I've gone one step further:  I've begun putting even the
>>> *contents* of my .st scripts into the image too, inside Blocks whose
>>> code can be exported via #exportLinuxScripts!  I have not submitted
>>> this hack to trunk (yet), but it means you *can't* have accidental
>>> syntax errors because the code-editor of the IDE catches it when you
>>> save the method.  The other benefit already mentioned is that ALL
>>> senders, even the one in .st script, is recognized and managed in the
>>> IDE, and MC.
>>
>> I can see why _a developer_ might use the #run: stuff. It looks very
>> convenient, and when you're hacking on your own stuff it looks just
>> fine to use.
>>
>> But let's look at CI scripts. Do you propose to put the Hudson stuff
>> in the base 4.5 image, as well as all the paraphernalia around running
>> tests in a CI environment?
>
> Of course not.
>
>> And then when we have other script-y things
>> that we need - we shove those in the image too?
>
> Just the bits that contain Smalltalk code.  Maintaining that code in
> the image means it stays in sync with the image code it calls, and
> syntax errors cannot ever happen.

>> Ideally ReleaseBuilder wouldn't be in the image, for instance: because
>> it's just scaffolding nonsense.
>
> ("pollute"?  "shove"? "nonsense"?  Frank I'm trying to help not strike
> a nerve..)

I'm not using these words to rile you up. I just like calling a spade a spade.

> I think we need to stay with self-documenting release images.  The
> purpose of ReleaseBuilder is to tell us how that release image was
> built.  That's not nonsense.

The Squeak user doesn't care about ReleaseBuilder. The trunk developer
doesn't care about ReleaseBuilder. Only one person cares about
ReleaseBuilder, and that's the release manager. And that's once per
release cycle. It's scaffolding. It's a one-off janitorial task that,
other than at the end of a release cycle, is deadweight in the image.

I didn't say that _ReleaseBuilder_ was nonsense. I said _it being in
the base image_ was nonsense. I mean, come on, didn't your builders
dismantle the scaffolding they used to build your house before you
moved in? That scaffolding served a valuable purpose, but it's not
part of the house!

> In fact, when I had problems with the CI image, it really brought into
> focus the trouble of having to "trust" the image we ultimately
> release.  I had no idea what was in that image, nor how it was built.
> I couldn't possibly deploy it.

I trust hand-rolled images far, far less than I do images produced by
scripts. We can test the latter, at least.

Now I realise that the current CI base image has issues, and you know
what? You know why? Precisely because it is _so hard_ to work with
images from a command line. It doesn't have to be like this. It
_shouldn't_ be like this.

The whole point of my work on automation is to _remove the human
element_ from the process. "A little trust goes a long way. The less
you have, the further you'll go" (Maxim 30 from The Seventy Maxims of
Maximally Effective Mercenaries,
http://www.schlockmercenary.com/2003-03-08)

>>> And so every image I deploy for a vertical purpose knows how to export
>>> the library of scripts needed to operate that purpose from the
>>> command-line.
>>
>> Yes, "vertical" is the key word here: #run: and in-image scripts are
>> great when you're working with an image tailored for a specific
>> purpose.
>>
>> But I want to act on images that are built for a _general_ purpose.
>
> How can we know the exact ST code of how those general-purpose images are built?

Because (a) it's the update stream and (b) the base image is built by
a script, from a known base version, that can be debugged and
reworked.

> CI is a vertical application -- it 1) runs test cases against latest
> code and 2) reports results.  As a tertiary responsibility, we're
> investigating whether it should 3) be used to build release images.
> If _all_ the Smalltalk code which builds the release can stay with the
> image which has withstood the scrutiny of the trunk process, and CI
> would only "invoke" it, I think it would go a long way toward trusting
> CI for building release images.

I've built CI stuff for Ruby, Smalltalk and C# code. I've used it with
Java and Scala. Only one language on that list has been a pain in the
axe every. single. step. of. the. way. And it's Smalltalk. Why?
Because we have an obsession with hand-rolling hand-crafted binary
artifacts lovingly assembled by hand. That's fine for an individual
user's image. It's rubbish when you want to try and understand what
this blob of stuff actually contains.

> Any individual should be able to "make" an equivalent 4.5 solely from
> a 4.4, via code visible in the image.

An individual _should not have to_. They should be able to download a
random CI-built image, knowing that it _works_ because the CI
published the test results for that image. The image should be
automatically built, tested and deployed by a completely deterministic
build process.

Being able to update your image from some ancient thing is great, and
we should preserve it, but _I do not want that_ as a means of building
an artifact for the general public to consume.

But this discussion is just going to end up with you saying that
unloading is how you get a minimal image and me saying that building
up an image is how you get a full-fat image.

frank


More information about the Squeak-dev mailing list