- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

by Frank Shearar

On 6 August 2012 21:09, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sun, Aug 5, 2012 at 2:15 PM, Guillermo Polito <guillermopolito(a)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 >

Aug. 6, 2012

Re: [Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

by Eliot Miranda

On Sun, Aug 5, 2012 at 2:15 PM, Guillermo Polito <guillermopolito(a)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. 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

Aug. 6, 2012

Re: [Pharo-project] Playing with a declarative startup/shutdown subscription mechanism

by Eliot Miranda

On Sun, Aug 5, 2012 at 2:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 August 2012 23:37, StÃ©phane Ducasse <stephane.ducasse(a)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

Aug. 6, 2012