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 <marcel.taeumel at hpi.de>:
> 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 <marcel.taeumel at hpi.de>:
> 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 <lewis at mail.msen.com>:
> 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
> 
> 







>