On 21 November 2013 16:30, Goubier Thierry <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

��
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




--
Best regards,
Igor Stasenko.