I fail to see what atomic means in this context, it's too broad idea. To me atomic would be: compile all in a certain sequence, then install all at once atomically. And in this case, there is still a problem, because it would resolve installation order, not compilation order... The idea of compiling class side first sounds good to me. It's not atomic, but might just work. 2013/11/21 Marcus Denker <marcus.denker@inria.fr>
On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua@gmail.com> wrote:
On 21 November 2013 12:30, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <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