Years ago I was trying to rationalise all the various functionality of Smalltalk/SmalltalkImage across
forks. I also wanted to support a scheme that would handle being bootstrapped from sources.

i.e. the startup process may load in or unload a number of classes from sources at an early stage, and when the time came to think about #startUp they may not have been #initialised, (the #startUp might be their initialisation).

So I vaguely recollect that when I had a go at re-doing the startuplist I removed this responsibility to a class of its own, called StartupManager, and removed the class var that holds the list in favour of a voting system.

I found some code hiding away (somewhat obfuscated)

https://bazaar.launchpad.net/~keithy/cuis/System-Support_StartupManager/revision/1#StartupManager-into-Cuis2/1-System-Support-StartupManager.install/0002/StartupManager-(startup-shutdown)-int.1.st

Looking through the comments I find

StatupManager

New simple startUp shutDown protocol

classes implement #startUpPriority #shutDownPriority to register.
Note: this code could be hosted on a different class, such as SmalltalkImage,

The startUp and shutdownLists are compiled by looking at all implementors of:'

startUpPriority and #shutDownPriority'

Priorities are: #first #earliest #earlier #early #normal #late #later #latest #last'

As you can imagine this was very much a first attempt at resolving these problems.

Keith

On 30 Apr 2019, at 0:15, Keith wrote:

Years ago I was trying to rationalise all the various functionality of Smalltalk/SmalltalkImage across
forks. I also wanted to support a scheme that would handle being bootstrapped from sources.

i.e. the startup process may load in or unload a number of classes from sources at an early stage, and when the time came to think about #startUp they may not have been #initialised, (the #startUp might be their initialisation).

So I vaguely recollect that when I had a go at re-doing the startuplist I removed this responsibility to a class of its own, called StartupManager, and removed the class var that holds the list in favour of a voting system.

I found some code hiding away (somewhat obfuscated)

https://bazaar.launchpad.net/~keithy/cuis/System-Support_StartupManager/revision/1#StartupManager-into-Cuis2/1-System-Support-StartupManager.install/0002/StartupManager-(startup-shutdown)-int.1.st

Looking through the comments I find

StatupManager

New simple startUp shutDown protocol

classes implement #startUpPriority #shutDownPriority to register.
Note: this code could be hosted on a different class, such as SmalltalkImage,

The startUp and shutdownLists are compiled by looking at all implementors of:'
#startUpPriority and #shutDownPriority'
Priorities are: #first #earliest #earlier #early #normal #late #later #latest #last'

As you can imagine this was very much a first attempt at resolving these problems.

Keith

One of the other goals was to support removable/loadable UI in the bootstrap process

I found this code in there, which indicates that the vote was essentially on a numeric 0-999 scale.

StartupManager class methodsFor: 'system-startup-shutdown' stamp: 'kph 2/4/2010 16:44'!"

priorities

^ IdentityDictionary new

at: #first put: 0; "reserved for Delay"
at: #earliest put: 10;
at: #earlier put: 100;
at: #early put: 200;
at: #normal put: 500;
at: #late put: 800;
at: #later put: 900;
at: #latest put: 990;
at: #last put: 999; "reserved for Delay"
yourself.

and some code, sorting on given priority value, followed by class name.

startUpList

| priorities list |

priorities := self class priorities.
list := SortedCollection sortBlock: [ :a :b |
a value = b value
ifFalse: [ a value <= b value]
ifTrue: [ a key name <= b key name ] ].'

self systemNavigation allClassesRespondingTo: #startUpPriority
do: [ :cl | list add: (cl -> (priorities at: cl startUpPriority ifAbsent: [ cl startUpPriority ] )) ].

^ list

On 29 Apr 2019, at 23:14, tim Rowledge wrote:

Hi marcel -

On 2019-04-28, at 11:40 PM, Marcel Taeumel <[hidden email]> wrote:
command-line scripts are executed *after* all other start-up calls were made using a deferred UI message. There is no need to fiddle around with the order in the start-up list. See:

SmalltalkImage >> #processStartUpList:
AutoStart class >> #startUp: (last line)
ProjectLauncher >> #startUp
ProjectLauncher >> #startUpAfterLogin

I see that; but then we have to work out why the stdin/out/err filehandles need (re)initialising. FileStream class>>startUp: (true) is supposed to do it as part of the normal startup sequence but I had to add it at the beginning of my doit-file. Not to mention why does it seem to not work at all on Windows? And also, there is still the point that things are not in the requested/required order in the StartUp list.

As an extra excitement, how shall we allow for having startup files that want to avoid the UI starting up - say to support the idea of using Squeak for quick jobs as part of scripting? I'm not at all sure what a good answer would be here, it seems at first thought that we'd need either have two ways to specify the files in the commandline (say, -earlyfilein & -uifilein, which are both horrible and should not be used!) or to have some tags in the files to say where sections get evaluated - perhaps [preUI] & [postUI].

This was the functionality of my InstallSeries code.

The idea was to aim to load a project as a series of file ins, from a hierarchy of directories whose structure would indicate the priority, such as #preUI, "I am the UI" and #postUI.

The file out scheme, would create InstallSeries compatible changesets according to specific slice definitions, such as "methods in the image categorised as (startup-shutdown)." Thus a slice definition could be applied to more than one image or fork, for import or export.

The aim was to patch each fork (pharo squeak cuis et al) at an early stage in the bootstrap so that subsequent slices of functionality could be held in common. I think I got as far as loading Seaside in Cuis.

Keith