- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] Pharo Days 2015

by Craig Latta

Hoi Francois-- > I can host one or two people at my place in Mons, Belgium (~1h drive > from INRIA Lille) for free. I can drive to the conference both days. > > In the best case, I might have some friends to host me (us?) in Lille. > So we can have some beers without having to drive. Oh, cool, I'd love to stay there. (Sorry for the broadcast, I didn't see your email address anywhere.) thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Oct. 30, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 30, 2014

[pharo-project/pharo-core] 3461c9: 40338

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3461c9e17150b97bc90b9bd86127b046e4dfe7e3 https://github.com/pharo-project/pharo-core/commit/3461c9e17150b97bc90b9bd8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-30 (Thu, 30 Oct 2014) Changed paths: R MorphicTests.package/HandBugsTest.class/README.md R MorphicTests.package/HandBugsTest.class/definition.st R MorphicTests.package/HandBugsTest.class/instance/accessing/testTargetPoint.st R MorphicTests.package/MorphBugsTest.class/README.md R MorphicTests.package/MorphBugsTest.class/definition.st R MorphicTests.package/MorphBugsTest.class/instance/accessing/adhereToEdgeTest.st R MorphicTests.package/MorphicUIBugTest.class/instance/private/findWindowInWorldLabeled_.st M MorphicTests.package/MorphicUIBugTest.class/instance/running/setUp.st M MorphicTests.package/MorphicUIBugTest.class/instance/running/tearDown.st R MorphicTests.package/MorphicUIBugTest.class/instance/tests/testOpenWorkspace.st M MorphicTests.package/RenderBugsTest.class/instance/private/long.st M MorphicTests.package/RenderBugsTest.class/instance/private/shouldntTakeLong_.st M MorphicTests.package/RenderBugsTest.class/instance/tests/testForward.st M MorphicTests.package/RenderBugsTest.class/instance/tests/testHeading.st M MorphicTests.package/RenderBugsTest.class/instance/tests/testSetForward.st M MorphicTests.package/RenderBugsTest.class/instance/tests/testTestTime.st M MorphicTests.package/StickynessBugsTest.class/instance/tests/testForTiltedStickyness.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script338.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40338.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40338 14343 MorphicUIBugTest failing with GTPlayground active https://pharo.fogbugz.com/f/cases/14343 http://files.pharo.org/image/40/40338.zip

Oct. 30, 2014