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

Re: [Pharo-dev] Animation by Stepping

by phil＠highoctane.be

Rick, What OS are you using TUIO/OSC on? If you do iPad stuff, you do not need that as the iOS VM and image can support touch. Phil On Thu, Feb 20, 2014 at 6:51 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Interesting topic, there is also this > > http://www.smalltalkhub.com/#!/~vmariano/Pegasus > > but I have not used it so I cant say how usable it is. > > > On Thu, Feb 20, 2014 at 7:46 PM, J.F. Rick <self(a)je77.com> wrote: > >> Thanks for that. Based on that, I investigated a bit further. It seems to >> be a touch UI problem. I'm using TUIO to read touch events. When doing >> animations, the OSC process (at user background priority) fails to trigger. >> I need to change how I use the OSCServer. >> >> Cheers, >> >> Jeff >> >> >> On Thu, Feb 20, 2014 at 5:48 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >> >>> I've done such a kind of app (without Athens but with Morphic) on the >>> iPad. >>> >>> I works nicely. >>> >>> Now, MorphicUIManager>>spawnNewProcess tells us: >>> >>> spawnNewProcess >>> >>> UIProcess := [ >>> [World doOneCycle. Processor yield. false] whileFalse: []. >>> ] newProcess priority: Processor userSchedulingPriority. >>> UIProcess name: 'Morphic UI process'. >>> UIProcess resume >>> >>> >>> So, World doOneCycle forever. >>> >>> World being a PasteUpMorph >>> >>> then we enter this ping pong of double dispatches in the the doOneCycle >>> (I think this could be utterly simplified but hey, it takes courage to go >>> in there. I've got my own scribbled map but it would take quite a while to >>> change things. Add to that that Stef and Igor appear to be working on some >>> event internals so that all of the previous knowledge will be moot...) >>> >>> >>> PasteUpMorph>>doOneCycle >>> worldState doOneCycleFor: self >>> >>> with worldState being a WorldState >>> >>> at one point, the worldState will call the World>>drawOn: aCanvas >>> >>> Which happens under: >>> >>> WorldState>>doOneCycleNowFor: aWorld >>> "Immediately do one cycle of the interaction loop. >>> This should not be called directly, but only via doOneCycleFor:" >>> >>> DisplayScreen checkForNewScreenSize. >>> >>> "process user input events" >>> LastCycleTime := Time millisecondClockValue. >>> self handsDo: [:h | >>> ActiveHand := h. >>> h processEvents. >>> ActiveHand := nil >>> ]. >>> >>> "the default is the primary hand" >>> ActiveHand := self hands first. >>> >>> aWorld runStepMethods. "there are currently some variations here" >>> self displayWorldSafely: aWorld. >>> >>> runStepMethods call into the runLocalStepMethodsIn: aWorld >>> >>> where all kinds of old things show up (like priorWorld where we do not >>> have that anymore, as we only have one nowÃ . >>> >>> and where the stepList is also processed and this: >>> >>> (now < lastStepTime or: [now - lastStepTime > 5000]) >>> ifTrue: [self adjustWakeupTimes: now]. "clock slipped" >>> >>> takes place (I wonder why, someone can explain?) >>> >>> And if the stepList isn't empty, it will go through all step methods: >>> >>> [stepList isEmpty not and: [stepList first scheduledTime < now]] >>> whileTrue: >>> [lastStepMessage := stepList removeFirst. >>> morphToStep := lastStepMessage receiver. >>> (morphToStep shouldGetStepsFrom: aWorld) >>> ifTrue: >>> [lastStepMessage value: now. >>> lastStepMessage ifNotNil: >>> [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime]. >>> lastStepMessage scheduledTime: now + (stepTime max: 1). >>> stepList add: lastStepMessage]]. >>> lastStepMessage := nil]. >>> lastStepTime := now. >>> >>> >>> Ah, now + (stepTime max: 1)... guess that zero will not cut it then. >>> Minimum stepTime will at least be one. >>> >>> This explains that I guess. >>> >>> The Squeak 4.3 doOneCycleNowFor: aWorld is more or less similar (it has >>> a capturingGesture thing but without effect). >>> >>> And the stepTime has also the max:1 thing. >>> >>> runLocalStepMethodsIn: aWorld >>> "Run morph 'step' methods (LOCAL TO THIS WORLD) whose time has come. >>> Purge any morphs that are no longer in this world. >>> ar 3/13/1999: Remove buggy morphs from the step list so that they >>> don't raise repeated errors." >>> >>> | now morphToStep stepTime priorWorld | >>> now := Time millisecondClockValue. >>> priorWorld := ActiveWorld. >>> ActiveWorld := aWorld. >>> self triggerAlarmsBefore: now. >>> stepList isEmpty >>> ifTrue: >>> [ActiveWorld := priorWorld. >>> ^self]. >>> (now < lastStepTime or: [now - lastStepTime > 5000]) >>> ifTrue: [self adjustWakeupTimes: now]. "clock slipped" >>> [stepList isEmpty not and: [stepList first scheduledTime < now]] >>> whileTrue: >>> [lastStepMessage := stepList removeFirst. >>> morphToStep := lastStepMessage receiver. >>> (morphToStep shouldGetStepsFrom: aWorld) >>> ifTrue: >>> [lastStepMessage value: now. >>> lastStepMessage ifNotNil: >>> [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime]. >>> lastStepMessage scheduledTime: now + (stepTime max: 1). >>> stepList add: lastStepMessage]]. >>> lastStepMessage := nil]. >>> lastStepTime := now. >>> ActiveWorld := priorWorld >>> >>> >>> So, I wonder why it would be different in Squeak. >>> >>> HTH >>> >>> Phil >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Feb 20, 2014 at 5:16 PM, J.F. Rick <self(a)je77.com> wrote: >>> >>>> Athens graphics are fast enough that it is possible to do high >>>> frame-rate animations. I've been trying (and, to various degrees, >>>> succeeding) in adding animations to my touch applications. I'm using >>>> stepping to do it. Basically, you just move pieces / update the display >>>> when step gets called. If you set the stepTime to 30, you should get >>>> somewhere around 30 frames per second, which is quite smooth. >>>> >>>> The problem I have is that the step mechanism in Pharo seems to block >>>> out the UI thread. In Squeak, you could return 0 for the stepTime message >>>> and then step would get called each UI cycle. In Pharo, the two seem to be >>>> disconnected. If the stepTime is too low, the processor will be busy doing >>>> redrawing and the UI loop is stopped. When I do stepTime of 20, the UI >>>> stops responding until after the animation is over. When I do stepTime of >>>> 50, the UI keeps working. The lower the stepTime, the smoother the >>>> animation, but also the chance that the UI becomes unresponsive. That's a >>>> nasty tradeoff. Is there a good way to do step style animation without this >>>> tradeoff? Why was stepping and the UI loop separated? Is there a different >>>> way that animation should be implemented? >>>> >>>> Cheers, >>>> >>>> Jeff >>>> >>>> -- >>>> Jochen "Jeff" Rick, Ph.D. >>>> http://www.je77.com/ >>>> Skype ID: jochenrick >>>> >>> >>> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > >

Feb. 20, 2014

Re: [Pharo-dev] Animation by Stepping

by kilon alios

Interesting topic, there is also this http://www.smalltalkhub.com/#!/~vmariano/Pegasus but I have not used it so I cant say how usable it is. On Thu, Feb 20, 2014 at 7:46 PM, J.F. Rick <self(a)je77.com> wrote: > Thanks for that. Based on that, I investigated a bit further. It seems to > be a touch UI problem. I'm using TUIO to read touch events. When doing > animations, the OSC process (at user background priority) fails to trigger. > I need to change how I use the OSCServer. > > Cheers, > > Jeff > > > On Thu, Feb 20, 2014 at 5:48 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> I've done such a kind of app (without Athens but with Morphic) on the >> iPad. >> >> I works nicely. >> >> Now, MorphicUIManager>>spawnNewProcess tells us: >> >> spawnNewProcess >> >> UIProcess := [ >> [World doOneCycle. Processor yield. false] whileFalse: []. >> ] newProcess priority: Processor userSchedulingPriority. >> UIProcess name: 'Morphic UI process'. >> UIProcess resume >> >> >> So, World doOneCycle forever. >> >> World being a PasteUpMorph >> >> then we enter this ping pong of double dispatches in the the doOneCycle >> (I think this could be utterly simplified but hey, it takes courage to go >> in there. I've got my own scribbled map but it would take quite a while to >> change things. Add to that that Stef and Igor appear to be working on some >> event internals so that all of the previous knowledge will be moot...) >> >> >> PasteUpMorph>>doOneCycle >> worldState doOneCycleFor: self >> >> with worldState being a WorldState >> >> at one point, the worldState will call the World>>drawOn: aCanvas >> >> Which happens under: >> >> WorldState>>doOneCycleNowFor: aWorld >> "Immediately do one cycle of the interaction loop. >> This should not be called directly, but only via doOneCycleFor:" >> >> DisplayScreen checkForNewScreenSize. >> >> "process user input events" >> LastCycleTime := Time millisecondClockValue. >> self handsDo: [:h | >> ActiveHand := h. >> h processEvents. >> ActiveHand := nil >> ]. >> >> "the default is the primary hand" >> ActiveHand := self hands first. >> >> aWorld runStepMethods. "there are currently some variations here" >> self displayWorldSafely: aWorld. >> >> runStepMethods call into the runLocalStepMethodsIn: aWorld >> >> where all kinds of old things show up (like priorWorld where we do not >> have that anymore, as we only have one nowÃ . >> >> and where the stepList is also processed and this: >> >> (now < lastStepTime or: [now - lastStepTime > 5000]) >> ifTrue: [self adjustWakeupTimes: now]. "clock slipped" >> >> takes place (I wonder why, someone can explain?) >> >> And if the stepList isn't empty, it will go through all step methods: >> >> [stepList isEmpty not and: [stepList first scheduledTime < now]] >> whileTrue: >> [lastStepMessage := stepList removeFirst. >> morphToStep := lastStepMessage receiver. >> (morphToStep shouldGetStepsFrom: aWorld) >> ifTrue: >> [lastStepMessage value: now. >> lastStepMessage ifNotNil: >> [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime]. >> lastStepMessage scheduledTime: now + (stepTime max: 1). >> stepList add: lastStepMessage]]. >> lastStepMessage := nil]. >> lastStepTime := now. >> >> >> Ah, now + (stepTime max: 1)... guess that zero will not cut it then. >> Minimum stepTime will at least be one. >> >> This explains that I guess. >> >> The Squeak 4.3 doOneCycleNowFor: aWorld is more or less similar (it has a >> capturingGesture thing but without effect). >> >> And the stepTime has also the max:1 thing. >> >> runLocalStepMethodsIn: aWorld >> "Run morph 'step' methods (LOCAL TO THIS WORLD) whose time has come. >> Purge any morphs that are no longer in this world. >> ar 3/13/1999: Remove buggy morphs from the step list so that they don't >> raise repeated errors." >> >> | now morphToStep stepTime priorWorld | >> now := Time millisecondClockValue. >> priorWorld := ActiveWorld. >> ActiveWorld := aWorld. >> self triggerAlarmsBefore: now. >> stepList isEmpty >> ifTrue: >> [ActiveWorld := priorWorld. >> ^self]. >> (now < lastStepTime or: [now - lastStepTime > 5000]) >> ifTrue: [self adjustWakeupTimes: now]. "clock slipped" >> [stepList isEmpty not and: [stepList first scheduledTime < now]] >> whileTrue: >> [lastStepMessage := stepList removeFirst. >> morphToStep := lastStepMessage receiver. >> (morphToStep shouldGetStepsFrom: aWorld) >> ifTrue: >> [lastStepMessage value: now. >> lastStepMessage ifNotNil: >> [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime]. >> lastStepMessage scheduledTime: now + (stepTime max: 1). >> stepList add: lastStepMessage]]. >> lastStepMessage := nil]. >> lastStepTime := now. >> ActiveWorld := priorWorld >> >> >> So, I wonder why it would be different in Squeak. >> >> HTH >> >> Phil >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Feb 20, 2014 at 5:16 PM, J.F. Rick <self(a)je77.com> wrote: >> >>> Athens graphics are fast enough that it is possible to do high >>> frame-rate animations. I've been trying (and, to various degrees, >>> succeeding) in adding animations to my touch applications. I'm using >>> stepping to do it. Basically, you just move pieces / update the display >>> when step gets called. If you set the stepTime to 30, you should get >>> somewhere around 30 frames per second, which is quite smooth. >>> >>> The problem I have is that the step mechanism in Pharo seems to block >>> out the UI thread. In Squeak, you could return 0 for the stepTime message >>> and then step would get called each UI cycle. In Pharo, the two seem to be >>> disconnected. If the stepTime is too low, the processor will be busy doing >>> redrawing and the UI loop is stopped. When I do stepTime of 20, the UI >>> stops responding until after the animation is over. When I do stepTime of >>> 50, the UI keeps working. The lower the stepTime, the smoother the >>> animation, but also the chance that the UI becomes unresponsive. That's a >>> nasty tradeoff. Is there a good way to do step style animation without this >>> tradeoff? Why was stepping and the UI loop separated? Is there a different >>> way that animation should be implemented? >>> >>> Cheers, >>> >>> Jeff >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick >

Feb. 20, 2014

Re: [Pharo-dev] Animation by Stepping

by J.F. Rick

Thanks for that. Based on that, I investigated a bit further. It seems to be a touch UI problem. I'm using TUIO to read touch events. When doing animations, the OSC process (at user background priority) fails to trigger. I need to change how I use the OSCServer. Cheers, Jeff On Thu, Feb 20, 2014 at 5:48 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > I've done such a kind of app (without Athens but with Morphic) on the iPad. > > I works nicely. > > Now, MorphicUIManager>>spawnNewProcess tells us: > > spawnNewProcess > > UIProcess := [ > [World doOneCycle. Processor yield. false] whileFalse: []. > ] newProcess priority: Processor userSchedulingPriority. > UIProcess name: 'Morphic UI process'. > UIProcess resume > > > So, World doOneCycle forever. > > World being a PasteUpMorph > > then we enter this ping pong of double dispatches in the the doOneCycle (I > think this could be utterly simplified but hey, it takes courage to go in > there. I've got my own scribbled map but it would take quite a while to > change things. Add to that that Stef and Igor appear to be working on some > event internals so that all of the previous knowledge will be moot...) > > > PasteUpMorph>>doOneCycle > worldState doOneCycleFor: self > > with worldState being a WorldState > > at one point, the worldState will call the World>>drawOn: aCanvas > > Which happens under: > > WorldState>>doOneCycleNowFor: aWorld > "Immediately do one cycle of the interaction loop. > This should not be called directly, but only via doOneCycleFor:" > > DisplayScreen checkForNewScreenSize. > > "process user input events" > LastCycleTime := Time millisecondClockValue. > self handsDo: [:h | > ActiveHand := h. > h processEvents. > ActiveHand := nil > ]. > > "the default is the primary hand" > ActiveHand := self hands first. > > aWorld runStepMethods. "there are currently some variations here" > self displayWorldSafely: aWorld. > > runStepMethods call into the runLocalStepMethodsIn: aWorld > > where all kinds of old things show up (like priorWorld where we do not > have that anymore, as we only have one nowÃ . > > and where the stepList is also processed and this: > > (now < lastStepTime or: [now - lastStepTime > 5000]) > ifTrue: [self adjustWakeupTimes: now]. "clock slipped" > > takes place (I wonder why, someone can explain?) > > And if the stepList isn't empty, it will go through all step methods: > > [stepList isEmpty not and: [stepList first scheduledTime < now]] > whileTrue: > [lastStepMessage := stepList removeFirst. > morphToStep := lastStepMessage receiver. > (morphToStep shouldGetStepsFrom: aWorld) > ifTrue: > [lastStepMessage value: now. > lastStepMessage ifNotNil: > [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime]. > lastStepMessage scheduledTime: now + (stepTime max: 1). > stepList add: lastStepMessage]]. > lastStepMessage := nil]. > lastStepTime := now. > > > Ah, now + (stepTime max: 1)... guess that zero will not cut it then. > Minimum stepTime will at least be one. > > This explains that I guess. > > The Squeak 4.3 doOneCycleNowFor: aWorld is more or less similar (it has a > capturingGesture thing but without effect). > > And the stepTime has also the max:1 thing. > > runLocalStepMethodsIn: aWorld > "Run morph 'step' methods (LOCAL TO THIS WORLD) whose time has come. Purge > any morphs that are no longer in this world. > ar 3/13/1999: Remove buggy morphs from the step list so that they don't > raise repeated errors." > > | now morphToStep stepTime priorWorld | > now := Time millisecondClockValue. > priorWorld := ActiveWorld. > ActiveWorld := aWorld. > self triggerAlarmsBefore: now. > stepList isEmpty > ifTrue: > [ActiveWorld := priorWorld. > ^self]. > (now < lastStepTime or: [now - lastStepTime > 5000]) > ifTrue: [self adjustWakeupTimes: now]. "clock slipped" > [stepList isEmpty not and: [stepList first scheduledTime < now]] > whileTrue: > [lastStepMessage := stepList removeFirst. > morphToStep := lastStepMessage receiver. > (morphToStep shouldGetStepsFrom: aWorld) > ifTrue: > [lastStepMessage value: now. > lastStepMessage ifNotNil: > [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime]. > lastStepMessage scheduledTime: now + (stepTime max: 1). > stepList add: lastStepMessage]]. > lastStepMessage := nil]. > lastStepTime := now. > ActiveWorld := priorWorld > > > So, I wonder why it would be different in Squeak. > > HTH > > Phil > > > > > > > > > > > > > > > > > > > > On Thu, Feb 20, 2014 at 5:16 PM, J.F. Rick <self(a)je77.com> wrote: > >> Athens graphics are fast enough that it is possible to do high frame-rate >> animations. I've been trying (and, to various degrees, succeeding) in >> adding animations to my touch applications. I'm using stepping to do it. >> Basically, you just move pieces / update the display when step gets called. >> If you set the stepTime to 30, you should get somewhere around 30 frames >> per second, which is quite smooth. >> >> The problem I have is that the step mechanism in Pharo seems to block out >> the UI thread. In Squeak, you could return 0 for the stepTime message and >> then step would get called each UI cycle. In Pharo, the two seem to be >> disconnected. If the stepTime is too low, the processor will be busy doing >> redrawing and the UI loop is stopped. When I do stepTime of 20, the UI >> stops responding until after the animation is over. When I do stepTime of >> 50, the UI keeps working. The lower the stepTime, the smoother the >> animation, but also the chance that the UI becomes unresponsive. That's a >> nasty tradeoff. Is there a good way to do step style animation without this >> tradeoff? Why was stepping and the UI loop separated? Is there a different >> way that animation should be implemented? >> >> Cheers, >> >> Jeff >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Feb. 20, 2014

Re: [Pharo-dev] Animation by Stepping

by Alejandro Infante

I know that Roassal2 is purely based on Athens and have pretty smooth animations. Maybe you can ask them about it. Cheers, Alejandro 2014-02-20 8:55 GMT-08:00 <btc(a)openinworld.com>: > J.F. Rick wrote: > >> Athens graphics are fast enough that it is possible to do high frame-rate >> animations. I've been trying (and, to various degrees, succeeding) in >> adding animations to my touch applications. I'm using stepping to do it. >> Basically, you just move pieces / update the display when step gets called. >> If you set the stepTime to 30, you should get somewhere around 30 frames >> per second, which is quite smooth. >> >> The problem I have is that the step mechanism in Pharo seems to block out >> the UI thread. In Squeak, you could return 0 for the stepTime message and >> then step would get called each UI cycle. In Pharo, the two seem to be >> disconnected. If the stepTime is too low, the processor will be busy doing >> redrawing and the UI loop is stopped. When I do stepTime of 20, the UI >> stops responding until after the animation is over. When I do stepTime of >> 50, the UI keeps working. The lower the stepTime, the smoother the >> animation, but also the chance that the UI becomes unresponsive. That's a >> nasty tradeoff. Is there a good way to do step style animation without this >> tradeoff? Why was stepping and the UI loop separated? Is there a different >> way that animation should be implemented? >> >> Cheers, >> >> Jeff >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > What came out of > http://gsoc2013.esug.org/projects/athens-animation ? > > >

Feb. 20, 2014

[pharo-project/pharo-core]

by GitHub

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

Feb. 20, 2014

[pharo-project/pharo-core] 7d5ea1: 30775

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 7d5ea1b48b412302d1aa1b9c0d421b502cc606f8 https://github.com/pharo-project/pharo-core/commit/7d5ea1b48b412302d1aa1b9c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-02-20 (Thu, 20 Feb 2014) Changed paths: M Announcements-Tests-Core.package/AnnouncementSetTest.class/README.md M Announcements-Tests-Core.package/WeakAnnouncerTest.class/README.md M CollectionsTests.package/AssociationTest.class/README.md M CollectionsTests.package/BagTest.class/README.md M CollectionsTests.package/ByteArrayTest.class/README.md M CollectionsTests.package/ByteSymbolTest.class/README.md M CollectionsTests.package/DictionaryTest.class/README.md M CollectionsTests.package/FIFOQueueTests.class/README.md M CollectionsTests.package/GeneratorTest.class/README.md M CollectionsTests.package/HeapTest.class/README.md M CollectionsTests.package/IdentityBagTest.class/README.md M CollectionsTests.package/IdentityDictionaryTest.class/README.md M CollectionsTests.package/IdentitySetTest.class/README.md M CollectionsTests.package/IntegerArrayTest.class/README.md M CollectionsTests.package/IntervalTest.class/README.md M CollectionsTests.package/KeyedTreeTest.class/README.md M CollectionsTests.package/LIFOQueueTests.class/README.md M CollectionsTests.package/LiteralDictionaryTest.class/README.md M CollectionsTests.package/MatrixTest.class/README.md M CollectionsTests.package/PluggableDictionaryTest.class/README.md M CollectionsTests.package/PluggableSetTest.class/README.md M CollectionsTests.package/ReduceTest.class/README.md M CollectionsTests.package/SharedQueueTest.class/README.md M CollectionsTests.package/SmallDictionaryTest.class/README.md M CollectionsTests.package/SmallIdentityDictionaryTest.class/README.md M CollectionsTests.package/SortedCollectionTest.class/README.md M CollectionsTests.package/StackTest.class/README.md M CollectionsTests.package/TAddForIdentityCollectionsTest.class/README.md M CollectionsTests.package/TAddForUniquenessTest.class/README.md M CollectionsTests.package/TAddTest.class/README.md M CollectionsTests.package/TAsStringCommaAndDelimiterSequenceableTest.class/README.md M CollectionsTests.package/TAsStringCommaAndDelimiterTest.class/README.md M CollectionsTests.package/TBeginsEndsWith.class/README.md M CollectionsTests.package/TCloneTest.class/README.md M CollectionsTests.package/TConcatenationEqualElementsRemovedTest.class/README.md M CollectionsTests.package/TConcatenationTest.class/README.md M CollectionsTests.package/TConvertAsSetForMultiplinessIdentityTest.class/README.md M CollectionsTests.package/TConvertAsSetForMultiplinessTest.class/README.md M CollectionsTests.package/TConvertAsSortedTest.class/README.md M CollectionsTests.package/TConvertTest.class/README.md M CollectionsTests.package/TCopyPartOfSequenceable.class/README.md M CollectionsTests.package/TCopyPartOfSequenceableForMultipliness.class/README.md M CollectionsTests.package/TCopyPreservingIdentityTest.class/README.md M CollectionsTests.package/TCopySequenceableSameContents.class/README.md M CollectionsTests.package/TCopySequenceableWithOrWithoutSpecificElements.class/README.md M CollectionsTests.package/TCopySequenceableWithReplacement.class/README.md M CollectionsTests.package/TCopySequenceableWithReplacementForSorted.class/README.md M CollectionsTests.package/TCreationWithTest.class/README.md M CollectionsTests.package/TDictionaryAddingTest.class/README.md M CollectionsTests.package/TDictionaryAssociationAccessTest.class/README.md M CollectionsTests.package/TDictionaryComparingTest.class/README.md M CollectionsTests.package/TDictionaryCopyingTest.class/README.md M CollectionsTests.package/TDictionaryEnumeratingTest.class/README.md M CollectionsTests.package/TDictionaryImplementationTest.class/README.md M CollectionsTests.package/TDictionaryIncludesTest.class/README.md M CollectionsTests.package/TDictionaryIncludesWithIdentityCheckTest.class/README.md M CollectionsTests.package/TDictionaryKeyAccessTest.class/README.md M CollectionsTests.package/TDictionaryKeysValuesAssociationsAccess.class/README.md M CollectionsTests.package/TDictionaryPrintingTest.class/README.md M CollectionsTests.package/TDictionaryRemovingTest.class/README.md M CollectionsTests.package/TDictionaryValueAccessTest.class/README.md M CollectionsTests.package/TEmptySequenceableTest.class/README.md M CollectionsTests.package/TGrowableTest.class/README.md M CollectionsTests.package/TIdentityAddTest.class/README.md M CollectionsTests.package/TIncludesForIdentityCollectionsTest.class/README.md M CollectionsTests.package/TIncludesTest.class/README.md M CollectionsTests.package/TIncludesWithIdentityCheckTest.class/README.md M CollectionsTests.package/TIndexAccess.class/README.md M CollectionsTests.package/TIndexAccessForMultipliness.class/README.md M CollectionsTests.package/TIterateSequencedReadableTest.class/README.md M CollectionsTests.package/TOccurrencesForIdentityCollectionsTest.class/README.md M CollectionsTests.package/TOccurrencesForMultiplinessTest.class/README.md M CollectionsTests.package/TOccurrencesTest.class/README.md M CollectionsTests.package/TPrintOnSequencedTest.class/README.md M CollectionsTests.package/TPrintTest.class/README.md M CollectionsTests.package/TPutBasicTest.class/README.md M CollectionsTests.package/TPutTest.class/README.md M CollectionsTests.package/TRemoveByIndexTest.class/README.md M CollectionsTests.package/TRemoveForMultiplenessTest.class/README.md M CollectionsTests.package/TRemoveTest.class/README.md M CollectionsTests.package/TReplacementSequencedTest.class/README.md M CollectionsTests.package/TSequencedConcatenationTest.class/README.md M CollectionsTests.package/TSequencedElementAccessTest.class/README.md M CollectionsTests.package/TSequencedStructuralEqualityTest.class/README.md M CollectionsTests.package/TSetArithmetic.class/README.md M CollectionsTests.package/TSizeTest.class/README.md M CollectionsTests.package/TSortTest.class/README.md M CollectionsTests.package/TSubCollectionAccess.class/README.md M CollectionsTests.package/WeakFinalizersTest.class/README.md M CollectionsTests.package/WeakIdentityKeyDictionaryTest.class/README.md M CollectionsTests.package/WeakKeyDictionaryTest.class/README.md M CollectionsTests.package/WeakKeyToCollectionDictionaryTest.class/README.md M CollectionsTests.package/WeakOrderedCollectionTest.class/README.md M CollectionsTests.package/WeakRegistryTest.class/README.md M CollectionsTests.package/WeakSetTest.class/README.md M CollectionsTests.package/WeakValueDictionaryTest.class/README.md M CollectionsTests.package/WriteStreamTest.class/README.md M MonticelloConfigurations.package/MCMcmReader.class/README.md M MonticelloConfigurations.package/MCMcmWriter.class/README.md M MonticelloFileTree-Core.package/MCFileTreeAbstractReader.class/README.md M MonticelloFileTree-Core.package/MCFileTreeAbstractStWriter.class/README.md M MonticelloFileTree-Core.package/MCFileTreeFileUtils.class/README.md M MonticelloFileTree-Core.package/MCFileTreeJsonParser.class/README.md M MonticelloFileTree-Core.package/MCFileTreePackageStructureStWriter.class/README.md M MonticelloFileTree-Core.package/MCFileTreeRepository.class/README.md M MonticelloFileTree-Core.package/MCFileTreeStCypressReader.class/README.md M MonticelloFileTree-Core.package/MCFileTreeStCypressWriter.class/README.md M MonticelloFileTree-Core.package/MCFileTreeStReader.class/README.md M MonticelloFileTree-Core.package/MCFileTreeStSnapshotReader.class/README.md M MonticelloFileTree-Core.package/MCFileTreeStSnapshotWriter.class/README.md M MonticelloFileTree-Core.package/MCFileTreeStWriter.class/README.md M MonticelloFileTree-Core.package/MCFileTreeVersionInfoWriter.class/README.md M MonticelloFileTree-Core.package/MCFileTreeWriter.class/README.md M MonticelloFileTree-FileSystem-Utilities.package/MCFileTreeFileSystemUtils.class/README.md M MonticelloGUI.package/MCChangeSelector.class/README.md M MonticelloGUI.package/MCDependentsWrapper.class/README.md M MonticelloGUI.package/MCMergeBrowser.class/README.md M MonticelloGUI.package/MCPatchBrowser.class/README.md M MonticelloGUI.package/MCRepositoryInspector.class/README.md M MonticelloGUI.package/MCSliceInfo.class/README.md M MonticelloGUI.package/MCSnapshotBrowser.class/README.md M MonticelloGUI.package/MCTool.class/README.md M MonticelloGUI.package/MCVersionHistoryBrowser.class/README.md M MonticelloGUI.package/MCWorkingCopyBrowser.class/README.md M MonticelloGUI.package/MCWorkingHistoryBrowser.class/README.md A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script428.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30775.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/ComposableModel.class/class/defaults/buttonHeight.st M Spec-Core.package/ComposableModel.class/class/defaults/buttonWidth.st M Spec-Core.package/ComposableModel.class/class/defaults/inputTextHeight.st M Spec-Core.package/ComposableModel.class/class/defaults/toolbarHeight.st M Spec-Core.package/ComposableModel.class/instance/initialization/initialize.st M Spec-Core.package/ComposableModel.class/instance/protocol/aboutText.st A Spec-Core.package/MenuModel.class/class/specs/popup.st A Spec-Core.package/MenuModel.class/instance/protocol/buildWithSpecAsPopup.st M Spec-Core.package/MenuModel.class/instance/protocol/openWithSpecAt_.st M Spec-Core.package/TreeModel.class/instance/initialize/registerEvents.st A Spec-Core.package/WindowModel.class/instance/protocol/maximize.st A Spec-Core.package/WindowModel.class/instance/protocol/minimize.st A Spec-Core.package/extension/ToolDockingBarMorph/instance/adoptMenuGroupModel_first_.st A Spec-Core.package/extension/ToolDockingBarMorph/instance/adoptMenuItemModel_accumulator_.st A Spec-Core.package/extension/ToolDockingBarMorph/instance/adoptMenuModel_.st A Spec-Core.package/extension/ToolDockingBarMorph/instance/buildButtonFor_.st A Spec-Core.package/extension/ToolDockingBarMorph/instance/emptyAccumulator_.st M Spec-Debugger.package/SpecDebugger.class/class/specs/specOptimized.st A Spec-Examples.package/ApplicationWithToolbar.class/README.md A Spec-Examples.package/ApplicationWithToolbar.class/class/specs/defaultSpec.st A Spec-Examples.package/ApplicationWithToolbar.class/definition.st A Spec-Examples.package/ApplicationWithToolbar.class/instance/accessing/menu.st A Spec-Examples.package/ApplicationWithToolbar.class/instance/accessing/text.st A Spec-Examples.package/ApplicationWithToolbar.class/instance/initialization/initializeWidgets.st A Spec-Examples.package/ApplicationWithToolbar.class/instance/initialization/subMenu.st A Spec-Examples.package/ApplicationWithToolbar.class/instance/protocol/title.st A Spec-MorphicAdapters.package/MorphicMenuAdapter.class/class/instance creation/adaptAsPopup_.st M Spec-MorphicAdapters.package/MorphicMenuAdapter.class/class/specs/defaultSpec.st A Spec-MorphicAdapters.package/MorphicMenuAdapter.class/class/specs/popupSpec.st A Spec-MorphicAdapters.package/MorphicMenuAdapter.class/instance/initialization/adaptAsPopup_.st M Spec-MorphicAdapters.package/MorphicMenuAdapter.class/instance/private/buildWidget.st A Spec-MorphicAdapters.package/MorphicMenuAdapter.class/instance/private/buildWidgetPopup.st M Spec-MorphicAdapters.package/MorphicNewListAdapter.class/instance/widget API/getMenu_.st M Spec-MorphicAdapters.package/MorphicTreeAdapter.class/instance/widget API/menu_shifted_.st A Spec-MorphicAdapters.package/MorphicWindowAdapter.class/instance/spec protocol/maximize.st A Spec-MorphicAdapters.package/MorphicWindowAdapter.class/instance/spec protocol/minimize.st M Versionner-Core-Announcements.package/MBAnnouncement.class/README.md M Versionner-Core-Announcements.package/MBConfigurationInfoChanged.class/README.md M Versionner-Core-Announcements.package/MBConfigurationInfoCreated.class/README.md M Versionner-Core-Announcements.package/MBConfigurationInfoDeleted.class/README.md M Versionner-Core-Announcements.package/MBInfoListChanged.class/README.md M Versionner-Core-Commands.package/MBAddConfigurationCommand.class/README.md M Versionner-Core-Commands.package/MBAddRepositoryCommand.class/README.md M Versionner-Core-Commands.package/MBBrowsePackageCommand.class/README.md M Versionner-Core-Commands.package/MBCheckpointDevCommand.class/README.md M Versionner-Core-Commands.package/MBConfigurationChangesCommand.class/README.md M Versionner-Core-Commands.package/MBConfigurationInfoCommand.class/README.md M Versionner-Core-Commands.package/MBConfigurationPackageHistoryCommand.class/README.md M Versionner-Core-Commands.package/MBCopyBaselineCommand.class/README.md M Versionner-Core-Commands.package/MBDevCycleCommands.class/README.md M Versionner-Core-Commands.package/MBHelpCommand.class/README.md M Versionner-Core-Commands.package/MBInspectConfigurationCommand.class/README.md M Versionner-Core-Commands.package/MBLoadConfigurationCommand.class/README.md M Versionner-Core-Commands.package/MBLoadPackageCommand.class/README.md M Versionner-Core-Commands.package/MBLoadProjectFromArchiveCommand.class/README.md M Versionner-Core-Commands.package/MBPackageChangesCommand.class/README.md M Versionner-Core-Commands.package/MBPackageHistoryCommand.class/README.md M Versionner-Core-Commands.package/MBRevertPackageCommand.class/README.md M Versionner-Core-Commands.package/MBSaveConfigurationCommand.class/README.md M Versionner-Core-Commands.package/MBSavePackageCommand.class/README.md M Versionner-Core-Commands.package/MBSetUserCommand.class/README.md M Versionner-Core-Commands.package/MBValidateAllConfigurationCommand.class/README.md M Versionner-Core-Commands.package/MBVersionCommand.class/README.md M Versionner-Core-Model.package/MBAbstractVersionInfo.class/README.md M Versionner-Core-Model.package/MBInfo.class/README.md M Versionner-Core-Model.package/MBLabelInfo.class/README.md M Versionner-Core-Model.package/MBPackageInfo.class/README.md M Versionner-Core-Model.package/MBProjectInfo.class/README.md M Versionner-Core-Model.package/MBVersionInfo.class/README.md M Versionner-Tests-Core-Model.package/MBAbstractTest.class/README.md M Versionner-Tests-Core-Model.package/MBAbstractVersionInfoTest.class/README.md M Versionner-Tests-Core-Model.package/MBBaselineInfoTest.class/README.md M Versionner-Tests-Core-Model.package/MBConfigurationBranchTest.class/README.md M Versionner-Tests-Core-Model.package/MBConfigurationInfoTest.class/README.md M Versionner-Tests-Core-Model.package/MBConfigurationRootTest.class/README.md M Versionner-Tests-Core-Model.package/MBGroupInfoTest.class/README.md M Versionner-Tests-Core-Model.package/MBInfoTest.class/README.md M Versionner-Tests-Core-Model.package/MBPackageInfoTest.class/README.md M Versionner-Tests-Core-Model.package/MBSpecInfoTest.class/README.md M Versionner-Tests-Resources.package/MBMonticelloPackagesResource.class/README.md Log Message: ----------- 30775 12939 Class comments missing for Announcements-Tests package https://pharo.fogbugz.com/f/cases/12939 12928 Spec new update https://pharo.fogbugz.com/f/cases/12928 12937 Class comments missing in Versionner package https://pharo.fogbugz.com/f/cases/12937 12940 Class comments missing for CollectionsTests package https://pharo.fogbugz.com/f/cases/12940 12943 Class comments missing for Monticello- packages https://pharo.fogbugz.com/f/cases/12943 http://files.pharo.org/image/30/30775.zip

Feb. 20, 2014

Re: [Pharo-dev] Animation by Stepping

by btc＠openinworld.com

J.F. Rick wrote: > Athens graphics are fast enough that it is possible to do high > frame-rate animations. I've been trying (and, to various degrees, > succeeding) in adding animations to my touch applications. I'm using > stepping to do it. Basically, you just move pieces / update the > display when step gets called. If you set the stepTime to 30, you > should get somewhere around 30 frames per second, which is quite smooth. > > The problem I have is that the step mechanism in Pharo seems to block > out the UI thread. In Squeak, you could return 0 for the stepTime > message and then step would get called each UI cycle. In Pharo, the > two seem to be disconnected. If the stepTime is too low, the processor > will be busy doing redrawing and the UI loop is stopped. When I do > stepTime of 20, the UI stops responding until after the animation is > over. When I do stepTime of 50, the UI keeps working. The lower the > stepTime, the smoother the animation, but also the chance that the UI > becomes unresponsive. That's a nasty tradeoff. Is there a good way to > do step style animation without this tradeoff? Why was stepping and > the UI loop separated? Is there a different way that animation should > be implemented? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick What came out of http://gsoc2013.esug.org/projects/athens-animation ?

Feb. 20, 2014

Re: [Pharo-dev] Animation by Stepping

by phil＠highoctane.be

I've done such a kind of app (without Athens but with Morphic) on the iPad. I works nicely. Now, MorphicUIManager>>spawnNewProcess tells us: spawnNewProcess UIProcess := [ [World doOneCycle. Processor yield. false] whileFalse: []. ] newProcess priority: Processor userSchedulingPriority. UIProcess name: 'Morphic UI process'. UIProcess resume So, World doOneCycle forever. World being a PasteUpMorph then we enter this ping pong of double dispatches in the the doOneCycle (I think this could be utterly simplified but hey, it takes courage to go in there. I've got my own scribbled map but it would take quite a while to change things. Add to that that Stef and Igor appear to be working on some event internals so that all of the previous knowledge will be moot...) PasteUpMorph>>doOneCycle worldState doOneCycleFor: self with worldState being a WorldState at one point, the worldState will call the World>>drawOn: aCanvas Which happens under: WorldState>>doOneCycleNowFor: aWorld "Immediately do one cycle of the interaction loop. This should not be called directly, but only via doOneCycleFor:" DisplayScreen checkForNewScreenSize. "process user input events" LastCycleTime := Time millisecondClockValue. self handsDo: [:h | ActiveHand := h. h processEvents. ActiveHand := nil ]. "the default is the primary hand" ActiveHand := self hands first. aWorld runStepMethods. "there are currently some variations here" self displayWorldSafely: aWorld. runStepMethods call into the runLocalStepMethodsIn: aWorld where all kinds of old things show up (like priorWorld where we do not have that anymore, as we only have one nowÃ . and where the stepList is also processed and this: (now < lastStepTime or: [now - lastStepTime > 5000]) ifTrue: [self adjustWakeupTimes: now]. "clock slipped" takes place (I wonder why, someone can explain?) And if the stepList isn't empty, it will go through all step methods: [stepList isEmpty not and: [stepList first scheduledTime < now]] whileTrue: [lastStepMessage := stepList removeFirst. morphToStep := lastStepMessage receiver. (morphToStep shouldGetStepsFrom: aWorld) ifTrue: [lastStepMessage value: now. lastStepMessage ifNotNil: [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime]. lastStepMessage scheduledTime: now + (stepTime max: 1). stepList add: lastStepMessage]]. lastStepMessage := nil]. lastStepTime := now. Ah, now + (stepTime max: 1)... guess that zero will not cut it then. Minimum stepTime will at least be one. This explains that I guess. The Squeak 4.3 doOneCycleNowFor: aWorld is more or less similar (it has a capturingGesture thing but without effect). And the stepTime has also the max:1 thing. runLocalStepMethodsIn: aWorld "Run morph 'step' methods (LOCAL TO THIS WORLD) whose time has come. Purge any morphs that are no longer in this world. ar 3/13/1999: Remove buggy morphs from the step list so that they don't raise repeated errors." | now morphToStep stepTime priorWorld | now := Time millisecondClockValue. priorWorld := ActiveWorld. ActiveWorld := aWorld. self triggerAlarmsBefore: now. stepList isEmpty ifTrue: [ActiveWorld := priorWorld. ^self]. (now < lastStepTime or: [now - lastStepTime > 5000]) ifTrue: [self adjustWakeupTimes: now]. "clock slipped" [stepList isEmpty not and: [stepList first scheduledTime < now]] whileTrue: [lastStepMessage := stepList removeFirst. morphToStep := lastStepMessage receiver. (morphToStep shouldGetStepsFrom: aWorld) ifTrue: [lastStepMessage value: now. lastStepMessage ifNotNil: [stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime]. lastStepMessage scheduledTime: now + (stepTime max: 1). stepList add: lastStepMessage]]. lastStepMessage := nil]. lastStepTime := now. ActiveWorld := priorWorld So, I wonder why it would be different in Squeak. HTH Phil On Thu, Feb 20, 2014 at 5:16 PM, J.F. Rick <self(a)je77.com> wrote: > Athens graphics are fast enough that it is possible to do high frame-rate > animations. I've been trying (and, to various degrees, succeeding) in > adding animations to my touch applications. I'm using stepping to do it. > Basically, you just move pieces / update the display when step gets called. > If you set the stepTime to 30, you should get somewhere around 30 frames > per second, which is quite smooth. > > The problem I have is that the step mechanism in Pharo seems to block out > the UI thread. In Squeak, you could return 0 for the stepTime message and > then step would get called each UI cycle. In Pharo, the two seem to be > disconnected. If the stepTime is too low, the processor will be busy doing > redrawing and the UI loop is stopped. When I do stepTime of 20, the UI > stops responding until after the animation is over. When I do stepTime of > 50, the UI keeps working. The lower the stepTime, the smoother the > animation, but also the chance that the UI becomes unresponsive. That's a > nasty tradeoff. Is there a good way to do step style animation without this > tradeoff? Why was stepping and the UI loop separated? Is there a different > way that animation should be implemented? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick >

Feb. 20, 2014

Animation by Stepping

by J.F. Rick

Athens graphics are fast enough that it is possible to do high frame-rate animations. I've been trying (and, to various degrees, succeeding) in adding animations to my touch applications. I'm using stepping to do it. Basically, you just move pieces / update the display when step gets called. If you set the stepTime to 30, you should get somewhere around 30 frames per second, which is quite smooth. The problem I have is that the step mechanism in Pharo seems to block out the UI thread. In Squeak, you could return 0 for the stepTime message and then step would get called each UI cycle. In Pharo, the two seem to be disconnected. If the stepTime is too low, the processor will be busy doing redrawing and the UI loop is stopped. When I do stepTime of 20, the UI stops responding until after the animation is over. When I do stepTime of 50, the UI keeps working. The lower the stepTime, the smoother the animation, but also the chance that the UI becomes unresponsive. That's a nasty tradeoff. Is there a good way to do step style animation without this tradeoff? Why was stepping and the UI loop separated? Is there a different way that animation should be implemented? Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Feb. 20, 2014

[pharo-project/pharo-core]

by GitHub

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

Feb. 20, 2014