Re: [Newbies] Re: Proper object removal
On Wed, 2008-06-04 at 14:41 +0200, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 12:12:59 +0200, Bert Freudenberg wrote:
On 04.06.2008, at 10:32, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl 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.
Not 100% useless, since temporary variables (and arguments, for that
matter) survive any attempt, from within the same method, to garbage
collect them:
{'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.
Yikes. Klaus, please keep the hair-splitting to squeak-dev if possible.
Ah. Didn't know that enumerating+removing with a block with argument
+ GC'ing in the same method, belongs to hair-splitting. Instead, I always
thought that's one of the reasons that at least one to-be-removed object
is guaranteed to not go away.
But anyways, thanks for letting me know ;)
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 ;)
Norbert
Assigning to a block parameter is just wrong.
You better read before you write (the way you most often do indeed ;) then
you'd find that I didn't write any assignment to anything. Instead, I
ignored that and pointed to a potential beginner's problem. Sorry you
didn't like that ;)
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.
And if he does removal+GC+check for success in the same method? I cannot
see whether someone just copies arbitrary statements given in a response
to a question, or carefully puts them into separate methods, in his code
in his .image, now or never ;)
Rob: Here's a recipe to find out what is keeping your instances from
being garbage-collected:
http://wiki.squeak.org/squeak/2631
- Bert -
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Re: Proper object removal
On Thu, Jun 5, 2008 at 8:02 AM, Norbert Hartl [EMAIL PROTECTED] wrote:
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 ;)
Nonetheless, thanks to all your help, I understand things better now, and
can properly remove objects I currently have control over. Because I was
able to test things based on all your feedback, I have narrowed my problem
down to an Aida misunderstanding on my part.
For any Aida-ers out there, playing with a WebGrid, it's bound objects, and
garbage collection should lead one to a greater understanding of
WebSession(s) and WebSessionManager(s)! I'm not saying I've figured it out
yet--just that I can get reproducible results now!
Thanks for the help,
Rob
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Re: Proper object removal
Rob Rothwell wrote: Nonetheless, thanks to all your help, I understand things better now, and can properly remove objects I currently have control over. Because I was able to test things based on all your feedback, I have narrowed my problem down to an Aida misunderstanding on my part. For any Aida-ers out there, playing with a WebGrid, it's bound objects, and garbage collection should lead one to a greater understanding of WebSession(s) and WebSessionManager(s)! I'm not saying I've figured it out yet--just that I can get reproducible results now! Yes, WebGrid (kind of smart web table) caches presented objects in session presentation state (instances of your Apps, that is subclasses of WebApplication) until you clean up that state. Because Aida web apps don't have a session timeout by default, this cleanup is done explicitly, usually every night. But let we move this discussion back to Aida mailing list. Others can follow or join it here: http://www.aidaweb.si/community.html Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Re: Proper object removal
On 04.06.2008, at 10:32, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl 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.
Not 100% useless, since temporary variables (and arguments, for that
matter) survive any attempt, from within the same method, to garbage
collect them:
{'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.
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
- Bert -
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Re: Proper object removal
On Wed, Jun 4, 2008 at 6:12 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: 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. I was hoping that was not the case! I WANT to be a beginner right now, not understanding something simple! Rob: Here's a recipe to find out what is keeping your instances from being garbage-collected: http://wiki.squeak.org/squeak/2631 Thanks, Rob ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Re: Proper object removal
On Wed, Jun 4, 2008 at 8:41 AM, Klaus D. Witzel [EMAIL PROTECTED]
wrote:
{'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.
So...if I do line 1, then line 3, should I see items in the Array, or just
the Array itself.
This is all very interesting, because in my application I am creating lots
of collections of objects maintaining parent/child pointers, and I have
obviously just done it WRONG!
Chasing pointers and objects is showing me that when I remove objects from
my collections, I need to do that all the way down, I think...
Thank you for helping my brain move in the right direction.
Rob
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Re: Proper object removal
On Wed, Jun 4, 2008 at 9:41 AM, Klaus D. Witzel [EMAIL PROTECTED] wrote: 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. I guess it would have to, wouldn't it? 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. Thanks for pointing this out--maybe I can learn something and get this working properly! Rob ___ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Re: [Newbies] Re: Proper object removal
On 04.06.2008, at 15:20, Rob Rothwell wrote:
On Wed, Jun 4, 2008 at 8:41 AM, Klaus D. Witzel [EMAIL PROTECTED]
wrote:
{'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.
So...if I do line 1, then line 3, should I see items in the Array,
or just the Array itself.
This is all very interesting, because in my application I am
creating lots of collections of objects maintaining parent/child
pointers, and I have obviously just done it WRONG!
Chasing pointers and objects is showing me that when I remove
objects from my collections, I need to do that all the way down, I
think...
Normally you do not need to do this all the way down. Say you have a
tree of objects, where the parent points to its children, and the
children each back to its parent. Then it is sufficient to remove one
child to have the whole subtree rooted at the child go away. There is
no need to delete all the children's children. Also, the back
pointers do no harm. But it is important that there are no other
references to these objects - no inspectors, debuggers, etc.
As soon as there is no path from a global object to your object, it
is subject to garbage collection (which will happen later, not
immediately). The #allInstances method still finds these unreachable
objects, because it simply looks at each and every object that was not
yet gc'ed.
- Bert -
___
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
