March 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Reflectivity] change regarding announcement in Pharo7

by Marcus Denker

> On 29 Mar 2018, at 04:00, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Interesting. > > What exactly is slow? The installation of a meta link? How slower is it? > yes, as the IDE updates. I is really slow, to the point i did not even benchmark. (just running the tests feels extremely slow, in Pharo6 getting slower the more browsers are open) And the tests do not even install many links. We could get numbers by running all tests before and after the patch. Marcus

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Guillermo Polito

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(a)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(a)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(a)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(a)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(a)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

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Guillermo Polito

Issue: https://pharo.manuscript.com/f/cases/21658/Monticello-initializers-are-not-… On Thu, Mar 29, 2018 at 9:33 AM, Guillermo Polito <guillermopolito(a)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(a)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(a)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(a)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

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Guillermo Polito

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(a)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(a)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(a)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

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Max Leske

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(a)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(a)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 >

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Martin McClure

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(a)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 >

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Sven Van Caekenberghe

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(a)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

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Martin McClure

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

March 29, 2018

Re: [Pharo-dev] [Reflectivity] change regarding announcement in Pharo7

by Tudor Girba

Hi, Interesting. What exactly is slow? The installation of a meta link? How slower is it? Cheers, Doru > On Mar 28, 2018, at 4:03 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > One questionable (but practical) thing that MetaLinks have is that they announce (MetalinkChanged) when they are installed or uninstalled. > This is nice for being able to show them in the UI (and e.g. the Watcher implemented with them). > > But it is very very slowâ¦ so I now made it an option: > > https://github.com/pharo-project/pharo/pull/1160 > > it is by default off, but can be turned on reflectively at any point. > > > e.g. the link of the execution counter now looks like this: > > link := MetaLink new > metaObject: self; > selector: #increase; > optionAnnounce: true. > > It has announcing enable so that the browser refreshes when it gets added or removed. > > Marcus -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

March 29, 2018

Build 739 breaks project load initialization order?

by Martin McClure

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

March 28, 2018