+1
I have a lot of respect for you taking such a long path, for being patient &
persistent.
> On 10 Mar 2015, at 18:06, Max Leske <[email protected]> wrote:
>
> Great work Ben!
>
>> On 10 Mar 2015, at 17:44, Ben Coman <[email protected]> wrote:
>>
>> This is solved with the integration of issue 14353 into build 40548.
>>
>> On an OSX > Virtualbox > LinuxMint17 with the following script...
>> for i in `seq 1 10` ;
>> do
>> (time $MYPHAROVM $MYIMAGE \
>> eval "(Delay forSeconds: 1) wait") 2>&1 > /dev/null | grep real
>> done
>>
>> Build 40547 gives...
>> real 0m1.288s
>> real 0m1.256s
>> real 0m1.258s
>> real 0m0.254s
>> real 0m0.269s
>> real 0m0.274s
>> real 0m0.260s
>> real 0m0.245s
>> real 0m0.254s
>> real 0m1.260s
>>
>> Build 40548 gives...
>> real 0m1.285s
>> real 0m1.259s
>> real 0m1.260s
>> real 0m1.260s
>> real 0m1.280s
>> real 0m1.267s
>> real 0m1.265s
>> real 0m1.293s
>> real 0m1.267s
>> real 0m1.278s
>>
>> HTH,
>> cheers -ben
>>
>>
>> On Mon, Mar 2, 2015 at 12:08 PM, Ben Coman <[email protected]> wrote:
>>
>> This is not going to get as much use before Release as I had hoped, so I
>> refactored it to be able to easily switch between the existing and new code
>> by making two schedulers...
>> * DelayMillisecondScheduler - essentially the existing code
>> * DelayMicrosecondScheduler - based off new primitive
>> which are switchable on the fly via a System Setting.
>>
>> To try to make it easier to review, I've separated changes into three stages:
>> * SLICE.10 accumulates changes the Delay class to add some better semantics
>> to instance variables and method renames
>> * SLICE.14 accumulates changes to split DelayScheduler into two subclasses
>> for the two different schedulers (use the incoming code in the merge
>> conflict)
>> * SLICE.17 accumulates changes to modify DelayMicrosecondScheduler, plus a
>> couple of polishing things.
>>
>> I've added some review notes to the issue
>> https://pharo.fogbugz.com/default.asp?14353
>>
>> fyi, Tomorrow I start a new job at Buewaters Power Station [1] (2 x 208MW
>> generators). They've been without an electrical engineer for three months
>> leading up to their annual outage in five weeks, so I'm probably flat there
>> playing catch-up for the next two months. Today (GMT+8) would be a really
>> good time to engage me with feedback and queries. I'll try to hang out on
>> IRC as much as possible to speed up discussion.
>>
>> [1] http://www.bluewatersps.com.au/
>>
>> cheers -ben
>>
>>
>>
>> On Mon, Mar 2, 2015 at 3:09 AM, stepharo <[email protected]> wrote:
>>
>> Please help us to push ben code.
>>
>>
>>
>> -------- Message transféré --------
>> Sujet : Re: [Pharo-dev] Super fast delay
>> Date : Wed, 25 Feb 2015 02:00:25 +0800
>> De : Ben Coman <[email protected]>
>> Répondre à : Pharo Development List <[email protected]>
>> Pour : Pharo Development List <[email protected]>
>>
>>
>> I've updated this fix for build 40504. The following slice is read for
>> review.
>> SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6
>>
>> Even if you do not feel up to reviewing the code, it would be good for a few
>> people to merge this to get a broad sample of symptoms fixed or caused.
>>
>> 1. Open up Monticello and get ready to load the above slice from Pharo4Inbox
>> repository.
>> 2. In a workspace, do "Delay stopTimerEventLoop". Ignore the
>> #intercyclePause: message that stream by.
>> 3. Merge slice.
>> 4. In a workspace, do "Delay startTimerEventLoop". The stream of
>> #interCyclePause message should fade.
>> 5. Operate as you normally would. Test some cases that previously caused an
>> error.
>>
>> cheers -ben
>>
>> On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[email protected]> wrote:
>>
>>
>> On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[email protected]> wrote:
>>
>>
>> On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther
>> <[email protected]> wrote:
>> On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:
>>
>> Good Morning Ben, Stef,
>>
>> > We really need people to have a look at the code of Ben.
>>
>> I downloaded a Pharo-4 image today and executed:
>>
>> To clarify. The fix is not yet in Pharo-4.
>>
>>
>> time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay
>> forSeconds: 5) wait"
>> a Delay(5000 msecs)
>>
>> real 0m1.254s
>> user 0m1.192s
>> sys 0m0.060s
>>
>>
>> So the first delay doesn't appear to wait the five seconds. I
>> would like to work on kqueue/epoll and remove polling and it
>> looks this involves code with Delay as well. I wonder if you
>> could provide an overview of what needs to be done and what is
>> done?
>>
>> The pre-requisite issue 14942 is waiting for review. It really should take
>> only 10 minutes to review...
>> 1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is
>> "true".
>> 2. Open the Pharo4Inbox and filter on 14942.
>> 3. Select newest slice and <Merge>.
>> 4. Observe the diff shows all "false" parts removed (it doesn't really get
>> much simpler than this to review).
>> 5. Click <merge> to finish.
>> 6. Observe the image continues to run smoothly.
>> 7. Report your observations on https://pharo.fogbugz.com/default.asp?14942
>>
>> btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class
>> variables from Delay.
>> When 14942 is integrated, can 14966 be integrated very soon after that. I
>> am basing the change of Delay to microsecond delay off 14966.
>> cheers -ben
>>
>>
>>
>>
>> I need to refresh myself on the fix I did back in 2-Dec. Its languished
>> while some support infrastructure was added to help the system ride-through
>> the change.
>>
>> cheers -ben
>>
>>
>>
>>
>>
>
