+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 <maxleske@gmail.com> wrote:
>
> Great work Ben!
>
>> On 10 Mar 2015, at 17:44, Ben Coman <btc@openInWorld.com> 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 <btc@openinworld.com> 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 <stepharo@free.fr> 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 <btc@openInWorld.com>
>> R��pondre �� : Pharo Development List <pharo-dev@lists.pharo.org>
>> Pour :�� �� �� ��Pharo Development List <pharo-dev@lists.pharo.org>
>>
>>
>> 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 <btc@openinworld.com> wrote:
>>
>>
>> On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <btc@openinworld.com> wrote:
>>
>>
>> On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <holger@freyther.de> 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
>>
>>
>>
>>
>>
>