On 5 August 2012 23:37, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

I have the impression that you will need a finer order at least for the kernel. so putting

...

SomeClass>>startUp: quitting <systemShutdown: #kernel priority: 1000> self blahblah.

looks to me the way to go and yes we should clean that part two.

Now what is the gain to have pragma and not just a class side method returning a number?

Stef

the downside of it, that you apparently more slower than explicit subscription (you have to scan over all methods with such pragma). i cannot remember what solution i proposed.. ah ok.. i recall. i proposed to introduce a session-awareness. i.e. an object holds a reference to a session object and before each access to its some session-specific resource it should check if session has changed or not. and if session is obsolete, then you know that you must reinitialize (meaning do a startup). this is what i did in NB: it does not registering for startup, but instead it initializing at first attempt to use it. So if nobody using it, nothing happens (means no extra cycles burned at startup for nothing). This also solves nicely a problem with priority of service initialization: - imagine service A requires service B to function, but user code attempts to access a service A first. Now since service A will try to access a service B first, as result, a service B will be naturally (re)initialized first. Like that, you don't even need to think (or make sure), who should be (re)initialized first, because chain of priority automatically adjusts itself according to program flow. -- Best regards, Igor Stasenko.

On Sun, Aug 5, 2012 at 2:57 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 5 August 2012 23:37, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

I have the impression that you will need a finer order at least for the kernel. so putting

...

SomeClass>>startUp: quitting <systemShutdown: #kernel priority: 1000> self blahblah.

looks to me the way to go and yes we should clean that part two.

...

Now what is the gain to have pragma and not just a class side method returning a number?

Stef

the downside of it, that you apparently more slower than explicit subscription (you have to scan over all methods with such pragma).

No. Registration can be done when methods are added or removed. Pragmas don't have to be scanned on each invocation. Instead the need is for a hook when methods are added or removed, and such hooks exist.

i cannot remember what solution i proposed.. ah ok.. i recall. i proposed to introduce a session-awareness. i.e. an object holds a reference to a session object and before each access to its some session-specific resource it should check if session has changed or not. and if session is obsolete, then you know that you must reinitialize (meaning do a startup). this is what i did in NB: it does not registering for startup, but instead it initializing at first attempt to use it. So if nobody using it, nothing happens (means no extra cycles burned at startup for nothing). This also solves nicely a problem with priority of service initialization: - imagine service A requires service B to function, but user code attempts to access a service A first. Now since service A will try to access a service B first, as result, a service B will be naturally (re)initialized first. Like that, you don't even need to think (or make sure), who should be (re)initialized first, because chain of priority automatically adjusts itself according to program flow.

-- Best regards, Igor Stasenko.

-- best, Eliot

On 6 August 2012 21:09, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Sun, Aug 5, 2012 at 2:15 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:

...

Hi!

Last days I was playing to replace the image startup/shutdown mechanism via a pragma subscription because I was pissed off with how difficult is to integrate the change of a new startup in the system. The idea is: - reduce the mess on subscription/unsubscription, initialization, etc - reduce dependencies of external packages in core packages.

This way, if you want to subscribe a class side method to be executed on startup, you annotate it:

SomeClass>>startUp: resuming <systemStartup: #application> self blahblah.

SomeClass>>startUp: quitting <systemShutdown: #kernel> self blahblah.

You need before: and after:. IMO, you also need to support multiple befores or afters. I think that's much better than a priority scheme.

You also need a tool to visualise the resulting DAG, if you want to understand the order in which the resulting methods will execute. Dumping the pragmas in an appropriate manner in a dotfile would be ample. frank

Also, as I said in response to Igor's message, you can register when pragma methds are added/removed, rather than looking for methods when initialization/shutdown is run.

...

Now, instead of an order in classes startup, I played with the idea of having run levels (which I named #kernel, #application and #user because I was not inspired :P). Then I replaced the whole system startup and It's working...

The code is very simple, you can have a look at the category System-Tasks which can be downloaded from:

MCGemstoneRepository location: 'http://ss3.gemstone.com/ss/PharoTaskForces' user: '' password: ''

SLICE-Issue-666-Playing-With-startup-GuillermoPolito.2

Be careful, that package contains the startup code + the replacement of the old startup by the new one :).

Now, I'd like to have some feedback, u like it? u buy it? which should be the names for the run levels? how many run levels should we have? :P

Cheers, Guille

-- best, Eliot