- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

so now that this is working: what is the process you follow? Initialize after each package? Stef On May 19, 2012, at 8:25 PM, Mariano Martinez Peck wrote: > 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 >

May 20, 2012

[Pharo-project] Inspecting keys in Dictionaries

by Davide Varvello

Hi, I'd like to inspect keys of a Dictionary but if I open an inspector on the dictionary and inspect a key, the inspector shows its value, instead I'd like it shows the key object. Is there an easy way to do it? Cheers Davide -- View this message in context: http://forum.world.st/Inspecting-keys-in-Dictionaries-tp4630944.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2012

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

by Dale Henrichs

Mariano, No problem, man! Sometimes you've got to "talk out loud" to figure out what you are doing wrong, I know that I do that often enough myself ... 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:43:35 PM | Subject: Re: [Pharo-project] Order of sending class side #initialize | | | | | On Sat, May 19, 2012 at 11:30 PM, Dale Henrichs < dhenrich(a)vmware.com | > wrote: | | | 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... | | | | | | heheheheh I should stop sending crap emails to the mailing list. Once | again, sorry for the noise. I was a problem in my own code. A | default flag has the incorrect value and I was initializing | twice...once after each packages and then once they all finished... | | anyway, now it works :) | | Thanks Dale for your patient | | | | | 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 | | | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | |

May 19, 2012

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

by Ben Coman

Mariano Martinez Peck wrote: > 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 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, > > I guess if you have two inheritance paths A <-- B --< C and A <-- B <-- D and C depends on D then an #initialize order of A, B, C, D is problematic. Some naive musings... 1. Have a mechanism to lazily invoke #initialize only when the class is first referenced. One way may be to load classes into a holding area in the image but install a proxy class that when referenced replaces itself with the one from the holding area. Your above code will ensure this happens for each loaded class by the end of the package load. 2. Parse the #initialize of C and D to determine dependency graph - but perhaps this is not statically defined. 3. Specify a requirement for #initialize code to hardcode a call to #initialize for any class it depends on. 4. Require packages to implement something like #initializeDependent to make them compatible with Fuel. I imagine the bootstrapping project has to solve a similar issue and pehaps share an approach. cheers -ben

May 19, 2012

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

by Mariano Martinez Peck

On Sat, May 19, 2012 at 11:30 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > 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... > > heheheheh I should stop sending crap emails to the mailing list. Once again, sorry for the noise. I was a problem in my own code. A default flag has the incorrect value and I was initializing twice...once after each packages and then once they all finished... anyway, now it works :) Thanks Dale for your patient > 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 | | 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] [squeak-dev] Re: Epoch returns local offset

by Enrico Spinielli

The choise of epoch is arbitrary, Calendrical Calculations<http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/> , set it to Rata Die 0 and defines all the ones for the other calendars - Mayan, Gregorian, Julian, Persian ... - accordingly. I did implement the Python equivalent of the Common Lisp code<goog_1788886544> from the book<http://code.google.com/p/pycalcal/source/browse/calendrica-3.0.cl>, you can browse both in my pycalcal project<http://code.google.com/p/pycalcal/>page (Python code is in the zip distribution). I have a yet unfinished implementation in Smalltalk on squeaksource called Calendrica <http://www.squeaksource.com/Calendrica>. Bye Enrico On Thu, May 17, 2012 at 2:26 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > (cross posting to squeak-dev) > > On Wed, May 16, 2012 at 01:50:16PM -0700, Sean P. DeNigris wrote: > > > > David T. Lewis wrote > > > > > > So no, it is not a constant. > > > > > > > Let me rephrase: wouldn't it be better if it was a constant, like dos and > > unix? > > Yes it would be better if the Smalltalk epoch was an unambiguously defined > value, but unfortunately it is not. That is the reason that the clearly > defined Posix epoch would be a more suitable basis for these calculations. > > <ot> > Funny that you should mention DOS. DOS has exactly the same problem > as Squeak/Pharo in this regard. It was originally designed as a simple > single-user system, where the user was expected to set the clock properly > on all of his/her alarm clocks, kitchen appliances, and computers. It > has no knowledge of time zones or daylight savings time, and this leads > to all sorts of bugs in applications running on MS-DOS that assume that > the system time is correct. I was dealing with a real-life bug of this > sort last week that had people spending huge amounts of time and energy > trying to figure out what was causing clocks to be "reset" in a complex > multi-platform application that happened to include some old DOS based > computers that were sending time stamped messages. > </ot> > > > I find the current behavior confusing e.g. > > > > dt := '1/15/2012 0000+00:00' asDateAndTime. > > > > DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e > abbreviation > > = 'PDT' ]). > > s := dt asSeconds. "3504013200" > > > > "Now I move to Greenwich" > > DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e > abbreviation > > = 'UTC' ]). > > DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!" > > > > Yes, that looks broken to me too. But DateAndTime class>>fromSeconds: is > documented as "Answer a DateAndTime since the Squeak epoch: 1 January 1901" > which by definition cannot be correctly implemented. > > One solution would be to gain agreement among all flavors of Smalltalk > as to the proper definition of the Smalltalk epoch. But it seems to me > that it would be vastly simpler to just use a definition that is already > agreed and documented (i.e. Posix epoch), and leave the "Smalltalk epoch" > behind as an interesting historical artifact. > > Dave > > > -- Enrico Spinielli "Do Androids dream of electric sheep?"â Philip K. Dick "Hear and forget; see and remember;do and understand."âMitchel Resnick "He who refuses to do arithmetic is doomed to talk nonsense."âJohn McCarthy

May 19, 2012

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