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

WhatsUp from: 2015-01-19 until: 2015-01-31

by seaside＠rmod.lille.inria.fr

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 ;)

Jan. 19, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by stepharo

> 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

Jan. 18, 2015

Re: [Pharo-dev] [squeak-dev] re: Context status 2015-01-16

by Chris Muller

Hi Stef, On Sun, Jan 18, 2015 at 5:15 AM, stepharo <stepharo(a)free.fr> 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..

Jan. 18, 2015

Re: [Pharo-dev] review request

by Ben Coman

On Sun, Jan 18, 2015 at 7:44 PM, Sven Van Caekenberghe <sven(a)stfx.eu> 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

Jan. 18, 2015

Re: [Pharo-dev] Context status 2015-01-16

by Craig Latta

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)

Jan. 18, 2015

Re: [Pharo-dev] review request

by Sven Van Caekenberghe

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 <btc(a)openInWorld.com> 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 >

Jan. 18, 2015

Re: [Pharo-dev] [squeak-dev] re: Context status 2015-01-16

by stepharo

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

Jan. 18, 2015

Re: [Pharo-dev] review request

by stepharo

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 >

Jan. 18, 2015

Re: [Pharo-dev] review request

by Ben Coman

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

Jan. 18, 2015

Re: [Pharo-dev] Studies on group effectiveness

by Alain Rastoul

Le 17/01/2015 14:23, Eliot Miranda a Ã©crit : > http://mobile.nytimes.com/2015/01/18/opinion/sunday/why-some-teams-are-smar… > <http://mobile.nytimes.com/2015/01/18/opinion/sunday/why-some-teams-are-smar…> > > The studies find that smart teams are distinguished by three > characteristics, sharing time evenly between members, being good at > reading each other's emotional states, and having more women. On-line > groups are distinguished by the /same/ three characteristics. > > Eliot (phone) Very interesting readings, thank you. Communities are also individuals. in the search about personal motivations , I was wondering if the women advantage was not related to difference in ego expression, one of the most ranked motivations in community participations, but found no clear study or statement about that difference. -- Regards, Alain

Jan. 18, 2015