- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

Thanks Chris about the speed what do you compare? using accessors to access month/date or something else. This is not clear to me. On Apr 23, 2010, at 9:49 PM, Chris Muller wrote: > In case anyone cares, Brent and I have been working together > professionally for the last couple of years. Brent, we have been > running with that method modified since 2007 to not do that > conversion. We have not sufferred any ill-effects from it. Check our > vanilla image: > > DateAndTime>>#= comparand > "comparand conforms to protocol DateAndTime, > or can be converted into something that conforms." > | comparandAsDateAndTime | > self == comparand ifTrue: [ ^ true ]. > (comparand isKindOf: self class) ifFalse: [ ^ false ]. > [ comparandAsDateAndTime := comparand asDateAndTime ] > on: MessageNotUnderstood > do: [ ^ false ]. > ^ self offset = comparandAsDateAndTime offset > ifTrue: [ self hasEqualTicks: comparandAsDateAndTime ] > ifFalse: [ self asUTC ticks = comparandAsDateAndTime asUTC ticks ] > > I agree with Stef on this. Not only is it confusing to me, it is > inconsistent with other type-checks. But the primary reason I > overrode it back in 2007 was for better performance. Try benching the > above against the stock comparison... > > - Chris > > On Fri, Apr 23, 2010 at 2:26 PM, Brent Pinkney <brent(a)zamail.co.za> wrote: >> On Friday 23 April 2010 21:12:03 StÃ©phane Ducasse wrote: >>> Hi all >>> >>> I'm trying to fix some tests and I do not like the behavior of DateAndTime >>> = Comparing aDateAndTime and a something tries to convert the something in >>> a dateAndTime automagically. I find that not really good because it hides >>> potential problem: manipulating string instead of objects. >>> >>> So I would like to have >>> (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' -> >>> false (aDateAndTime offset: '0:12:00:00') asString = >>> '1901-01-01T00:00:00+12:00' -> true. >>> >>> What do you think. >> >> Hi, >> >> I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date... >> Please tread carefully - lots of production code relies on that. >> >> Already my (DateAndTime now != DateAndTime now) have been removed :( >> >> Thanks >> >> Brent >> >> _______________________________________________ >> 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

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

Now I'm more fighting with (Duration readFrom: '0:00:00:00.001 ' readStream) nanoSeconds -> 1 http://code.google.com/p/pharo/issues/detail?id=1202 as well as self assert: (DateAndTime readFrom: '1901-01-01T00:00:00+12:00' readStream) asString -> '1901-01-01T00:00:00+02:00' ;) which works in squeak! Stef On Apr 23, 2010, at 9:37 PM, Henrik Johansen wrote: > > On Apr 23, 2010, at 9:26 31PM, Brent Pinkney wrote: > >> On Friday 23 April 2010 21:12:03 StÃ©phane Ducasse wrote: >>> Hi all >>> >>> I'm trying to fix some tests and I do not like the behavior of DateAndTime >>> = Comparing aDateAndTime and a something tries to convert the something in >>> a dateAndTime automagically. I find that not really good because it hides >>> potential problem: manipulating string instead of objects. >>> >>> So I would like to have >>> (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' -> >>> false (aDateAndTime offset: '0:12:00:00') asString = >>> '1901-01-01T00:00:00+12:00' -> true. >>> >>> What do you think. >> >> Hi, >> >> I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date... >> Please tread carefully - lots of production code relies on that. >> >> Already my (DateAndTime now != DateAndTime now) have been removed :( >> >> Thanks >> >> Brent > Because even if the resolution of a DateAndTime is nanoseconds, the clock available to derive now from has a resolution of milliseconds (microseconds using an updated VM on some platforms). (Not to mention the now method actually uses a second resolution...) > > Thus a test which states that asking for now two times in a row should always result in different DateAndTime values does not make sense. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

Thanks for the explanation. Stef On Apr 23, 2010, at 9:37 PM, Henrik Johansen wrote: > > On Apr 23, 2010, at 9:26 31PM, Brent Pinkney wrote: > >> On Friday 23 April 2010 21:12:03 StÃ©phane Ducasse wrote: >>> Hi all >>> >>> I'm trying to fix some tests and I do not like the behavior of DateAndTime >>> = Comparing aDateAndTime and a something tries to convert the something in >>> a dateAndTime automagically. I find that not really good because it hides >>> potential problem: manipulating string instead of objects. >>> >>> So I would like to have >>> (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' -> >>> false (aDateAndTime offset: '0:12:00:00') asString = >>> '1901-01-01T00:00:00+12:00' -> true. >>> >>> What do you think. >> >> Hi, >> >> I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date... >> Please tread carefully - lots of production code relies on that. >> >> Already my (DateAndTime now != DateAndTime now) have been removed :( >> >> Thanks >> >> Brent > Because even if the resolution of a DateAndTime is nanoseconds, the clock available to derive now from has a resolution of milliseconds (microseconds using an updated VM on some platforms). (Not to mention the now method actually uses a second resolution...) > > Thus a test which states that asking for now two times in a row should always result in different DateAndTime values does not make sense. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Nicolas Cellier

2010/4/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi all > > I'm trying to fix some tests and I do not like the behavior of DateAndTime = > Comparing aDateAndTime and a something tries to convert the something in a dateAndTime automagically. > I find that not really good because it hides potential problem: manipulating string instead of objects. > > So I would like to have > Â Â Â Â (aDateAndTime offset: '0:12:00:00') = Â '1901-01-01T00:00:00+12:00' -> false > Â Â Â Â (aDateAndTime offset: '0:12:00:00') asString = Â '1901-01-01T00:00:00+12:00' -> true. > > What do you think. > I would expect this for = 1) Reflexive self assert: x = x. 2) Symmetric self assert: (x = y) = (y = x). 3) Transitive self assert: (x = y) & (y = z) ==> (x = z). I guess equality with a String at least breaks 2). Nicolas > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Brent Pinkney

> Do you have examples? For month I have problems, > Then I wonder why > > aDateAndTime = aMonth > is better > than > aDateAndTime month = aMonth Hi, Chris Muller has just told me that I am dead wron on the equality issue, so I stand corrected. He will post soon. On the above, this is a bit of archeology - the Month and Week classes were introduced into Squeak before I added the ANSI Chronology classes and the whole Timespan hierarchy. I could only get the chronology into the image by preserving compatibility. It could probably be refactored now. Brent

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Chris Muller

In case anyone cares, Brent and I have been working together professionally for the last couple of years. Brent, we have been running with that method modified since 2007 to not do that conversion. We have not sufferred any ill-effects from it. Check our vanilla image: DateAndTime>>#= comparand "comparand conforms to protocol DateAndTime, or can be converted into something that conforms." | comparandAsDateAndTime | self == comparand ifTrue: [ ^ true ]. (comparand isKindOf: self class) ifFalse: [ ^ false ]. [ comparandAsDateAndTime := comparand asDateAndTime ] on: MessageNotUnderstood do: [ ^ false ]. ^ self offset = comparandAsDateAndTime offset ifTrue: [ self hasEqualTicks: comparandAsDateAndTime ] ifFalse: [ self asUTC ticks = comparandAsDateAndTime asUTC ticks ] I agree with Stef on this. Not only is it confusing to me, it is inconsistent with other type-checks. But the primary reason I overrode it back in 2007 was for better performance. Try benching the above against the stock comparison... - Chris On Fri, Apr 23, 2010 at 2:26 PM, Brent Pinkney <brent(a)zamail.co.za> wrote: > On Friday 23 April 2010 21:12:03 StÃ©phane Ducasse wrote: >> Hi all >> >> I'm trying to fix some tests and I do not like the behavior of DateAndTime >> = Comparing aDateAndTime and a something tries to convert the something in >> a dateAndTime automagically. I find that not really good because it hides >> potential problem: manipulating string instead of objects. >> >> So I would like to have >> Â Â Â (aDateAndTime offset: '0:12:00:00') = Â '1901-01-01T00:00:00+12:00' -> >> false (aDateAndTime offset: '0:12:00:00') asString = >> '1901-01-01T00:00:00+12:00' -> true. >> >> What do you think. > > Hi, > > I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date... > Please tread carefully - lots of production code relies on that. > > Already my (DateAndTime now != DateAndTime now) Â have been removed :( > > Thanks > > Brent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

Hi brent >> > Hi, > > I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date... Do you have examples? For month I have problems, Then I wonder why aDateAndTime = aMonth is better than aDateAndTime month = aMonth > Please tread carefully - lots of production code relies on that. did you mean that production code rely on string automatic conversion when compared to? > > Already my (DateAndTime now != DateAndTime now) have been removed :( Apparently it was not in 3.9 so I do not know when it was removed but this was not in pharo. Then finally if you do not raise the issue we are not omniscient so we cannot know it. stef > > Thanks > > Brent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Henrik Johansen

On Apr 23, 2010, at 9:26 31PM, Brent Pinkney wrote: > On Friday 23 April 2010 21:12:03 StÃ©phane Ducasse wrote: >> Hi all >> >> I'm trying to fix some tests and I do not like the behavior of DateAndTime >> = Comparing aDateAndTime and a something tries to convert the something in >> a dateAndTime automagically. I find that not really good because it hides >> potential problem: manipulating string instead of objects. >> >> So I would like to have >> (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' -> >> false (aDateAndTime offset: '0:12:00:00') asString = >> '1901-01-01T00:00:00+12:00' -> true. >> >> What do you think. > > Hi, > > I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date... > Please tread carefully - lots of production code relies on that. > > Already my (DateAndTime now != DateAndTime now) have been removed :( > > Thanks > > Brent Because even if the resolution of a DateAndTime is nanoseconds, the clock available to derive now from has a resolution of milliseconds (microseconds using an updated VM on some platforms). (Not to mention the now method actually uses a second resolution...) Thus a test which states that asking for now two times in a row should always result in different DateAndTime values does not make sense. Cheers, Henry

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by StÃ©phane Ducasse

On Apr 23, 2010, at 9:26 PM, Brent Pinkney wrote: > On Friday 23 April 2010 21:12:03 StÃ©phane Ducasse wrote: >> Hi all >> >> I'm trying to fix some tests and I do not like the behavior of DateAndTime >> = Comparing aDateAndTime and a something tries to convert the something in >> a dateAndTime automagically. I find that not really good because it hides >> potential problem: manipulating string instead of objects. >> >> So I would like to have >> (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' -> >> false (aDateAndTime offset: '0:12:00:00') asString = >> '1901-01-01T00:00:00+12:00' -> true. >> >> What do you think. > > Hi, > > I wrote that code, and it is needed to compare DateAndTimes with Timespans - eg Month, Year, Date... > Please tread carefully - lots of production code relies on that. Thanks for the info. Now I think that strings are dead objects and we should not use them in place of real ones. > Already my (DateAndTime now != DateAndTime now) have been removed :( was it in 3.9? Stef > > Thanks > > Brent > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] Serialization of font object

by StÃ©phane Ducasse

I was thinking more as a simple mechanism to serialize the info you gave than to serialize the objects since after you may not have the fonts in your system but should guess a substitution. Stef On Apr 23, 2010, at 9:22 PM, Henrik Johansen wrote: > > On Apr 23, 2010, at 7:37 33PM, StÃ©phane Ducasse wrote: > >> may be using the storeOn: aStream and readFrom: mechanism? >> > I doubt it would work for FreeType fonts, which hold external handles. > For StrikeFonts, it may, but even if it did, you'd probably end up importing a new Font instance (complete with an XX KB bitmap), for each Morph... > > Cheers, > Henry > >> >> On Apr 23, 2010, at 4:28 PM, Henrik Johansen wrote: >> >>> On Apr 23, 2010, at 4:01 48PM, nullPointer wrote: >>> >>>> >>>> >>>> Regards >>>> >>>> I see in Pharo a few ways for create a font, StrikeFont, LogicalFont... I >>>> need generate dinamically code in Smalltalk for build UIs, and my problem >>>> now is when I have serialize the font of a widget. Which could be the best >>>> way for do that? In other objects like arrays, points, associations is >>>> possible get that calling #printString method. Exists some equivalence for >>>> that in fonts, or is needed implement that mechanism of zero? >>>> >>>> Thanks for answers >>> >>> I would store the the name/boldness/size etc., then use (LogicalFont familyName: pointSize: stretchValue:weightValue: slantValue: ) realFont >>> to discover the closest font available when loading the morph into an image again. >>> >>> Cheers, >>> Henry >>> _______________________________________________ >>> 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

April 23, 2010