May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Order of sending class side #initialize

by Dale Henrichs

Okay, Are you loading all of the classes (for all packages) before you run the initializers? ... I'm pretty sure that some of the initializations need to be run before subclasses are _loaded_. Next, you should try to force your initialization order to match that of Metacello, if that doesn't help then something else is the root cause of your problems... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, May 19, 2012 2:20:14 PM | Subject: Re: [Pharo-project] Order of sending class side #initialize | | | | | On Sat, May 19, 2012 at 9:01 PM, Dale Henrichs < dhenrich(a)vmware.com | > wrote: | | | Mariano, | | To shed some light on the exact problem, I think that you should | record the initialization order of a Metacello load and compare that | to the initialization order that you are using. | | While your algorithm looks like it is correct it doesn't necessarily | match the actual initialization order you get when using Monticello | and Metacello... | | It would be interesting to find out where the differences in order | are and then focus on understanding why... | | | Hi Dale. Well, I did that. I noticed 2 differences: | | 1) If the class already exist and the #initialize is the same, it is | not re-executed. In my case, I execute it always. I know, this is a | problem I have. Nevertheless, the only classes that already exist in | the image I am loading is Zinc...and the problem does not seem | related to that. | | 2) The order of the classes/methods inside a package is different. I | mean, I load the packages in order, but inside, for each package, | the order I send #initialize is not the same as Monticello. Example: | | My code: | | Initializing class: WAKeyGenerator class | Initializing class: WAUrlEncoder class | Initializing class: WAServerManager class | Initializing class: WALocale class | Initializing class: WAResponse class | Initializing class: WAXmlEncoder class | Initializing class: WASystemConfiguration class | Initializing class: WASharedConfiguration class | Initializing class: WAAbstractFileLibrary class | | Monticello: | | Initialize class: (Seaside-Core-Libraries) -- WAAbstractFileLibrary | Initialize class: (Seaside-Core-Configuration) -- | WASystemConfiguration | Initialize class: (Seaside-Core-Configuration) -- | WASharedConfiguration | Initialize class: (Seaside-Core-Document) -- WAUrlEncoder | Initialize class: (Seaside-Core-Document) -- WAXmlEncoder | Initialize class: (Seaside-Core-Utilities) -- WAKeyGenerator | Initialize class: (Seaside-Core-HTTP) -- WALocale | Initialize class: (Seaside-Core-HTTP) -- WAResponse | Initialize class: (Seaside-Core-Server) -- WAServerManager | | So...maybe this is the reason? what I am thinking now that maybe the | problem is not in the initialization but instead of export? I mean, | maybe Monticello exports methods/classes with certain order and | that's why it works? because when exporting I am not using any order | at all. | | Thanks | | | | | | Dale | | | | ----- Original Message ----- | | From: "Mariano Martinez Peck" < marianopeck(a)gmail.com > | | To: "Pharo Development" < pharo-project(a)lists.gforge.inria.fr > | | Sent: Saturday, May 19, 2012 11:25:57 AM | | Subject: [Pharo-project] Order of sending class side #initialize | | | | Hi guys. I am doing some experiments with FuelPackageLoader and I | | have a problem with the initialization. All my unit tests pass but | | when trying to export/import seaside/pier/magritte, I have a | | problem. | | What I do basically, is to ask Metacello the list of packages that | | I | | need to loaded for seaside and friends. The list is IN ORDER OF | | LOADING. So what I do during the import is to load each package in | | the correct order (the one Metacello told me). For each package I | | load, I initialize its classes (at the end of the load of the | | package). The order I initialize classes for a package is: | | | | ((aPackage classes select: [:each | each isBehavior]) | | sort: [:a :b | a allSuperclasses size > initializeOnLoad | | (self class includesSelector: #initialize) | | ifTrue: [self initialize] | | | | | | so...I am having a problem with seaside with a class and it looks | | like a problem of the order of the initialize. Do you think | | something is wrong with our approach? any idea? | | | | thanks in advance, | | | | -- | | Mariano | | http://marianopeck.wordpress.com | | | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | |

May 19, 2012

Re: [Pharo-project] Order of sending class side #initialize

by Mariano Martinez Peck

Here are the output of both scenarios. Notice that my experiment finishes in WAWalkbackErrorHandler because there is where I have the error. Thanks for any help. On Sat, May 19, 2012 at 11:20 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, May 19, 2012 at 9:01 PM, Dale Henrichs <dhenrich(a)vmware.com>wrote: > >> Mariano, >> >> To shed some light on the exact problem, I think that you should record >> the initialization order of a Metacello load and compare that to the >> initialization order that you are using. >> >> While your algorithm looks like it is correct it doesn't necessarily >> match the actual initialization order you get when using Monticello and >> Metacello... >> >> It would be interesting to find out where the differences in order are >> and then focus on understanding why... >> > > Hi Dale. Well, I did that. I noticed 2 differences: > > 1) If the class already exist and the #initialize is the same, it is not > re-executed. In my case, I execute it always. I know, this is a problem I > have. Nevertheless, the only classes that already exist in the image I am > loading is Zinc...and the problem does not seem related to that. > > 2) The order of the classes/methods inside a package is different. I mean, > I load the packages in order, but inside, for each package, the order I > send #initialize is not the same as Monticello. Example: > > My code: > > Initializing class: WAKeyGenerator class > Initializing class: WAUrlEncoder class > Initializing class: WAServerManager class > Initializing class: WALocale class > Initializing class: WAResponse class > Initializing class: WAXmlEncoder class > Initializing class: WASystemConfiguration class > Initializing class: WASharedConfiguration class > Initializing class: WAAbstractFileLibrary class > > Monticello: > > Initialize class: (Seaside-Core-Libraries) -- WAAbstractFileLibrary > Initialize class: (Seaside-Core-Configuration) -- WASystemConfiguration > Initialize class: (Seaside-Core-Configuration) -- WASharedConfiguration > Initialize class: (Seaside-Core-Document) -- WAUrlEncoder > Initialize class: (Seaside-Core-Document) -- WAXmlEncoder > Initialize class: (Seaside-Core-Utilities) -- WAKeyGenerator > Initialize class: (Seaside-Core-HTTP) -- WALocale > Initialize class: (Seaside-Core-HTTP) -- WAResponse > Initialize class: (Seaside-Core-Server) -- WAServerManager > > So...maybe this is the reason? what I am thinking now that maybe the > problem is not in the initialization but instead of export? I mean, maybe > Monticello exports methods/classes with certain order and that's why it > works? because when exporting I am not using any order at all. > > Thanks > > > > >> >> Dale >> >> ----- Original Message ----- >> | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> >> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> | Sent: Saturday, May 19, 2012 11:25:57 AM >> | Subject: [Pharo-project] Order of sending class side #initialize >> | >> | Hi guys. I am doing some experiments with FuelPackageLoader and I >> | have a problem with the initialization. All my unit tests pass but >> | when trying to export/import seaside/pier/magritte, I have a >> | problem. >> | What I do basically, is to ask Metacello the list of packages that I >> | need to loaded for seaside and friends. The list is IN ORDER OF >> | LOADING. So what I do during the import is to load each package in >> | the correct order (the one Metacello told me). For each package I >> | load, I initialize its classes (at the end of the load of the >> | package). The order I initialize classes for a package is: >> | >> | ((aPackage classes select: [:each | each isBehavior]) >> | sort: [:a :b | a allSuperclasses size > | do: [:aClass | >> | Transcript show: 'Initializing class: ', aClass name; cr. >> | aClass initializeOnLoad] >> | >> | and >> | >> | Class >> initializeOnLoad >> | (self class includesSelector: #initialize) >> | ifTrue: [self initialize] >> | >> | >> | so...I am having a problem with seaside with a class and it looks >> | like a problem of the order of the initialize. Do you think >> | something is wrong with our approach? any idea? >> | >> | thanks in advance, >> | >> | -- >> | Mariano >> | http://marianopeck.wordpress.com >> | >> | >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

May 19, 2012

Re: [Pharo-project] Order of sending class side #initialize

by Mariano Martinez Peck

On Sat, May 19, 2012 at 9:01 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Mariano, > > To shed some light on the exact problem, I think that you should record > the initialization order of a Metacello load and compare that to the > initialization order that you are using. > > While your algorithm looks like it is correct it doesn't necessarily match > the actual initialization order you get when using Monticello and > Metacello... > > It would be interesting to find out where the differences in order are and > then focus on understanding why... > Hi Dale. Well, I did that. I noticed 2 differences: 1) If the class already exist and the #initialize is the same, it is not re-executed. In my case, I execute it always. I know, this is a problem I have. Nevertheless, the only classes that already exist in the image I am loading is Zinc...and the problem does not seem related to that. 2) The order of the classes/methods inside a package is different. I mean, I load the packages in order, but inside, for each package, the order I send #initialize is not the same as Monticello. Example: My code: Initializing class: WAKeyGenerator class Initializing class: WAUrlEncoder class Initializing class: WAServerManager class Initializing class: WALocale class Initializing class: WAResponse class Initializing class: WAXmlEncoder class Initializing class: WASystemConfiguration class Initializing class: WASharedConfiguration class Initializing class: WAAbstractFileLibrary class Monticello: Initialize class: (Seaside-Core-Libraries) -- WAAbstractFileLibrary Initialize class: (Seaside-Core-Configuration) -- WASystemConfiguration Initialize class: (Seaside-Core-Configuration) -- WASharedConfiguration Initialize class: (Seaside-Core-Document) -- WAUrlEncoder Initialize class: (Seaside-Core-Document) -- WAXmlEncoder Initialize class: (Seaside-Core-Utilities) -- WAKeyGenerator Initialize class: (Seaside-Core-HTTP) -- WALocale Initialize class: (Seaside-Core-HTTP) -- WAResponse Initialize class: (Seaside-Core-Server) -- WAServerManager So...maybe this is the reason? what I am thinking now that maybe the problem is not in the initialization but instead of export? I mean, maybe Monticello exports methods/classes with certain order and that's why it works? because when exporting I am not using any order at all. Thanks > > Dale > > ----- Original Message ----- > | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > | Sent: Saturday, May 19, 2012 11:25:57 AM > | Subject: [Pharo-project] Order of sending class side #initialize > | > | Hi guys. I am doing some experiments with FuelPackageLoader and I > | have a problem with the initialization. All my unit tests pass but > | when trying to export/import seaside/pier/magritte, I have a > | problem. > | What I do basically, is to ask Metacello the list of packages that I > | need to loaded for seaside and friends. The list is IN ORDER OF > | LOADING. So what I do during the import is to load each package in > | the correct order (the one Metacello told me). For each package I > | load, I initialize its classes (at the end of the load of the > | package). The order I initialize classes for a package is: > | > | ((aPackage classes select: [:each | each isBehavior]) > | sort: [:a :b | a allSuperclasses size | do: [:aClass | > | Transcript show: 'Initializing class: ', aClass name; cr. > | aClass initializeOnLoad] > | > | and > | > | Class >> initializeOnLoad > | (self class includesSelector: #initialize) > | ifTrue: [self initialize] > | > | > | so...I am having a problem with seaside with a class and it looks > | like a problem of the order of the initialize. Do you think > | something is wrong with our approach? any idea? > | > | thanks in advance, > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | > > -- Mariano http://marianopeck.wordpress.com

May 19, 2012

[Pharo-project] [update 2.0] #20078

by StÃ©phane Ducasse

20078 ----- - Issue 5923: More Sensor cleans and Process browser cleans. Thanks Igor Stasenko. http://code.google.com/p/pharo/issues/detail?id=5923 - Issue 5921: menu for transcripter http://code.google.com/p/pharo/issues/detail?id=5921 - Issue 5915: Cleaning Icons http://code.google.com/p/pharo/issues/detail?id=5915 - Issue 5904: Less dependentFields users. Thanks Benjamin van Ryseghem. It was fun pair hacking. http://code.google.com/p/pharo/issues/detail?id=5904 - Issue 5903: MonticelloAnnouncer may announce two times an announcement. Thanks Igor and Benjamin. http://code.google.com/p/pharo/issues/detail?id=5903 Stef (more and many more to come).

May 19, 2012

Re: [Pharo-project] Order of sending class side #initialize

by Dale Henrichs

Another data point is Lukas' build scripts for the Jenkins[1]. They use Gofer to load, but they "get the initialization correct", as does Metacello. Dale [1] https://github.com/renggli/builder/blob/master/scripts/seaside3.st ----- Original Message ----- | From: "Dale Henrichs" <dhenrich(a)vmware.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, May 19, 2012 12:01:38 PM | Subject: Re: [Pharo-project] Order of sending class side #initialize | | Mariano, | | To shed some light on the exact problem, I think that you should | record the initialization order of a Metacello load and compare that | to the initialization order that you are using. | | While your algorithm looks like it is correct it doesn't necessarily | match the actual initialization order you get when using Monticello | and Metacello... | | It would be interesting to find out where the differences in order | are and then focus on understanding why... | | Dale | | ----- Original Message ----- | | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> | | Sent: Saturday, May 19, 2012 11:25:57 AM | | Subject: [Pharo-project] Order of sending class side #initialize | | | | Hi guys. I am doing some experiments with FuelPackageLoader and I | | have a problem with the initialization. All my unit tests pass but | | when trying to export/import seaside/pier/magritte, I have a | | problem. | | What I do basically, is to ask Metacello the list of packages that | | I | | need to loaded for seaside and friends. The list is IN ORDER OF | | LOADING. So what I do during the import is to load each package in | | the correct order (the one Metacello told me). For each package I | | load, I initialize its classes (at the end of the load of the | | package). The order I initialize classes for a package is: | | | | ((aPackage classes select: [:each | each isBehavior]) | | sort: [:a :b | a allSuperclasses size > initializeOnLoad | | (self class includesSelector: #initialize) | | ifTrue: [self initialize] | | | | | | so...I am having a problem with seaside with a class and it looks | | like a problem of the order of the initialize. Do you think | | something is wrong with our approach? any idea? | | | | thanks in advance, | | | | -- | | Mariano | | http://marianopeck.wordpress.com | | | | | |

May 19, 2012

Re: [Pharo-project] Order of sending class side #initialize

by Dale Henrichs

Mariano, To shed some light on the exact problem, I think that you should record the initialization order of a Metacello load and compare that to the initialization order that you are using. While your algorithm looks like it is correct it doesn't necessarily match the actual initialization order you get when using Monticello and Metacello... It would be interesting to find out where the differences in order are and then focus on understanding why... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> | Sent: Saturday, May 19, 2012 11:25:57 AM | Subject: [Pharo-project] Order of sending class side #initialize | | Hi guys. I am doing some experiments with FuelPackageLoader and I | have a problem with the initialization. All my unit tests pass but | when trying to export/import seaside/pier/magritte, I have a | problem. | What I do basically, is to ask Metacello the list of packages that I | need to loaded for seaside and friends. The list is IN ORDER OF | LOADING. So what I do during the import is to load each package in | the correct order (the one Metacello told me). For each package I | load, I initialize its classes (at the end of the load of the | package). The order I initialize classes for a package is: | | ((aPackage classes select: [:each | each isBehavior]) | sort: [:a :b | a allSuperclasses size > initializeOnLoad | (self class includesSelector: #initialize) | ifTrue: [self initialize] | | | so...I am having a problem with seaside with a class and it looks | like a problem of the order of the initialize. Do you think | something is wrong with our approach? any idea? | | thanks in advance, | | -- | Mariano | http://marianopeck.wordpress.com | |

May 19, 2012

[Pharo-project] Order of sending class side #initialize

by Mariano Martinez Peck

Hi guys. I am doing some experiments with FuelPackageLoader and I have a problem with the initialization. All my unit tests pass but when trying to export/import seaside/pier/magritte, I have a problem. What I do basically, is to ask Metacello the list of packages that I need to loaded for seaside and friends. The list is IN ORDER OF LOADING. So what I do during the import is to load each package in the correct order (the one Metacello told me). For each package I load, I initialize its classes (at the end of the load of the package). The order I initialize classes for a package is: ((aPackage classes select: [:each | each isBehavior]) sort: [:a :b | a allSuperclasses size > initializeOnLoad (self class includesSelector: #initialize) ifTrue: [self initialize] so...I am having a problem with seaside with a class and it looks like a problem of the order of the initialize. Do you think something is wrong with our approach? any idea? thanks in advance, -- Mariano http://marianopeck.wordpress.com

May 19, 2012

Re: [Pharo-project] ss3 down?

by Mariano Martinez Peck

Now it works :) On Sat, May 19, 2012 at 5:32 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > I'm not seeing that ... could you provide more details... > > Dale > > ----- Original Message ----- > | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Saturday, May 19, 2012 8:21:57 AM > | Subject: Re: [Pharo-project] ss3 down? > | > | Hi Dale. Thanks for checking. In fact, the website is down but as > | soon as you try to log in and go to one of your projects, you get a > | error 500. > | > | thanks! > | > | > | On Sat, May 19, 2012 at 5:17 PM, Dale Henrichs < dhenrich(a)vmware.com > | > wrote: > | > | > | Mariano, > | > | SS3 is back online. Several of the vms running in the data center > | were unintentionally power cycled and then did not restart correctly > | ... > | > | > | Dale > | > | ----- Original Message ----- > | > | > | | From: "Dale Henrichs" < dhenrich(a)vmware.com > > | | To: Pharo-project(a)lists.gforge.inria.fr > | | Sent: Saturday, May 19, 2012 7:55:37 AM > | | Subject: Re: [Pharo-project] ss3 down? > | | > | | There was maintenance scheduled for the data center, but I was > | | assured that it would effect ss3 ... loks like that might be the > | | case ... getting the IS guys on the case now. > | | > | | Thanks for the heads up. > | | > | | Dale > | | > | | ----- Original Message ----- > | | | From: "Mariano Martinez Peck" < marianopeck(a)gmail.com > > | | | To: "Pharo Development" < pharo-project(a)lists.gforge.inria.fr > > | | | Sent: Saturday, May 19, 2012 7:23:47 AM > | | | Subject: [Pharo-project] ss3 down? > | | | > | | | > | | | > | | | -- > | | | Mariano > | | | http://marianopeck.wordpress.com > | | | > | | | > | | > | | > | > | > | > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | > > -- Mariano http://marianopeck.wordpress.com

May 19, 2012

Re: [Pharo-project] ss3 down?

by Dale Henrichs

I'm not seeing that ... could you provide more details... Dale ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, May 19, 2012 8:21:57 AM | Subject: Re: [Pharo-project] ss3 down? | | Hi Dale. Thanks for checking. In fact, the website is down but as | soon as you try to log in and go to one of your projects, you get a | error 500. | | thanks! | | | On Sat, May 19, 2012 at 5:17 PM, Dale Henrichs < dhenrich(a)vmware.com | > wrote: | | | Mariano, | | SS3 is back online. Several of the vms running in the data center | were unintentionally power cycled and then did not restart correctly | ... | | | Dale | | ----- Original Message ----- | | | | From: "Dale Henrichs" < dhenrich(a)vmware.com > | | To: Pharo-project(a)lists.gforge.inria.fr | | Sent: Saturday, May 19, 2012 7:55:37 AM | | Subject: Re: [Pharo-project] ss3 down? | | | | There was maintenance scheduled for the data center, but I was | | assured that it would effect ss3 ... loks like that might be the | | case ... getting the IS guys on the case now. | | | | Thanks for the heads up. | | | | Dale | | | | ----- Original Message ----- | | | From: "Mariano Martinez Peck" < marianopeck(a)gmail.com > | | | To: "Pharo Development" < pharo-project(a)lists.gforge.inria.fr > | | | Sent: Saturday, May 19, 2012 7:23:47 AM | | | Subject: [Pharo-project] ss3 down? | | | | | | | | | | | | -- | | | Mariano | | | http://marianopeck.wordpress.com | | | | | | | | | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | |

May 19, 2012

Re: [Pharo-project] ss3 down?

by StÃ©phane Ducasse

thanks dale. Stef (dizzy under pain lowering pills) > Mariano, > > SS3 is back online. Several of the vms running in the data center were unintentionally power cycled and then did not restart correctly ... > > Dale

May 19, 2012