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

[pharo-project/pharo-core]

by GitHub

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

Nov. 1, 2014

[pharo-project/pharo-core] 408c92: 40345

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 408c92abe11199db54816cd0646fb16bc62fe244 https://github.com/pharo-project/pharo-core/commit/408c92abe11199db54816cd0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-01 (Sat, 01 Nov 2014) Changed paths: M Morphic-Base.package/ImageMorph.class/instance/menus/addCustomMenuItems_hand_.st R Morphic-Base.package/MenuMorph.class/instance/construction/addTranslatedList_.st R Morphic-Base.package/MenuMorph.class/instance/construction/addUpdating_action_.st A Morphic-Base.package/MenuMorph.class/instance/construction/addUpdating_selector_.st M Morphic-Base.package/MenuMorph.class/instance/construction/addUpdating_target_selector_argumentList_.st A Morphic-Base.package/MenuMorph.class/instance/deprecated/addTranslatedList_.st A Morphic-Base.package/MenuMorph.class/instance/deprecated/addUpdating_action_.st M Morphic-Core.package/Morph.class/instance/drop shadows/addDropShadowMenuItems_hand_.st M Morphic-Core.package/Morph.class/instance/layout-menu/addCellLayoutMenuItems_hand_.st M Morphic-Core.package/Morph.class/instance/layout-menu/addLayoutMenuItems_hand_.st M Morphic-Core.package/Morph.class/instance/layout-menu/addTableLayoutMenuItems_hand_.st M Morphic-Core.package/Morph.class/instance/menus/addToggleItemsToHaloMenu_.st M Morphic-Core.package/Morph.class/instance/text-anchor/addTextAnchorMenuItems_hand_.st M Morphic-Core.package/PasteUpMorph.class/instance/menu %26 halo/addWorldToggleItemsToHaloMenu_.st M Morphic-Widgets-Extra.package/DockingBarMorph.class/instance/menu/addCustomMenuItems_hand_.st A Polymorph-Widgets.package/ThemeIcons.class/class/cleanup/cleanUp.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script345.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40345.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40345 14335 renaming addUpdating:action: into addUpdating:selector: https://pharo.fogbugz.com/f/cases/14335 14360 ThemeIcons should be cleared on #cleanUp https://pharo.fogbugz.com/f/cases/14360 http://files.pharo.org/image/40/40345.zip

Nov. 1, 2014

Re: [Pharo-dev] Super fast delay

by Ben Coman

Ben Coman wrote: > Norbert Hartl wrote: >>> 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 >> >> >> >> > > This is ready for review as "Delay refactoring (part 2) - change from > milliseconds to microseconds" > https://pharo.fogbugz.com/default.asp?14353 > > Note that this continues on from "Delay refactoring (part 1) - move > scheduler from class-side to instance-side of its own class" > https://pharo.fogbugz.com/default.asp?14261 > > So load part 1 first if you only want to see the from milliseconds to > microseconds changes. Now if you don't like part 1, I'll do the work to > break out part 2 on its own - but it was simpler for me to work on part > 2 since: > * with instances I could define, run and debug tests without > interference from the live system-delay-scheduler. > * the code swapping (newCodeEnabled) pattern I'd used for part 1 helped. > * eliminating the clock rollover conditional simplifies what I am > planning for part 3 > > I don't have the virtual machine environment to replicate the problem, > so please report if it this has any effect. > > cheers -ben > > I've confirmed this works with build 40346 on LinuxMint17 on Virtualbox on OSX. With the following script test.sh... ---- #!/bin/bash for i in `seq 1 20` ; do (time pharo-vm-nox ./test.image \ eval "(Delay forSeconds: 2) wait") 2>&1 > /dev/null | grep real done ---- I get... # bash ./test.sh real 0m0.160s real 0m2.159s real 0m0.161s real 0m0.176s real 0m2.158s real 0m0.160s real 0m0.157s real 0m0.170s real 0m0.154s real 0m0.156s real 0m0.159s real 0m2.161s real 0m0.156s real 0m0.149s real 0m0.158s real 0m0.167s real 0m0.162s real 0m2.152s real 0m0.212s real 0m2.212s In the image load slice 14353, then evaluate "Delay newCodeEnabled: true", and save the image. Then from the shell... # ./test.sh real 0m2.161s real 0m2.156s real 0m2.206s real 0m2.170s real 0m2.156s real 0m2.162s real 0m2.158s real 0m2.163s real 0m2.158s real 0m2.158s real 0m2.163s real 0m2.168s real 0m2.162s real 0m2.158s real 0m2.162s real 0m2.164s real 0m2.153s real 0m2.152s real 0m2.198s real 0m2.173s cheers -ben

Nov. 1, 2014