The Trunk: Kernel-dtl.1363.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Kernel-dtl.1363.mcz

commits-2
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].
+
+
  !


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

Eliot Miranda-2
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?



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

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

What about a little bit more "double dispatch"?

(Smalltalk classNamed: #DoItFirst) ifNotNil: [ :doit | doit startUpFromDelay ].
(Smalltalk classNamed: #DoItFirst) ifNotNil: [ :doit | doit startUpFromFileDirectory ].

Best,
Marcel

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?





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

David T. Lewis
In reply to this post by Eliot Miranda-2
On Tue, Dec 08, 2020 at 09:39:01PM -0800, Eliot Miranda wrote:

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

Would this be better? Asking first here because I don't want to clutter
up the ancestry with small commits.

Kernel>>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.
        "If --debug was specified as a DoItFirst command line option, invoke
        it now. Use perform to avoid hard dependency on DoItFirst."
        (Smalltalk classNamed: #DoItFirst) ifNotNil: [ :doit | doit perform: #reevaluateDebug].

>
> Also do we really need two lines of white space tacked onto the end of the method?
>

No, sorry about that.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

David T. Lewis
In reply to this post by marcel.taeumel
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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

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

Best,
Marcel

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




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

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





DoItFirst-mt.1.cs (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

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




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

marcel.taeumel
Hi Dave.



We might want to move the following behind "Project":

12 - MessageTally
15 - ImageSegment (!! Does not even have #startUp implemented !!)
16 - PowerManagement
17 - ExternalSettings
18 - SecurityManager (maybe)

Best,
Marcel

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




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.1363.mcz

David T. Lewis
Hi Marcel,

Thanks very much for looking at this. I do not have access to Windows
at the present time, so I appreciate you taking the time to do this.

I loaded your change set, so I understand now what you were suggesting.

The image lockups are a big concern, I don't understand what's happening
there. But here some things that might help figure it out:

The "Error: no content to install" errors are all related to the start
document loading. For purposes of testing DoItFirst, you may want to
disable the "Read document at startup" preference to prevent the errors.

This is BTW the reason for System-dtl.1197 in the inbox. The preference
for start document loading is a long standing source of confusion, and
I would like to get rid of it if possible.

I do not know what is happening with the '--' handling, but it might be
a problem for Windows. The unix VMs handle this in the VM prior to passing
it on to the image, and I suspect that the Windows VM will not do anything
with it at all except pass it in to the image. The '--' token is a
unix shell convention that probably does not make sense on other platforms.

The --debug handling is an interesting one. My goal was to be able to
open a functional debugger at the earliest possible time in the startup
processing. When I use the --debug option, I can open a functional
debugger. It does not yet have access to the sources file (hence code
appears as decompiled) but it does work, and I can use the debugger to
proceed carefully through the rest of the startup list.

On the other hand, if I try to use the --debug option for an image
that was saved in MVC, I cannot find a way to proceed from the pre-debugger
window to the full debugger, so the feature is useless.

So I think you are right, we probably should rearrange the startup
list, and do the --debug only after Project startup. Also I think that
it does make sense for the Project startup to be done at the earliest
possible time, since it is fundamental for anything involving UI tools
such as a debugger.

Thanks again for looking at this, I know that it's a pain to work through
this stuff. And if inbox System-dtl.1197 is useful (or not) on Windows
to help simplify this mess, I'd be happy to hear about that too.

Dave


On Mon, Dec 14, 2020 at 12:43:16PM +0100, Marcel Taeumel wrote:

> Hi Dave.
>
>
>
> We might want to move the following behind "Project":
>
> 12 - MessageTally
> 15 - ImageSegment (!! Does not even have #startUp implemented !!)
> 16 - PowerManagement
> 17 - ExternalSettings
> 18 - SecurityManager (maybe)
>
> Best,
> Marcel
> 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
>
>







>