Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

[Andrei Chis]

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

On Wed, Jan 20, 2016 at 2:32 PM, Nicolai Hess  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
>

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

[Nicolai Hess]

2016-01-20 14:47 GMT+01:00 Andrei Chis :

> 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




>
> On Wed, Jan 20, 2016 at 2:32 PM, Nicolai Hess 
> 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
>>
>
>

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

[Nicolai Hess]

2016-01-20 19:18 GMT+01:00 Nicolai Hess :

>
>
> 2016-01-20 14:47 GMT+01:00 Andrei Chis :
>
>> 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.




>
>
>
>
>>
>> On Wed, Jan 20, 2016 at 2:32 PM, Nicolai Hess 
>> 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
>>>
>>
>>
>

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

[Nicolai Hess]

2016-01-20 23:23 GMT+01:00 Nicolai Hess :

>
>
> 2016-01-20 19:18 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2016-01-20 14:47 GMT+01:00 Andrei Chis :
>>
>>> 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.



>
>
>
>
>>
>>
>>
>>
>>>
>>> On Wed, Jan 20, 2016 at 2:32 PM, Nicolai Hess 
>>> 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

>>>
>>>
>>
>

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

[Nicolai Hess]

2016-01-25 20:10 GMT+01:00 Nicolai Hess :

>
>
> 2016-01-20 23:23 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2016-01-20 19:18 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2016-01-20 14:47 GMT+01:00 Andrei Chis :
>>>
 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 
 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
>


>>>
>>
>

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

[Tudor Girba]

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

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

[Nicolai Hess]

2016-01-31 13:46 GMT+01:00 Tudor Girba :

> 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 "-> 14" (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"





>
>
> > On Jan 31, 2016, at 9:42 AM, Nicolai Hess  wrote:
> >
> >
> >
> > 2016-01-25 20:10 GMT+01:00 Nicolai Hess :
> >
> >
> > 2016-01-20 23:23 GMT+01:00 Nicolai Hess :
> >
> >
> > 2016-01-20 19:18 GMT+01:00 Nicolai Hess :
> >
> >
> > 2016-01-20 14:47 GMT+01:00 Andrei Chis :
> > 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 al

Re: [Pharo-dev] Rubric: spotter with preview leaks some memory

[Nicolai Hess]

2016-01-31 14:52 GMT+01:00 Nicolai Hess :

>
>
> 2016-01-31 13:46 GMT+01:00 Tudor Girba :
>
>> 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 "-> 14" (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 
>> wrote:
>> >
>> >
>> >
>> > 2016-01-25 20:10 GMT+01:00 Nicolai Hess :
>> >
>> >
>> > 2016-01-20 23:23 GMT+01:00 Nicolai Hess :
>> >
>> >
>> > 2016-01-20 19:18 GMT+01:00 Nicolai Hess :
>> >
>> >
>> > 2016-01-20 14:47 GMT+01:00 Andrei Chis :
>> > 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 RubText