Le 21/11/2013 16:37, Igor Stasenko a écrit :
On 21 November 2013 16:30, Goubier Thierry <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
On 21 November 2013 12:30, Marcus Denker
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>__>> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> On 19 Nov 2013, at 16:45, Sven Van Caekenberghe
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
