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







Reply via email to