Issue: https://pharo.manuscript.com/f/cases/21658/Monticello-initializers-are-not-enabled-by-default
On Thu, Mar 29, 2018 at 9:33 AM, Guillermo Polito <[email protected] > wrote: > I'm checking it. > > It may be a side effect of: https://github.com/pharo- > project/pharo/pull/1130 > > Short story long: > - building Pharo we need to ensure that class initializations are > executed in a particular order, so some metacello configurations are > disabling monticello initializers during baselines > - I introduced/refactored a couple of new baselines because I'm playing > with creating smaller images. > - I discovered (and tried to patch probably not entirely right) a bug > that makes baseline postloads being executed more than once > - but all tests were green :D > > So I'll introduce a new test to verify that monticello initializers are > enabled by default and check what the problem is. > Keep you updated. > > > On Thu, Mar 29, 2018 at 9:18 AM, Max Leske <[email protected]> wrote: > >> I can confirm that class side #initialization is broken. Don't know since >> when though. >> >> Cheers, >> Max >> >> >> >> On 29 March 2018 at 08:28:00, Martin McClure ([email protected]) >> wrote: >> >> Good to know. In my case, however, I'm always loading code into a fresh >> image where these classes don't previously exist, so I would think that >> #initialize would always be sent. >> >> >> On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote: >> > class side #initialize is only send by MC if the incoming source code >> is different, has changed. I always add a date in a comment to be sure. >> > >> >> On 29 Mar 2018, at 04:47, Martin McClure <[email protected]> >> wrote: >> >> >> >> On 03/28/2018 04:35 PM, Martin McClure wrote: >> >>> I have a project that loads via Metacello in builds up through build >> >>> 738. In 739 the load fails with DNU. >> >>> >> >>> The failure is in a method I have specified via a #postLoadDoIt:. It >> >>> fails because it sends a message to a pool variable, which is nil. >> >>> However, it should not be nil because it should have been initialized >> by >> >>> a class-side #initialize method in a prerequisite package. >> >>> >> >>> Again, this worked up through build 738. Any idea what changed in 739 >> >>> that would cause this, and is this change intentional? >> >> Odd, I don't see any code changes that would be likely to have caused >> this. >> >> >> >> Is the expected behavior of Metacello to send #initialize to classes >> in >> >> prerequisite packages before running a #postLoadDoIt in a package? I'd >> >> think so, but am starting to wonder if this is perhaps unordered and >> >> I've just been lucky... >> >> >> >> -Martin >> > >> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
