On 31 December 2013 16: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.

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

> 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? And then when we have other script-y things
that we need - we shove those in the image too?

Ideally ReleaseBuilder wouldn't be in the image, for instance: because
it's just scaffolding nonsense.

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

frank

> On Tue, Dec 31, 2013 at 5:48 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 30 December 2013 21:33, David T. Lewis <lewis at mail.msen.com> wrote:
>>> On Mon, Dec 30, 2013 at 09:04:05PM +0100, Levente Uzonyi wrote:
>>>> On Mon, 30 Dec 2013, Frank Shearar wrote:
>>>>
>>>> >On 30 December 2013 19:14, Levente Uzonyi <leves at elte.hu> wrote:
>>>> >>On Mon, 30 Dec 2013, Frank Shearar wrote:
>>>> >>
>>>> >>>On 30 December 2013 18:36,  <commits at source.squeak.org> wrote:
>>>> >>>>
>>>> >>>>A new version of CommandLine was added to project The Inbox:
>>>> >>>>http://source.squeak.org/inbox/CommandLine-fbs.3.mcz
>>>> >>>>
>>>> >>>>==================== Summary ====================
>>>> >>>>
>>>> >>>>Name: CommandLine-fbs.3
>>>> >>>>Author: fbs
>>>> >>>>Time: 30 December 2013, 6:36:22.399 pm
>>>> >>>>UUID: a8ce5a55-8bb5-ac4b-a112-eb308ce3bf53
>>>> >>>>Ancestors: CommandLine-fbs.2
>>>> >>>>
>>>> >>>>If launched headless (with option -headless or -vm-display-null), use
>>>> >>>>the
>>>> >>>>CommandLineToolSet instead of the StandardToolSet.
>>>> >>>>
>>>> >>>>We must startUp: before AutoStart because AutoStart triggers the
>>>> >>>>processing of startup scripts (because it asks all registered
>>>> >>>>AbstractLaunchers - in particular, ProjectLauncher - to do their thing).
>>>> >>>>
>>>> >>>>=============== Diff against CommandLine-fbs.2 ===============
>>>> >>>
>>>> >>>
>>>> >>>This allows headless things to report bad things happening, like
>>>> >>>dumping syntax error notifications to stdout and exiting.
>>>> >>
>>>> >>
>>>> >>People who use RFB won't like this, because it quits the image on the
>>>> >>first
>>>> >>error.
>>>> >
>>>> >Does RFB get used in a _headless_ manner? An alternative would be to
>>>>
>>>> It depends. RFB can be used with -vm-display-null, or one can use xpra and
>>>> use -vm-display-x11. We start our images with xpra, but still connect to
>>>> them using RFB, because it's more responsive. xpra is still useful,
>>>> because it's not safe to press alt+. through RFB, because you can
>>>> interrupt the RFB process itself.
>>>
>>> Our squeaksource.com image works this way. We run it as a headless image
>>> with -vm-display-null, and the image has RFBServer to support interactive
>>> access. It works very well, and I believe that this is a common configuration
>>> for Seaside application servers.
>>
>> OK, so I misunderstood what "headless" meant. I thought it meant
>> "doesn't use a GUI", but it really means "doesn't render a GUI to a
>> physical device".
>>
>> In that case, the commit's useless. I'll have to take a look at what
>> the Pharo guys have done, and see how I can make that work.
>>
>> What I need is to be able to treat the execution of an image as a
>> strictly command-line process. I need to, without doing anything
>> inside a startup script, to be able to signal to the image that it
>> must use the CommandLineToolSet. The CLTS and DummyUIManager will then
>> ensure that external interactions with the user happen only over
>> stdout, stderr and std in.
>>
>> Using SmalltalkImage >> #run: doesn't do what I need, because syntax
>> errors are thrown outside the block, when the startup script is
>> parsed. Although it might do the trick if we rewrote the way startup
>> scripts are run. There's a bunch of wrongness in CodeLoader already
>> (like parsing relative file paths relative to the image's location,
>> rather than the current working directory).
>>
>> Either way, it's much more work than I can stomach for the moment.
>> I'll shelve this commit.
>>
>> frank
>>
>>> Dave