Build 739 breaks project load initialization order?

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 ([hidden email]) 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 <[hidden email]> 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
>

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 <[hidden email]> 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 ([hidden email]) 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 <[hidden email]> 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 Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

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 <[hidden email]> 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 <[hidden email]> 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 ([hidden email]) 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 <[hidden email]> 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 Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

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 Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

Great! Thanks Guille!

 

On 29 March 2018 at 09:49:37, Guillermo Polito ([hidden email]) wrote:

PR: https://github.com/pharo-project/pharo/pull/1161

I added a test to avoid this problem in the future.

Guille

On Thu, Mar 29, 2018 at 9:36 AM, Guillermo Polito <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 ([hidden email]) 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 <[hidden email]> 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 Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

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 Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13

--

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 Web: http://guillep.github.io Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13