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

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

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 1/29/16 2:45 PM, David Allouche wrote: > Thanks Dale for all the explanations. > > How Monticello and version control relate in the big picture is starting to make sense for me. > > Now, I better understand why filetree ended up uses a file-per-method format, even though that is relatively hostile to git user interfaces optimised for other languages. There is really a need for a file-per-class exchange format, because that would works a lot better with the existing VCS ecosystem. I agree 100%, but as I've mentioned in another post, I think that switching to a file-per-class exchange format needs to be a cross-dialect effort. A format that accommodates the diversity of Smalltalk class definition and even method metadata while still being readable is a bit of a challenge - solvable, but challenging.... Personally, I have other fish to fry, but I would be willing to participate in such an effort if someone else is willing to lead the charge:) Dale

Jan. 30, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

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 ... The other bit of Monticello metadata that is maintained by FileTree involves the per method timestamp and developer initials - these are stored in a method properties file associated with each class. In fact is nearly impossible for a human to properly merge to Monticello version histories, which is why Thierry Goubier's GitFileTree-MergeDriver[1] is especially useful. Thierry's MergeDriver fires up a Pharo image (called by git) and performs object surgery to merge the conflicting version histories and method properties. Anyway, in the scenario that I described, I simplified the process a bit and left out some of the gorier details. When I cherry-picked the commit for my topic branch and merged that commit into Sven's latest master branch, the Monticello metadata was certain to conflict, but when you perform a merge on a local git repository and you've registered Thierry's merge driver with git, the Monticello metadata is automatically merged. I also made the assumption that Sven would not have made any additional commits to his master branch between the time I merged his master branch and the time I submitted the pull request - the latest version of a file wins in a merge as long as they share the same immediate previous ancestor. If Sven had made a new commit, the Monticello metadata would have conflicted ... For the record, these "guaranteed conflicts" are the only reason that "removing Monticello metadata" enters into the conversation .... git maintains it's own version history and method properties, so for developers who are "exclusively using git" the Monticello metadata is an annoying source of "meaningless conflicts." All of the information that is present in Monticello meta data is present in git in another form As I said, Thierry Goubier's magical GitFileTree-MergeDriver[1] eliminates the conflict pain when the merges are performed in a local git repository, but on GitHub, merging the Monticello metadata is a constant thorn in one's side, since it becomes necessary to perform a manual merge (and leverage Thierry's Merge Driver) when Monticello metadata is involved. Dale [1] https://github.com/ThierryGoubier/GitFileTree-MergeDriver

Jan. 30, 2016