Hi, Hmm. I work with Spotter with preview enabled all the time… but I do not seem to get to the point in which I have to kill the styling process. How do the signs look like (maybe I am not looking at the right thing)?
Cheers, Doru > On Jan 31, 2016, at 9:42 AM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > 2016-01-25 20:10 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: > > > 2016-01-20 23:23 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: > > > 2016-01-20 19:18 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: > > > 2016-01-20 14:47 GMT+01:00 Andrei Chis <chisvasileand...@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 > 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 Rubric mutability issue in RubTextComposer binary search > 17284 Rubric SubscriptOutOfBounds error > 17447 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 <nicolaih...@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 -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."
