Build 739 breaks project load initialization order?
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? Thanks, -Martin
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
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 <martin@hand2mouse.com> 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
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 <martin@hand2mouse.com> 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 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 (martin@hand2mouse.com) 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 <martin@hand2mouse.com> 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 <maxleske@gmail.com> 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 (martin@hand2mouse.com) 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 <martin@hand2mouse.com> 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
Issue: https://pharo.manuscript.com/f/cases/21658/Monticello-initializers-are-not-e... On Thu, Mar 29, 2018 at 9:33 AM, Guillermo Polito <guillermopolito@gmail.com
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 <maxleske@gmail.com> 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 (martin@hand2mouse.com) 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 <martin@hand2mouse.com> 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
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 <guillermopolito@gmail.com
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 < guillermopolito@gmail.com> wrote:
I'm checking it.
It may be a side effect of: https://github.com/pharo-proje ct/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 <maxleske@gmail.com> 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 (martin@hand2mouse.com) 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 <martin@hand2mouse.com> 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 <+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
Great! Thanks Guille! On 29 March 2018 at 09:49:37, Guillermo Polito (guillermopolito@gmail.com) 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 <guillermopolito@gmail.com
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 < guillermopolito@gmail.com> wrote:
I'm checking it.
It may be a side effect of: https://github.com/pharo-proje ct/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 <maxleske@gmail.com> 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 (martin@hand2mouse.com) 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 <martin@hand2mouse.com> 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 <+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
Thanks a lot Guille. I love you attitude and your systematic tests On Thu, Mar 29, 2018 at 10:10 AM, Max Leske <maxleske@gmail.com> wrote:
Great! Thanks Guille!
On 29 March 2018 at 09:49:37, Guillermo Polito (guillermopolito@gmail.com) 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 < guillermopolito@gmail.com> 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 < guillermopolito@gmail.com> wrote:
I'm checking it.
It may be a side effect of: https://github.com/pharo-proje ct/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 <maxleske@gmail.com> 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 (martin@hand2mouse.com) 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 <martin@hand2mouse.com> 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 <+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 <+33%206%2052%2070%2066%2013>
Thanks, Guille! I can confirm that my load once again initializes properly. -Martin On 03/29/2018 12:48 AM, Guillermo Polito wrote:
PR:Â https://github.com/pharo-project/pharo/pull/1161
I added a test to avoid this problem in the future.
Guille
participants (5)
-
Guillermo Polito -
Martin McClure -
Max Leske -
Stephane Ducasse -
Sven Van Caekenberghe