Le 21/11/2013 16:37, Igor Stasenko a écrit :
On 21 November 2013 16:30, Goubier Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>> wrote:
What about having a configuration with a prerequisite package setting up options ? Or optimisation tuning in one of the preload script of the package ?
We already have ways to tune that; wouldn't they be better than setting a not so clear class before instance ordering (and what if the class itself requires that kind of tuning?).
i doubt that there can be universal formal solution to this. We have to put some reasonable constraints into system, in order to be able to have a predictable behavior during boot-loading or bootstrapping. Or , somehow , package should carry enough metadata to tell system , in what order it must load things in it.. and problem obviously is wider than just order of compilation inside a single class, because it is just a part of bigger picture which is: - order or class loading and initialization
i imagine that a complete (or say, most flexible) load order control must include class loading and class initialization e.g.:
load: ClassA , load:ClassB, init:ClassB, init:ClassA, load:ClassC
Of course, a perfect solution would be that, it would avoid seeing Undeclared stuff popping up when loading... I'd like an automatic way to load stuff so that even recursively dependent classes would not trigger any Undeclared stuff :) But, at the same time, if we have special requests, we can order them via package pre-requisites and preload scripts, isn't it? Thierry
Thierry
Le 21/11/2013 16:15, Marcus Denker a écrit :
On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com> <mailto:siguctua@gmail.com <mailto:siguctua@gmail.com>>> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr> <mailto:marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>__>> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu> <mailto:sven@stfx.eu <mailto:sven@stfx.eu>>> wrote:
> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu> <mailto:sven@stfx.eu <mailto:sven@stfx.eu>>> wrote: > >>> >>> Yes, you can do it per class-hierarchy⦠you can implement on the class side a method to parametrize the compiler: >>> >>> compiler >>> ^super compiler options: #(- optionInlineTimesRepeat) >> >> Thanks, Marcus, that works just great. > > Marcus, > > Are we sure this option mechanism works when loading code through Monticello ? >
No⦠we should make sure that MC loads the method first. I think it does that for #compilerClass already (but not sure).
which is still doesn't eliminates problem completely, because nothing prevents me from having:
compilerClass ^ self otherMethod
and now in order to work, MC have to know somehow that #otherMethod should also be loaded first. But i think some prioritization guarantees would be really useful. At least i think we can easily prioritize class-side compilation over instance side. Like that, when you compiling any of instance-side method, you know that class side is already there (and can be used as such in different kinds of hooks).
yes, we need atomic code loading.
Marcus
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
-- Best regards, Igor Stasenko.
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95