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 <nicolaihess@gmail.com> wrote:
>
>
>
> 2016-01-25 20:10 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
>
>
> 2016-01-20 23:23 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
>
>
> 2016-01-20 19:18 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
>
>
> 2016-01-20 14:47 GMT+01:00 Andrei Chis <chisvasileandrei@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 <nicolaihess@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."