Re: [Pharo-dev] review request
Ben Coman wrote: I know everyone is busy and working in their own domains not having the time to review a lot of other people's issues. However I am on my own, not part of a team where I can walk over and tap someone on the shoulder to ask for review of an issue I've resolved. It is a bit discouraging not to be able to proceed for lack of review. I'd be glad for any feedback including "its crap, do it a different way". So consider this a virtual should tap. I have... * refactored the two calls to #forMilliseconds: out to a single call * replaced call to #wait with #waitOr: * added #waitOr: Here is the diff... WorldState >> interCyclePause: milliSecs | currentTime wait | self serverMode ifFalse: [ (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [ currentTime := Time millisecondClockValue. wait := lastCycleTime + milliSecs - currentTime. + "wait is the time remaining until milliSecs has passed + since lastCycle. If wait is zero or less, no need to Delay" + "If wait is greater than milliSeconds then bypass Delay, + by setting wait to zero." - (wait > 0 and: [ wait <= milliSecs ] ) ifTrue: [ - (Delay forMilliseconds: wait) wait ] ] ] + wait > milliSecs ifTrue: [ wait := 0 ] ] ] "btw, wait>milliSecs can only occur when clock rolls over. Eliminate after integrating issue 14353 ?" - ifTrue: [ (Delay forMilliseconds: 50) wait ]. + ifTrue: [ wait := 50 ]. + wait > 0 ifTrue: [ + (Delay forMilliseconds: wait) waitOr: [ + self inform: 'WorldState>>interCyclePause failed.' ] ]. lastCycleTime := Time millisecondClockValue. CanSurrenderToOS := true. "--" +Delay >> waitOr: anErrorBlock + self schedule. + [ beingWaitedOn + ifTrue: [ delaySemaphore wait ] + ifFalse:[ anErrorBlock value ] + ] ifCurtailed:[self unschedule]. +"Only the high priority timer event loop (TEL) signals /delaySempahore/. If the + TEL is not running, a delay will block forever (for example the UI will lock up). + /beingWaitedOn/ is only set to true from the TEL (via + DelayScheduler>>scheduleDelay: and Delay>>timingPriorityWaitedOn:) so test + this to determine if TEL is running. Avoid waiting when the TEL is not running." "--" This is for issue 14669 "Delay refactoring (part 2a) - avoid UI locking up when timer event loop is stopped" that is required to facilitate integration of issue 14353 "Delay refactoring (part 2) - change from milliseconds to microseconds. cheers -ben https://pharo.fogbugz.com/default.asp?14669 https://pharo.fogbugz.com/default.asp?14353 I should add, the test procedure would be: 1. Open Tools > Process Browser Observe it shows "(80) Delay Scheduling Process: DelayScheduler>>runTimerEventLoop" 2. Merge slice 14669 3. In Workspace do "Delay stopTimerEventLoop" Observe many informs stream up screen. Now the UI might be a bit slow bit is still responsive. Previously the UI would have locked up. This is the point of this change - having a chance to correct the fault. 4. Update the list in Tools > Process Browser. Observe process "(80...)" is gone. 5. In Workspace do "Delay startTimerEventLoop" Observe the informs have stopped. cheers -ben
Re: [Pharo-dev] review request
Hi ben I'm really bad in concurrent programming. I forwarded your mail to igor because he is good in concurrent programming and told me that monday he will start to work on his paid project so may be he will see my mail. I want to thank you for your energy and I understand that you can be frustrated by the lack of feedback. What you are doing is important. This is why I want to write a couple of chapter on concurrent programming. Stef I know everyone is busy and working in their own domains not having the time to review a lot of other people's issues. However I am on my own, not part of a team where I can walk over and tap someone on the shoulder to ask for review of an issue I've resolved. It is a bit discouraging not to be able to proceed for lack of review. I'd be glad for any feedback including "its crap, do it a different way". So consider this a virtual should tap. I have... * refactored the two calls to #forMilliseconds: out to a single call * replaced call to #wait with #waitOr: * added #waitOr: Here is the diff... WorldState >> interCyclePause: milliSecs | currentTime wait | self serverMode ifFalse: [ (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [ currentTime := Time millisecondClockValue. wait := lastCycleTime + milliSecs - currentTime. + "wait is the time remaining until milliSecs has passed + since lastCycle. If wait is zero or less, no need to Delay" + "If wait is greater than milliSeconds then bypass Delay, + by setting wait to zero." - (wait > 0 and: [ wait <= milliSecs ] ) ifTrue: [ - (Delay forMilliseconds: wait) wait ] ] ] + wait > milliSecs ifTrue: [ wait := 0 ] ] ] "btw, wait>milliSecs can only occur when clock rolls over. Eliminate after integrating issue 14353 ?" - ifTrue: [ (Delay forMilliseconds: 50) wait ]. + ifTrue: [ wait := 50 ]. + wait > 0 ifTrue: [ + (Delay forMilliseconds: wait) waitOr: [ + self inform: 'WorldState>>interCyclePause failed.' ] ]. lastCycleTime := Time millisecondClockValue. CanSurrenderToOS := true. "--" +Delay >> waitOr: anErrorBlock + self schedule. + [beingWaitedOn + ifTrue: [ delaySemaphore wait ] + ifFalse:[ anErrorBlock value ] + ]ifCurtailed:[self unschedule]. +"Only the high priority timer event loop (TEL) signals /delaySempahore/. If the + TEL is not running, a delay will block forever (for example the UI will lock up). + /beingWaitedOn/ is only set to true from the TEL (via + DelayScheduler>>scheduleDelay: and Delay>>timingPriorityWaitedOn:) so test + this to determine if TEL is running. Avoid waiting when the TEL is not running." "--" This is for issue 14669 "Delay refactoring (part 2a) - avoid UI locking up when timer event loop is stopped" that is required to facilitate integration of issue 14353 "Delay refactoring (part 2) - change from milliseconds to microseconds. cheers -ben https://pharo.fogbugz.com/default.asp?14669 https://pharo.fogbugz.com/default.asp?14353
Re: [Pharo-dev] [squeak-dev] re: Context status 2015-01-16
For your information guille produced pharo images of 11k for simple addition, 18k for large numbers. Also Seaside counter application of about 500k. We will continue to work on this architecture. Of course this is done in Pharo so it will not really be exciting for you. Stef
Re: [Pharo-dev] review request
Hi Ben, First off, thank you for looking into this, it is important, but it is also delicate and few people dare look at this stuff. I did the scenario you described in #40450 on Mac OS X and everything went as you described: although there were tons of notification messages, the UI remained usable though slow. I did some Zn tests afterwards, including save/restart of the image and did not see any problems. Sven > On 18 Jan 2015, at 10:22, Ben Coman wrote: > > Ben Coman wrote: >> I know everyone is busy and working in their own domains not having the time >> to review a lot of other people's issues. However I am on my own, not part >> of a team where I can walk over and tap someone on the shoulder to ask for >> review of an issue I've resolved. It is a bit discouraging not to be able >> to proceed for lack of review. I'd be glad for any feedback including "its >> crap, do it a different way". So consider this a virtual should tap. I >> have... >> * refactored the two calls to #forMilliseconds: out to a single call >> * replaced call to #wait with #waitOr: * added #waitOr: Here is the >> diff... >> WorldState >> interCyclePause: milliSecs >> | currentTime wait | >> self serverMode >> ifFalse: [ >> (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [ >> currentTime := Time millisecondClockValue. >> wait := lastCycleTime + milliSecs - currentTime. >> + "wait is the time remaining until milliSecs has passed + since lastCycle. >> If wait is zero or less, no need to Delay" >> + "If wait is greater than milliSeconds then bypass Delay, + by setting wait >> to zero." >> - (wait > 0 and: [ wait <= milliSecs ] ) ifTrue: [ >> - (Delay forMilliseconds: wait) wait ] ] ] >> + wait > milliSecs ifTrue: [ wait := 0 ] ] ] "btw, wait>milliSecs can only >> occur when clock rolls over. Eliminate after integrating issue 14353 ?" - >> ifTrue: [ (Delay forMilliseconds: 50) wait ]. >> + ifTrue: [ wait := 50 ]. >> + wait > 0 ifTrue: [ + (Delay forMilliseconds: wait) waitOr: [ + >> self inform: 'WorldState>>interCyclePause failed.' ] ]. >> lastCycleTime := Time millisecondClockValue. >> CanSurrenderToOS := true. >> "--" >> +Delay >> waitOr: anErrorBlock >> + self schedule. >> + [ beingWaitedOn + ifTrue: [ delaySemaphore wait ] + ifFalse:[ anErrorBlock >> value ] >> + ] ifCurtailed:[self unschedule]. >> +"Only the high priority timer event loop (TEL) signals /delaySempahore/. >> If the + TEL is not running, a delay will block forever (for example the UI >> will lock up). + /beingWaitedOn/ is only set to true from the TEL (via + >> DelayScheduler>>scheduleDelay: and Delay>>timingPriorityWaitedOn:) so test + >> this to determine if TEL is running. Avoid waiting when the TEL is not >> running." >> "--" >> This is for issue 14669 "Delay refactoring (part 2a) - avoid UI locking up >> when timer event loop is stopped" that is required to facilitate integration >> of issue 14353 "Delay refactoring (part 2) - change from milliseconds to >> microseconds. >> cheers -ben >> https://pharo.fogbugz.com/default.asp?14669 >> https://pharo.fogbugz.com/default.asp?14353 > > I should add, the test procedure would be: > > 1. Open Tools > Process Browser > Observe it shows "(80) Delay Scheduling Process: > DelayScheduler>>runTimerEventLoop" > > 2. Merge slice 14669 > > 3. In Workspace do "Delay stopTimerEventLoop" > Observe many informs stream up screen. Now the UI might be a bit slow bit is > still responsive. Previously the UI would have locked up. This is the point > of this change - having a chance to correct the fault. > > 4. Update the list in Tools > Process Browser. > Observe process "(80...)" is gone. > > 5. In Workspace do "Delay startTimerEventLoop" > Observe the informs have stopped. > > cheers -ben >
Re: [Pharo-dev] Context status 2015-01-16
Hi Stef-- > For your information guille produced pharo images of 11k for simple > addition, 18k for large numbers. Also Seaside counter application of > about 500k. Why so large? The simple addition image I made is 1k. > Of course this is done in Pharo so it will not really be exciting for > you. The minimal kernel isn't the exciting part, it's just a prerequisite. The exciting part is the distributed module system (Naiad). You need a minimal kernel for that to be practical. There is nothing like Naiad for Pharo yet. As always, I'm very interested in collaborating with you. thanks! -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Re: [Pharo-dev] review request
On Sun, Jan 18, 2015 at 7:44 PM, Sven Van Caekenberghe wrote: > Hi Ben, > > First off, thank you for looking into this, it is important, but it is > also delicate and few people dare look at this stuff. > This is why it would be good to give it plenty of time to settle in before Pharo 4 release. > > I did the scenario you described in #40450 on Mac OS X and everything went > as you described: although there were tons of notification messages, the UI > remained usable though slow. I did some Zn tests afterwards, including > save/restart of the image and did not see any problems. > > Sven > > Thanks for testing. cheers -ben
Re: [Pharo-dev] [squeak-dev] re: Context status 2015-01-16
Hi Stef, On Sun, Jan 18, 2015 at 5:15 AM, stepharo wrote: > For your information guille produced pharo images of 11k for simple > addition, 18k for large numbers. > Also Seaside counter application of about 500k. Of course, the real trick is if those tiny images can actually be grown into something relevant and useful.. That's the dream I have for Craig's Spoon -- letting the _machine_ form the "application" rather than a human. No doubt, a 500K Seaside image is /super cool/ and I think its past time I congratulated you and your entire team on Pharo. What y'all are doing takes a lot of patience and skill, your perseverence after this many years is inspiring. You seem to be doing all the things necessary to put "Smalltalk" onto the radar of young and cool developers, I hope it works for the sake of Smalltalk. > We will continue to work on this architecture. > Of course this is done in Pharo so it will not really be exciting for you. Well, if Craig's dream will be realized then it will be exciting for both Squeak and Pharo. I do find Pharo very interesting to observe even though I'm motivated by different goals..
Re: [Pharo-dev] What Logging framework for Pharo
Stef, I'm really sorry if my question and the answers, opinions and expectations of this thread made you feel bad. Do not worry. this is not this thread in particular. It is just an instance of larger process. People in general have strange expectation about Pharo. A basic google project has a around 20 to 25 full time paid engineers Pharo far far less. Now we can be powerful if people understand that they can help It was a not a strange expectation or a general discussion on logging at all, but a true question about existing logging facility in Pharo that I do not know, and the fact is there was Beacon, SystemLogger and ZnLogger, and albeit it may look depressing to you, this thread has some very interesting pointers to me. I think everybody's answer has some valid arguments from it's own point of view, none of them is really controversial, and the merging you talked about should settle everyone's expectations right. For me, I was looking for a logging tool for a project I (re)started some time ago and broke recently, trying to refactor it. More precisely I don't know why a client socket connection is closing, here I think Beacon will really help me on that, ZnLogger or SystemLogger could too. And even if the sl4s package looks good, it would help less for debugging (I 'm not saying it is not good), inspecting logged objects will be really a big plus. I would be very interested in following, participating or helping (docs, or whatever useful, eventually code or tests with my very limited skills and with some guidance) on this logging subject if needed, but I do not feel skilled enough on the Pharo part to solve most (if not any) fogbugz cases I saw, I would certainly only do a mess (I'm sure I'm not the only one in that case, the sep is very high between using and solving cases). So to me just using it for now is a good way to get deeper into it and probably one day be skilled enough to help ... :) Take your area of expertise and see how you can improve Pharo. Because your expertise has a value. And And I'm very sorry too that I cannot go to Pharo day, I would have loved to see presentations , meet some people, talk about it (logging tools or whatever) but I definitely can't . too bad :( I know the feeling. Now you can help at different levels - produce something you like - read and review book chapters - ... stef
[Pharo-dev] WhatsUp from: 2015-01-19 until: 2015-01-31
Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2015-01-31 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)
[Pharo-dev] improving print-it in playground
Hi, I worked with Andrei to find a solution for improving the print-it support. You can take a look here: http://www.humane-assessment.com/blog/improving-print-it-support-in-gtplayground The current solution can be found in the latest Pharo image. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
