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?). 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>> wrote:
On 21 November 2013 12:30, Marcus Denker <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>> wrote:
> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <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 / 83 95