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

Re: [Pharo-dev] Question

by jdelgado＠lsi.upc.edu

Thanks a lot, Eliot! Bests, Jordi > On Wed, Oct 29, 2014 at 9:48 AM, <jdelgado(a)lsi.upc.edu> wrote: > >> Hi all, >> >> ------------------------------------------------ >> My question is: >> One thing I've observed is that local/temporal variables in the blocks >> passed to #ifTrue:iFfalse are not stored in the separate remote (heap >> allocated) array, but in the method context (see page 328 of Deep Into >> Pharo to see what I mean). Is this true? > > > yes. > > >> why? >> > > because the blocks don't really exist. they have been optimized away and > the control flow implemented using conditional branches and jumps instead > of closures and polymorphism. Hence there is no other scope to hold > temps > in other than the method context (or the block context of a block > containing optimized blocks). > > But realise that the remote temp vector is *only* used for variables that > are referred to from more than one full scope (method or unoptimized > block) > that can change value after they have been closed-over. If a variable is > closed over but doesn't change then its value is copied into the block, > and > ends up in a temporary slot in the block's activation, not in the > indirection vector. > > > >> Thanks in advance, >> >> Bests, >> >> Jordi >> ------------------------------------------------ >> >> PS: >> Now, to put that question in context, here comes a really long "rest of >> the message" part. >> >> We assume we have Continuation class >> #callcc: implemented as: >> callcc: aBlock >> ^ Continuation currentDo: aBlock >> (#callcc: can be found in ContinuationTests, but I prefer to change >> its location. It does not matter at all where it is). >> >> A version of whileTrue: can be implemented with callcc: and no >> iterative constructs, let's call it BlockClosure >> #whileTrueCC: >> whileTrueCC: aBlock >> | cont | >> cont := Continuation callcc: [ :cc | cc ]. >> self value ifTrue: [ aBlock value. >> cont value: cont] >> ifFalse: [^ nil]. >> >> and you can use it in the same way as #whileTrue:, for example: >> | n | >> n := 10. >> [ n > 0 ] whileTrueCC: [ >> Transcript show: n asString; cr. >> n := n-1 ] >> >> I observed some strange behavior dealing with local variables and >> continuations. Assume we have: >> >> Version 1) >> whileTrueCC: aBlock >> | cont tmp | >> tmp := 0. >> cont := Continuation callcc: [ :cc | cc ]. >> self value ifTrue: [ aBlock value. >> Transcript show: 'inside whileTrueCC: -> ', >> tmp >> asString; cr. >> tmp := tmp + 1. >> cont value: cont] >> ifFalse: [^ nil]. >> >> Version 2) >> whileTrueCC: aBlock >> | cont tmp | >> tmp := 0. >> [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does >> nothing, apparently" >> cont := Continuation callcc: [ :cc | cc ]. >> self value ifTrue: [ aBlock value. >> Transcript show: 'inside whileTrueCC: -> ', >> tmp >> asString; cr. >> tmp := tmp + 1. >> cont value: cont] >> ifFalse: [^ nil]. >> >> I try both versions with: >> | n | >> n := 4. >> [ n > 0 ] whileTrueCC: [ n := n-1 ] >> >> Version 1: >> It writes in the Transcript: >> inside whileTrueCC: -> 0 >> inside whileTrueCC: -> 0 >> inside whileTrueCC: -> 0 >> inside whileTrueCC: -> 0 >> >> Version 2: >> It writes in the Transcript: >> inside whileTrueCC: -> 0 >> inside whileTrueCC: -> 1 >> inside whileTrueCC: -> 2 >> inside whileTrueCC: -> 3 >> >> Which is ok, according to what I understood from Deep Into Pharo. The >> thing is, why the ifTrue: block does not make tmp behave as when we >> close >> it with '[ tmp ]' in version 2? >> > > See above. The compiler is not smart enough to realise that the value of > [tmp] is discarded, so it thinks there is a block created that closed over > tmp which may be evaluated at any time (because it could get assigned to a > variable and used later). So tmp is modified *after* it has been closed > over (in the while block) and hence the compiler puts it in a temp vector. > > > PS 2: The behavior is *exactly* the same in Version 2 if I close tmp >> *after* grabbing the continuation, that is, if I go >> cont := Continuation callcc: [ :cc | cc ]. >> [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does >> nothing, apparently" >> instead of >> [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does >> nothing, apparently" >> cont := Continuation callcc: [ :cc | cc ]. >> > > > -- > best, > Eliot >

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Eliot Miranda

On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman <btc(a)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 > > 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

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Ben Coman

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 > 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 ??? cheers -ben

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Ben Coman

Holger Hans Peter Freyther wrote: > On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote: > > Good Evening, > >> I have a report that it doesn't work on a linux desktop either. So at least there is one case where it does not work in a non-virtualized environment. Maybe interesting: >> >> root@2d-misc:/opt/mock-server# time pharo-vm-nox ./Pharo.image eval "(Delay forSeconds: 5) wait. (Delay forSeconds: 10) wait" >> a Delay(10000 msecs) > > > yes the first delay seems to fail. I have some holes in my > analysis but so far I see: > > Process A > (Delay forSeconds: 5) wait > Delay class >> scheduleDelay > aDelay resumptionTime: 5622 > > Process B > Delay class >> handleTimerEvent is being executed > "Check for clock wrap-around." > nowTick := Time millisecondClockValue. > nowTick < ActiveDelayStartTime ifTrue: [ > "clock wrapped" > ... > self restoreResumptionTimes > > Delay class >> restoreResumptionTimes > mydelay adjustResumptiomTimeOldBase: > mydelay's resumptionTime is now negative. > but the time base hasn't been changed > as the Delay was started _after_ the > image has been resumed (or at least while > it is being resumed). > > ... nowTick >= ActiveDelay resumptionTime ifTrue: [ > ActiveDelay signalWaitingProcess. > > > > What I notice is that: > > restoreResumptionTimes > "Private! Restore the resumption times of all scheduled Delays after a snapshot or clock roll-over. This method should be called only while the AccessProtect semaphore is held." > > But handleTimerEvent doesn't seem to use AccessProtect. The comment > and implementation appear to be not consistent. > > holger > > > #handleTimerEvent runs in the highest priority process at TimingPriority=80. The AccessProtect mutex is about controlling how multiple lower priority processes poke instances of Delay into the ScheduledDelay and FinishedDelay variables for #handleTimerEvent to process (being invoked by signaling TimingSempahore from within the AccessProtect). However restoreResumptionTimes is also called from #startUp by low priority processes and that is probably when AccessProtect is required. However2, I am working on an alternative implementation to use Semaphores rather than the AccessProtect mutex, which should bypass your concern. It should be ready for review early next week. cheers -ben

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Holger Hans Peter Freyther

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? 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

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Holger Hans Peter Freyther

On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote: Good Evening, > I have a report that it doesn't work on a linux desktop either. So at least there is one case where it does not work in a non-virtualized environment. Maybe interesting: > > root@2d-misc:/opt/mock-server# time pharo-vm-nox ./Pharo.image eval "(Delay forSeconds: 5) wait. (Delay forSeconds: 10) wait" > a Delay(10000 msecs) yes the first delay seems to fail. I have some holes in my analysis but so far I see: Process A (Delay forSeconds: 5) wait Delay class >> scheduleDelay aDelay resumptionTime: 5622 Process B Delay class >> handleTimerEvent is being executed "Check for clock wrap-around." nowTick := Time millisecondClockValue. nowTick < ActiveDelayStartTime ifTrue: [ "clock wrapped" ... self restoreResumptionTimes Delay class >> restoreResumptionTimes mydelay adjustResumptiomTimeOldBase: mydelay's resumptionTime is now negative. but the time base hasn't been changed as the Delay was started _after_ the image has been resumed (or at least while it is being resumed). ... nowTick >= ActiveDelay resumptionTime ifTrue: [ ActiveDelay signalWaitingProcess. What I notice is that: restoreResumptionTimes "Private! Restore the resumption times of all scheduled Delays after a snapshot or clock roll-over. This method should be called only while the AccessProtect semaphore is held." But handleTimerEvent doesn't seem to use AccessProtect. The comment and implementation appear to be not consistent. holger

Oct. 29, 2014

Re: [Pharo-dev] Question

by Eliot Miranda

On Wed, Oct 29, 2014 at 9:48 AM, <jdelgado(a)lsi.upc.edu> wrote: > Hi all, > > ------------------------------------------------ > My question is: > One thing I've observed is that local/temporal variables in the blocks > passed to #ifTrue:iFfalse are not stored in the separate remote (heap > allocated) array, but in the method context (see page 328 of Deep Into > Pharo to see what I mean). Is this true? yes. > why? > because the blocks don't really exist. they have been optimized away and the control flow implemented using conditional branches and jumps instead of closures and polymorphism. Hence there is no other scope to hold temps in other than the method context (or the block context of a block containing optimized blocks). But realise that the remote temp vector is *only* used for variables that are referred to from more than one full scope (method or unoptimized block) that can change value after they have been closed-over. If a variable is closed over but doesn't change then its value is copied into the block, and ends up in a temporary slot in the block's activation, not in the indirection vector. > Thanks in advance, > > Bests, > > Jordi > ------------------------------------------------ > > PS: > Now, to put that question in context, here comes a really long "rest of > the message" part. > > We assume we have Continuation class >> #callcc: implemented as: > callcc: aBlock > ^ Continuation currentDo: aBlock > (#callcc: can be found in ContinuationTests, but I prefer to change > its location. It does not matter at all where it is). > > A version of whileTrue: can be implemented with callcc: and no > iterative constructs, let's call it BlockClosure >> #whileTrueCC: > whileTrueCC: aBlock > | cont | > cont := Continuation callcc: [ :cc | cc ]. > self value ifTrue: [ aBlock value. > cont value: cont] > ifFalse: [^ nil]. > > and you can use it in the same way as #whileTrue:, for example: > | n | > n := 10. > [ n > 0 ] whileTrueCC: [ > Transcript show: n asString; cr. > n := n-1 ] > > I observed some strange behavior dealing with local variables and > continuations. Assume we have: > > Version 1) > whileTrueCC: aBlock > | cont tmp | > tmp := 0. > cont := Continuation callcc: [ :cc | cc ]. > self value ifTrue: [ aBlock value. > Transcript show: 'inside whileTrueCC: -> ', tmp > asString; cr. > tmp := tmp + 1. > cont value: cont] > ifFalse: [^ nil]. > > Version 2) > whileTrueCC: aBlock > | cont tmp | > tmp := 0. > [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does > nothing, apparently" > cont := Continuation callcc: [ :cc | cc ]. > self value ifTrue: [ aBlock value. > Transcript show: 'inside whileTrueCC: -> ', tmp > asString; cr. > tmp := tmp + 1. > cont value: cont] > ifFalse: [^ nil]. > > I try both versions with: > | n | > n := 4. > [ n > 0 ] whileTrueCC: [ n := n-1 ] > > Version 1: > It writes in the Transcript: > inside whileTrueCC: -> 0 > inside whileTrueCC: -> 0 > inside whileTrueCC: -> 0 > inside whileTrueCC: -> 0 > > Version 2: > It writes in the Transcript: > inside whileTrueCC: -> 0 > inside whileTrueCC: -> 1 > inside whileTrueCC: -> 2 > inside whileTrueCC: -> 3 > > Which is ok, according to what I understood from Deep Into Pharo. The > thing is, why the ifTrue: block does not make tmp behave as when we close > it with '[ tmp ]' in version 2? > See above. The compiler is not smart enough to realise that the value of [tmp] is discarded, so it thinks there is a block created that closed over tmp which may be evaluated at any time (because it could get assigned to a variable and used later). So tmp is modified *after* it has been closed over (in the while block) and hence the compiler puts it in a temp vector. PS 2: The behavior is *exactly* the same in Version 2 if I close tmp > *after* grabbing the continuation, that is, if I go > cont := Continuation callcc: [ :cc | cc ]. > [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does > nothing, apparently" > instead of > [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does > nothing, apparently" > cont := Continuation callcc: [ :cc | cc ]. > -- best, Eliot

Oct. 29, 2014

Re: [Pharo-dev] **Important** PharoDays Preparation

by phil＠highoctane.be

? Le 29 oct. 2014 17:43, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > > On 29 Oct 2014, at 17:36, phil(a)highoctane.be wrote: > > > > I am in. > > > > Phil > > You should, because you are on 3 of the pictures that I used on the web > page in progress ;-) > > > Le 29 oct. 2014 11:47, "stepharo" <stepharo(a)free.fr> a Ã©crit : > > Hi guys > > > > We will organize at Lille the 29 and 30 of January PharoDays. > > Now to help us building a budget I would like to know if you already > know that you plan to attend the conference. > > Could you fill up the doodle > > > > http://doodle.com/icxtazwfq76caxf8 > > > > Stef > > > > >

Oct. 29, 2014

Question

by jdelgado＠lsi.upc.edu

Hi all, ------------------------------------------------ My question is: One thing I've observed is that local/temporal variables in the blocks passed to #ifTrue:iFfalse are not stored in the separate remote (heap allocated) array, but in the method context (see page 328 of Deep Into Pharo to see what I mean). Is this true? why? Thanks in advance, Bests, Jordi ------------------------------------------------ PS: Now, to put that question in context, here comes a really long "rest of the message" part. We assume we have Continuation class >> #callcc: implemented as: callcc: aBlock ^ Continuation currentDo: aBlock (#callcc: can be found in ContinuationTests, but I prefer to change its location. It does not matter at all where it is). A version of whileTrue: can be implemented with callcc: and no iterative constructs, let's call it BlockClosure >> #whileTrueCC: whileTrueCC: aBlock | cont | cont := Continuation callcc: [ :cc | cc ]. self value ifTrue: [ aBlock value. cont value: cont] ifFalse: [^ nil]. and you can use it in the same way as #whileTrue:, for example: | n | n := 10. [ n > 0 ] whileTrueCC: [ Transcript show: n asString; cr. n := n-1 ] I observed some strange behavior dealing with local variables and continuations. Assume we have: Version 1) whileTrueCC: aBlock | cont tmp | tmp := 0. cont := Continuation callcc: [ :cc | cc ]. self value ifTrue: [ aBlock value. Transcript show: 'inside whileTrueCC: -> ', tmp asString; cr. tmp := tmp + 1. cont value: cont] ifFalse: [^ nil]. Version 2) whileTrueCC: aBlock | cont tmp | tmp := 0. [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does nothing, apparently" cont := Continuation callcc: [ :cc | cc ]. self value ifTrue: [ aBlock value. Transcript show: 'inside whileTrueCC: -> ', tmp asString; cr. tmp := tmp + 1. cont value: cont] ifFalse: [^ nil]. I try both versions with: | n | n := 4. [ n > 0 ] whileTrueCC: [ n := n-1 ] Version 1: It writes in the Transcript: inside whileTrueCC: -> 0 inside whileTrueCC: -> 0 inside whileTrueCC: -> 0 inside whileTrueCC: -> 0 Version 2: It writes in the Transcript: inside whileTrueCC: -> 0 inside whileTrueCC: -> 1 inside whileTrueCC: -> 2 inside whileTrueCC: -> 3 Which is ok, according to what I understood from Deep Into Pharo. The thing is, why the ifTrue: block does not make tmp behave as when we close it with '[ tmp ]' in version 2? PS 2: The behavior is *exactly* the same in Version 2 if I close tmp *after* grabbing the continuation, that is, if I go cont := Continuation callcc: [ :cc | cc ]. [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does nothing, apparently" instead of [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does nothing, apparently" cont := Continuation callcc: [ :cc | cc ].

Oct. 29, 2014

Re: [Pharo-dev] **Important** PharoDays Preparation

by Sven Van Caekenberghe

> On 29 Oct 2014, at 17:36, phil(a)highoctane.be wrote: > > I am in. > > Phil You should, because you are on 3 of the pictures that I used on the web page in progress ;-) > Le 29 oct. 2014 11:47, "stepharo" <stepharo(a)free.fr> a Ã©crit : > Hi guys > > We will organize at Lille the 29 and 30 of January PharoDays. > Now to help us building a budget I would like to know if you already know that you plan to attend the conference. > Could you fill up the doodle > > http://doodle.com/icxtazwfq76caxf8 > > Stef >

Oct. 29, 2014