The Trunk: Kernel-dtl.1363.mcz

Am 09.12.2020 06:39:15 schrieb Eliot Miranda <[hidden email]>:

Hi David,

> On Dec 8, 2020, at 1:13 PM, [hidden email] wrote:
>
> David T. Lewis uploaded a new version of Kernel to project The Trunk:
> http://source.squeak.org/trunk/Kernel-dtl.1363.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-dtl.1363
> Author: dtl
> Time: 8 December 2020, 4:13:03.533263 pm
> UUID: dc65867e-37e6-4295-aa44-ef26c62ba250
> Ancestors: Kernel-eem.1362
>
> Let Delay class>>startup invoke DoItFirst class>>reevaluateDebug. If a DoItFirst command line option has requested a debugger, then invoke it now after Delay startUp processing..
>
> =============== Diff against Kernel-eem.1362 ===============
>
> Item was changed:
> ----- Method: Delay class>>startUp (in category 'snapshotting') -----
> startUp
> "Restart active delay, if any, when resuming a snapshot."
>
> DelaySuspended ifFalse:[^self error: 'Trying to activate Delay twice'].
> DelaySuspended := false.
> self restoreResumptionTimes.
> AccessProtect signal.
> + (Smalltalk classNamed: #DoItFirst) ifNotNil: [ :doit | doit perform: #reevaluateDebug].
> +
> +
> !

I don’t understand why this is necessary/what this code does. A comment in the startUp method would go a long way. Also do we really need two lines of white space tacked onto the end of the method?

Am 09.12.2020 20:59:42 schrieb David T. Lewis <[hidden email]>:

Hi Marcel,

On Wed, Dec 09, 2020 at 11:21:15AM +0100, Marcel Taeumel wrote:
> Hi David.
>
> Thanks for working on this! :-)
>
> That special case in "Delay" reminds me of the suggestion to just put "DoItFirst" at a more sensible place in the start-up list. But then it would not be "do it first" anymore. :-D Same for FileDirectory.
>

Pretty much everything I tried needed a bit of hackery someplace,
and in the end it seemed simplest to do everything from the first
position in the startup list, with whatever minimal hacks were needed
to make this work.

I found that the only command option that could not be processed from
the first entry in the startup list was --debug. It works when run after
the Delay startup, but not before. So I arranged for the command "action"
to be registered in the DoItFirst startup, but not actually invoked until
the end of the Delay startup.

The FileDirectory hack is not strictly required, but without it the --cwd
setting gets reset to the normal default later in the startup processing.
Thus it would be active for e.g. any --doit options, but would be reset
by the time the image finishes startup processing. Arguably that behavior
might be considered more correct, but it would be confusing to someone
who specified a --cwd option and expected it to take effect for the
image overall. The "solution" was to add a second invocation of the
--cwd option at the end of the FileDirectory startup.

> What about a little bit more "double dispatch"?
>
> (Smalltalk classNamed: #DoItFirst) ifNotNil: [ :doit | doit startUpFromDelay ].
>
> (Smalltalk classNamed: #DoItFirst) ifNotNil: [ :doit | doit startUpFromFileDirectory ].
>

The tricky part is still there - how do you arrange for the option
blocks to be evaluated at the earliest possible time, but no sooner?

Dave

Am 11.12.2020 23:16:54 schrieb David T. Lewis <[hidden email]>:

Hi Marcel,

On Thu, Dec 10, 2020 at 08:07:48AM +0100, Marcel Taeumel wrote:

> Hi Dave.
>
> >??The tricky part is still there - how do you arrange for the option
> > blocks to be evaluated at the earliest possible time, but no sooner?
>
> Oh, the semantics would stay as you proposed. But for the future, there would we a direct reference from DoItFirst to the "helper classes". At the moment, you leak the implementation details #reevaluateDebug and #reevaluateCwd outside DoItFirst. With just this little indirection, that leak would disappear:
>
> DoItFirst class >> startUpFromDelay
>
> ?? ??self reevaluateDebug.
>
> DoItFirst class >> startUpFromFileDirectory
>
> ?? ??self reevaluateCwd.
>

I think I am misunderstanding this, but as you earlier suggested I should
write something for the wiki to explain how it works (or should work).

Dave

Am 14.12.2020 11:33:37 schrieb Marcel Taeumel <[hidden email]>:

Hi Dave.

Maybe this change set helps. :-) Well ... that "--debug" still seems fishy. You must go past "Project" to show any interactive debugger. Why would "Delay" be enough? Hmmm... Still playing around with it. :-)

This does not work:

./Squeak.exe Squeak-Trunk-32bit.image --evaluate 3+4

Best,

Marcel

Am 11.12.2020 23:16:54 schrieb David T. Lewis <[hidden email]>:

Hi Marcel,

On Thu, Dec 10, 2020 at 08:07:48AM +0100, Marcel Taeumel wrote:

> Hi Dave.
>
> >??The tricky part is still there - how do you arrange for the option
> > blocks to be evaluated at the earliest possible time, but no sooner?
>
> Oh, the semantics would stay as you proposed. But for the future, there would we a direct reference from DoItFirst to the "helper classes". At the moment, you leak the implementation details #reevaluateDebug and #reevaluateCwd outside DoItFirst. With just this little indirection, that leak would disappear:
>
> DoItFirst class >> startUpFromDelay
>
> ?? ??self reevaluateDebug.
>
> DoItFirst class >> startUpFromFileDirectory
>
> ?? ??self reevaluateCwd.
>

I think I am misunderstanding this, but as you earlier suggested I should
write something for the wiki to explain how it works (or should work).

Dave

Am 14.12.2020 12:32:05 schrieb Marcel Taeumel <[hidden email]>:

Ah! :-) Windows-specific quirks ahead. :-D

This works fine:

./SqueakConsole.exe -- --evaluate '3+4'

This locks up the image (i.e. no clock tick):

./Squeak.exe -- --evaluate '3+4'

And all combinations with an actual image name end up in ProjetLauncher >> startUpAfterLogin (via AutoStart):

./Squeak.exe Squeak-Trunk-32bit.image --evaluate '3+4'

./SqueakConsole.exe Squeak-Trunk-32bit.image --evaluate '3+4'

This locks up the image but clock keeps ticking:

./SqueakConsole.exe -- --debug

(Note that "Attach tools to mouse cursor" preference is enabled. ^__^)

Best,

Marcel

Am 14.12.2020 11:33:37 schrieb Marcel Taeumel <[hidden email]>:

Hi Dave.

Maybe this change set helps. :-) Well ... that "--debug" still seems fishy. You must go past "Project" to show any interactive debugger. Why would "Delay" be enough? Hmmm... Still playing around with it. :-)

This does not work:

./Squeak.exe Squeak-Trunk-32bit.image --evaluate 3+4

Best,

Marcel

Am 11.12.2020 23:16:54 schrieb David T. Lewis <[hidden email]>:

Hi Marcel,

On Thu, Dec 10, 2020 at 08:07:48AM +0100, Marcel Taeumel wrote:

> Hi Dave.
>
> >??The tricky part is still there - how do you arrange for the option
> > blocks to be evaluated at the earliest possible time, but no sooner?
>
> Oh, the semantics would stay as you proposed. But for the future, there would we a direct reference from DoItFirst to the "helper classes". At the moment, you leak the implementation details #reevaluateDebug and #reevaluateCwd outside DoItFirst. With just this little indirection, that leak would disappear:
>
> DoItFirst class >> startUpFromDelay
>
> ?? ??self reevaluateDebug.
>
> DoItFirst class >> startUpFromFileDirectory
>
> ?? ??self reevaluateCwd.
>

I think I am misunderstanding this, but as you earlier suggested I should
write something for the wiki to explain how it works (or should work).

Dave