April 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Spec and e.g. hResizing:

by Sean P. DeNigris

Igor Stasenko wrote > The problem is, that users always want something different than > framework proposes :) Yes! While we're figuring things out, I feel like there /has/ to be some easy way to dig into Morphic until Spec supplies what's needed. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-and-e-g-hResizing-tp4683208p4683212.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 23, 2013

Re: [Pharo-users] Spec and e.g. hResizing:

by Igor Stasenko

UI.. how many battles lost on this field.. :) I yet to see a framework which would allow to specify layout (in declarative style) in exact way how user wants it to be. The problem is, that users always want something different than framework proposes :) This is the nature of UI. On 24 April 2013 00:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I see in the old-school layouts that it was possible to use #hResizing: > {#ButtonSpec. > ... > #hResizing:. #spaceFill... > > but I'm not sure how to do that now. I tried unsuccessfully: > SpecLayout composed > newRow: [ :spec | spec > newColumn: [ :col | col > add: #myLabel; > send: #hResizing: withArguments: { #shrinkWrap } ] width: 50; > add: #myModel ] height: 30; > yourself. > > > I was thinking maybe #add:withSpec: had something to do with it? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spec-and-e-g-hResizing-tp4683208.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 23, 2013

Spec and e.g. hResizing:

by Sean P. DeNigris

I see in the old-school layouts that it was possible to use #hResizing: {#ButtonSpec. ... #hResizing:. #spaceFill... but I'm not sure how to do that now. I tried unsuccessfully: SpecLayout composed newRow: [ :spec | spec newColumn: [ :col | col add: #myLabel; send: #hResizing: withArguments: { #shrinkWrap } ] width: 50; add: #myModel ] height: 30; yourself. I was thinking maybe #add:withSpec: had something to do with it? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-and-e-g-hResizing-tp4683208.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 23, 2013

Re: [Pharo-users] Terminating a Process when an object dies

by Igor Stasenko

On 23 April 2013 23:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Igor Stasenko wrote >> well, #createProcessFor: implies that copy get's the pointer to process. >> no need to pass it back to sender. > > I need the return value because I need to suspend and resume the process > from the original Timer, which is what the GUI holds a pointer to. > ah ok. well, you see, you have too many concerns combined at single point. so, why then it surprises you that code is so ugly? :) ... and btw, with such additional concern i fear that you will become a victim of another pitfall: - suspending process which waits on semaphore (delay) may be resumed without your permission by signaling that semaphore (when delay expires). and the problem is a design flaw in Semaphore/Process implementation which treats a process which waits on semaphore as 'suspended'. You can look for mailing list archive for discussion about that (if i remember, i raised this issue first in squeak mailing list). > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Terminating-a-Process-when-an-object-dies-tp4683036p4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 23, 2013

Re: [Pharo-users] Terminating a Process when an object dies

by Igor Stasenko

On 23 April 2013 21:07, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi all, > > > @Sven, yes of course I forgot the WeakArray to save the hard ref in my > previous explanation. > > > 2013/4/23 Igor Stasenko <siguctua(a)gmail.com> >> >> On 23 April 2013 18:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> > Igor Stasenko wrote >> >> but what you expecting? >> >> you refer to 'self' multiple times. sure thing it cannot be GC-ed, >> >> neither process will die because >> >> of plenty of references on stack. >> >> Even block closure which you creating for fork will have home context >> >> which keeps reference to 'self', >> >> e.g. receiver. >> > >> > I'm expecting magic apparently because I am stupid when it comes to >> > processes ;) I changed all the "self"s to array first, which also didn't >> > work, but then I read your statement about the home context... >> > >> > Luc's class-side trick seems to work: >> > Timer>>start >> > >> > | array | >> > array := WeakArray with: self. >> > process := self class createProcessFor: array. "tried passing >> > self here, >> > but it seemed to keep the process around" >> > >> of course, because the home context (will be the method below) of >> closure captures method's arguments, >> and holding them strongly.. >> >> >> > Timer class>>createProcessFor: aWeakArray >> > >> > [ [ aWeakArray first notNil ] whileTrue: [ >> > | timer | >> > aWeakArray first interval asDelay wait. >> > "We have to check again if the timer was garbage >> > collected during the >> > wait" >> > aWeakArray first ifNotNil: [ >> > aWeakArray first value: aWeakArray first value + >> > 1. >> > aWeakArray first announcer announce: >> > (TimerValueChanged to: aWeakArray >> > first value) ] ] ] fork. >> > >> > Wow, it would seem that an object using a process internally that is >> > only >> > valid when the object is around is a fairly common use case. I can't >> > believe >> > how complicated this is :/ >> > >> it is not apparent to me why this is common use case. :) >> >> you can also simply pass a copy of 'self' to process. >> as long as copy accessing same announcer, your ticker process will >> work perfectly. >> then all you would need to do is: >> >> | copy | >> copy := self copy. > > > @Igor. > It will not work here I think. > because you make the shallow copy before initializing the process and the > finalize message is then sent to the copy. this is exactly what i intended. The original don't needs to even know the process. It simply passing the initialized values (interval, announcer etc to its copy).. the rest is done by copy. Like that there is guarantee that you won't leak reference of original object to worker thread. > as Sven proposed, a WeakArray would be good but I never deeply test it. > You can do it with weak array as well. To make code less uglier, capture the object into temp for a while, like that you don't have to do 'array first ifnotnil:' all the time, e.g.: temp := array first. temp ifNotNil: [ blah blah "here you have guarantee that anything which stored in 'array first' will not be GCed" ]. temp := nil. > Anyway, I always fight with the finalization mechanism. > > With Noury we wrote an ActiveObject class some time ago that has an internal > process that is stopped and the activeobject is finalized. > The only thing is to be **really** carreful when giving the block to the > ActiveObject to not introduce references. > > Here one of the test case that is green: > > testDoesStopBlockUponFinalizationForLowestPriority > |counter startSemaphore finalizationSemaphore process | > counter := 0. > startSemaphore := Semaphore new. > finalizationSemaphore := Semaphore new. > activeObject := ActiveObject > do: [ > startSemaphore signal. > [(Delay forMilliseconds: 50) wait]repeat > ] > ensure: [ > counter := 1. > finalizationSemaphore signal. > ]. > activeObject > priority: Processor lowestPriority; > start. > self deny: (startSemaphore waitTimeoutSeconds: 2). > process := activeObject process. > activeObject := nil. > Smalltalk garbageCollect. > self deny: (finalizationSemaphore waitTimeoutSeconds: 2). > self assert: counter = 1. > self assert: process isTerminated > > > Here the whole code: > > MCHttpRepository > location: 'http://car.mines-douai.fr/squeaksource/ReusableBricks' > user: '' > password: '' > > Luc > > >> >> process := self class createProcessFor: copy. >> WeakRegistry default add: self executor: copy. >> >> and implement: >> >> finalize >> process terminate. >> process := nil. >> >> >> Then createProcessFor: will be simple: >> >> Timer class>>createProcessFor: timer >> [ >> [ timer wait. " make Demeter a bit happier" >> timer tick. "this should increment counter and announce >> TimerValueChanged, >> like that we're not make Demeter unhappy" >> ] whileTrue ] fork. >> >> (actually , to make mr.Demeter completely happy, i would do >> [ timer waitAndTick ] whileTrue. >> ) >> >> and, tick, will be something like that: >> >> tick >> process ifNil: [ ^ false ]. >> self incrementCounter. >> self announce: (MyGreatAnnouncement with: whatever). >> ^ true. >> >> cheerz :) >> >> > ----- >> > Cheers, >> > Sean >> > -- >> > View this message in context: >> > http://forum.world.st/Terminating-a-Process-when-an-object-dies-tp4683036p4… >> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

April 23, 2013

Re: [Pharo-users] Terminating a Process when an object dies

by Sean P. DeNigris

Igor Stasenko wrote > well, #createProcessFor: implies that copy get's the pointer to process. > no need to pass it back to sender. I need the return value because I need to suspend and resume the process from the original Timer, which is what the GUI holds a pointer to. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Terminating-a-Process-when-an-object-dies-tp4683036p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 23, 2013

Re: [Pharo-users] Terminating a Process when an object dies

by Igor Stasenko

On 23 April 2013 21:47, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Luc Fabresse wrote >> @Igor. >> It will not work here I think. >> because you make the shallow copy before initializing the process and the >> finalize message is then sent to the copy. > > Yes, I had to copy the process variable to the copy, but it just gets uglier > and uglier... > copy := self copy. > process := self class createProcessFor: copy. > copy process: process. > WeakRegistry default add: self executor: copy. > well, #createProcessFor: implies that copy get's the pointer to process. no need to pass it back to sender. > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Terminating-a-Process-when-an-object-dies-tp4683036p4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 23, 2013

Finalization Documentation

by Sean P. DeNigris

This might be a good addition to PBE2 ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Finalization-Documentation-tp4683194.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 23, 2013

Re: [Pharo-users] Terminating a Process when an object dies

by Sven Van Caekenberghe

On 23 Apr 2013, at 19:59, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Sean P. DeNigris wrote >> If you run TimerTest>>#testStart from Nautilus with an open Process >> Browser (with auto-update enabled), you'll see the process appear and then >> disappear. > > Although if I evaluate the snippet in the class comment of SpdLedMorph, the > process hangs around. Arggghhhh. This is crazy!!! I loaded your code and I have the impression that it works, both in the test and in a workspace. But it drives me crazy that my version does not seem to work. I will have to come back to this tomorrow with a fresh mind. Sven

April 23, 2013

Re: [Pharo-users] Terminating a Process when an object dies

by Sean P. DeNigris

Luc Fabresse wrote > @Igor. > It will not work here I think. > because you make the shallow copy before initializing the process and the > finalize message is then sent to the copy. Yes, I had to copy the process variable to the copy, but it just gets uglier and uglier... copy := self copy. process := self class createProcessFor: copy. copy process: process. WeakRegistry default add: self executor: copy. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Terminating-a-Process-when-an-object-dies-tp4683036p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 23, 2013