On 8 August 2013 00:07, Chris Muller <asqueaker at gmail.com> wrote:
> Hi Frank,
>
>> To test this, I've written a near-stub HeadlessUIManager. A UIManager
>> indicates that it may be used by returning true from #isActiveManager.
>>
>> I have two questions:
>>
>> (a) How can I detect whether or not I'm running headless, from within the image?
>
> I use the method in that CommandLine handler package I sent to you a
> while back.  It simply checks command-line args:
>
> SmalltalkImage>>#isHeadless
>      "Display global is set even when headless.  So checking the -vm
> arguments looking for headless operation."
>      -1000
>           to: -1
>           do:
>                [ : n |
>                (#('display=none' '-headless' '-vm-display-null')
> includes: (self getSystemAttribute: n)) ifTrue: [ ^ true ] ].
>      ^ false

(a) Sorry for not reading the code you sent me. (b) I'd really hoped
to avoid reading the arguments supplied to the VM, precisely because
of the variance in the parameter. But if that's what I need to do,
that's what I need to do...

>> (b) Given that MorphicUIManager class >> #isActiveManager returns true
>> if there's a World, and I'm not quite ready to set World to nil
>> because running headless is relatively unsupported, how do I make sure
>> that _this_ UIManager runs, and not _that_ one?
>
> How about just handling ProvideAnswerNotification from a high level?
>
>      [nil inform: 'No changes']
>           on: ProvideAnswerNotification
>           do: [ : noti | noti defaultAction ]
>
> You might want even more error handling than that, though, for running
> headless.  Check out that CommandLineProcessor in the Ma-Core package.
>    I've been using it for several years now for running batch in
> headless or headful operation.  All the error handling for printing
> messages and stack traces and exiting the image vs. halting, etc. is
> handled fairly elegantly by this one class.

Yes, I could do that too, and it's a cheaper way to validate my
hypothesis. Thanks!

>> I'd expected a UIManager class >> #default: like ToolSet has. Or even
>> better, something based on a resumable exception.
>
> ProvideAnswerNotification.

Well, no. That's how you communicate with the UIManager, for sure.
What I want is for the "UIManager default" part to be configurable. If
it used a resumable exception I could even test
ProvideAnswerNotification's behaviour. At the moment, if I try write
such a test, I can't control which UIManager is used.

But I'm wary of just slapping resumable exceptions all over the place.
The cost to find out the resumed value is linear in the call stack,
and it's a serious pain to debug code that uses delimited dynamic
variables. Unless you don't care about the lookup, of course. But if
the lookup's what you're debugging...

frank