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

Re: [Pharo-project] Inspecting keys in Dictionaries

by Davide Varvello

Thanks Herby, But if I run an inspector on keys I lose the possibility to see the name of any single key because when you inspect an array you see only a numeric list on the left side of the inspector. Is there a way to avoid it? Davide Herby VojÄÃk wrote > > Writing "nameOfTheDictionary keys" in the inspect window, selecting it > and inspecting it? > > Herby > > Davide Varvello wrote: >> 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. >> > -- View this message in context: http://forum.world.st/Inspecting-keys-in-Dictionaries-tp4630944p4630961.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2012

[Pharo-project] Fwd: Re: [Sugar-devel] Dr.Geo on XO 1

by Hilaire Fernandes

With Pharo 1.4 (but not with Pharo 1.3) we have a problem leading to the crash of DrGeo (based on Pharo 1.4) on low memory machine. It is clearly a problem related to Pharo 1.4 Any idea why ? Hilaire -------- Original Message -------- Subject: Re: [Sugar-devel] Dr.Geo on XO 1 Date: Sun, 20 May 2012 13:46:01 +0200 From: Bert Freudenberg <bert(a)freudenbergs.de> To: Sascha Silbe <silbe(a)activitycentral.com> CC: Ariel Calzada <ariel.calzada(a)gmail.com>, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch>, Sugar Devel <sugar-devel(a)lists.sugarlabs.org>, Rafael Ortiz <rafael(a)activitycentral.com> On 20.05.2012, at 11:00, Sascha Silbe wrote: > Bert Freudenberg <bert(a)freudenbergs.de> writes: > >> Nope, that was not it. I compiled with -mtune=geode, makes no >> difference. > > Make sure to set -march=<architecture> to something appropriate. -march > tells gcc what instructions it can use (so anything that doesn't support > these instructions will fail to run the resulting executable), whereas > -mtune only tells it to optimise for a certain processor type (but the > executable will continue to run on other processors as long as they > support the instruction set specified by -march). I actually had used "-march=pentiumpro -mtune=geode" as recommended here: http://wiki.laptop.org/go/Geode_LX and even with an additional -O0 it still crashes. > In gdb I see it's segfaulting inside the GC logic. It's really >> puzzling this only happens on the XO-1 ... > > You could try booting an XO-1.5 with mem=256M (append that to boot-file > in /bootpart/boot/olpc.fth) to simulate the memory pressure of an XO-1. YES! That reproduces the crash on XO-1.5. Good thinking! :) I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but no swap. Top reports: Mem: 766204k total, 601588k used, 164616k free, 45624k buffers Swap: 0k total, 0k used, 0k free, 277024k cached but DrGeo still crashes. OTOH, Etoys runs fine using the same Squeak VM on the same system (and on XO-1). So I wonder what the new DrGeo does differently ... - Bert -

May 20, 2012

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

by Edgar J. De Cleene

On 5/19/12 6:20 PM, "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > because when exporting I am not using any order at all. Hey Mariano: IMHO you SHOULD use a exporting order and this could be the same when you export a plain .cs. All you working on Fuel and Injectorare doing a great job !!! Edgar

May 20, 2012

Re: [Pharo-project] Inspecting keys in Dictionaries

by Herby VojÄÃk

Writing "nameOfTheDictionary keys" in the inspect window, selecting it and inspecting it? Herby Davide Varvello wrote: > 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 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 < b 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 < b 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 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 < b > 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 < b 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