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

[Pharo-project] War plan for Pharo20 beta

by StÃ©phane Ducasse

Hi guys I really think that we should focus on fixing the tests first. - I will remove the spellchecking tests so that tests run faster - Integrate a couple of more fixes to make us faster when merging. - then I will try to spot the progress bar bugs. Stef

Dec. 30, 2012

Re: [Pharo-project] [update 2.0] #20461

by StÃ©phane Ducasse

Looking at the log I do not see how this is related to the changes we did. I'm puzzled Now I'm rerunning the tests flushing the cache MCMethodDefinition flushMethodCache first But I expect exactly the same result. Stef On Dec 30, 2012, at 10:57 AM, StÃ©phane Ducasse wrote: > So I downloaded the latest version and run the tests locally > Here are the issues that we should fix > > > - so far I have only MCStReaderTest>>testCommentWithStyle and testMethodWithStyle that are red. > > - Now I do not understand why the RB tests are so long. (spellchecking the complete system does not look like a good idea) > I have testPullUWithMethodThatCannotâ¦ failing > > - Why do we have the spell checker rules or tests in the image? (or why do we get the rb-spelling.dat file > > - Then a large number of subscriptOutOfBounds: related to the progress bar problems. > Camillo if you want to have a look I could never integrate your changes and changing the dispatch of Mouse event or related > was not a good idea from my point of view. > > > - the VM crash and I do not see how this can be related to changing a tests in a cache for MC. > > I took the version 20459 and run the tests > > - I get the same > MCStReaderTest>>testCommentWithStyle and testMethodWithStyle that are red. > I have testPullUWithMethodThatCannotâ¦ failing > a couple more ReleaseTest red > RB tests are too long. > > - Then a large number of subscriptOutOfBounds: related to the progress bar problems. > Camillo if you want to have a look I could never integrate your changes and changing the dispatch of Mouse event or related > was not a good idea from my point of view. > > - I do not understand why the VM does not crash may this is related to the fact that now we fill up more the WeakRegistry? > > > I think that we should coordinate and streamline the process > We started to address fixes that are burning us: > - MC cache because it messed up the method recategorisation and it was introducing pain at each of our movement. > - > > > > > Stef > > > <PharoDebug.log>

Dec. 30, 2012

Re: [Pharo-project] DateAndTime class>>midnight

by Max Leske

On 30.12.2012, at 10:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Max, > > On 30 Dec 2012, at 09:42, Max Leske <maxleske(a)gmail.com> wrote: > >> Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??). >> >> In any case, I see two problems: >> 1. as already said, comparison operations on Date are broken (and on DateAndTime) >> 2. "midnight" is no longer the same as "midnight". Consider the following example: >> >> now := DateAndTime now. >> midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond. >> midnight = DateAndTime midnight "---> true" >> >> Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equalâ¦ >> >> I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects. >> >> Sorry Cami, I know that's your work :) > > This is not a comment on the problem itself, but on your arguments. > An object is how it behaves, not what its instance variables hold. > If two objects are equal for #= and behave the same, then it does not matter what's inside. > You're right of course. But that doesn't mean that messages should obfuscate the internals of an object. All I meant to say is that I believe in simple objects and simple relationships between objects and I don't think that DateAndTime is simple enough (just to clarify: I don't think I could do it any better :) I know that dates and times can be a can of worms). > Unless you really need timezones (why since they are mostly a representation aspect ?), you could have a look at ZTimestamp in http://mc.stfx.eu/Neo which is much simpler. Thanks for the pointer. No, I don't need time zones. I stumbled upon this "problem" (or notâ¦) while debugging a date comparison issue that suddenly cropped up (beause of #midnight). > > Sven > >> On 30.12.2012, at 00:01, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> ah no wait :) this is fine :) it's midnight from your local time-zone. >>> >>> hence the seconds change in UTC ;) >>> >>> #seconds + #offset = 0 >>> >>> so this is fine ;) >>> >>> On 2012-12-29, at 19:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>>> midnight should be local time and DateAndTime work internally with UTC time only >>>> >>>> so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values. >>>> >>>> On 2012-12-29, at 18:51, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>>> Possible bug in 2.0 which messes with equality checks: >>>>> >>>>> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0. >>>>> This messes up equality checks for Date because Date class>>current uses #midnight. >>>>> >>>>> Please confirm and I'll open a bug report. >>>>> >>>>> Cheers, >>>>> Max >>>> >>> >>> >> >> > >

Dec. 30, 2012

Re: [Pharo-project] [update 2.0] #20461

by StÃ©phane Ducasse

So I downloaded the latest version and run the tests locally Here are the issues that we should fix - so far I have only MCStReaderTest>>testCommentWithStyle and testMethodWithStyle that are red. - Now I do not understand why the RB tests are so long. (spellchecking the complete system does not look like a good idea) I have testPullUWithMethodThatCannotâ¦ failing - Why do we have the spell checker rules or tests in the image? (or why do we get the rb-spelling.dat file - Then a large number of subscriptOutOfBounds: related to the progress bar problems. Camillo if you want to have a look I could never integrate your changes and changing the dispatch of Mouse event or related was not a good idea from my point of view. - the VM crash and I do not see how this can be related to changing a tests in a cache for MC. I took the version 20459 and run the tests - I get the same MCStReaderTest>>testCommentWithStyle and testMethodWithStyle that are red. I have testPullUWithMethodThatCannotâ¦ failing a couple more ReleaseTest red RB tests are too long. - Then a large number of subscriptOutOfBounds: related to the progress bar problems. Camillo if you want to have a look I could never integrate your changes and changing the dispatch of Mouse event or related was not a good idea from my point of view. - I do not understand why the VM does not crash may this is related to the fact that now we fill up more the WeakRegistry? I think that we should coordinate and streamline the process We started to address fixes that are burning us: - MC cache because it messed up the method recategorisation and it was introducing pain at each of our movement. - Stef

Dec. 30, 2012

Re: [Pharo-project] DateAndTime class>>midnight

by Sven Van Caekenberghe

Max, On 30 Dec 2012, at 09:42, Max Leske <maxleske(a)gmail.com> wrote: > Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??). > > In any case, I see two problems: > 1. as already said, comparison operations on Date are broken (and on DateAndTime) > 2. "midnight" is no longer the same as "midnight". Consider the following example: > > now := DateAndTime now. > midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond. > midnight = DateAndTime midnight "---> true" > > Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equalâ¦ > > I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects. > > Sorry Cami, I know that's your work :) This is not a comment on the problem itself, but on your arguments. An object is how it behaves, not what its instance variables hold. If two objects are equal for #= and behave the same, then it does not matter what's inside. Unless you really need timezones (why since they are mostly a representation aspect ?), you could have a look at ZTimestamp in http://mc.stfx.eu/Neo which is much simpler. Sven > On 30.12.2012, at 00:01, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> ah no wait :) this is fine :) it's midnight from your local time-zone. >> >> hence the seconds change in UTC ;) >> >> #seconds + #offset = 0 >> >> so this is fine ;) >> >> On 2012-12-29, at 19:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> midnight should be local time and DateAndTime work internally with UTC time only >>> >>> so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values. >>> >>> On 2012-12-29, at 18:51, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> Possible bug in 2.0 which messes with equality checks: >>>> >>>> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0. >>>> This messes up equality checks for Date because Date class>>current uses #midnight. >>>> >>>> Please confirm and I'll open a bug report. >>>> >>>> Cheers, >>>> Max >>> >> >> > >

Dec. 30, 2012

Re: [Pharo-project] [update 2.0] #20461

by StÃ©phane Ducasse

Then the change in 20460 is rather simple. It make sure that the MC cache does not return old method information when snaphotting. So I do not see why we cannot fix the problems now. Stef On Dec 30, 2012, at 12:07 AM, Camillo Bruni wrote: > looks like the integration server is not failing: > > https://ci.lille.inria.fr/pharo/job/Pharo-2.0/ > > looks like we have to rollback the MC changes from 20460 > > On 2012-12-29, at 18:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 20461 >> ----- >> >> - Issue 4018: Color class enhancement. Thanks Alexander Bergel. >> http://code.google.com/p/pharo/issues/detail?id=4018 >> >> - Issue 7187: Doit is broken in spec. Thanks Benjamin van Ryseghem >> http://code.google.com/p/pharo/issues/detail?id=7187 >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.77.diff >> http://ss3.gemstone.com/ss/Pharo20/Graphics-Primitives-StephaneDucasse.97.d… >> >> Stef > >

Dec. 30, 2012

Re: [Pharo-project] [update 2.0] #20461

by StÃ©phane Ducasse

Strange why does it work on my machine? Can you take the image before and do an update? This change was difficult to integrate so I would prefer not to rollback and rollback should be the exception (like not been able to execute code anymore like for the last nasty logic in Changesorter whose cleaning phase was bringing the system in a state where it can only loop on code execution) Stef > looks like the integration server is not failing: > > https://ci.lille.inria.fr/pharo/job/Pharo-2.0/ > > looks like we have to rollback the MC changes from 20460 > > On 2012-12-29, at 18:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 20461 >> ----- >> >> - Issue 4018: Color class enhancement. Thanks Alexander Bergel. >> http://code.google.com/p/pharo/issues/detail?id=4018 >> >> - Issue 7187: Doit is broken in spec. Thanks Benjamin van Ryseghem >> http://code.google.com/p/pharo/issues/detail?id=7187 >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.77.diff >> http://ss3.gemstone.com/ss/Pharo20/Graphics-Primitives-StephaneDucasse.97.d… >> >> Stef > >

Dec. 30, 2012

Re: [Pharo-project] DateAndTime class>>midnight

by Max Leske

Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??). In any case, I see two problems: 1. as already said, comparison operations on Date are broken (and on DateAndTime) 2. "midnight" is no longer the same as "midnight". Consider the following example: now := DateAndTime now. midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond. midnight = DateAndTime midnight "---> true" Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equalâ¦ I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects. Sorry Cami, I know that's your work :) On 30.12.2012, at 00:01, Camillo Bruni <camillobruni(a)gmail.com> wrote: > ah no wait :) this is fine :) it's midnight from your local time-zone. > > hence the seconds change in UTC ;) > > #seconds + #offset = 0 > > so this is fine ;) > > On 2012-12-29, at 19:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> midnight should be local time and DateAndTime work internally with UTC time only >> >> so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values. >> >> On 2012-12-29, at 18:51, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Possible bug in 2.0 which messes with equality checks: >>> >>> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0. >>> This messes up equality checks for Date because Date class>>current uses #midnight. >>> >>> Please confirm and I'll open a bug report. >>> >>> Cheers, >>> Max >> > >

Dec. 30, 2012

Re: [Pharo-project] [update 2.0] #20461

by Camillo Bruni

looks like the integration server is not failing: https://ci.lille.inria.fr/pharo/job/Pharo-2.0/ looks like we have to rollback the MC changes from 20460 On 2012-12-29, at 18:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 20461 > ----- > > - Issue 4018: Color class enhancement. Thanks Alexander Bergel. > http://code.google.com/p/pharo/issues/detail?id=4018 > > - Issue 7187: Doit is broken in spec. Thanks Benjamin van Ryseghem > http://code.google.com/p/pharo/issues/detail?id=7187 > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-StephaneDucasse.77.diff > http://ss3.gemstone.com/ss/Pharo20/Graphics-Primitives-StephaneDucasse.97.d… > > Stef

Dec. 29, 2012

Re: [Pharo-project] DateAndTime class>>midnight

by Camillo Bruni

ah no wait :) this is fine :) it's midnight from your local time-zone. hence the seconds change in UTC ;) #seconds + #offset = 0 so this is fine ;) On 2012-12-29, at 19:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > midnight should be local time and DateAndTime work internally with UTC time only > > so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values. > > On 2012-12-29, at 18:51, Max Leske <maxleske(a)gmail.com> wrote: > >> Possible bug in 2.0 which messes with equality checks: >> >> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0. >> This messes up equality checks for Date because Date class>>current uses #midnight. >> >> Please confirm and I'll open a bug report. >> >> Cheers, >> Max >

Dec. 29, 2012