- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default

by Esteban Lorenzano

> On 31 Jan 2016, at 13:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > layoutProperties := NullLayoutProperties uniqueInstance > to share only one object you would be creating âextension morphs"l anyway > > On Sun, Jan 31, 2016 at 1:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> On 31 Jan 2016, at 12:43, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Hi. >> >> Wait, I do not like this... remember *anything* can be a Morph, not just a widget (points, "atoms bouncing", etc.). >> >> Could you explain it? Because you can't add point to morph for example. > > A morph can be a point. > If you define: > > Morph new > color: Color yellow; > extent: 1@1; > position: 10@10; > openInWorld. > > you will have a âpointâ in the world. Now imagine 10k of those (to run simulations or whatever). > Thatâs what I mean :) > >> >> 2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> no, I donât :) >> I commented there. >> >>> On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: >>> >>> Hello >>> >>> Do you agree? >>> https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-… <https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-…> >>> >>> Cheers, >>> Alex >> >> > >

Jan. 31, 2016

Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default

by Henrik Nergaard

LayoutProperties is an optional part of Morph using some type of defined layout (mostly used by the LayoutPolicy subclasses), this is though not the only way to do layout for a Morph and its submorphs; so not every morph needs it nor should have it. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Aliaksei Syrel Sent: Sunday, January 31, 2016 1:17 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default layoutProperties := NullLayoutProperties uniqueInstance to share only one object On Sun, Jan 31, 2016 at 1:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>> wrote: On 31 Jan 2016, at 12:43, Denis Kudriashov <dionisiydk(a)gmail.com<mailto:dionisiydk@gmail.com>> wrote: Hi. Wait, I do not like this... remember *anything* can be a Morph, not just a widget (points, "atoms bouncing", etc.). Could you explain it? Because you can't add point to morph for example. A morph can be a point. If you define: Morph new color: Color yellow; extent: 1@1; position: 10@10; openInWorld. you will have a âpointâ in the world. Now imagine 10k of those (to run simulations or whatever). Thatâs what I mean :) 2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>>: no, I donât :) I commented there. On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel(a)gmail.com<mailto:alex.syrel@gmail.com>> wrote: Hello Do you agree? https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-… Cheers, Alex

Jan. 31, 2016

Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default

by Aliaksei Syrel

layoutProperties := NullLayoutProperties uniqueInstance to share only one object On Sun, Jan 31, 2016 at 1:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 31 Jan 2016, at 12:43, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > Wait, I do not like this... remember *anything* can be a Morph, not just a >> widget (points, "atoms bouncing", etc.). >> > > Could you explain it? Because you can't add point to morph for example. > > > A morph can be a point. > If you define: > > Morph new > color: Color yellow; > extent: 1@1; > position: 10@10; > openInWorld. > > you will have a âpointâ in the world. Now imagine 10k of those (to run > simulations or whatever). > Thatâs what I mean :) > > > 2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> no, I donât :) >> I commented there. >> >> On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> Hello >> >> Do you agree? >> >> https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-… >> >> Cheers, >> Alex >> >> >> > >

Jan. 31, 2016

Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default

by Esteban Lorenzano

> On 31 Jan 2016, at 12:43, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > Wait, I do not like this... remember *anything* can be a Morph, not just a widget (points, "atoms bouncing", etc.). > > Could you explain it? Because you can't add point to morph for example. A morph can be a point. If you define: Morph new color: Color yellow; extent: 1@1; position: 10@10; openInWorld. you will have a âpointâ in the world. Now imagine 10k of those (to run simulations or whatever). Thatâs what I mean :) > > 2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > no, I donât :) > I commented there. > >> On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: >> >> Hello >> >> Do you agree? >> https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-… <https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-…> >> >> Cheers, >> Alex > >

Jan. 31, 2016

Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default

by Aliaksei Syrel

Closed, thanks for feedback :) Cheers, Alex On Sun, Jan 31, 2016 at 12:43 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > Wait, I do not like this... remember *anything* can be a Morph, not just a >> widget (points, "atoms bouncing", etc.). >> > > Could you explain it? Because you can't add point to morph for example. > > 2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> no, I donât :) >> I commented there. >> >> On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> Hello >> >> Do you agree? >> >> https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-… >> >> Cheers, >> Alex >> >> >> >

Jan. 31, 2016

Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default

by Denis Kudriashov

Hi. Wait, I do not like this... remember *anything* can be a Morph, not just a > widget (points, "atoms bouncing", etc.). > Could you explain it? Because you can't add point to morph for example. 2016-01-31 12:21 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > no, I donât :) > I commented there. > > On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello > > Do you agree? > > https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-… > > Cheers, > Alex > > >

Jan. 31, 2016

Re: [Pharo-dev] 17502. Morph layoutProperties must not be nil by default

by Esteban Lorenzano

no, I donât :) I commented there. > On 30 Jan 2016, at 21:22, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello > > Do you agree? > https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-… <https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-…> > > Cheers, > Alex

Jan. 31, 2016

Re: [Pharo-dev] ProcessTest>>testSchedulingIsFirstComeFirstServed

by Ben Coman

On Sun, Jan 31, 2016 at 6:16 PM, Ben Coman <btc(a)openinworld.com> wrote: > My general understanding of process scheduling is that it is FIFO > within same priority. Indeed Pharo has a test for this > ProcessTest>>testSchedulingIsFirstComeFirstServed, which however I > thought was a bit fragile and I was looking to revise. > > But now I'm curious whether same-priority-process FIFO scheduling is > an expected guarantee? > On both Pharo 5 build 50560 & Squeak 5 build 15113 the following test fails... > > [ 1 to: 100000 do: [ :n | > | ranFirst ranSecond | > [ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond > := 1] ] forkAt: 78. > [ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond > := 2] ] forkAt: 78. > ] forkAt: 79. > self assert: ranFirst=1. > self assert: ranSecond=2. ] > ] fork. > > ... but only after 20k iterations, which seems an "almost" guarantee. > Interestingly, it doesn't fail when run without the outer fork. > Also if I take an alternate approach with less message calls... > > faults := OrderedCollection new. > done := Semaphore new. > [ 1 to: 10000000 do: [ :n | | ranFirst ranSecond | > [ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond > := 1] ] forkAt: 78. > [ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond > := 2] ] forkAt: 78. > ] forkAt: 79. > (ranFirst=1 and: ranSecond=2) ifFalse: [ faults add: { n . > ranFirst . ranSecond } ]. > ]. > done signal. > ] fork. > done wait. > faults inspect. > > I only get seven failures in 10 million iterations. > "an OrderedCollection( > #( 258535 2 1) > #(1148605 2 1) > #(3502820 2 1) > #(4010935 2 1) > #(4533713 2 1) > #(6301878 2 1) > #(8497001 2 1))" > > So what I'm wondering is if there is a bug to hunt down, or if FIFO > scheduling is simply not an expected guarantee? > > cheers -ben A while ago in Pharo I added DelayNullScheduler, which stops the timingPriority(=80) process that schedules delays. After selecting it via World > System > Settings > System > Delay Scheduler I cannot reproduce any of the faults(?) above. (Aside: I just found performance a bit better if DelayNullScheduler>>schedule: first does a "Processor yield") With the usual delay scheduler operating, the fault(?) can be bypassed by signalling the timingSemaphore... timingSemaphore := Delay testCaseSupportTimingSemaphore. [ 1 to: 100000 do: [ :n | | ranFirst ranSecond | [ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond := 1] ] forkAt: 78. [ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond := 2] ] forkAt: 78. ] forkAt: 79. self assert: ranFirst=1. self assert: ranSecond=2. ] timingSemaphore signal. ] fork. The fault(?) can also be bypassed by commenting the call to #intercyclePause: out of WorldState>>doOneCycleFor: I'd be glad for any insights. cheers -ben

Jan. 31, 2016

ProcessTest>>testSchedulingIsFirstComeFirstServed

by Ben Coman

My general understanding of process scheduling is that it is FIFO within same priority. Indeed Pharo has a test for this ProcessTest>>testSchedulingIsFirstComeFirstServed, which however I thought was a bit fragile and I was looking to revise. But now I'm curious whether same-priority-process FIFO scheduling is an expected guarantee? On both Pharo 5 build 50560 & Squeak 5 build 15113 the following test fails... [ 1 to: 100000 do: [ :n | | ranFirst ranSecond | [ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond := 1] ] forkAt: 78. [ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond := 2] ] forkAt: 78. ] forkAt: 79. self assert: ranFirst=1. self assert: ranSecond=2. ] ] fork. ... but only after 20k iterations, which seems an "almost" guarantee. Interestingly, it doesn't fail when run without the outer fork. Also if I take an alternate approach with less message calls... faults := OrderedCollection new. done := Semaphore new. [ 1 to: 10000000 do: [ :n | | ranFirst ranSecond | [ [ ranFirst ifNil: [ ranFirst := 1 ] ifNotNil: [ ranSecond := 1] ] forkAt: 78. [ ranFirst ifNil: [ ranFirst := 2 ] ifNotNil: [ ranSecond := 2] ] forkAt: 78. ] forkAt: 79. (ranFirst=1 and: ranSecond=2) ifFalse: [ faults add: { n . ranFirst . ranSecond } ]. ]. done signal. ] fork. done wait. faults inspect. I only get seven failures in 10 million iterations. "an OrderedCollection( #( 258535 2 1) #(1148605 2 1) #(3502820 2 1) #(4010935 2 1) #(4533713 2 1) #(6301878 2 1) #(8497001 2 1))" So what I'm wondering is if there is a bug to hunt down, or if FIFO scheduling is simply not an expected guarantee? cheers -ben

Jan. 31, 2016

Re: [Pharo-dev] GTDebugger missing block parameters?

by Nicolai Hess

2016-01-28 1:37 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai > > On Jan 15, 2016, at 4:57 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-15 13:26 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > >> When debugging a method containing a block with a parameter, >> the parameter is missing from the variable list (because it is aliased?). >> > > Yes, this happens with block vars from optimized blocks (ifNotNil:). > The tempvars arent't local to the block, but method vars. > And the debugger (debuggerMap) doesn't knows about this (this happens on > both debuggers AFAIK). > > > It works in the Squeak debugger. Try e.g. debugging > Character space printOn: Transcript > Yes, thanks Eliot. I try to find out what happens here (opals based debugger map works quite different from squeak compiler infrastructure (parser / handling of optimized block contexts). > > > >> >> Stephan >> > >

Jan. 31, 2016