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

Re: [Pharo-project] Monticello and different time zones

by Frank Shearar

On 7 September 2011 12:33, Andy Kellens <akellens(a)vub.ac.be> wrote: > > On 07 Sep 2011, at 12:38, Frank Shearar wrote: > >> On 7 September 2011 10:52, Andy Kellens <akellens(a)vub.ac.be> wrote: >>> Hello, >>> >>> While working here with Veronica on importing the history of Ring, I found some strange behaviour in Monticello. >>> Veronica and StÃ©phane were working on Ring at CAMP Smalltalk in Edinburgh; StÃ©phane already changed his time zone to GMT time; Veronica did not. >>> >>> As a result, there is a commit of a package from StÃ©phane at 6pm that has as an ancestor a package from Veronica at 7pm. >>> It looks like Monticello uses the timestamp of Â the computer from which the package was published; not the timestamp from the computer. >>> Given that people are working on the same code from all across the world, this can be a bit counter-intuitive. >>> >>> Shouldn't Monticello use the timestamp from the server? >> >> What's a server, though? My computer? Your computer? Some shared >> repository (which is really just another peer)? >> >> What if I commit one version to my local package cache, daylight >> savings starts (or ends - I can never remember which makes the clock >> go back), and I commit a new version. Hey presto, the new version has >> a timestamp older than the old version. >> >> The answer is this: don't look at the timestamp; it's irrelevant. Look >> at the ancestry of the package. > > The motivation of using the timestamp is that we are computing dependencies between packages. > Sure, in the case that you have a Metacello configuration, or you use slices, it is fairly easy to see which versions of packages go together. > However, if you do not have this information, timestamps seem to be the only thing you can rely on. I've worked a little on this recently, in trying to break up LanguageBoxes so I can port it to Squeak. The approach I used was to try port DependencyBrowser to point at a Monticello repository instead of an image. It examines the latest version (*) of every package within that repository, collecting information like "this package defines these classes" and "this method uses these classes, so must depend on that package". It's very far from complete, mind you. (*) Version with the highest number frank > Actually, we were able to pin down the problem: it is not an issue of Monticello at all but rather an issue related to how time zones are handled in Pharo. > Pharo appears to set the local time zone when opening the image; if you are traveling with an image open (what Veronica did), change time zones, and continue to work, then your TimeStamps are not aware of the fact that you changed time zones. > > This made me wonder: what is the reason for keeping track of the current time zone within the image, and not just relying on the computer's time when calculating DateAndTime now? > There is a primitive that asks for the local time zone. > >> >> frank >> >>> Kind regards, >>> >>> Andy >>> >> > > >

Sept. 7, 2011

Re: [Pharo-project] Monticello and different time zones

by Andy Kellens

On 07 Sep 2011, at 12:38, Frank Shearar wrote: > On 7 September 2011 10:52, Andy Kellens <akellens(a)vub.ac.be> wrote: >> Hello, >> >> While working here with Veronica on importing the history of Ring, I found some strange behaviour in Monticello. >> Veronica and StÃ©phane were working on Ring at CAMP Smalltalk in Edinburgh; StÃ©phane already changed his time zone to GMT time; Veronica did not. >> >> As a result, there is a commit of a package from StÃ©phane at 6pm that has as an ancestor a package from Veronica at 7pm. >> It looks like Monticello uses the timestamp of the computer from which the package was published; not the timestamp from the computer. >> Given that people are working on the same code from all across the world, this can be a bit counter-intuitive. >> >> Shouldn't Monticello use the timestamp from the server? > > What's a server, though? My computer? Your computer? Some shared > repository (which is really just another peer)? > > What if I commit one version to my local package cache, daylight > savings starts (or ends - I can never remember which makes the clock > go back), and I commit a new version. Hey presto, the new version has > a timestamp older than the old version. > > The answer is this: don't look at the timestamp; it's irrelevant. Look > at the ancestry of the package. The motivation of using the timestamp is that we are computing dependencies between packages. Sure, in the case that you have a Metacello configuration, or you use slices, it is fairly easy to see which versions of packages go together. However, if you do not have this information, timestamps seem to be the only thing you can rely on. Actually, we were able to pin down the problem: it is not an issue of Monticello at all but rather an issue related to how time zones are handled in Pharo. Pharo appears to set the local time zone when opening the image; if you are traveling with an image open (what Veronica did), change time zones, and continue to work, then your TimeStamps are not aware of the fact that you changed time zones. This made me wonder: what is the reason for keeping track of the current time zone within the image, and not just relying on the computer's time when calculating DateAndTime now? There is a primitive that asks for the local time zone. > > frank > >> Kind regards, >> >> Andy >> >

Sept. 7, 2011

Re: [Pharo-project] TextLint for Emacs & TextMate

by Damien Pollet

On 7 September 2011 13:14, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Coral could be useful, but is it ready and working on Linux, Windows and MacOS? So? you're opposed to refactoring? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Sept. 7, 2011

Re: [Pharo-project] TextLint for Emacs & TextMate

by Damien Cassou

On Wed, Sep 7, 2011 at 12:58 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 6 September 2011 16:43, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> What about vi - the best editor ever ;-) > > I will have a look at it when I'm done with the current urgent lecture > preparation. Also I suspect Coral could be useful around here? Coral could be useful, but is it ready and working on Linux, Windows and MacOS? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 7, 2011

Re: [Pharo-project] TextLint for Emacs & TextMate

by Damien Pollet

On 6 September 2011 16:43, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> What about vi - the best editor ever ;-) I will have a look at it when I'm done with the current urgent lecture preparation. Also I suspect Coral could be useful around here? > I would be happy to include it if someone does it. That would be a > good way to prove me vi is extensible because I don't think it is :-). That was not a very subtle troll. Come on, I know you can do better :p -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Sept. 7, 2011

Re: [Pharo-project] Glamour configuration doesn't load in Pharo 1.3

by Alain Plantec

On 05/09/2011 00:54, Alain Plantec wrote: > On 04/09/2011 21:56, Tudor Girba wrote: >> Hi, >> I do not have time to check right now, but we would not want to have >> it like that. > > ok, I understand. > I will remove all this bad dependencies. > Alain Done, hope its ok now. Cheers Alain > >> >> Cheers, >> Doru >> >> >>> Cheers >>> Alain >>> >> >> -- >> www.tudorgirba.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." >> >> >> > > >

Sept. 7, 2011

Re: [Pharo-project] Monticello and different time zones

by Frank Shearar

On 7 September 2011 10:52, Andy Kellens <akellens(a)vub.ac.be> wrote: > Hello, > > While working here with Veronica on importing the history of Ring, I found some strange behaviour in Monticello. > Veronica and StÃ©phane were working on Ring at CAMP Smalltalk in Edinburgh; StÃ©phane already changed his time zone to GMT time; Veronica did not. > > As a result, there is a commit of a package from StÃ©phane at 6pm that has as an ancestor a package from Veronica at 7pm. > It looks like Monticello uses the timestamp of Â the computer from which the package was published; not the timestamp from the computer. > Given that people are working on the same code from all across the world, this can be a bit counter-intuitive. > > Shouldn't Monticello use the timestamp from the server? What's a server, though? My computer? Your computer? Some shared repository (which is really just another peer)? What if I commit one version to my local package cache, daylight savings starts (or ends - I can never remember which makes the clock go back), and I commit a new version. Hey presto, the new version has a timestamp older than the old version. The answer is this: don't look at the timestamp; it's irrelevant. Look at the ancestry of the package. frank > Kind regards, > > Andy >

Sept. 7, 2011

[Pharo-project] Monticello and different time zones

by Andy Kellens

Hello, While working here with Veronica on importing the history of Ring, I found some strange behaviour in Monticello. Veronica and StÃ©phane were working on Ring at CAMP Smalltalk in Edinburgh; StÃ©phane already changed his time zone to GMT time; Veronica did not. As a result, there is a commit of a package from StÃ©phane at 6pm that has as an ancestor a package from Veronica at 7pm. It looks like Monticello uses the timestamp of the computer from which the package was published; not the timestamp from the computer. Given that people are working on the same code from all across the world, this can be a bit counter-intuitive. Shouldn't Monticello use the timestamp from the server? Kind regards, Andy

Sept. 7, 2011

[Pharo-project] [update 1.4] #14123

by Marcus Denker

14123 ----- Issue 4767: remove ScriptLoader>>#installingInstaller http://code.google.com/p/pharo/issues/detail?id=4767 Issue 4735: Compatibility package is dirty in Pharo1.4a update: #14112 http://code.google.com/p/pharo/issues/detail?id=4735 -- Marcus Denker -- http://marcusdenker.de

Sept. 7, 2011

[Pharo-project] How to convert Sensor polling left over

by StÃ©phane Ducasse

Hi igor how should I convert code like that [ Sensor anyButtonPressed ] whileFalse: [ aBitBlt destOrigin: Sensor cursorPoint. aBitBlt copyBits ]. So that it avoid polling? Should we change contents := (Sensor shiftPressed not) ifTrue: [currentCompiledMethod decompileWithTemps] ifFalse: [currentCompiledMethod decompile]. contents := contents decompileString asText makeSelector or [(nextEvent := Sensor peekEvent) isNil] whileFalse: [nextEvent first = currentBuf first ifFalse: [^trail contents "different event type"]. nextEvent fifth = currentBuf fifth ifFalse: [^trail contents "buttons changed"]. nextEvent sixth = currentBuf sixth ifFalse: [^trail contents "modifiers changed"]. "nextEvent is similar. Remove it from the queue, and check the next." nextEvent := Sensor nextEvent. nextEvent ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth ]]. Then when I install the nonpolling behavior InputEventSensor installPollingEventSensorFramework the menu of the world gets sluggish (may be I do not use the right VM BTW). Stef

Sept. 7, 2011