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 <[email protected]
<mailto:[email protected]>> wrote:
On 21 November 2013 12:30, Marcus Denker <[email protected]
<mailto:[email protected]>> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <[email protected]
<mailto:[email protected]>> wrote:
>
> On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <[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 / 83 95
