October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] unexpected merge conflict

by Marcus Denker

> On 30 Oct 2014, at 13:59, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > > On Thu, Oct 30, 2014 at 3:47 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > > On 29 Oct 2014, at 23:35, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > > > > Hi, > > > > In a fresh Pharo 4 image I want to merge a package (Glamour-Presentations) but I get a merge conflict. > > > > Nevertheless, the package from the image has no changes and the package cache is empty. Shouldn't there be no merge conflict in this case? > > > > I think we do not have the repositories defined correctly for these packages. > (or alternatively, the current packages need to be in the pharo repo which is not the case). > > Hmm... Now it's behaving even more strangely. > When I try to manually merge I sometimes get/don't get the merge conflict. > However, when I load that package through a configuration I always get a warning that I have a merge conflict. > > (ConfigurationOfGTPlaygroundCore project version: '2.0.0') load > > It' strange because it only happens for one method, while this version of GTools has a lot of other changes. > There was a huge refactoring reated to menus that might have touched that one methodâ¦ Marcus

Oct. 30, 2014

Re: [Pharo-dev] unexpected merge conflict

by Andrei Chis

On Thu, Oct 30, 2014 at 3:47 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 29 Oct 2014, at 23:35, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > Hi, > > > > In a fresh Pharo 4 image I want to merge a package > (Glamour-Presentations) but I get a merge conflict. > > > > Nevertheless, the package from the image has no changes and the package > cache is empty. Shouldn't there be no merge conflict in this case? > > > > I think we do not have the repositories defined correctly for these > packages. > (or alternatively, the current packages need to be in the pharo repo which > is not the case). > Hmm... Now it's behaving even more strangely. When I try to manually merge I sometimes get/don't get the merge conflict. However, when I load that package through a configuration I always get a warning that I have a merge conflict. (ConfigurationOfGTPlaygroundCore project version: '2.0.0') load It' strange because it only happens for one method, while this version of GTools has a lot of other changes. > > Marcus > > >

Oct. 30, 2014

[pharo-project/pharo-core] 8374a2: 40340

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 8374a209a81280927d47d95cd77c09894a2bb04d https://github.com/pharo-project/pharo-core/commit/8374a209a81280927d47d95c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-30 (Thu, 30 Oct 2014) Changed paths: M SUnit-UI.package/TestRunner.class/instance/initialization/initialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script340.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40340.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/ClassModification.class/definition.st R Slot.package/ClassModification.class/instance/accessing/subclassSlotOffset.st M Slot.package/ClassModification.class/instance/testing/modifiesClassVariables.st Log Message: ----------- 40340 14351 cleanup ClassModification: remove unused ivars https://pharo.fogbugz.com/f/cases/14351 14350 Replace Announcer>>#on:send:to:s senders in SUnit-UI https://pharo.fogbugz.com/f/cases/14350 http://files.pharo.org/image/40/40340.zip

Oct. 30, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40340 Home: https://github.com/pharo-project/pharo-core

Oct. 30, 2014

Re: [Pharo-dev] Super fast delay

by Norbert Hartl

> Am 30.10.2014 um 12:52 schrieb Ben Coman <btc(a)openinworld.com>: > > Eliot Miranda wrote: >> On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> Holger Hans Peter Freyther wrote: >> On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter >> Freyther wrote: >> On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote: >> Good Evening, >> Hi again, >> I don't know how you debug startUp issues. I just added an >> OrderedCollection >> into the systemdictionary and use it as a log.. >> time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay >> forSeconds: 3) wait. (Smalltalk at: #Foo) do: [:each | >> FileStream stderr nextPutAll: each printString; cr].1" >> ... old events from saving the image... >> {#handleTimerEvent->7147} >> {#handleTimerEvent->7167} >> {#resumptionTime->7187} >> {#handleTimerEvent->7167} >> {#handleTimerEvent->7187} >> {#start->true} >> {#start->393102159} >> {#start->393102159} >> {#resumptionTime->3279} >> {#handleTimerEvent->279} >> {#adjustResum->-393098880} >> {#restoreWithActiveDelay->266} >> {#adjustResum->-393098601} >> 1 >> real 0m0.294s >> user 0m0.244s >> sys 0m0.048s >> So what happens is Delay class>>#startU is called. and >> ActiveDelayStartTime is being set to 393102159. Then the >> delay is being created and resumptionTime is set to 3279. >> At the first time handleTimerEvent runs the milliSecondClock >> jumped backwards from 393102159 to 3279 which leads to >> an adjustment of the time. >> a.) Why does the time jump backwards like this during the >> resumption of the image? "3279" is not the old time nor >> the new starting time. >> b.) So even if that is a "wrap" around. Why does it go >> wrong? Are there unit tests for the clock wraps around? >> There are no unit tests, I guess since its all done using class >> variables its too hard test without disturbing the system. >> Now I have spent the last week refactoring this out to the >> instance-side of a new class "DelayScheduler" which should help with >> getting unit tests. Its ready for review [1], maybe you could take >> a look. >> [1] https://pharo.fogbugz.com/__default.asp?14261 >> <https://pharo.fogbugz.com/default.asp?14261> >> Maybe it is the same reason delays just don't work after >> image resumption? >> The "first" issue appears that when start is being executed >> that the clock is still wrong. At the same the clock is >> being considered wrapped the resumption time was actually >> already "correct' (3279 instead of 393102159+3279). >> Does this ring a bell? >> holger >> btw, its too late in the night for me to try something, but I have >> been wondering, should the check for clock roll-over occur >> immediately after >> TimingSemaphore wait >> wakes up. That is, before the Schedule and Finish requests are >> handled ??? >> The check for rollover should be thrown away and the system implemented over the VM's support for 64-bit microseconds since 1901. It's in the VM, it isn't susceptible to rollover for ~ 50,000 years, and doesn't require the millisecond clock to be synced to the second clock, because all times can be derived from the one 64-bit microsecond clock. >> -- >> best, >> Eliot > > I'll give it a go. > cheers -ben > Super, thanks in advance, Norbert

Oct. 30, 2014

Re: [Pharo-dev] Super fast delay

by Ben Coman

Eliot Miranda wrote: > > > On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > Holger Hans Peter Freyther wrote: > > On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter > Freyther wrote: > > On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote: > > Good Evening, > > > Hi again, > > I don't know how you debug startUp issues. I just added an > OrderedCollection > into the systemdictionary and use it as a log.. > > time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay > forSeconds: 3) wait. (Smalltalk at: #Foo) do: [:each | > FileStream stderr nextPutAll: each printString; cr].1" > ... old events from saving the image... > {#handleTimerEvent->7147} > {#handleTimerEvent->7167} > {#resumptionTime->7187} > {#handleTimerEvent->7167} > {#handleTimerEvent->7187} > {#start->true} > {#start->393102159} > {#start->393102159} > {#resumptionTime->3279} > {#handleTimerEvent->279} > {#adjustResum->-393098880} > {#restoreWithActiveDelay->266} > {#adjustResum->-393098601} > 1 > > real 0m0.294s > user 0m0.244s > sys 0m0.048s > > > So what happens is Delay class>>#startU is called. and > ActiveDelayStartTime is being set to 393102159. Then the > delay is being created and resumptionTime is set to 3279. > At the first time handleTimerEvent runs the milliSecondClock > jumped backwards from 393102159 to 3279 which leads to > an adjustment of the time. > > > a.) Why does the time jump backwards like this during the > resumption of the image? "3279" is not the old time nor > the new starting time. > > b.) So even if that is a "wrap" around. Why does it go > wrong? Are there unit tests for the clock wraps around? > > > There are no unit tests, I guess since its all done using class > variables its too hard test without disturbing the system. > > Now I have spent the last week refactoring this out to the > instance-side of a new class "DelayScheduler" which should help with > getting unit tests. Its ready for review [1], maybe you could take > a look. > > [1] https://pharo.fogbugz.com/__default.asp?14261 > <https://pharo.fogbugz.com/default.asp?14261> > > Maybe it is the same reason delays just don't work after > image resumption? > > The "first" issue appears that when start is being executed > that the clock is still wrong. At the same the clock is > being considered wrapped the resumption time was actually > already "correct' (3279 instead of 393102159+3279). > > Does this ring a bell? > > holger > > > > btw, its too late in the night for me to try something, but I have > been wondering, should the check for clock roll-over occur > immediately after > TimingSemaphore wait > wakes up. That is, before the Schedule and Finish requests are > handled ??? > > > The check for rollover should be thrown away and the system implemented > over the VM's support for 64-bit microseconds since 1901. It's in the > VM, it isn't susceptible to rollover for ~ 50,000 years, and doesn't > require the millisecond clock to be synced to the second clock, because > all times can be derived from the one 64-bit microsecond clock. > > -- > best, > Eliot I'll give it a go. cheers -ben

Oct. 30, 2014

Re: [Pharo-dev] GTDebugger popping up instead of the usual popup box.

by Marcus Denker

> On 30 Oct 2014, at 10:58, phil(a)highoctane.be wrote: > > The Pharo3 debugger was showing a kind of message with 2 buttons. > > So, I guess that it is what I want to see. > The pre-debug window. > Phil > > > On Thu, Oct 30, 2014 at 10:13 AM, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > What would you expect in this case? > > Doru > > On Thu, Oct 30, 2014 at 9:37 AM, phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>> wrote: > While loading a package with missing classes, I get > > > <image.png> > > Instead of the normal popup with a choice. > > Pharo3+GT > > How to handle this case? > > Phil > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" >

Oct. 30, 2014

Re: [Pharo-dev] GTDebugger popping up instead of the usual popup box.

by phil＠highoctane.be

The Pharo3 debugger was showing a kind of message with 2 buttons. So, I guess that it is what I want to see. Phil On Thu, Oct 30, 2014 at 10:13 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > What would you expect in this case? > > Doru > > On Thu, Oct 30, 2014 at 9:37 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> While loading a package with missing classes, I get >> >> >> [image: Inline image 1] >> >> Instead of the normal popup with a choice. >> >> Pharo3+GT >> >> How to handle this case? >> >> Phil >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 30, 2014

[pharo-project/pharo-core] b7014a: 40339

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b7014a82ccef973a33d750746c93096ba68846a4 https://github.com/pharo-project/pharo-core/commit/b7014a82ccef973a33d75074… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-30 (Thu, 30 Oct 2014) Changed paths: A Nautilus.package/AbstractNautilusUI.class/instance/as yet unclassified/shiftedTextPaneMenuRequest.st M Refactoring-Changes.package/RBRefactoryChangeManager.class/instance/initialize-release/connectToChanges.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script339.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40339.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40339 14345 Replace Announcer>>#on:send:to:s senders in Refactoring-Changes https://pharo.fogbugz.com/f/cases/14345 10520 Right clicking on the source pane in Nautilus and clicking extended search itself produces a walkback https://pharo.fogbugz.com/f/cases/10520 http://files.pharo.org/image/40/40339.zip

Oct. 30, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40339 Home: https://github.com/pharo-project/pharo-core

Oct. 30, 2014