March 2015 - Pharo-dev - lists.pharo.org

update of pharo by example?

by Alexandre Bergel

Hi! Iâve heard some of you are working on an update of pharo by example. Is there anything ready for now? Some chapter maybe? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 10, 2015

Out of the Box support for launching, browsing and proxy

by Torsten Bergmann

Still there are three basic things I miss hardly in a unified way from the out of the box PHARO/ PHARO VM for the standard platforms (Unix, Win, Mac): 1. ability to execute another process (to start another executable process either asynchronous or blocking until the external process is finished) 2. ability to open a browser on a URL 3. Query for the native platform HTTP/HTTPs proxy settings (if there is one) so Zinc and others work behind a proxy. Situation hasnt improved on this side compared to Squeak/Squeak VM times (which also did not provide something like this). I know there is OSProcess, FFI, NB, and my OS-... packages and anyone could roll their own. But I would like to see this included BY DEFAULT in an easy and uniform way: either in the VM or default image even when on exotic platforms it returns ERROR_NOT_AVAILABLE. Any comments? Thanks T.

March 10, 2015

Re: [Pharo-dev] Super fast delay

by Torsten Bergmann

Sven wrote: > +1 > > I have a lot of respect for you taking such a long path, for being patient & persistent. +100

March 10, 2015

Re: [Pharo-dev] Super fast delay

by Ben Coman

On Wed, Mar 11, 2015 at 1:28 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > +1 > > I have a lot of respect for you taking such a long path, for being patient > & persistent. > Thanks. It was like a bone I just had to keep chewing until I got the marrow. Actually the changes themselves weren't so hard. The hard part was to change-it-on-the-fly with the CI and Integration tools at arms length - which anyway led to learning more about those systems. Future changes should be easier. cheers -ben > > > On 10 Mar 2015, at 18:06, Max Leske <maxleske(a)gmail.com> wrote: > > > > Great work Ben! > > > >> On 10 Mar 2015, at 17:44, Ben Coman <btc(a)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(a)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(a)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(a)openInWorld.com> > >> RÃ©pondre Ã : Pharo Development List <pharo-dev(a)lists.pharo.org> > >> Pour : Pharo Development List <pharo-dev(a)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(a)openinworld.com> > wrote: > >> > >> > >> On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> > >> On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther < > holger(a)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 > >> > >> > >> > >> > >> > > > > >

March 10, 2015

Re: [Pharo-dev] Super fast delay

by Sven Van Caekenberghe

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

March 10, 2015

Re: [Pharo-dev] Super fast delay

by Max Leske

Great work Ben! > On 10 Mar 2015, at 17:44, Ben Coman <btc(a)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(a)openinworld.com <mailto: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 <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/ <http://www.bluewatersps.com.au/> > > cheers -ben > > > > On Mon, Mar 2, 2015 at 3:09 AM, stepharo <stepharo(a)free.fr <mailto: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(a)openInWorld.com> > RÃ©pondre Ã : Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > Pour : Pharo Development List <pharo-dev(a)lists.pharo.org <mailto: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(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > > On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > > On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <holger(a)freyther.de <mailto: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 <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 > > > > >

March 10, 2015

Re: [Pharo-dev] Fwd: Re: Super fast delay

by Ben Coman

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(a)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(a)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(a)openInWorld.com> > RÃ©pondre Ã : Pharo Development List <pharo-dev(a)lists.pharo.org> > Pour : Pharo Development List <pharo-dev(a)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(a)openinworld.com> wrote: > > > On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther < > holger(a)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 > > > > >

March 10, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] bea5e5: 40548

by Ben Coman

YAY!! Thanks Esteban for integration, and Nicolai and Max for code reviews. To observe the new behaviour: 1. Tools > Process Browser Observe at the top "(80) Delay Scheduling Process: DelayMicrosecondScheduler>>runTimerEventLoop" This based on the new primitive by Eliot that rolls over every 50,000 years. 2. System > Settings > System > Delay Scheduler - select "DelayMillisecondScheduler" 3. Right-click back in Process Browser, and select [update list]. Observe at the top "(80) Delay Scheduling Process: DelayMillisecondScheduler>>runTimerEventLoop" This is the old primitive that rolls over every 6 days. Actually not really very exciting to look at ;) - but there you go! I'm glad its integrated. Now we'll see if any corner case bugs shake out of the woodwork. Note that the option list also includes "DelayScheduler". This is the old scheduler I refactored out from the class side of Delay. This was only kept as-is to smooth this integration step. It essentially became DelayMillisecondScheduler and will be removed from that list to allow some required cleanup to proceed. In the "super fast delay" thread I'll advise that it is solved. cheers -ben On Tue, Mar 10, 2015 at 11:43 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 10 Mar 2015, at 16:31, GitHub <noreply(a)github.com> wrote: > > > > Branch: refs/heads/4.0 > > Home: https://github.com/pharo-project/pharo-core > > Commit: bea5e5edece36093f82ab3a8854b61377dfbd0a1 > > > https://github.com/pharo-project/pharo-core/commit/bea5e5edece36093f82ab3a8… > > Author: Jenkins Build Server <board(a)pharo-project.org> > > Date: 2015-03-10 (Tue, 10 Mar 2015) > > > > Changed paths: > > M Kernel.package/Delay.class/README.md > > R Kernel.package/Delay.class/class/enable new code/newCodeEnabled.st > > A Kernel.package/Delay.class/class/settings/delaySchedulerClass.st > > A Kernel.package/Delay.class/class/settings/delaySchedulerClass_.st > > A Kernel.package/Delay.class/class/settings/systemSettingOn_.st > > M Kernel.package/Delay.class/definition.st > > R Kernel.package/Delay.class/instance/enable new > code/newCodeEnabled.st > > A Kernel.package/Delay.class/instance/printing/millisecondsToGo.st > > M Kernel.package/Delay.class/instance/printing/printOn_.st > > A Kernel.package/Delay.class/instance/private - > scheduler/schedulerBeingWaitedOn.st > > A Kernel.package/Delay.class/instance/private - > scheduler/schedulerBeingWaitedOn_.st > > A Kernel.package/Delay.class/instance/private - > scheduler/schedulerResumptionTime.st > > A Kernel.package/Delay.class/instance/private - > scheduler/schedulerResumptionTime_.st > > A Kernel.package/Delay.class/instance/private - > scheduler/schedulerSignalWaitingProcess.st > > A Kernel.package/Delay.class/instance/private - > scheduler/scheduler_resumptionTime_.st > > M Kernel.package/Delay.class/instance/private/setDelay_.st > > M > Kernel.package/Delay.class/instance/private/setDelay_forSemaphore_.st > > M Kernel.package/Delay.class/instance/public/delayDuration.st > > A > Kernel.package/Delay.class/instance/public/millisecondDelayDuration.st > > A Kernel.package/DelayMicrosecondScheduler.class/README.md > > A Kernel.package/DelayMicrosecondScheduler.class/definition.st > > A Kernel.package/DelayMicrosecondScheduler.class/instance/low > priority processes/schedule_.st > > A > Kernel.package/DelayMicrosecondScheduler.class/instance/primitives/primSignal_atUTCMicroseconds_.st > > A > Kernel.package/DelayMicrosecondScheduler.class/instance/printing/millisecondsUntilResumptionTime_.st > > A > Kernel.package/DelayMicrosecondScheduler.class/instance/snapshotting/adjust_resumptionTimeOldBase_newBase_.st > > A > Kernel.package/DelayMicrosecondScheduler.class/instance/snapshotting/restoreResumptionTimes.st > > A > Kernel.package/DelayMicrosecondScheduler.class/instance/snapshotting/saveResumptionTimes.st > > A > Kernel.package/DelayMicrosecondScheduler.class/instance/snapshotting/startUp.st > > A Kernel.package/DelayMicrosecondScheduler.class/instance/timer > process/handleTimerEvent_.st > > A Kernel.package/DelayMicrosecondScheduler.class/instance/timer > process/runTimerEventLoop.st > > A Kernel.package/DelayMicrosecondScheduler.class/instance/timer > process/scheduleDelay_.st > > A Kernel.package/DelayMicrosecondScheduler.class/instance/timer > process/startTimerEventLoop.st > > A Kernel.package/DelayMicrosecondScheduler.class/instance/timer > process/stopTimerEventLoop.st > > A Kernel.package/DelayMicrosecondScheduler.class/instance/timer > process/unscheduleDelay_.st > > A Kernel.package/DelayMillisecondScheduler.class/README.md > > A Kernel.package/DelayMillisecondScheduler.class/definition.st > > A Kernel.package/DelayMillisecondScheduler.class/instance/low > priority processes/schedule_.st > > A > Kernel.package/DelayMillisecondScheduler.class/instance/primitives/primSignal_atMilliseconds_.st > > A > Kernel.package/DelayMillisecondScheduler.class/instance/printing/millisecondsUntilResumptionTime_.st > > A > Kernel.package/DelayMillisecondScheduler.class/instance/snapshotting/adjust_resumptionTimeOldBase_newBase_.st > > A > Kernel.package/DelayMillisecondScheduler.class/instance/snapshotting/restoreResumptionTimes.st > > A > Kernel.package/DelayMillisecondScheduler.class/instance/snapshotting/saveResumptionTimes.st > > A Kernel.package/DelayMillisecondScheduler.class/instance/timer > process/handleTimerEvent_.st > > A Kernel.package/DelayMillisecondScheduler.class/instance/timer > process/runTimerEventLoop.st > > A Kernel.package/DelayMillisecondScheduler.class/instance/timer > process/scheduleDelay_.st > > A Kernel.package/DelayMillisecondScheduler.class/instance/timer > process/startTimerEventLoop.st > > A Kernel.package/DelayMillisecondScheduler.class/instance/timer > process/stopTimerEventLoop.st > > A Kernel.package/DelayMillisecondScheduler.class/instance/timer > process/unscheduleDelay_.st > > M Kernel.package/DelayScheduler.class/README.md > > M Kernel.package/DelayScheduler.class/instance/class initialization/ > initialize.st > > A > Kernel.package/DelayScheduler.class/instance/printing/millisecondsUntilResumptionTime_.st > > M > Kernel.package/DelayScheduler.class/instance/testing/nextWakeUpTime.st > > M Kernel.package/DelayScheduler.class/instance/timer > process/stopTimerEventLoop.st > > A > Kernel.package/DelayWaitTimeout.class/instance/signaling/schedulerSignalWaitingProcess.st > > A Kernel.package/Duration.class/instance/converting/asMicroseconds.st > > A > Kernel.package/MonitorDelay.class/instance/private/schedulerSignalWaitingProcess.st > > A KernelTests.package/DelayMicrosecondSchedulerTest.class/README.md > > A KernelTests.package/DelayMicrosecondSchedulerTest.class/ > definition.st > > A > KernelTests.package/DelayMicrosecondSchedulerTest.class/instance/running/tearDown.st > > A > KernelTests.package/DelayMicrosecondSchedulerTest.class/instance/support/busyWaitMilliseconds_.st > > A > KernelTests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testDurationLessThanMaxTicks.st > > A > KernelTests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testDurationMoreThanMaxTicks.st > > A > KernelTests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForMilliseconds.st > > A > KernelTests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testForSeconds.st > > A > KernelTests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testMillisecondsToGo.st > > A > KernelTests.package/DelayMicrosecondSchedulerTest.class/instance/tests/testTestInterferenceWithSystemTimingSemaphore.st > > A KernelTests.package/DelayMillisecondSchedulerTest.class/README.md > > A KernelTests.package/DelayMillisecondSchedulerTest.class/ > definition.st > > A > KernelTests.package/DelayMillisecondSchedulerTest.class/instance/running/tearDown.st > > A > KernelTests.package/DelayMillisecondSchedulerTest.class/instance/support/busyWaitMilliseconds_.st > > A > KernelTests.package/DelayMillisecondSchedulerTest.class/instance/tests/testDurationLessThanMaxTicks.st > > A > KernelTests.package/DelayMillisecondSchedulerTest.class/instance/tests/testDurationMoreThanMaxTicks.st > > A > KernelTests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForMilliseconds.st > > A > KernelTests.package/DelayMillisecondSchedulerTest.class/instance/tests/testForSeconds.st > > A > KernelTests.package/DelayMillisecondSchedulerTest.class/instance/tests/testMillisecondsToGo.st > > A > KernelTests.package/DelayMillisecondSchedulerTest.class/instance/tests/testTestInterferenceWithSystemTimingSemaphore.st > > R KernelTests.package/DelaySchedulerTest.class/README.md > > R KernelTests.package/DelaySchedulerTest.class/definition.st > > R > KernelTests.package/DelaySchedulerTest.class/instance/running/tearDown.st > > R > KernelTests.package/DelaySchedulerTest.class/instance/tests/testMaxTickLessThanDuration.st > > R > KernelTests.package/DelaySchedulerTest.class/instance/tests/testMaxTickMoreThanDuration.st > > R > KernelTests.package/DelaySchedulerTest.class/instance/tests/testTestInterferenceWithSystemTimingSemaphore.st > > R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/ > script547.st > > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/ > script548.st > > R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/ > update40547.st > > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/ > update40548.st > > M > ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > > > Log Message: > > ----------- > > 40548 > > 14353 Delay refactoring (part 2) - change from milliseconds to > microseconds > > https://pharo.fogbugz.com/f/cases/14353 > > > > http://files.pharo.org/image/40/40548.zip > > a distinctive four-note "short-short-short-long" motif twice ;-) > > it seems to work fine, great work Ben ! > > Sven > > >

March 10, 2015

[pharo-project/pharo-core] 6c59e2: 40549

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6c59e2bd0466a083452a7e3fb28405435529966d https://github.com/pharo-project/pharo-core/commit/6c59e2bd0466a083452a7e3f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-03-10 (Tue, 10 Mar 2015) Changed paths: M FileSystem-Core.package/PlatformResolver.class/instance/private/directoryFromEnvVariableNamed_or_.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script548.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script549.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40548.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40549.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot-Tests.package/PropertySlotTest.class/README.md A Slot-Tests.package/PropertySlotTest.class/definition.st A Slot-Tests.package/PropertySlotTest.class/instance/tests/testCreateClassWithPropertySlot.st R Slot.package/PointerLayout.class/instance/accessing/slotAt_.st R Slot.package/PointerLayout.class/instance/compatibility/atName_.st R Slot.package/PointerLayout.class/instance/compatibility/atName_ifAbsent_.st M Slot.package/PointerLayout.class/instance/validation/checkInheritedSlots.st M Traits.package/TBehavior.class/instance/initialization/initializeSlots_.st M Traits.package/TClassDescription.class/instance/slots/usesSpecialSlot.st M Traits.package/TClassDescription.class/instance/slots/usesSpecialVariables.st Log Message: ----------- 40549 15106 Test, typo fix (and tiny cleanup) for Slots https://pharo.fogbugz.com/f/cases/15106 15108 prevent a potential error in PlatformResolver https://pharo.fogbugz.com/f/cases/15108 http://files.pharo.org/image/40/40549.zip

March 10, 2015

[pharo-project/pharo-core]

by GitHub

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

March 10, 2015