January 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Problem with OB compare versions - Issue 1033 again :(

by Mariano Martinez Peck

Hi: In latest Dev version there is again this bug :( http://code.google.com/p/pharo/issues/detail?id=1033 The problem is that OBVersionBrowser DNU definitionPanel In previous versions OBBrowser has definitionPanel but in latest version it doesnt. I think the fix is as putting again: OBBrowser >> definitionPanel ^ panels detect: [:ea | ea isDefinition] ifNone: [self error: 'No definition panel configured'] Or maybe it should be in OBVersionBrowser ? Cheers Mariano

Jan. 16, 2010

Re: [Pharo-project] Date fromString: '6-Jan-10'

by StÃ©phane Ducasse

But if you deal with incomplete data why not building your own reader and control it. I think that a library class cannot be tuned to deal with all kind of crazy situation. I would prefer that Date is robust and consistent and that people implement their own custom situation. Does anybody know how it is done in other languages. Stef On Jan 16, 2010, at 9:36 PM, David Harris wrote: > I think a solution that can tuned or tweaked to it's application would > be must useful. It's all very well to insist on users using four- > digit years, but for processing historical data, for example, one > doesn't have the luxury of insisting on the data format, but has to > use what is there :-( > > Perhaps a variable that determines the transition from 19xx to 20xx > would be appropriate? > > David > PS- here in Canada we interpret 4/5/xxxx the opposite to the USA. I > always use yyyy.mm.dd.hh.ss to the appropriate resolution :-) > > > On 2010-01-16, at 10:42 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > >> Yes >> >> Date fromString: '6-Jan-03' >> -> 6 January 2003 >> >> is also wrong. So david just tried to patch this wrong behavior. >> >> Stef >> >> >> On Jan 16, 2010, at 6:02 PM, csrabak(a)bol.com.br wrote: >> >>> I'm afraid the 'fix' is trying to repair something is not broken! >>> >>> Date fromString: '6-Jan-10'. giving "6 January 1910" has not >>> anything wrong. Within five year we'll have users/programmers >>> complaining that: >>> >>> Date fromString: '6-Jan-16'. gave "6 January 1916" and *obviously* >>> it should have given "6 January 2015"!! >>> >>> Rather document that years given with two figures get counted from >>> 1900 (as it used to be in last century) and have people to use four >>> digits for years in the 2000s. >>> >>> Otherwise: >>> >>> 1) We need to get used to the concept of an epoch time for Pharo; or >>> >>> 2) the number to be tested has to be the current year! >>> >>> My 0.019999. . . >>> >>> -- >>> Cesar Rabak >>> >>> >>> Em 16/01/2010 07:57, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr >>>> escreveu: >>> >>> >>> hi guys >>> >>> can one of you give a look at the this fix because I'm confused. >>> Kernel-DavidHotham.538 >>> >>> year < 20 ifTrue: [year := 2000 + year] >>> was >>> year < 10 ifTrue: [year := 2000 + year] >>> >>> both solutions look strange to me. >>> >>> http://code.google.com/p/pharo/issues/detail?id=1749 >>> >>> >>> readFrom: aStream >>> "Read a Date from the stream in any of the forms: >>> (5 April 1982; 5-APR-82) >>> (April 5, 1982) >>> (4/5/82) >>> (5APR82)" >>> | day month year | >>> aStream peek isDigit >>> ifTrue: [day := Integer readFrom: aStream]. >>> [aStream peek isAlphaNumeric] >>> whileFalse: [aStream skip: 1]. >>> aStream peek isLetter >>> ifTrue: ["number/name... or name..." >>> month := (String new: 10) writeStream. >>> [aStream peek isLetter] >>> whileTrue: [month nextPut: aStream next]. >>> month := month contents. >>> day isNil >>> ifTrue: ["name/number..." >>> [aStream peek isAlphaNumeric] >>> whileFalse: [aStream skip: 1]. >>> day := Integer readFrom: aStream]] >>> ifFalse: ["number/number..." >>> month := Month nameOfMonth: day. >>> day := Integer readFrom: aStream]. >>> [aStream peek isAlphaNumeric] >>> whileFalse: [aStream skip: 1]. >>> year := Integer readFrom: aStream. >>>>> year < 20 ifTrue: [year := 2000 + year] >>> ifFalse: [ year < 1900 ifTrue: [ year := 1900 + year]]. >>> >>> ^ self >>> year: year >>> month: month >>> day: day >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.0 & 1.1 failing tests testFinalizationOfEquals

by Nicolas Cellier

2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Ah Ah, I found the guilty: > > Set>> do: Â use 1 to: array size do: [:i | (array at: i) ... > > But array inst. var can be overwritten inside the loop due to #rehash > > OK, OK, I thought I would catch it be redefining do: in WeakKeyDictionary > > do: aBlock > Â Â Â Â "This needs to be redefined because array inst. var. can eventually > be overwritten during the loop (due to rehash, due to fullCheck) and > make super fail." > > Â Â Â Â tally = 0 ifTrue: [^ self]. > Â Â Â Â array do: > Â Â Â Â Â Â Â Â [:each | > Â Â Â Â Â Â Â Â each ifNotNil: [aBlock value: each]] > Never mind, this was a bad idea anyway, Dictionary do: should only iterate on values > But ARGHH SUPER EVIL, this method does not get executed BECAUSE : > > Dictionary>>associationsDo: aBlock > Â Â Â Â "Evaluate aBlock for each of the receiver's elements (key/value > Â Â Â Â associations)." > > Â Â Â Â super do: aBlock > > ARGHH, it really uses super do:, not my brand new #do: > > This is a good reason I DON'T LIKE INVOKING super WITH A DIFFERENT selector... > > Does not matter, I will just redefine Set>>do:, but that was my evil > minute of the day... > > Nicolas > > 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Oh, now it fails due to WeakIdentityKeyDictionary bug... >> >> Nicolas >> >> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> I wrote this test pre-closure. >>> The problem with closures is that they are optimized to retain a >>> pointer to the values of outer temporary variable they use when >>> activated. >>> Thus the BlockClosures forAnyTwoEqualObjects ofDifferentIdentity >>> registeringAnActionAtFinalizationForEachObject all refer to 'hello' >>> pointed by o1 and its copy pointed by o2. >>> In other words, o1 and o2 are not the single pointers to the String >>> 'hello' and its copy. >>> thenForcingFinalizationOfObjects only clean o1 and o2, but omit to >>> clean the closures that still point to 'hello'... >>> Thus, 'hello' is not finalized. >>> One possibility is to also clean the closures pointing to 'hello'. >>> But now the code is tricky... It's aim was to be simple damned :) >>> >>> Nicolas >>> >>> >>> here is a corrected version : >>> >>> >>> testFinalizationOfEquals >>> Â Â Â Â "self debug: #testFinalizationOfEquals" >>> >>> Â Â Â Â | finalizationProbe o1 o2 >>> Â Â Â Â forAnyTwoEqualObjects >>> Â Â Â Â ofDifferentIdentity >>> Â Â Â Â registeringAnActionAtFinalizationForEachObject >>> Â Â Â Â thenForcingFinalizationOfObjects >>> Â Â Â Â implyBothRegisteredActionsAreExecuted | >>> >>> Â Â Â Â finalizationProbe := Set new. >>> Â Â Â Â o1 := 'hello' copy. >>> Â Â Â Â o2 := 'hello' copy. >>> Â Â Â Â forAnyTwoEqualObjects := [o1 = o2]. >>> Â Â Â Â ofDifferentIdentity := [o1 ~~ o2]. >>> Â Â Â Â registeringAnActionAtFinalizationForEachObject := [ >>> Â Â Â Â Â Â Â Â o1 toFinalizeSend: #add: to: finalizationProbe Â with: 'first object finalized'. >>> Â Â Â Â Â Â Â Â o2 toFinalizeSend: #add: to: finalizationProbe Â with: 'second object >>> finalized']. >>> Â Â Â Â thenForcingFinalizationOfObjects := [ >>> Â Â Â Â Â Â Â Â forAnyTwoEqualObjects := ofDifferentIdentity := >>> registeringAnActionAtFinalizationForEachObject := nil. >>> Â Â Â Â Â Â Â Â o1 := o2 := nil. Smalltalk garbageCollect]. >>> Â Â Â Â implyBothRegisteredActionsAreExecuted := [finalizationProbe size = 2]. >>> >>> Â Â Â Â self >>> Â Â Â Â Â Â Â Â assert: forAnyTwoEqualObjects; >>> Â Â Â Â Â Â Â Â assert: ofDifferentIdentity; >>> Â Â Â Â Â Â Â Â should: [ >>> Â Â Â Â Â Â Â Â Â Â Â Â registeringAnActionAtFinalizationForEachObject value. >>> Â Â Â Â Â Â Â Â Â Â Â Â thenForcingFinalizationOfObjects value. >>> Â Â Â Â Â Â Â Â Â Â Â Â implyBothRegisteredActionsAreExecuted value]. >>> >> >

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.0 & 1.1 failing tests testFinalizationOfEquals

by Nicolas Cellier

Ah Ah, I found the guilty: Set>> do: use 1 to: array size do: [:i | (array at: i) ... But array inst. var can be overwritten inside the loop due to #rehash OK, OK, I thought I would catch it be redefining do: in WeakKeyDictionary do: aBlock "This needs to be redefined because array inst. var. can eventually be overwritten during the loop (due to rehash, due to fullCheck) and make super fail." tally = 0 ifTrue: [^ self]. array do: [:each | each ifNotNil: [aBlock value: each]] But ARGHH SUPER EVIL, this method does not get executed BECAUSE : Dictionary>>associationsDo: aBlock "Evaluate aBlock for each of the receiver's elements (key/value associations)." super do: aBlock ARGHH, it really uses super do:, not my brand new #do: This is a good reason I DON'T LIKE INVOKING super WITH A DIFFERENT selector... Does not matter, I will just redefine Set>>do:, but that was my evil minute of the day... Nicolas 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Oh, now it fails due to WeakIdentityKeyDictionary bug... > > Nicolas > > 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> I wrote this test pre-closure. >> The problem with closures is that they are optimized to retain a >> pointer to the values of outer temporary variable they use when >> activated. >> Thus the BlockClosures forAnyTwoEqualObjects ofDifferentIdentity >> registeringAnActionAtFinalizationForEachObject all refer to 'hello' >> pointed by o1 and its copy pointed by o2. >> In other words, o1 and o2 are not the single pointers to the String >> 'hello' and its copy. >> thenForcingFinalizationOfObjects only clean o1 and o2, but omit to >> clean the closures that still point to 'hello'... >> Thus, 'hello' is not finalized. >> One possibility is to also clean the closures pointing to 'hello'. >> But now the code is tricky... It's aim was to be simple damned :) >> >> Nicolas >> >> >> here is a corrected version : >> >> >> testFinalizationOfEquals >> Â Â Â Â "self debug: #testFinalizationOfEquals" >> >> Â Â Â Â | finalizationProbe o1 o2 >> Â Â Â Â forAnyTwoEqualObjects >> Â Â Â Â ofDifferentIdentity >> Â Â Â Â registeringAnActionAtFinalizationForEachObject >> Â Â Â Â thenForcingFinalizationOfObjects >> Â Â Â Â implyBothRegisteredActionsAreExecuted | >> >> Â Â Â Â finalizationProbe := Set new. >> Â Â Â Â o1 := 'hello' copy. >> Â Â Â Â o2 := 'hello' copy. >> Â Â Â Â forAnyTwoEqualObjects := [o1 = o2]. >> Â Â Â Â ofDifferentIdentity := [o1 ~~ o2]. >> Â Â Â Â registeringAnActionAtFinalizationForEachObject := [ >> Â Â Â Â Â Â Â Â o1 toFinalizeSend: #add: to: finalizationProbe Â with: 'first object finalized'. >> Â Â Â Â Â Â Â Â o2 toFinalizeSend: #add: to: finalizationProbe Â with: 'second object >> finalized']. >> Â Â Â Â thenForcingFinalizationOfObjects := [ >> Â Â Â Â Â Â Â Â forAnyTwoEqualObjects := ofDifferentIdentity := >> registeringAnActionAtFinalizationForEachObject := nil. >> Â Â Â Â Â Â Â Â o1 := o2 := nil. Smalltalk garbageCollect]. >> Â Â Â Â implyBothRegisteredActionsAreExecuted := [finalizationProbe size = 2]. >> >> Â Â Â Â self >> Â Â Â Â Â Â Â Â assert: forAnyTwoEqualObjects; >> Â Â Â Â Â Â Â Â assert: ofDifferentIdentity; >> Â Â Â Â Â Â Â Â should: [ >> Â Â Â Â Â Â Â Â Â Â Â Â registeringAnActionAtFinalizationForEachObject value. >> Â Â Â Â Â Â Â Â Â Â Â Â thenForcingFinalizationOfObjects value. >> Â Â Â Â Â Â Â Â Â Â Â Â implyBothRegisteredActionsAreExecuted value]. >> >

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.0 & 1.1 failing tests testFinalizationOfEquals

by Nicolas Cellier

Oh, now it fails due to WeakIdentityKeyDictionary bug... Nicolas 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I wrote this test pre-closure. > The problem with closures is that they are optimized to retain a > pointer to the values of outer temporary variable they use when > activated. > Thus the BlockClosures forAnyTwoEqualObjects ofDifferentIdentity > registeringAnActionAtFinalizationForEachObject all refer to 'hello' > pointed by o1 and its copy pointed by o2. > In other words, o1 and o2 are not the single pointers to the String > 'hello' and its copy. > thenForcingFinalizationOfObjects only clean o1 and o2, but omit to > clean the closures that still point to 'hello'... > Thus, 'hello' is not finalized. > One possibility is to also clean the closures pointing to 'hello'. > But now the code is tricky... It's aim was to be simple damned :) > > Nicolas > > > here is a corrected version : > > > testFinalizationOfEquals > Â Â Â Â "self debug: #testFinalizationOfEquals" > > Â Â Â Â | finalizationProbe o1 o2 > Â Â Â Â forAnyTwoEqualObjects > Â Â Â Â ofDifferentIdentity > Â Â Â Â registeringAnActionAtFinalizationForEachObject > Â Â Â Â thenForcingFinalizationOfObjects > Â Â Â Â implyBothRegisteredActionsAreExecuted | > > Â Â Â Â finalizationProbe := Set new. > Â Â Â Â o1 := 'hello' copy. > Â Â Â Â o2 := 'hello' copy. > Â Â Â Â forAnyTwoEqualObjects := [o1 = o2]. > Â Â Â Â ofDifferentIdentity := [o1 ~~ o2]. > Â Â Â Â registeringAnActionAtFinalizationForEachObject := [ > Â Â Â Â Â Â Â Â o1 toFinalizeSend: #add: to: finalizationProbe Â with: 'first object finalized'. > Â Â Â Â Â Â Â Â o2 toFinalizeSend: #add: to: finalizationProbe Â with: 'second object > finalized']. > Â Â Â Â thenForcingFinalizationOfObjects := [ > Â Â Â Â Â Â Â Â forAnyTwoEqualObjects := ofDifferentIdentity := > registeringAnActionAtFinalizationForEachObject := nil. > Â Â Â Â Â Â Â Â o1 := o2 := nil. Smalltalk garbageCollect]. > Â Â Â Â implyBothRegisteredActionsAreExecuted := [finalizationProbe size = 2]. > > Â Â Â Â self > Â Â Â Â Â Â Â Â assert: forAnyTwoEqualObjects; > Â Â Â Â Â Â Â Â assert: ofDifferentIdentity; > Â Â Â Â Â Â Â Â should: [ > Â Â Â Â Â Â Â Â Â Â Â Â registeringAnActionAtFinalizationForEachObject value. > Â Â Â Â Â Â Â Â Â Â Â Â thenForcingFinalizationOfObjects value. > Â Â Â Â Â Â Â Â Â Â Â Â implyBothRegisteredActionsAreExecuted value]. >

Jan. 16, 2010

Re: [Pharo-project] Date fromString: '6-Jan-10'

by David Harris

I think a solution that can tuned or tweaked to it's application would be must useful. It's all very well to insist on users using four- digit years, but for processing historical data, for example, one doesn't have the luxury of insisting on the data format, but has to use what is there :-( Perhaps a variable that determines the transition from 19xx to 20xx would be appropriate? David PS- here in Canada we interpret 4/5/xxxx the opposite to the USA. I always use yyyy.mm.dd.hh.ss to the appropriate resolution :-) On 2010-01-16, at 10:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes > > Date fromString: '6-Jan-03' > -> 6 January 2003 > > is also wrong. So david just tried to patch this wrong behavior. > > Stef > > > On Jan 16, 2010, at 6:02 PM, csrabak(a)bol.com.br wrote: > >> I'm afraid the 'fix' is trying to repair something is not broken! >> >> Date fromString: '6-Jan-10'. giving "6 January 1910" has not >> anything wrong. Within five year we'll have users/programmers >> complaining that: >> >> Date fromString: '6-Jan-16'. gave "6 January 1916" and *obviously* >> it should have given "6 January 2015"!! >> >> Rather document that years given with two figures get counted from >> 1900 (as it used to be in last century) and have people to use four >> digits for years in the 2000s. >> >> Otherwise: >> >> 1) We need to get used to the concept of an epoch time for Pharo; or >> >> 2) the number to be tested has to be the current year! >> >> My 0.019999. . . >> >> -- >> Cesar Rabak >> >> >> Em 16/01/2010 07:57, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr >> > escreveu: >> >> >> hi guys >> >> can one of you give a look at the this fix because I'm confused. >> Kernel-DavidHotham.538 >> >> year < 20 ifTrue: [year := 2000 + year] >> was >> year < 10 ifTrue: [year := 2000 + year] >> >> both solutions look strange to me. >> >> http://code.google.com/p/pharo/issues/detail?id=1749 >> >> >> readFrom: aStream >> "Read a Date from the stream in any of the forms: >> (5 April 1982; 5-APR-82) >> (April 5, 1982) >> (4/5/82) >> (5APR82)" >> | day month year | >> aStream peek isDigit >> ifTrue: [day := Integer readFrom: aStream]. >> [aStream peek isAlphaNumeric] >> whileFalse: [aStream skip: 1]. >> aStream peek isLetter >> ifTrue: ["number/name... or name..." >> month := (String new: 10) writeStream. >> [aStream peek isLetter] >> whileTrue: [month nextPut: aStream next]. >> month := month contents. >> day isNil >> ifTrue: ["name/number..." >> [aStream peek isAlphaNumeric] >> whileFalse: [aStream skip: 1]. >> day := Integer readFrom: aStream]] >> ifFalse: ["number/number..." >> month := Month nameOfMonth: day. >> day := Integer readFrom: aStream]. >> [aStream peek isAlphaNumeric] >> whileFalse: [aStream skip: 1]. >> year := Integer readFrom: aStream. >>>> year < 20 ifTrue: [year := 2000 + year] >> ifFalse: [ year < 1900 ifTrue: [ year := 1900 + year]]. >> >> ^ self >> year: year >> month: month >> day: day >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 16, 2010

[Pharo-project] Pharo 1.0 & 1.1 failing tests testFinalizationOfEquals

by Nicolas Cellier

I wrote this test pre-closure. The problem with closures is that they are optimized to retain a pointer to the values of outer temporary variable they use when activated. Thus the BlockClosures forAnyTwoEqualObjects ofDifferentIdentity registeringAnActionAtFinalizationForEachObject all refer to 'hello' pointed by o1 and its copy pointed by o2. In other words, o1 and o2 are not the single pointers to the String 'hello' and its copy. thenForcingFinalizationOfObjects only clean o1 and o2, but omit to clean the closures that still point to 'hello'... Thus, 'hello' is not finalized. One possibility is to also clean the closures pointing to 'hello'. But now the code is tricky... It's aim was to be simple damned :) Nicolas here is a corrected version : testFinalizationOfEquals "self debug: #testFinalizationOfEquals" | finalizationProbe o1 o2 forAnyTwoEqualObjects ofDifferentIdentity registeringAnActionAtFinalizationForEachObject thenForcingFinalizationOfObjects implyBothRegisteredActionsAreExecuted | finalizationProbe := Set new. o1 := 'hello' copy. o2 := 'hello' copy. forAnyTwoEqualObjects := [o1 = o2]. ofDifferentIdentity := [o1 ~~ o2]. registeringAnActionAtFinalizationForEachObject := [ o1 toFinalizeSend: #add: to: finalizationProbe with: 'first object finalized'. o2 toFinalizeSend: #add: to: finalizationProbe with: 'second object finalized']. thenForcingFinalizationOfObjects := [ forAnyTwoEqualObjects := ofDifferentIdentity := registeringAnActionAtFinalizationForEachObject := nil. o1 := o2 := nil. Smalltalk garbageCollect]. implyBothRegisteredActionsAreExecuted := [finalizationProbe size = 2]. self assert: forAnyTwoEqualObjects; assert: ofDifferentIdentity; should: [ registeringAnActionAtFinalizationForEachObject value. thenForcingFinalizationOfObjects value. implyBothRegisteredActionsAreExecuted value].

Jan. 16, 2010

[Pharo-project] [update 1.1] #11164

by Marcus Denker

11164 ----- Issue 441: Hardcoded debugger Issue 1828: testAnnotationPane Issue 1819: 1.1: some packages have no repository -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 16, 2010

Re: [Pharo-project] Date fromString: '6-Jan-10'

by John M McIntosh

Well oddly I encounter a simular issue on the iPhone the other week when dealing with Apple's Date Scanner logic. It seems that if a person entered 1/1/09 that would generate jan 1st, 2009. but 1/1/9 would generate jan 1st, year 1 AD I recalling read a novel set in 1715 where they talked about the year 3, meaning 1703 not 3 AD. But I can't recall anyone this millennium using year 9 to refer to 2009 although they might tap that into a entry field. I note you *must* in this case separate the *correct* way of thinking to the *common mostly correct* way of thinking. Most people you met in the USA would think that 1/1/09 means 2009, NOT 1909. Obviously for fields that *could be* a date that could be > 100 years you would have to enforce four digit years, or something, but defaulting to 1909 versus 2009 might have interesting side-effects. Also expiry date 2014 as 1/1/14 this is not assumed to be 1914. On 2010-01-16, at 9:02 AM, csrabak(a)bol.com.br wrote: > I'm afraid the 'fix' is trying to repair something is not broken! > > Date fromString: '6-Jan-10'. giving "6 January 1910" has not anything wrong. Within five year we'll have users/programmers complaining that: > > Date fromString: '6-Jan-16'. gave "6 January 1916" and *obviously* it should have given "6 January 2015"!! > > Rather document that years given with two figures get counted from 1900 (as it used to be in last century) and have people to use four digits for years in the 2000s. > > Otherwise: > > 1) We need to get used to the concept of an epoch time for Pharo; or > > 2) the number to be tested has to be the current year! > > My 0.019999. . . > > -- > Cesar Rabak > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 16, 2010

Re: [Pharo-project] us the vm -memory in an image ?

by John M McIntosh

On 2010-01-16, at 9:11 AM, csrabak(a)bol.com.br wrote: > I agree with the intent but cannot figure out a means for evaluating (testing) the tweaking of the parameters in 'scientific' way!! > > -- > Cesar Rabak > Well some clues are in http://www.smalltalkconsulting.com/papers/GCPaper/GCTalk%202001.htm See the "Squeak Memory Layout" page But really you have to have an understanding of how the GC behaves, and then the various parms (which aren't in the 2001 paper). then some Sunits, and generate charts like slide 92, then decide how to alter behaviour. Having Sunits is a important criteria since it then tells you if changes are impacting time to run in a meaningful way, since altering the values can have a negative effect. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 16, 2010