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

Chris Muller asqueaker at gmail.com
Tue Dec 31 20:26:27 UTC 2013


>> 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 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.

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.

>> 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?

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.

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


More information about the Squeak-dev mailing list