Proper object removal

if you inspect this you get an inspector on an Array. To the left
select any entry with a left click (on Windows) and select "objects
pointing to this value". You get another inspector with an array of
the objects pointing to the object you can't delete.

Again inspecting one of these objects you can see how it points to
your original object. This might give you a clue. And manually
deleting these references (setting them to nil in the inspector) will
eventually free your original object for garbage collection.

If some of the objects you find are WeakArray or such you are in the
(to me) murky area of finalization and weak references. Squeak dev
would be the place to ask.

You don't state the size of your problem. Is it three or is it
thousands of instances hanging around?.

I once tried the pointer finder tool but wasn't satisfied with it.

And the swiki has a page on "cleaning up junk".

RR> I still see the object I removed, even with an explicit
RR> Smalltalk garbageCollect or garbageCollectMost. 

RR>  Anything I create seems to hang around forever.

Sometimes saving and reloading an image does a more thorough job than
garbageCollect. Maybe because of the above mentioned weak references.

Yikes. Klaus, please keep the hair-splitting to squeak-dev if possible.

Assigning to a block parameter is just wrong. Setting temps to nil is unnecessary in any normal method. If your code actually needs to worry about this, then you left the beginner playground.

Rob: Here's a recipe to find out what is keeping your instances from being garbage-collected:

http://wiki.squeak.org/squeak/2631

The objects are still referenced in the collection you get
from self selected. The line with "each := nil" is useless
as each is only a temporary variable. I assume that you want
to empty the selected collection as well. you could do

DataManager>>deleteSelectedAbstractors
  self selected copy do: [:each |
  self abstractors remove: each.
  self selected remove: each.
]

On Wed, Jun 4, 2008 at 3:55 AM, Norbert Hartl <[hidden email]> wrote:

The objects are still referenced in the collection you get
from self selected. The line with "each := nil" is useless
as each is only a temporary variable. I assume that you want
to empty the selected collection as well. you could do

DataManager>>deleteSelectedAbstractors
  self selected copy do: [:each |
  self abstractors remove: each.
  self selected remove: each.
]

So...why would I use a copy (self selected copy) in this case?  Is that a clue to my misunderstanding?

Rob

{'this ', 'and ', 'that'} collect: [:each | ].
Smalltalk garbageCollect.
{thisContext tempAt: 1} inspect

first line: create some object and make a temp var point to it.
second line: invoke GC.
third line: see what's still pointed to by the temp var.

What you want to see (according to your question about object removal) is just the empty array; and what I wanted to point out (without hair-splitting ;) is, that when you GC+check this within the same method, it *must* fail.

In Smalltalk it's very easy to script the removal+GC+check, for example in a workspace or add GC+check temporarily in a debugger session; that was my concern.

A good example for maintaining parent/child objects, which works perfectly, is Smalltalk's #addSubclass: #removeSubclass: (both on the instance side of Class); when you check these two methods think that 'superclass' is your parent pointer.

I don't care if it is called hair-splitting or something different. I
must agree with Bert. I found it interesting but misplaced on beginners.
What you were talking about had nothing to do with the Problem Rob was
asking (and to continue in Bert's words: If you use thisContext tempAt:
you've left the beginner area already). With your first line you
confused even me and I'm little bit reluctant now to be called a
newbie ;)

Writing

{ 'this', 'and', 'that' }

instead of

Array with: 'this and that'

let people like me assume there is some black magic happening. To under-
stand the problem dots instead of commata makes it clearer. So maybe you
can understand that while you are right you can spread uncertainty to
those which aren't that experienced (this includes me as well). And
to some who are that experienced it appears like hair-splitting ;)