On 21 November 2013 12:30, Marcus Denker <[email protected]> wrote:
> > On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <[email protected]> wrote: > > > > > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <[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). > > I mean, this build fails the PEGParser tests: > > > > https://ci.inria.fr/pharo-contribution/job/Xtreams/ > > > > but it includes the #compiler options in Xtreams-Parsing-nice.7 > > > > Could it not be that this is a chicken-egg problem: the #compiler > options are only there _after_ the class is loaded/compiled, or maybe it is > an instance/class side problem ? > > > > Sven > > > > > > > -- Best regards, Igor Stasenko.
