Thanks for your suggestion!
I am selecting random pointers to chase and getting this in almost all of the results:
globals: Environment declarations: IdentityDictionary #ActiveWorld -> PasteUpMorph submorphs: Array 6: PluggableSystemWindow (3168378) submorphs: Array 3: PluggableTreeMorph (1993854) scroller: TransformMorph (3408406) submorphs: Array 3: IndentingListItemMorph (2996756) complexContents: PointerExplorerWrapper item: Association value: Array
... and the last entry in the list is an object that is a subclass of the HWEntity class, like:
22392: HWGround.
Does this mean that my objects are being held onto by user interface objects? My UI elements are no longer being displayed so I don't know how this can be the case.
Thanks again!
Chris
Very interesting thought came to my mind, as a result of this post, Christopher. Potentially interesting and I think worth a consideration.
You are talking about an 22392: HWGround object and it clicked. Digital circuitry. Is this a negative ground object? What does *that* mean, a ground? Itโs an electrical circuit, stupid.
Hurumpf, does that mean we can cause objects to shortToGriund and force garbage collection by #vmbexomeForeward: to nil? Are there the analog (^,^) to a ground circuit, in Squeak? Why not?
Does this make any sense, have utility, along with a Squeak System Monitor displaying the image thermodynamics of Pressure, Volume & Temperature?
Utilities. Hello, customer support. Are you a customer? Please give me your account number. We deliver on our Promises made.
Oops! Your payment method needs upgrading for the Pro Services you are using in-imageโฆ ๐ฐ๐๐ป๐๐๏ธโค๏ธโ๐ฉน
โขโขโข ๐๐ ๐ฎ๐ค๐ช ๐๐ง๐ ๐๐ง๐๐ซ๐๐ฃ๐ ๐ ๐๐ค๐ง๐จ๐๐๐, ๐ฉ๐๐๐ฃ๐ ๐ฎ๐ค๐ช ๐๐ค๐ง ๐ข๐ค๐ซ๐๐ฃ๐ ๐ค๐ซ๐๐ง, ๐จ๐ค ๐ฉ๐๐๐ฉ ๐ ๐๐ค๐ช๐ก๐ ๐จ๐๐๐๐ก๐ฎ ๐ฅ๐๐จ๐จ! ๐ผ๐ง๐ง๐๐ซ๐๐๐๐ง๐๐, ๐ง๐๐๐๐๐ฉ โข ๐ฟ๐๐ฉ๐จ๐ช๐ฃ ๐ฎ๐ฐ๐ฌ๐ โข ๐ฐ
On Dec 23, 2022, at 16:14, Christopher Becker cb627hf@gmail.com wrote:
๏ปฟ Thanks for your suggestion!
I am selecting random pointers to chase and getting this in almost all of the results:
globals: Environment declarations: IdentityDictionary #ActiveWorld -> PasteUpMorph submorphs: Array 6: PluggableSystemWindow (3168378) submorphs: Array 3: PluggableTreeMorph (1993854) scroller: TransformMorph (3408406) submorphs: Array 3: IndentingListItemMorph (2996756) complexContents: PointerExplorerWrapper item: Association value: Array
... and the last entry in the list is an object that is a subclass of the HWEntity class, like:
22392: HWGround.
Does this mean that my objects are being held onto by user interface objects? My UI elements are no longer being displayed so I don't know how this can be the case.
Thanks again!
Chris
Object>>#shortToGround
self finalize. ^ self becomeForward: nil.
โขโขโข ๐๐ ๐ฎ๐ค๐ช ๐๐ง๐ ๐๐ง๐๐ซ๐๐ฃ๐ ๐ ๐๐ค๐ง๐จ๐๐๐, ๐ฉ๐๐๐ฃ๐ ๐ฎ๐ค๐ช ๐๐ค๐ง ๐ข๐ค๐ซ๐๐ฃ๐ ๐ค๐ซ๐๐ง, ๐จ๐ค ๐ฉ๐๐๐ฉ ๐ ๐๐ค๐ช๐ก๐ ๐จ๐๐๐๐ก๐ฎ ๐ฅ๐๐จ๐จ! ๐ผ๐ง๐ง๐๐ซ๐๐๐๐ง๐๐, ๐ง๐๐๐๐๐ฉ โข ๐ฟ๐๐ฉ๐จ๐ช๐ฃ ๐ฎ๐ฐ๐ฌ๐ โข ๐ฐ
On Dec 23, 2022, at 16:47, rabbit rabbit@callistohouse.org wrote:
๏ปฟVery interesting thought came to my mind, as a result of this post, Christopher. Potentially interesting and I think worth a consideration.
You are talking about an 22392: HWGround object and it clicked. Digital circuitry. Is this a negative ground object? What does *that* mean, a ground? Itโs an electrical circuit, stupid.
Hurumpf, does that mean we can cause objects to shortToGriund and force garbage collection by #vmbexomeForeward: to nil? Are there the analog (^,^) to a ground circuit, in Squeak? Why not?
Does this make any sense, have utility, along with a Squeak System Monitor displaying the image thermodynamics of Pressure, Volume & Temperature?
Utilities. Hello, customer support. Are you a customer? Please give me your account number. We deliver on our Promises made.
Oops! Your payment method needs upgrading for the Pro Services you are using in-imageโฆ ๐ฐ๐๐ป๐๐๏ธโค๏ธโ๐ฉน
โขโขโข ๐๐ ๐ฎ๐ค๐ช ๐๐ง๐ ๐๐ง๐๐ซ๐๐ฃ๐ ๐ ๐๐ค๐ง๐จ๐๐๐, ๐ฉ๐๐๐ฃ๐ ๐ฎ๐ค๐ช ๐๐ค๐ง ๐ข๐ค๐ซ๐๐ฃ๐ ๐ค๐ซ๐๐ง, ๐จ๐ค ๐ฉ๐๐๐ฉ ๐ ๐๐ค๐ช๐ก๐ ๐จ๐๐๐๐ก๐ฎ ๐ฅ๐๐จ๐จ! ๐ผ๐ง๐ง๐๐ซ๐๐๐๐ง๐๐, ๐ง๐๐๐๐๐ฉ โข ๐ฟ๐๐ฉ๐จ๐ช๐ฃ ๐ฎ๐ฐ๐ฌ๐ โข ๐ฐ
On Dec 23, 2022, at 16:14, Christopher Becker cb627hf@gmail.com wrote:
๏ปฟ Thanks for your suggestion!
I am selecting random pointers to chase and getting this in almost all of the results:
globals: Environment declarations: IdentityDictionary #ActiveWorld -> PasteUpMorph submorphs: Array 6: PluggableSystemWindow (3168378) submorphs: Array 3: PluggableTreeMorph (1993854) scroller: TransformMorph (3408406) submorphs: Array 3: IndentingListItemMorph (2996756) complexContents: PointerExplorerWrapper item: Association value: Array
... and the last entry in the list is an object that is a subclass of the HWEntity class, like:
22392: HWGround.
Does this mean that my objects are being held onto by user interface objects? My UI elements are no longer being displayed so I don't know how this can be the case.
Thanks again!
Chris
It strongly suggests that somewhere in your development time you didn't close a morph correctly.
Try selecting the PluggableSystemWindow (3168378) and inspecting it. Assuming that works, see if 'self delete' in the text view at the bottom of the inspector works. It *should* close the system window and after a garbage collect or two everything ought to be cleaned out.
On 2022-12-23, at 1:14 PM, Christopher Becker cb627hf@gmail.com wrote:
Thanks for your suggestion!
I am selecting random pointers to chase and getting this in almost all of the results:
globals: Environment declarations: IdentityDictionary #ActiveWorld -> PasteUpMorph submorphs: Array 6: PluggableSystemWindow (3168378) submorphs: Array 3: PluggableTreeMorph (1993854) scroller: TransformMorph (3408406) submorphs: Array 3: IndentingListItemMorph (2996756) complexContents: PointerExplorerWrapper item: Association value: Array
... and the last entry in the list is an object that is a subclass of the HWEntity class, like:
22392: HWGround.
Does this mean that my objects are being held onto by user interface objects? My UI elements are no longer being displayed so I don't know how this can be the case.
Thanks again!
Chris
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- S p a c e d o u t .
Since there is a PointerExplorerWrapper in this trace I believe that a pointer explorer is already open on one of the objects, or that this tool does not exclude itself from its own pointer search...
If the latter is the case, it would be a Heisentool, where the attempt of using it changes that which it is supposed to observe. :-P
tim Rowledge tim@rowledge.org schrieb am Sa., 24. Dez. 2022, 01:26:
It strongly suggests that somewhere in your development time you didn't close a morph correctly.
Try selecting the PluggableSystemWindow (3168378) and inspecting it. Assuming that works, see if 'self delete' in the text view at the bottom of the inspector works. It *should* close the system window and after a garbage collect or two everything ought to be cleaned out.
On 2022-12-23, at 1:14 PM, Christopher Becker cb627hf@gmail.com wrote:
Thanks for your suggestion!
I am selecting random pointers to chase and getting this in almost all
of the results:
globals: Environment declarations: IdentityDictionary #ActiveWorld -> PasteUpMorph submorphs: Array 6: PluggableSystemWindow (3168378) submorphs: Array 3: PluggableTreeMorph (1993854) scroller: TransformMorph (3408406) submorphs: Array 3: IndentingListItemMorph (2996756) complexContents: PointerExplorerWrapper item: Association value: Array
... and the last entry in the list is an object that is a subclass of
the HWEntity class, like:
22392: HWGround.
Does this mean that my objects are being held onto by user interface
objects? My UI elements are no longer being displayed so I don't know how this can be the case.
Thanks again!
Chris
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- S p a c e d o u t .
On Mon, Dec 26, 2022 at 10:04 AM Jakob Reschke jakres+squeak@gmail.com wrote:
Since there is a PointerExplorerWrapper in this trace I believe that a pointer explorer is already open on one of the objects, or that this tool does not exclude itself from its own pointer search...
If the latter is the case, it would be a Heisentool, where the attempt of using it changes that which it is supposed to observe. :-P
Which is why I don't use the pointer explorer when I'm trying to clean all instance of a class out. Instead:
TheClass allInstances anyOne chasePointers
:-P
:)
On Dec 26, 2022, at 3:23 PM, Chris Muller asqueaker@gmail.com wrote:
๏ปฟ
On Mon, Dec 26, 2022 at 10:04 AM Jakob Reschke jakres+squeak@gmail.com wrote:
Since there is a PointerExplorerWrapper in this trace I believe that a pointer explorer is already open on one of the objects, or that this tool does not exclude itself from its own pointer search...
If the latter is the case, it would be a Heisentool, where the attempt of using it changes that which it is supposed to observe. :-P
Which is why I don't use the pointer explorer when I'm trying to clean all instance of a class out. Instead:
TheClass allInstances anyOne chasePointers
TheClass someInstance ifNotNil: [:obj| obj chasePointers]
_,,,^..^,,,_ (phone)
If the latter is the case, it would be a Heisentool, where the attempt of
using it changes that which it is supposed to observe. :-P
Which is why I don't use the pointer explorer when I'm trying to clean all instance of a class out. Instead:
TheClass allInstances anyOne chasePointersTheClass someInstance ifNotNil: [:obj| obj chasePointers]
Ah, I will start using #someInstance, but typing ifNotNil: is a lot more work than closing a debugger when no more instances. Besides, wouldn't the Block Context's var, "obj" be another possible reference that #chasePointers might pick up on?
Hi Chris,
On Tue, Dec 27, 2022 at 11:50 AM Chris Muller ma.chris.m@gmail.com wrote:
If the latter is the case, it would be a Heisentool, where the attempt of
using it changes that which it is supposed to observe. :-P
Which is why I don't use the pointer explorer when I'm trying to clean all instance of a class out. Instead:
TheClass allInstances anyOne chasePointersTheClass someInstance ifNotNil: [:obj| obj chasePointers]
Ah, I will start using #someInstance, but typing ifNotNil: is a lot more work than closing a debugger when no more instances. Besides, wouldn't the Block Context's var, "obj" be another possible reference that #chasePointers might pick up on?
ifNotNil: is inlined. It is equivalent to this, but saves the temp decl, which is why it's so nice.
| obj | obj := TheClass someInstance. obj == nil ifFalse: [obj chasePointers]
_,,,^..^,,,_ best, Eliot
Hi Eliot,
ifNotNil: is inlined. It is equivalent to this, but saves the temp decl, which is why it's so nice.
| obj | obj := TheClass someInstance. obj == nil ifFalse: [obj chasePointers]
Why won't #chasePointers pick up the obj tempvar from the snippet above? Is this just because contexts are only married on demand?
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Donnerstag, 29. Dezember 2022 04:21 Uhr An: Chris Muller Cc: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Constantly growing Image file
Hi Chris,
On Tue, Dec 27, 2022 at 11:50 AM Chris Muller <ma.chris.m@gmail.commailto:ma.chris.m@gmail.com> wrote: If the latter is the case, it would be a Heisentool, where the attempt of using it changes that which it is supposed to observe. :-P
Which is why I don't use the pointer explorer when I'm trying to clean all instance of a class out. Instead:
TheClass allInstances anyOne chasePointers
TheClass someInstance ifNotNil: [:obj| obj chasePointers]
Ah, I will start using #someInstance, but typing ifNotNil: is a lot more work than closing a debugger when no more instances. Besides, wouldn't the Block Context's var, "obj" be another possible reference that #chasePointers might pick up on?
ifNotNil: is inlined. It is equivalent to this, but saves the temp decl, which is why it's so nice.
| obj | obj := TheClass someInstance. obj == nil ifFalse: [obj chasePointers]
_,,,^..^,,,_ best, Eliot
On Dec 29, 2022, at 5:17 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
๏ปฟ Hi Eliot,
ifNotNil: is inlined. It is equivalent to this, but saves the temp decl, which is why it's so nice.
| obj | obj := TheClass someInstance. obj == nil ifFalse: [obj chasePointers]
Why won't #chasePointers pick up the obj tempvar from the snippet above? Is this just because contexts are only married on demand?
IIRC itโs because chasePointers explicitly excludes its sender context.
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Donnerstag, 29. Dezember 2022 04:21 Uhr An: Chris Muller Cc: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Constantly growing Image file
Hi Chris,
On Tue, Dec 27, 2022 at 11:50 AM Chris Muller ma.chris.m@gmail.com wrote:
If the latter is the case, it would be a Heisentool, where the attempt of using it changes that which it is supposed to observe. :-P
Which is why I don't use the pointer explorer when I'm trying to clean all instance of a class out. Instead:
TheClass allInstances anyOne chasePointersTheClass someInstance ifNotNil: [:obj| obj chasePointers]
Ah, I will start using #someInstance, but typing ifNotNil: is a lot more work than closing a debugger when no more instances. Besides, wouldn't the Block Context's var, "obj" be another possible reference that #chasePointers might pick up on?
ifNotNil: is inlined. It is equivalent to this, but saves the temp decl, which is why it's so nice.
| obj | obj := TheClass someInstance. obj == nil ifFalse: [obj chasePointers]
_,,,^..^,,,_ best, Eliot
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
Christopher Becker -
Eliot Miranda -
Jakob Reschke -
rabbit -
Thiede, Christoph -
tim Rowledge