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

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

by Nicolai Hess

2016-01-25 20:10 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-20 23:23 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2016-01-20 19:18 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> >>> >>> 2016-01-20 14:47 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >>> >>>> Tried it in the last latest image and if I execute before >>>> #garbageCollect I just get 4 instances. >>>> >>>> Smalltalk garbageCollect. >>>> RubTextLine allInstances size "4" >>>> >>>> Now indeed if I browse the same class in nautilus I get a much smaller >>>> number of RubTextLine instances >>>> >>> >>> >>> I opened a bugreport >>> 17437 >>> <https://pharo.fogbugz.com/f/cases/17437/Rubric-spotter-with-preview-leaks-s…> >>> >>> Rubric: spotter with preview leaks some memory >>> >> >> >> I tried to reproduce this behavior with GTInspector instead of Spotter, >> for example, inspect: >> >> MethodFinder methods >> select on entry, -> another inspector pane shows up. Select th >> "Source"-tab. Now >> scroll through the list of methods in the first inspector pane. For every >> method the second pane updates the >> source tab with the code of the selected method. >> >> This generates many RubTextLine instances too. But not as many and I can >> always clean them up with Smalltalk garbageCollect. >> So, the is something that spotter does differently. >> > > And even if Smalltalk garbageCollect would clean all instances, > I don't think it is right, that scrolling through the method list (with > preview) should create hundred thousends of RubTextLine instances. > There is just not enough code visible, we definitly don't need that much. > There is something wrong. > Maybe these are all related 15153 <https://pharo.fogbugz.com/f/cases/15153/Rubric-mutability-issue-in-RubTextC…> Rubric mutability issue in RubTextComposer binary search 17284 <https://pharo.fogbugz.com/f/cases/17284/Rubric-SubscriptOutOfBounds-error> Rubric SubscriptOutOfBounds error 17447 <https://pharo.fogbugz.com/f/cases/17447/Playground-and-long-number-crashes-…> Playground and long number crashes with SubscriptOutOfBounds This may be an issue with text composer, called after styling and (I think) concurrent processes access and modifiy the RubTextComposers #lines attribute. some other observations: RubTextComposer>>#needComposition compares prevText / newText (attributes) runs ret := prevText runs ~= theText runs but both runs are often "different" even if they are for the same text: The text link classes are compared by identity instead of equality. And code like this RubShoutStyleDecorator>>replaceFrom: start to: stop with: aText self okToStyle ifFalse: [ ^ next replaceFrom: start to: stop with: aText ]. self disableDrawingWhile: [ aText addAttribute: self defaultFontChange. "<<<<--------- THIS" text ifNil: [ text := self text ]. text replaceFrom: start to: stop with: (self styler format: aText). will *always* add a trailing font change attribute, even if the prior styled and new styled text would be actually the same (originate from the same raw string)! there are multiple calls like aText addAttribute: self defaultFontChange. in other methods. GLMHighlighterTextStylerDecorator looks similiar with some minor changes (for no obvious reason and of course totally undocumented). Debugging this code is a pain with all the doesNotUnderstand redirection Analysing this code is a pain with all the undocumented code, copy and pasted to GLM (GLMHighlighterTextRubEditingMode/GLMHighlighterTextStylerDecorator/GLMHighlighterTextParserStyler....) copy and pasted *from* old text classes (with no indication if this is copied because it is used the same way or just DEAD code). And for real, does anyone work with spotter and preview enabled ? I can not work with it for more than some minutes without triggering this allocation of awfull many RubTextLine instances. I have to manually kill the styling process. no one? > > > >> >> >> >> >>> >>> >>> >>> >>>> >>>> On Wed, Jan 20, 2016 at 2:32 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>>> wrote: >>>> >>>>> Open fresh image 50536 >>>>> Open Spotter, >>>>> enable preview (cmd+p) >>>>> search for EllipseMorph >>>>> dive in instance-methods >>>>> scroll through the list one item after another. >>>>> >>>>> open playground >>>>> evaluate >>>>> RubTextLine allInstances size. "553896" >>>>> >>>>> >>>>> case 17421 is related to this, but does not fully solves this. >>>>> please review and comment on that fix, >>>>> so we can integrate this soon. >>>>> >>>>> The problem sometimes remains even with this fix. The memory >>>>> (instance count of RubTextLine) just grows in the background >>>>> >>>> >>>> >>> >> >

Jan. 31, 2016

Re: [Pharo-dev] Contributing to Pharo

by Ben Coman

On Sun, Jan 31, 2016 at 3:38 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On 1/30/16 1:54 AM, Bernhard Pieber wrote: >> >> Dale, >> >> Thanks for your thorough answer. I really appreciate how you include links >> to helpful articles. >> >> I find the description of the workflow you actually use very enlightening. >> However, one thing still remains unclear. In the last step, when merging the >> pull request. How is the unchanged metadata reconciled with the code >> changes? I just realized that I just donât know what information is in the >> Monticello metadata, which is not in the code? >> > Monticello metadata is basically the entire Monticello version history of > the package, it includes direct ancestors, commit comments, the GUID, etc. > For a FileTree repo, the meta data is stashed a separate file ... The form > of the data is actually serialized Smalltalk object graph - a deeply nested > set of Arrays - all written on a single line, so git has very little chance > of being able to merge two files What would it take to have the meta data spread out over multiple lines (if that would work better with git?) cheers -ben

Jan. 31, 2016

17502. Morph layoutProperties must not be nil by default

by Aliaksei Syrel

Hello Do you agree? https://pharo.fogbugz.com/f/cases/17502/Morph-layoutProperties-must-not-be-… Cheers, Alex

Jan. 30, 2016