Re: about startup
Locked
 
|
> http://code.google.com/p/pharo/issues/detail?id=1918
> > and I just saw that by accident so posting to pharo is a better way > if you refer to pharo as another fork. > Now a question is what is wrong with the current protocol? > > Stef Hi Stef, This is intended to be a simple example, for the purposes of showing off the concept of how it is possible to develop a slice of functionality, and deliver the knowledge in a form usable by all forks. This is achieved by distributing the code, the integration code, and the cleanUp code separately. My choice of example is to simply start at the beginning. 1. The current protocol, requires explicit registration and deregistration. 2. When you want to slice up the image into small pieces it is a pain to have a dependency elsewhere. Smalltalk/SmalltalkImage initialize is a prime example, where the Balloon-Collections could be removed (from cuis), but for their mention here. 3. the addToStartUpList: aClass after: anotherCompletelyUnrelatedClass idiom is simply asking for one package to be unnecessarily dependent upon another, just for the sake of setting the ordering. 4. The implementation code is fairly complex, compared to the alternative. There are some fringe cases and validation cases dotted around the image which would not be necessary. (e.g. on renaming or removing a class). Other projects on the go... System-InstallStreams - a parallel/heiarchical version of updates (competed) System-Packaging - a refactoring of all fileOut code into PackagingFileOut. - tidy up of fileout code from around the image - (un)loadable replacable in one place. - Used to craft fileOuts without using the changesorter tools. Keith |
|
|
keith wrote:
> My choice of example is to simply start at the beginning. > > 1. The current protocol, requires explicit registration and deregistration. > > 2. When you want to slice up the image into small pieces it is a pain to > have a dependency elsewhere. Smalltalk/SmalltalkImage initialize is a > prime example, where the Balloon-Collections could be removed (from > cuis), but for their mention here. > > 3. the addToStartUpList: aClass after: anotherCompletelyUnrelatedClass > idiom is simply asking for one package to be unnecessarily dependent > upon another, just for the sake of setting the ordering. > > 4. The implementation code is fairly complex, compared to the > alternative. There are some fringe cases and validation cases dotted > around the image which would not be necessary. (e.g. on renaming or > removing a class). +1 to all of the reasoning. Two things I'd do in your implementation is to a) use symbolic names for the priorities (so that one can say NormalLaunchPriority, EarlySystemStartup etc. instead of numbers) and b) have a unique order inside a priority group (say alphabetical) so that there's *some* defined order by which things get executed. The latter avoids suprises if there happens to be a dependency between initializations; at least it'll be always the same and you can plan for it accordingly. BTW, I'm *very* happy to see that you've found a way by which you feel comfortable contributing to Squeak. Your help is most welcome. Cheers, - Andreas |
|
|
On 4 February 2010 00:21, Andreas Raab <[hidden email]> wrote:
> keith wrote: >> >> My choice of example is to simply start at the beginning. >> >> 1. The current protocol, requires explicit registration and >> deregistration. >> >> 2. When you want to slice up the image into small pieces it is a pain to >> have a dependency elsewhere. Smalltalk/SmalltalkImage initialize is a prime >> example, where the Balloon-Collections could be removed (from cuis), but for >> their mention here. >> >> 3. the addToStartUpList: aClass after: anotherCompletelyUnrelatedClass >> idiom is simply asking for one package to be unnecessarily dependent upon >> another, just for the sake of setting the ordering. >> >> 4. The implementation code is fairly complex, compared to the alternative. >> There are some fringe cases and validation cases dotted around the image >> which would not be necessary. (e.g. on renaming or removing a class). > > +1 to all of the reasoning. Two things I'd do in your implementation is to > a) use symbolic names for the priorities (so that one can say > NormalLaunchPriority, EarlySystemStartup etc. instead of numbers) and b) > have a unique order inside a priority group (say alphabetical) so that > there's *some* defined order by which things get executed. The latter avoids > suprises if there happens to be a dependency between initializations; at > least it'll be always the same and you can plan for it accordingly. > > BTW, I'm *very* happy to see that you've found a way by which you feel > comfortable contributing to Squeak. Your help is most welcome. > I am a bit concerned about logic of prioritization of startup/shutdown lists. You can't implement the simplest 'run before anything else' rule, since there's no guarantees that any other package would not want to do the same and hence you'll get a conflict. Maybe, a System should throw an error, if it finds that there are two or more things which want to run on same priority, and signal the user/developer to solve a conflict before saving an image. Then, at startup, a system won't need to guess what follows what, since it is _always_ instructed by user explicitly. So, a proposal is, that classes , which want to take part in startup/shutdown phases providing a 'guessed' priority. The system collects all such classes and in case of conflict, _always_ asks user to solve it, and then using this slightly modified (but explicitly ordered) list to perform startup/shutdown. Still, even without it, Keith's approach is absolutely much better than existing one. > Cheers, > - Andreas -- Best regards, Igor Stasenko AKA sig. |
|
|
>>> My choice of example is to simply start at the beginning.
>>> >>> 1. The current protocol, requires explicit registration and >>> deregistration. >>> >>> 2. When you want to slice up the image into small pieces it is a >>> pain to >>> have a dependency elsewhere. Smalltalk/SmalltalkImage initialize >>> is a prime >>> example, where the Balloon-Collections could be removed (from >>> cuis), but for >>> their mention here. >>> >>> 3. the addToStartUpList: aClass after: >>> anotherCompletelyUnrelatedClass >>> idiom is simply asking for one package to be unnecessarily >>> dependent upon >>> another, just for the sake of setting the ordering. >>> >>> 4. The implementation code is fairly complex, compared to the >>> alternative. >>> There are some fringe cases and validation cases dotted around the >>> image >>> which would not be necessary. (e.g. on renaming or removing a >>> class). >> >> +1 to all of the reasoning. Two things I'd do in your >> implementation is to >> a) use symbolic names for the priorities (so that one can say >> NormalLaunchPriority, EarlySystemStartup etc. instead of numbers) >> and b) >> have a unique order inside a priority group (say alphabetical) so >> that >> there's *some* defined order by which things get executed. The >> latter avoids >> suprises if there happens to be a dependency between >> initializations; at >> least it'll be always the same and you can plan for it accordingly. >> >> BTW, I'm *very* happy to see that you've found a way by which you >> feel >> comfortable contributing to Squeak. Your help is most welcome. >> > > I am a bit concerned about logic of prioritization of startup/ > shutdown lists. > You can't implement the simplest 'run before anything else' rule, > since there's no guarantees that any other package would not want to > do the same and hence you'll get a conflict. Within "small rodents" (Cuis and derived images) the InstallStream's mechanism enables the basic structure of the image you are building to be fairly well crafted on top of the kernel. In particular it is not assumed that packages like seaside will load without a fight, so there is a definite place in which to fine tune different packages as they load. For example we will see if we can have a loader that can rename classes, or understands real or fake namespaces. So the worry of a conflict is not there for me. > Maybe, a System should throw an error, if it finds that there are two > or more things which want to run on same priority, and signal the > user/developer to solve a conflict before saving an image. Possible, but Andreas is preferring quantised priorities, whereas I kind of preferred the numeric fluid version, because it had a simpler implementation. In reality most packages don't care that much and just add themselves to the end of the list. This would be priority #normal I guess. > Then, at startup, a system won't need to guess what follows what, > since it is _always_ instructed by user explicitly. That was my expectation, though I was not expecting any check to be necessary. > So, a proposal is, that classes , which want to take part in > startup/shutdown phases providing a 'guessed' priority. Currently I am adopting Andreas idea, but you are still free to use a manual number if you need to tweak it. Priorities I have so far are: ^ 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. sorting is done, on priority first then class name. regards Keith |
|
|
In reply to this post by Andreas.Raab
On Wed, Feb 3, 2010 at 2:21 PM, Andreas Raab <[hidden email]> wrote:
An alternative is for a class to define its prerequisites, which classes it requires to have been initialized first for startup, and which classes it should be shut down before on shutdown, and do a topological sort (reverse the depth-first walk of the prerequisites digraph). Then there's no need for priorities. One could then add classes whose function it is to define positions in the list. So your NormalLaunchPriority, EarlySystemStartup et al would become classes that define in their prerequisites which system classes are stated up in their phase, and other classes could use these as their prerequisites instead of directly mentioning classes that might or might not be present in an image.
e.g. Delay class startupPrerequisites ^#() ProcessorScheduler class startupPrerequisites #{Delay} EarliestStartup class startupPrerequisites ^{ Delay. ProcessorScheduler }
WeakArray class startupPrerequisites ^{EarliestStartup} EarlyStartup class startupPrerequisites ^{ EarliestStartup .WeakArray } etc BTW, I'm *very* happy to see that you've found a way by which you feel comfortable contributing to Squeak. Your help is most welcome. +1
|
|
|
I am not really "comfortable" contributing to squeak... What I am doing is pursuing my own line of development, a fork if you will. However I am choosing to do this in an unselfish way, by discussing ideas, and publishing code in such a way as to be useful to others. I disagree with the trunk approach to development, because it professes to be a community effort to move things forward, however it is being pursued in the same manner as a fork, whose code is not published or managed in a state that others can routinely harvest. I continue to think that the tools are unhelpful in this process. Cuis2.0 adds a new dimension to this, since it doesn't have any tools! It forces you to think simply, and more importantly to think beyond the constraints of Monticello, and Mantis. This new batch of tools I am developing for publishing and maintaining slices of kernel functionality within Cuis, can also be used to routinely extract slices of functionality out of Squeak and Pharo. So if I find something I do like, I will be able to extract it, and track its development. If successful in their minimalization efforts, Pharo, and Squeak will eventually become minimal kernels, having no tools of their own, and this way of thinking may become strangely relevant once more. Keith |
|
|
keith wrote:
>> >> BTW, I'm *very* happy to see that you've found a way by which you >> feel comfortable contributing to Squeak. Your help is most welcome. >> >> > > I am not really "comfortable" contributing to squeak... Fair enough :-) > What I am doing is pursuing my own line of development, a fork if you > will. However I am choosing to do this in an unselfish way, by > discussing ideas, and publishing code in such a way as to be useful to > others. Indeed. I consider that contributing. We all have to find ways in which we think we can both be effective and have some fun with the system (regardless of whether that is in Squeak, Cuis, or Pharo). Your way may be different from mine but by the end of the day we both contribute in our own style, moving the system forward bit by bit. I'm just on a more incremental path, but that does neither exclude nor prevent more substantial changes like you're providing them. > I disagree with the trunk approach to development, because it professes > to be a community effort to move things forward, however it is being > pursued in the same manner as a fork, whose code is not published or > managed in a state that others can routinely harvest. Acknowledged. I respect your opinion, but I disagree. > If successful in their minimalization efforts, Pharo, and Squeak will > eventually become minimal kernels, having no tools of their own, and > this way of thinking may become strangely relevant once more. That is very well a possibility. Remember that one of my goals is to drive the development from the other end - using an incremental approach, making things loadable and hopefully getting at some point to a kernel the size of Cuis. Cheers, - Andreas |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |