- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo Association: alone we have little power, but many we are strong

by Sean P. DeNigris

StÃ©phane Ducasse wrote > I really believe that we can do something alltogether. We already have been :) And this funding will amplify and accelerate our progress!! -- View this message in context: http://forum.world.st/Pharo-Association-alone-we-have-little-power-but-many… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 20, 2013

[Pharo-project] How to load PetitParser UI in 1.4?

by Norbert Hartl

I tried to load version 1.5 of petit parser into a 1.4 image. And I get the error while Glamour is loading announcer already defined in MorphTreeModel Fixing it in the debugger and continue didn't help. I get an exception on opening the petit gui then. Any hints?

Jan. 20, 2013

Re: [Pharo-project] RateLimitingAnnouncer

by Fernando Olivero

Hi, instead of subclassing Announcement, i would add the limiting logic to the one receiving the announcements. To keep everything but the view agnostic of this "optimization" detail. Because all you need is to prevent the UI from rendering in intervals less then 100ms. The announcement doesn't care wether the UI should redraw or not. Fernando On Sun, Jan 20, 2013 at 11:16 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Jan 20, 2013, at 10:27 AM, Ben Coman wrote: > > > > > I am considering a use case where a complex UI rendering loop is linked > to an Announcement, which is being fired rapidly (eg < 1ms), and overall > system performance suffers. However the UI rendering loop really only needs > to execute every 100ms since that is sufficient for a user to perceive an > immediate response to their action. So I have rolled-my-own way to achieve > this for which I was looking for some feedback... > > > > 1. Is there any existing feature in Pharo I have missed that can limit > the firing rate of an announcement ? > > not that I know :) > > > 2. Would this be useful to others as a feature to ship with Pharo ? (so > I don't have to roll-my-own, and it gets more experienced eyes to ensure > its right :) ) > > > 3. General comments on my approach, improvements, alternatives. > > > > By way of a use case using Workspace, execute... > > ------------- > > | announcer mainCount uiCount | > > announcer := Announcer new. "RateLimitingAnnouncer new." > > mainCount := uiCount := 0. > > Transcript crShow: 'ui' ; tab; show: 'main' . > > announcer subscribe: AnnouncementMockA do: > > [ uiCount := uiCount + 1. > > "Imagine a longer duration UI rendering loop here" > > Transcript crShow: uiCount asString , ' ' , mainCount asString. > > ]. > > [ 10000 timesRepeat: > > [ mainCount := mainCount + 1. > > "(Delay forMilliseconds: 1 ) wait." > > announcer announce: AnnouncementMockA new. ] > > ] timeToRun . > > ------------- > > With 'Announcer' this takes 10 seconds to execute with the last lines > being... > > 9999 9999 > > 10000 10000 > > > > Replacing 'Announcer' with my own 'RateLimitingAnnouncer' listed below, > this takes 20 milliseconds with the last lines being... > > ui main > > 1 1 > > 2 10000 > > > > Uncommenting the "Delay" takes 30 seconds for Announcer - and 15 seconds > for RateLimitingAnnouncer with last lines of... > > 289 9935 > > 290 10000 > > > > > > Here is my code wrapping #announce: and #initialize... > > ----- > > Announcer subclass: #RateLimitingAnnouncer > > instanceVariableNames: 'maxRateMilliSeconds queuedCounts' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'LEKtrek-Core' > > ----- > > RateLimitingAnnouncer >>initialize > > super initialize . > > maxRateMilliSeconds := 100. > > queuedCounts := Dictionary new. > > ----- > > RateLimitingAnnouncer >>announce: anAnnouncement > > | announcementClass | > > > > "Track how many announcements fired since reset at end of forked Delay" > > announcementClass := anAnnouncement class. > > queuedCounts at: announcementClass > > ifPresent: [ :count | queuedCounts at: announcementClass put: > count + 1 ] > > ifAbsent: [ queuedCounts at: announcementClass put: 1 ]. > > > > "At first announcement since Delay'ed reset, forward this one and set > up Delay to condense subsequent ones. " ( (queuedCounts at: > announcementClass) = 1 ) ifTrue: > > [ [ "fire one announcement only for any announcement > arriving within delay period." > > (Delay forMilliseconds: maxRateMilliSeconds) wait. > [ (queuedCounts at: announcementClass) > 1 ] whileTrue: [ > "At least one announcement arrived before end of Delay. Forward one > announcement only and repeat" queuedCounts at: > announcementClass put: 1. > > super announce: anAnnouncement. > > (Delay forMilliseconds: maxRateMilliSeconds) wait. > ]. > > queuedCounts at: announcementClass put: 0. > > ] fork. ^ super announce: anAnnouncement. ]. > > ----- > > > > cheers -ben > > > > > > >

Jan. 20, 2013

[Pharo-project] squeaksource still down with "502 Proxy Error"

by Denis Kudriashov

Jan. 20, 2013

Re: [Pharo-project] RateLimitingAnnouncer

by StÃ©phane Ducasse

On Jan 20, 2013, at 10:27 AM, Ben Coman wrote: > > I am considering a use case where a complex UI rendering loop is linked to an Announcement, which is being fired rapidly (eg < 1ms), and overall system performance suffers. However the UI rendering loop really only needs to execute every 100ms since that is sufficient for a user to perceive an immediate response to their action. So I have rolled-my-own way to achieve this for which I was looking for some feedback... > > 1. Is there any existing feature in Pharo I have missed that can limit the firing rate of an announcement ? not that I know :) > 2. Would this be useful to others as a feature to ship with Pharo ? (so I don't have to roll-my-own, and it gets more experienced eyes to ensure its right :) ) > 3. General comments on my approach, improvements, alternatives. > > By way of a use case using Workspace, execute... > ------------- > | announcer mainCount uiCount | > announcer := Announcer new. "RateLimitingAnnouncer new." > mainCount := uiCount := 0. > Transcript crShow: 'ui' ; tab; show: 'main' . > announcer subscribe: AnnouncementMockA do: > [ uiCount := uiCount + 1. > "Imagine a longer duration UI rendering loop here" > Transcript crShow: uiCount asString , ' ' , mainCount asString. > ]. > [ 10000 timesRepeat: > [ mainCount := mainCount + 1. > "(Delay forMilliseconds: 1 ) wait." > announcer announce: AnnouncementMockA new. ] > ] timeToRun . > ------------- > With 'Announcer' this takes 10 seconds to execute with the last lines being... > 9999 9999 > 10000 10000 > > Replacing 'Announcer' with my own 'RateLimitingAnnouncer' listed below, this takes 20 milliseconds with the last lines being... > ui main > 1 1 > 2 10000 > > Uncommenting the "Delay" takes 30 seconds for Announcer - and 15 seconds for RateLimitingAnnouncer with last lines of... > 289 9935 > 290 10000 > > > Here is my code wrapping #announce: and #initialize... > ----- > Announcer subclass: #RateLimitingAnnouncer > instanceVariableNames: 'maxRateMilliSeconds queuedCounts' > classVariableNames: '' > poolDictionaries: '' > category: 'LEKtrek-Core' > ----- > RateLimitingAnnouncer >>initialize > super initialize . > maxRateMilliSeconds := 100. > queuedCounts := Dictionary new. > ----- > RateLimitingAnnouncer >>announce: anAnnouncement > | announcementClass | > > "Track how many announcements fired since reset at end of forked Delay" > announcementClass := anAnnouncement class. > queuedCounts at: announcementClass > ifPresent: [ :count | queuedCounts at: announcementClass put: count + 1 ] > ifAbsent: [ queuedCounts at: announcementClass put: 1 ]. > > "At first announcement since Delay'ed reset, forward this one and set up Delay to condense subsequent ones. " ( (queuedCounts at: announcementClass) = 1 ) ifTrue: > [ [ "fire one announcement only for any announcement arriving within delay period." > (Delay forMilliseconds: maxRateMilliSeconds) wait. [ (queuedCounts at: announcementClass) > 1 ] whileTrue: [ "At least one announcement arrived before end of Delay. Forward one announcement only and repeat" queuedCounts at: announcementClass put: 1. > super announce: anAnnouncement. > (Delay forMilliseconds: maxRateMilliSeconds) wait. ]. > queuedCounts at: announcementClass put: 0. > ] fork. ^ super announce: anAnnouncement. ]. > ----- > > cheers -ben > >

Jan. 20, 2013

[Pharo-project] RateLimitingAnnouncer

by Ben Coman

I am considering a use case where a complex UI rendering loop is linked to an Announcement, which is being fired rapidly (eg < 1ms), and overall system performance suffers. However the UI rendering loop really only needs to execute every 100ms since that is sufficient for a user to perceive an immediate response to their action. So I have rolled-my-own way to achieve this for which I was looking for some feedback... 1. Is there any existing feature in Pharo I have missed that can limit the firing rate of an announcement ? 2. Would this be useful to others as a feature to ship with Pharo ? (so I don't have to roll-my-own, and it gets more experienced eyes to ensure its right :) ) 3. General comments on my approach, improvements, alternatives. By way of a use case using Workspace, execute... ------------- | announcer mainCount uiCount | announcer := Announcer new. "RateLimitingAnnouncer new." mainCount := uiCount := 0. Transcript crShow: 'ui' ; tab; show: 'main' . announcer subscribe: AnnouncementMockA do: [ uiCount := uiCount + 1. "Imagine a longer duration UI rendering loop here" Transcript crShow: uiCount asString , ' ' , mainCount asString. ]. [ 10000 timesRepeat: [ mainCount := mainCount + 1. "(Delay forMilliseconds: 1 ) wait." announcer announce: AnnouncementMockA new. ] ] timeToRun . ------------- With 'Announcer' this takes 10 seconds to execute with the last lines being... 9999 9999 10000 10000 Replacing 'Announcer' with my own 'RateLimitingAnnouncer' listed below, this takes 20 milliseconds with the last lines being... ui main 1 1 2 10000 Uncommenting the "Delay" takes 30 seconds for Announcer - and 15 seconds for RateLimitingAnnouncer with last lines of... 289 9935 290 10000 Here is my code wrapping #announce: and #initialize... ----- Announcer subclass: #RateLimitingAnnouncer instanceVariableNames: 'maxRateMilliSeconds queuedCounts' classVariableNames: '' poolDictionaries: '' category: 'LEKtrek-Core' ----- RateLimitingAnnouncer >>initialize super initialize . maxRateMilliSeconds := 100. queuedCounts := Dictionary new. ----- RateLimitingAnnouncer >>announce: anAnnouncement | announcementClass | "Track how many announcements fired since reset at end of forked Delay" announcementClass := anAnnouncement class. queuedCounts at: announcementClass ifPresent: [ :count | queuedCounts at: announcementClass put: count + 1 ] ifAbsent: [ queuedCounts at: announcementClass put: 1 ]. "At first announcement since Delay'ed reset, forward this one and set up Delay to condense subsequent ones. " ( (queuedCounts at: announcementClass) = 1 ) ifTrue: [ [ "fire one announcement only for any announcement arriving within delay period." (Delay forMilliseconds: maxRateMilliSeconds) wait. [ (queuedCounts at: announcementClass) > 1 ] whileTrue: [ "At least one announcement arrived before end of Delay. Forward one announcement only and repeat" queuedCounts at: announcementClass put: 1. super announce: anAnnouncement. (Delay forMilliseconds: maxRateMilliSeconds) wait. ]. queuedCounts at: announcementClass put: 0. ] fork. ^ super announce: anAnnouncement. ]. ----- cheers -ben

Jan. 20, 2013

Re: [Pharo-project] Pharo Association: alone we have little power, but many we are strong

by StÃ©phane Ducasse

Thanks for the idea Yes we will do that and explain it on the various web sites. Stef On Jan 20, 2013, at 3:40 AM, Yanni Chiu wrote: > > > On 19/01/13 1:05 PM, StÃ©phane Ducasse wrote: >> >> Just a point: Join the Pharo association because all together we can get some power. > > The association/consortium needs some work on marketing/promotion. There was a question at the Toronto Smalltalk User Group that seemed to indicate to me that the association is not well understood, whereas the consortium is somewhat understood but "too expensive for individuals". > > Maybe, for those who do not follow the various lists, there could be a "Frequently Announced Items" posting that explains the consortium and association, and gives sign up links. I personally dislike automated posts, but sometimes people don't absorb all the information when it flies by on the mailing list just once. > > >

Jan. 20, 2013

Re: [Pharo-project] Pharo Association: alone we have little power, but many we are strong

by StÃ©phane Ducasse

Thanks Sean. I really believe that we can do something alltogether. stef On Jan 20, 2013, at 2:54 AM, Sean P. DeNigris wrote: > StÃ©phane Ducasse wrote >> Just a point: Join the Pharo association because all together we can get >> some power. > > Thanks for the reminder! All signed up... > > > > -- > View this message in context: http://forum.world.st/Pharo-Association-alone-we-have-little-power-but-many… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 20, 2013

Re: [Pharo-project] Pharo Association: alone we have little power, but many we are strong

by Yanni Chiu

On 19/01/13 1:05 PM, StÃ©phane Ducasse wrote: > > Just a point: Join the Pharo association because all together we can get some power. The association/consortium needs some work on marketing/promotion. There was a question at the Toronto Smalltalk User Group that seemed to indicate to me that the association is not well understood, whereas the consortium is somewhat understood but "too expensive for individuals". Maybe, for those who do not follow the various lists, there could be a "Frequently Announced Items" posting that explains the consortium and association, and gives sign up links. I personally dislike automated posts, but sometimes people don't absorb all the information when it flies by on the mailing list just once.

Jan. 20, 2013

Re: [Pharo-project] Pharo Association: alone we have little power, but many we are strong

by Sean P. DeNigris

StÃ©phane Ducasse wrote > Just a point: Join the Pharo association because all together we can get > some power. Thanks for the reminder! All signed up... -- View this message in context: http://forum.world.st/Pharo-Association-alone-we-have-little-power-but-many… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 20, 2013