2016-01-31 14:52 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:

>
>
> 2016-01-31 13:46 GMT+01:00 Tudor Girba <tu...@tudorgirba.com>:
>
>> 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
>>
>
> Open Spotter
> Enable Preview
> search for EllipseMorph
> dive into class EllipseMorph
> dive into (all) instance methods
> scroll through the list of methods ~  1/2 methods per second
> close spotter
> open Playground
> evaluate
> RubTextLine allInstances size "-> 140000" (yes 140 THOUSEND)
> again evaulate
>
> Smalltalk garbageCollect.
> RubTextLine allInstances size "if you are lucky this goes doewn to ~ < 10
> instances but"
>
> repeat this (spotter with preview scroll through the list)
> maybe scroll faster
>
> Smalltalk garbageCollect.
> RubTextLine allInstances size "->1206704"
> and after every new evuation, the count of instances grows instead of
> shrink.
> And even with no further action, the amount of (system)memory used by
> pharo steadily grows.
>
> The only way to make this list go down again, open process browser and
> look for a process like
> "a Process in RunArray>>at:setRunOffsetAndValue:"
> and terminate this process.
>
> Smalltalk garbageCollect.
> RubTextLine allInstances size  "-> 4"
>
>
And (very often) I get this error:

OrderedCollection(Object)>>errorSubscriptBounds:
OrderedCollection>>at:
RubTextComposer>>recomposeFrom:to:delta:
[ self composer recomposeFrom: start to: stop delta: delta ] in
RubParagraph>>recomposeFrom:to:delta: in Block: [ self composer
recomposeFrom: start to: stop delt...etc...
RubParagraph>>disableDrawingWhile:
RubParagraph>>recomposeFrom:to:delta:
Message>>sendTo:
[ aMessage sendTo: next ] in
RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand:
#recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ]
BlockClosure>>on:do:
RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand:
#recomposeFrom:to:delta:
Message>>sendTo:
[ aMessage sendTo: next ] in
RubExtraSelectionDecorator(RubParagraphDecorator)>>doesNotUnderstand:
#recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ]
BlockClosure>>on:do:
RubExtraSelectionDecorator(RubParagraphDecorator)>>doesNotUnderstand:
#recomposeFrom:to:delta:
Message>>sendTo:
[ aMessage sendTo: next ] in
RubCurrentLineBarDecorator(RubParagraphDecorator)>>doesNotUnderstand:
#recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ]
BlockClosure>>on:do:
RubCurrentLineBarDecorator(RubParagraphDecorator)>>doesNotUnderstand:
#recomposeFrom:to:delta:
Message>>sendTo:
[ aMessage sendTo: next ] in
RubShoutStylerDecorator(RubParagraphDecorator)>>doesNotUnderstand:
#recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ]
BlockClosure>>on:do:
RubShoutStylerDecorator(RubParagraphDecorator)>>doesNotUnderstand:
#recomposeFrom:to:delta:
RubShoutStylerDecorator>>stylerStyled:
RubShoutStylerDecorator>>stylerStyledInBackground:
[ self privateStyle: text.
view ifNotNil: [ view stylerStyledInBackground: text ] ] in [
backgroundProcess := [ self privateStyle: text.
view ifNotNil: [ view stylerStyledInBackground: text ] ]
    forkAt: Processor userBackgroundPriority ] in
RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: in Block: [
self privateStyle: text....
[ self value.
Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self
value....




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