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

Re: [Pharo-project] about DateAndTime =

by Chris Muller

Hi Stef, I will help on the Squeak side. I suppose I could work on that symmetry with Timestamp, but I'd rather talk about removing Timestamp instead first.. It doesn't really seem like we need two time-stamp classes, do we? On Fri, Apr 23, 2010 at 3:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I'm turning this into tests! > Brent if you want to help fixing let me know. > I will focus now on the parsing problem. > > Stef > > On Apr 23, 2010, at 9:51 PM, Nicolas Cellier wrote: > >> 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 >>> >> >> _______________________________________________ >> 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 Brent Pinkney

> What is Timestamp? A legacy class that has a Date and a TIme object. Predates ANSI DateAndTime. Should be purged IMHO. Brent

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Chris Muller

What is Timestamp? On Fri, Apr 23, 2010 at 3:25 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > It's still wrong though, in that it is not symmetric... > > Due to the isKindOf: self class test, and > = Â not being reimplemented in Timestamp (DateAndTime subclass), so Timestamp to DateAndTime comparitions will fail: > > aDateandTime = anEquivalentTimestamp true > anEquivalentTimestamp = aDateAndTime false > > There's a test for you! :D > > Cheers, > Henry > > On Apr 23, 2010, at 10:01 30PM, StÃ©phane Ducasse wrote: > >> 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 >> >> >> _______________________________________________ >> 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] curlplugin 2.0.0

by John M McIntosh

Ok, we seem to have a disconnect between the Plugin Source Code and the SUnits When I look in http://www.squeaksource.com/CurlPlugin I don't see any code to generate the primitives like: primEasyAutoReferer I'm sure it exists since it appears to be a patch file in the unix tree, however the author should update http://www.squeaksource.com/CurlPlugin so I can build a new plugin On 2010-04-21, at 1:59 PM, Jan van de Sandt wrote: > Hello John. > > I have tried to use the new CurlPlugin in the 4.2.4b1 Squeak VM and the VM that is shipped with Pharo 1.0. On both the environments I get a number of test errors and failures when I run CurlTests of CurlPlugn-dao.23: > > failures: > - testApiHttpOptions > - testApiOptions > - testApiSwitches > > errors: > - testApiInfoStrings > - testApiTimings > - testApiTransfersParameters > - testMassiceCurlHandleCreation > > All the problems are "primitive failed" problems. > > Jan. > > If I run the same tests on Ubuntu I get a single test failure: testApiTransfersParameters > > > > On Wed, Apr 21, 2010 at 10:57 AM, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > Hello John, > > Great news! Thank you very much for the work. I will try it out this evening and look at the unit test that fails. > > Jan. > > On 4/20/10, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > Hello John, > > > > Is it possible to update the CurlPlugin that is shipped with the Squeak Mac VM? It is great that the plugin is part of the standard VM. But the version that is shipped is quite old. Danil Osipchuk created a new version that contains valuable new functionality. For example the possibility to add custom headers to http requests. I would really like to use this feauture for Cloudfork. > > > > I think CurlPlugin-dao.23.mcz is the latest stable version of the plugin. (http://www.squeaksource.com/CurlPlugin.html) > > > > Regards, > > Jan. > > I've done this, via help from Saris Hein <hein(a)beta9.be> > It going to take a few days yet to leak into a VM push. > There is one test failure, you might want to track it down. > plugin 2.0.0 attached. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > > > -- > Jan van de Sandt > gsm: +31 (0)6 3039 5998 > > > > -- > Jan van de Sandt > gsm: +31 (0)6 3039 5998 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 23, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Adrian Lienhard

Hi Esteban, I like to come back to your cool Project Loader... I have some suggestions and questions: - I propose to add a message named #help and output the info for each operations like you do on the website [1] - The result of evaluating list or search: is not very nice because it contains OrderedCollection (...) etc. I suggest to return a formatted string that looks nicer. - Wouldn't it be convenient to have a method Gofer>>loadPackagerLoader (or similar) in Gofer that would do [2]? We could ask Lukas to add it to Gofer. Now the important one point: When we create repositories MetacelloRepositoryPharo1.0 and MetacelloRepositoryPharo1.1 etc. it would be nice if the project loader was automatically initialized with the appropriate repository in each image depending on its version. This could be done by checking for "SystemVersion current" in the method GoferProjectLoader class>>createRepositories. What do you think? In addition I would add the command "unstable" (or similar) for adding the unstable/testing repository "MetacelloRepository". Cheers, Adrian [1] http://www.smallworks.com.ar/en/community/GoferProjectLoader [2] Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGoferProjectLoader'; load. ConfigurationOfGoferProjectLoader project lastVersion load. On Mar 18, 2010, at 08:30 , Adrian Lienhard wrote: > Here is yet another way how we could model universes. We just have multiple Metacello repositories: > > - MetacelloRepository is the one that everybody can commit to (testing universe) > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 > - etc. > > A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed. > > This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality. > > Cheers, > Adrian > > > On Mar 17, 2010, at 23:41 , Miguel Enrique CobÃ¡ Martinez wrote: > >> El miÃ©, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribiÃ³: >>> ----- "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >>> >>> | > - any idea about how we go to differentiate "stable" and "unstable" >>> | >>> | > universes for each Pharo version? How does the user know which version >>> | > is the one he needs for his version of Pharo? Sorry, this is not >>> | > directly related to the Gofer Project Loader but I think it is the next >>> | > important step towards a working package management system! >>> | >>> | No clue... maybe we need to add to Metacello a new "dependence >>> | dimension", like "minimum version of distribution"... but Dale can be >>> | much more helpful than me in this area. >>> >>> I imagine that code targetted for specific Pharo versions will be treated like we treat code targeted for different Smalltalk dialects. So you would write specs like the following: >>> >>> spec for: #common do: [...]. >>> spec for: #squeakCommon do: [...]. >>> spec for: #pharo do: [...]. >>> spec for: #'pharo1.0' do: [...]. >>> spec for: #'pharo1.1' do: [...]. >>> >>> or possibly like the following, if a finer version granularity is needed: >>> >>> spec for: #common do: [...]. >>> spec for: #squeakCommon do: [...]. >>> spec for: #pharo do: [...]. >>> spec for: #'pharo1.0' do: [...]. >>> spec for: #'pharo1.0-10508' do: [...]. >>> spec for: #'pharo1.0-10515' do: [...]. >>> spec for: #'pharo1.1' do: [...]. >>> spec for: #'pharo1.1-11508' do: [...]. >>> spec for: #'pharo1.1-11515' do: [...]. >>> >>> Dale >>> >> >> umm, no please! >> >> There would be a lot of combinations after a while. >> >> Why about having a new spec universes message that accept a list of >> symbols, each symbol representing a given "universe" of tested packages. >> This list will be the only thing to modify when grouping different >> versions of the same package in different repositories. >> >> For example, I start with ConfigurationOfMagma version 1.0r43. Two weeks >> later I release ConfigurationOfMagma with support for loading 1.0r44. >> Both this versions have been tested on Pharo 1.0. So the both are >> marked >> >> spec universes: #(#pharo10). >> >> A week later Pharo 1.1 is released, and I test the configuration on this >> new version of pharo. Both work ok. So I modify the line to: >> >> spec universes: #(#pharo10 #pharo11) >> >> and commit. >> >> The tools (GoferProjectLoader) then add functionality to scan this list >> and presents the users only the appropriated ones based on the image the >> users is querying the repository. >> >> Of course this is very simplistic because as the debian model shows, >> requires a maintainer of each configuration and the user to report if a >> given #pharo11 marked version actually doesn't work. If something don't >> work, or a new version is given that works, or the tag #pharo11 is >> removed from that version effectively removing it from that given >> universe until bugs are fixed or worked around. >> >> What do you think? >> >> Cheers >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> 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 Henrik Johansen

It's still wrong though, in that it is not symmetric... Due to the isKindOf: self class test, and = not being reimplemented in Timestamp (DateAndTime subclass), so Timestamp to DateAndTime comparitions will fail: aDateandTime = anEquivalentTimestamp true anEquivalentTimestamp = aDateAndTime false There's a test for you! :D Cheers, Henry On Apr 23, 2010, at 10:01 30PM, StÃ©phane Ducasse wrote: > 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 > > > _______________________________________________ > 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

On Apr 23, 2010, at 10:11 PM, Chris Muller wrote: > I just noticed I used 'hello' instead of Obejct new, so I'll clarify.. > this is not about comparing Dates to Strings. It is faster in > comparing against _any_ othe robject than a DateAndTime. This is > important not only for system and compiler stuff working, but also for > applications which make use of heterogeneous collections of objects... yes I got it. I integrated your version. But I would like the properties mentioned by nicolas for comparison. Else we break something important for the sake of a certain lazilyness. Stef > > On Fri, Apr 23, 2010 at 3:08 PM, Chris Muller <asqueaker(a)gmail.com> wrote: >> By having added the type-check into the method: >> >> (comparand isKindOf: self class) ifFalse: [ ^ false ]. >> >> the speed of testing a DateAndTime against other objects is improved >> because it avoids that whole business of attempting to convert the >> object and trapping Error to return false... >> >> Did you try it? >> >> |dt| dt:=DateAndTime now. >> [ dt = 'hello' ] bench >> >> '492680.6638672266 per second.' (mine) vs. '34438.5122975405 per >> second.' (with attempted conversion) >> >> On Fri, Apr 23, 2010 at 3:01 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> 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 >>> >>> >>> _______________________________________________ >>> 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

On Apr 23, 2010, at 10:08 PM, Chris Muller wrote: > |dt| dt:=DateAndTime now. > [ dt = 'hello' ] bench I get |dt| dt:=DateAndTime now. [ dt = 'hello' ] bench '49063.3873225355 per second.' :) Ok I see. Now my point was more in the idea to compare strings with other objects. I could understand with lot of imagination that you want to compare a dt and a month. But not a string. Stef

April 23, 2010

Re: [Pharo-project] about DateAndTime =

by Chris Muller

I just noticed I used 'hello' instead of Obejct new, so I'll clarify.. this is not about comparing Dates to Strings. It is faster in comparing against _any_ othe robject than a DateAndTime. This is important not only for system and compiler stuff working, but also for applications which make use of heterogeneous collections of objects... On Fri, Apr 23, 2010 at 3:08 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > By having added the type-check into the method: > > Â Â Â (comparand isKindOf: self class) ifFalse: [ ^ false ]. > > the speed of testing a DateAndTime against other objects is improved > because it avoids that whole business of attempting to convert the > object and trapping Error to return false... > > Did you try it? > > |dt| dt:=DateAndTime now. > [ dt = 'hello' ] bench > > Â '492680.6638672266 per second.' Â (mine) vs. Â '34438.5122975405 per > second.' (with attempted conversion) > > On Fri, Apr 23, 2010 at 3:01 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> 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 >> >> >> _______________________________________________ >> 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 Chris Muller

By having added the type-check into the method: (comparand isKindOf: self class) ifFalse: [ ^ false ]. the speed of testing a DateAndTime against other objects is improved because it avoids that whole business of attempting to convert the object and trapping Error to return false... Did you try it? |dt| dt:=DateAndTime now. [ dt = 'hello' ] bench '492680.6638672266 per second.' (mine) vs. '34438.5122975405 per second.' (with attempted conversion) On Fri, Apr 23, 2010 at 3:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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 > > > _______________________________________________ > 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