September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Odd TimeStamp from string issue

by Chris Cunningham

On Tue, Sep 27, 2011 at 2:04 PM, Pat Maddox <patmaddox(a)me.com> wrote: > Might be sloppy writing because that last sentence seems to contradict the first one. At any rate, I wouldn't expect that to be valid. What is 24:00:01 ? TimeStamp fromString: '2011-09-27 24:00:01' -> '27 September 2011 12:00:01 am' As for contradictions (if it was from my message), this behavior is not expected by me, but it may be expected by the rest of the community (which is what I was asking about). It sounds like it isn't, though. I think the method is too permissive - it probably should have rejected my input as bad. The code path delegates the time portion off to Time, which delegates it off to Duration (with no bounds checks), then asks for the seconds and nanos back from Duration via #ticks, which hides the fact that a date boundary has been exceeded: days := self days. ^ Array with: days with: seconds - (days * SecondsInDay) with: nanos (the seconds - (days * SecondsInDay) part). -Chris

Sept. 27, 2011

Re: [Pharo-project] Odd TimeStamp from string issue

by Nicolas Cellier

2011/9/27 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2011/9/27 Pat Maddox <patmaddox(a)me.com>: >> I don't think that's a valid timestamp. From http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight >> >> The 24-hour clock notation avoids all of those ambiguities by using 00:00 for midnight at the start of the day and 12:00 for noon. From 23:59:59 the time shifts (one second later) to 00:00:00, the beginning of the next day. In 24-hour notation 24:00 can be used to refer to midnight at the end of a day. >> >> Might be sloppy writing because that last sentence seems to contradict the first one. At any rate, I wouldn't expect that to be valid. What is 24:00:01 ? >> >> Pat >> > > Hmm some days have leap seconds in UTC adjustments > http://en.wikipedia.org/wiki/Leap_second , so beware... > > Nicolas > However, it is 23:59:60 UTC rather than 24:00:01 Nicolas >> >> On Sep 27, 2011, at 1:47 PM, Chris Cunningham wrote: >> >>> Hi. Â This behavior tricked me and I'm curious if this is inteded or >>> not. Â If you take a timestamp from a string, and the hour is 24:00:00, >>> then it will assume that the time is at the beginning of the day, that >>> is, 23+ hours before the timestamp that starts at 23:59:59. >>> >>> TimeStamp fromString: '2011-09-27 24:00:00' Â -> Â '27 September 2011 12:00 am' >>> >>> I would have Â hoped that would either be the end of the day, or the >>> begining of the next one. >>> >>> So, is this expected behaviour? >>> >>> Thanks, >>> Chris >>> >> >> >> >

Sept. 27, 2011

Re: [Pharo-project] Odd TimeStamp from string issue

by Nicolas Cellier

2011/9/27 Pat Maddox <patmaddox(a)me.com>: > I don't think that's a valid timestamp. From http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight > > The 24-hour clock notation avoids all of those ambiguities by using 00:00 for midnight at the start of the day and 12:00 for noon. From 23:59:59 the time shifts (one second later) to 00:00:00, the beginning of the next day. In 24-hour notation 24:00 can be used to refer to midnight at the end of a day. > > Might be sloppy writing because that last sentence seems to contradict the first one. At any rate, I wouldn't expect that to be valid. What is 24:00:01 ? > > Pat > Hmm some days have leap seconds in UTC adjustments http://en.wikipedia.org/wiki/Leap_second , so beware... Nicolas > > On Sep 27, 2011, at 1:47 PM, Chris Cunningham wrote: > >> Hi. Â This behavior tricked me and I'm curious if this is inteded or >> not. Â If you take a timestamp from a string, and the hour is 24:00:00, >> then it will assume that the time is at the beginning of the day, that >> is, 23+ hours before the timestamp that starts at 23:59:59. >> >> TimeStamp fromString: '2011-09-27 24:00:00' Â -> Â '27 September 2011 12:00 am' >> >> I would have Â hoped that would either be the end of the day, or the >> begining of the next one. >> >> So, is this expected behaviour? >> >> Thanks, >> Chris >> > > >

Sept. 27, 2011

Re: [Pharo-project] Odd TimeStamp from string issue

by Pat Maddox

I don't think that's a valid timestamp. From http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight The 24-hour clock notation avoids all of those ambiguities by using 00:00 for midnight at the start of the day and 12:00 for noon. From 23:59:59 the time shifts (one second later) to 00:00:00, the beginning of the next day. In 24-hour notation 24:00 can be used to refer to midnight at the end of a day. Might be sloppy writing because that last sentence seems to contradict the first one. At any rate, I wouldn't expect that to be valid. What is 24:00:01 ? Pat On Sep 27, 2011, at 1:47 PM, Chris Cunningham wrote: > Hi. This behavior tricked me and I'm curious if this is inteded or > not. If you take a timestamp from a string, and the hour is 24:00:00, > then it will assume that the time is at the beginning of the day, that > is, 23+ hours before the timestamp that starts at 23:59:59. > > TimeStamp fromString: '2011-09-27 24:00:00' -> '27 September 2011 12:00 am' > > I would have hoped that would either be the end of the day, or the > begining of the next one. > > So, is this expected behaviour? > > Thanks, > Chris >

Sept. 27, 2011

Re: [Pharo-project] Odd TimeStamp from string issue

by StÃ©phane Ducasse

Looks strange to me. Stef On Sep 27, 2011, at 10:47 PM, Chris Cunningham wrote: > Hi. This behavior tricked me and I'm curious if this is inteded or > not. If you take a timestamp from a string, and the hour is 24:00:00, > then it will assume that the time is at the beginning of the day, that > is, 23+ hours before the timestamp that starts at 23:59:59. > > TimeStamp fromString: '2011-09-27 24:00:00' -> '27 September 2011 12:00 am' > > I would have hoped that would either be the end of the day, or the > begining of the next one. > > So, is this expected behaviour? > > Thanks, > Chris >

Sept. 27, 2011

[Pharo-project] Odd TimeStamp from string issue

by Chris Cunningham

Hi. This behavior tricked me and I'm curious if this is inteded or not. If you take a timestamp from a string, and the hour is 24:00:00, then it will assume that the time is at the beginning of the day, that is, 23+ hours before the timestamp that starts at 23:59:59. TimeStamp fromString: '2011-09-27 24:00:00' -> '27 September 2011 12:00 am' I would have hoped that would either be the end of the day, or the begining of the next one. So, is this expected behaviour? Thanks, Chris

Sept. 27, 2011

Re: [Pharo-project] [Vm-dev] I don't understand the GC root table

by Mariano Martinez Peck

Thanks guys. Indeed, I was totally confused. Maybe 'rootTable' is a little bit confusing... What do you think about changing at least the selector from image side (Smalltalk rootTable)? or it would be even more confusing? Thanks! On Mon, Sep 26, 2011 at 2:06 PM, Stefan Marr <squeak(a)stefan-marr.de> wrote: > > Hi: > > On 26 Sep 2011, at 13:22, Andreas Raab wrote: > > > The rootTable is used during incremental GC. Its contents are those > objects in old space that are roots for objects in new space (see > ObjectMemory>>beRootIfOld:). It has nothing to do with the (global) roots of > the interpreter; in fact the root table is cleared right at the beginning of > fullGC (see senders of #clearRootsTable). The global roots are explicitly > enumerated in Interpreter>>markAndTraceInterpreterOops. > > Not sure whether it is worthwhile to change such details, but I belief the > standard terminology would be 'remembered set'. At least that is the typical > name for recorded references between different object sets maintained > separately, AFAIK. > > And it could avoid confusion. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Mariano http://marianopeck.wordpress.com

Sept. 27, 2011

[Pharo-project] System update with .sources file

by Norbert Hartl

I downloaded the 14163 image and did a system update. First I started it without copying the .sources file. While upgrading to 14164 I got a warning which you can see in the attached screenshot. Proceed is working. Then I tested it again with .sources file in place and I didn't got the warning. Is there an easy explanation for this? Norbert

Sept. 27, 2011

[Pharo-project] [update 1.4] #14169-#14171

by Marcus Denker

14171 ----- Issue 3236: Cuis DateAndTime Enhancement (Part3) http://code.google.com/p/pharo/issues/detail?id=3236 Issue 4845: TestRunner: Show the currently running TestCase with selector and class http://code.google.com/p/pharo/issues/detail?id=4845 -- Marcus Denker -- http://marcusdenker.de

Sept. 27, 2011

Re: [Pharo-project] New problem with rehash [WAS] Re: MethodDictionary fast #rehash

by Mariano Martinez Peck

On Tue, Sep 27, 2011 at 5:28 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Sep 27, 2011 at 5:18 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Tue, 27 Sep 2011, Mariano Martinez Peck wrote: >> >> Hi. With this latest new #rehash there is a problem. I took Levente >>> changes >>> from Squeak. >>> @Levente: the same happens in squeak so this may interest you. >>> >>> The #rehash is right now >>> >>> rehash >>> >>> | newInstance | >>> newInstance := self species new: self basicSize - 1. "Make sure it has >>> the same capacity" >>> 1 to: self basicSize do: [ :index | >>> (self basicAt: index) ifNotNil: [ :key | >>> newInstance at: key put: (array at: index) ] ]. >>> self copyFrom: newInstance >>> >>> The problem is that #new: does: >>> >>> new: numberOfElements >>> "Create an instance large enough to hold numberOfElements without >>> growing. Note that the basic size must be a power of 2. It is VITAL (see >>> grow) that size gets doubled if numberOfElements is a power of 2" >>> >>> | size | >>> size := self sizeFor: numberOfElements. >>> ^(self basicNew: size) initialize: size >>> >>> And #sizeFor: does: >>> >>> sizeFor: numberOfElements >>> "Return the minimum capacity of a dictionary that can hold >>> numberOfElements elements. At least 25% of the array must be empty and >>> the >>> return value must be a power of 2." >>> >>> ^1 bitShift: (numberOfElements * 4 // 3) highBit >>> >>> So....the problem is that you always increase the size of the MD. So when >>> you do: >>> newInstance := self species new: self basicSize - 1. "Make sure it has >>> the >>> same capacity" >>> if fact you are creating a MD of a different size, which means that the >>> capacity is different and hence, using #copyFrom: will create >>> inconsisten >>> MD loosing methods, which causes the crash now. >>> >>> You could add a >>> >>> newInstance capacity = self capacity >>> ifTrue: [ self copyFrom: newInstance ] >>> ifFalse: [ self becomeForward: newInstance ] >>> >>> but that doesn't make sense because you always increase, so you will end >>> up >>> using always the become. >>> >>> I guess you can change to this: >>> >>> newInstance := self species new: self size. "Make sure it has the same >>> capacity" >>> >>> but the problem is if in the future we change again #sizeFor. >>> >>> So....I think a correct solution could be something like this: >>> >>> newInstance := (self species basicNew: self basicSize) initialize: self >>> basicSize. "Make sure it has the same capacity" >>> >>> or..move that to MethodDict class side and do: >>> >>> newInstance := (self species newWithExactBasicSize: self basicSize) >>> "Make sure it has the same capacity" >>> >>> >>> newWithExactBasicSize: basicSize >>> >>> ^(self basicNew: basicSize) initialize: basicSize >>> >>> >>> what do you think ? >>> >> >> Nice find. I think your last suggestion is the way to go, though I'd call >> the method #newWithCapacity: instead of #newWithExactBasicSize:. >> >> > Thanks, I also think the better solution is the last one. Ok, I will take > the suggestion of #newWithCapacity: > Now...what I am not sure is whether we could have this problem in another > place apart from #rehash:. > For example, what about #removeAll: ? > > Wel...#removeAll: is not necessary because even if you would do a copyFrom: from a bigger object to an smaller one it is not a problem because they are all empty and the result of the object will be the smaller of the two... Anyway, I think it is clearer if I use newWithCapacity: here as well. Ahhh and it was funny why the tests didn't show up this bug: testRehashPreservesCapacity | oldDictionary rehashedDictionary | oldDictionary := self modifiedMethodDictionaryCopy. rehashedDictionary := oldDictionary copy; rehash; yourself. self assertPreservesCapacity: oldDictionary comparedTo: rehashedDictionary. and testRehashPreservesElements | oldDictionary rehashedDictionary | oldDictionary := self modifiedMethodDictionaryCopy. rehashedDictionary := oldDictionary copy; rehash; yourself. self assertPreservesElements: oldDictionary comparedTo: rehashedDictionary. self assertPreservesElements: rehashedDictionary comparedTo: oldDictionary. They were testing against the SAME instance hehhehehe. I have just fix them as well. Cheers > If you can help me with that... > > Cheers! > > > >> >> Levente >> >> >> >>> >>> Cheers >>> >>> >>> >>> On Sun, Sep 18, 2011 at 8:13 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>> >>>> >>>> On Sun, Sep 18, 2011 at 5:40 PM, Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)**gmail.com<nicolas.cellier.aka.nice(a)gmail.com>> >>>> wrote: >>>> >>>> I'm not quite sure it is correct. >>>>> The problem is if another Process want to use this MethodDictionary >>>>> while it is in an inconsistent state... >>>>> Or if you are rehashing on of the MethodDictionary which contains one >>>>> of the methods used by the rehashing itself. >>>>> >>>>> >>>> Interesting. Thanks Nicolas for the pointer. >>>> >>>> >>>> See recent changes from Levente in trunk. >>>>> >>>>> >>>>> heheheheh it seems Levente is still reading the Pharo mailing list. >>>> So...I took his commits of today, and I have made a Pharo change set. >>>> I have put all the information here: >>>> http://code.google.com/p/**pharo/issues/detail?id=4826<http://code.google.com/p/pharo/issues/detail?id=4826> >>>> >>>> Basically, he used #copyFrom: which is primitive and hence it avoids the >>>> inconsistent state. >>>> >>>> If someone can check the changeset and give the OK, we can integrate it. >>>> >>>> Thanks a lot >>>> >>>> >>>> Nicolas >>>>> >>>>> 2011/9/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Sep 17, 2011 at 10:26 PM, Nicolas Cellier >>>>>> <nicolas.cellier.aka.nice(a)**gmail.com<nicolas.cellier.aka.nice(a)gmail.com>> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> 2011/9/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>>>> >>>>>>>> Hi guys. I was checking MethodDictionary >> rehash and this is >>>>>>>> >>>>>>> terribly >>>>> >>>>>> slow >>>>>>>> because of the #become. Then I saw #rehashWithoutBecome but it >>>>>>>> >>>>>>> answers >>>>> >>>>>> a >>>>>>>> different instance. I need a #rehash that does the rehash in the >>>>>>>> real >>>>>>>> object >>>>>>>> and answers self. So...I need the regular #rehash but I want to >>>>>>>> avoid >>>>>>>> the >>>>>>>> #become. Is that possible somehow? >>>>>>>> >>>>>>>> This is the current implementation: >>>>>>>> >>>>>>>> rehashWithoutBecome >>>>>>>> >>>>>>>> | newInstance | >>>>>>>> newInstance := self species new: self basicSize - 1. "Make sure >>>>>>>> >>>>>>> it >>>>> >>>>>> has >>>>>>>> the same capacity" >>>>>>>> 1 to: self basicSize do: [ :index | >>>>>>>> (self basicAt: index) ifNotNil: [ :key | >>>>>>>> newInstance at: key put: (array at: index) ] ]. >>>>>>>> ^newInstance >>>>>>>> >>>>>>>> I am terrible bad with Collection and friends, but cannot we do >>>>>>>> soemthing >>>>>>>> like this: >>>>>>>> >>>>>>>> rehashWithoutBecome >>>>>>>> >>>>>>>> | newInstance | >>>>>>>> newInstance := self species new: self basicSize - 1. "Make sure >>>>>>>> >>>>>>> it >>>>> >>>>>> has >>>>>>>> the same capacity" >>>>>>>> >>>>>>>> 1 to: self basicSize do: [ :index | >>>>>>>> (self basicAt: index) ifNotNil: [ :key | >>>>>>>> newInstance at: key put: (array at: index) ] ]. >>>>>>>> >>>>>>>> 1 to: newInstance basicSize do: [ :index | >>>>>>>> (newInstance basicAt: index) ifNotNil: [ :key | >>>>>>>> self at: key put: (newInstance array at: index) ] ]. >>>>>>>> >>>>>>>> ^ self >>>>>>>> >>>>>>>> >>>>>>> I guess you should at least also copy the nil entries... >>>>>>> Maybe something like >>>>>>> >>>>>>> 1 to: newInstance basicSize do: [ :index | >>>>>>> self basicAt: index put: (newInstance basicAt: index). >>>>>>> array at: index put: (newInstance array at: index)]. >>>>>>> >>>>>>> >>>>>> >>>>>> Good point. So....I was not that mistaken ;) >>>>>> I have just replaced CompiledMethod >> hash with this new method and >>>>>> at >>>>>> least all the tests in MethodDictionaryTest are green. >>>>>> Do you think this implementation is correct or there can be problems? >>>>>> because it is really MUCH faster than the original one. >>>>>> >>>>>> Thanks in advance >>>>>> >>>>>> >>>>>>> >>>>>>>> Thanks for any help. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>>> >>>> >>>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Sept. 27, 2011