Hi All,
I'm simulating a VMMaker image generated by closing several windows, leaving only a single workspace open:
Monticello Browser Transcript In-image Compilation Workspace Message Names Form CameraInterface class Form In-image Compilation Workspace IGC Workspace Webcam Workspace 3DICL Source Generation Workspace Recording Workspace Spur and 3D Synchronization Workspace (play A) ToDo Workspace Socket Workspace WebCam Resolution Workspace Slang Test Workspace Message Names VM Simulation Workspace Version: 3DICC-Plugins-eem.115 Senders of buildCenterRows Slang Test Workspace Workspace
Alas all the closed windows are still present, and still consuming lots of time getting processed at start-up time.
The thing keeping all these instances alive is the TextEditorCommandHistory. Here is the pointer chase for one of the windows, obtained via PluggableSystemWindow someInstance chasePointers
If one uses "chase pointers" in an inspector on all instances of PluggableSystemWindow then the deferred action queue may show up as the thing keeping the window alive. It isn't.
Smalltalk an IdentityDictionary(size 4991) a HandMorph(878960) a TextMorphForEditView(2311672) a SmalltalkEditor a TextEditorCommandHistory {a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand} a TextEditorCommand a Text for '' a PluggableSystemWindow<Monticello Browser>(2275431) '' a RunArray runs: #(1 52 1) values: {{a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)} . {a TextInspectIt} . {a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)}} {{a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)} . {a TextInspectIt} . {a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)}} {a TextInspectIt} a TextInspectIt a PluggableSystemWindow<Monticello Browser>(2275431) _,,,^..^,,,_ best, Eliot
Hi Eliot,
could you reproduce this, starting from a fresh image? By opening a workspace, typing something into it, and closing it again, or opening and closing a Monticello browser, I could not reproduce it.
Nevertheless, the issue you are describing sounds familiar to me. Does Extras > Purge Undo Records serve as a workaround for you?
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2024-04-26T14:35:29-07:00, eliot.miranda@gmail.com wrote:
Hi All,
I'm simulating a VMMaker image generated by closing several windows,
leaving only a single workspace open:
Monticello Browser Transcript In-image Compilation Workspace Message Names Form CameraInterface class Form In-image Compilation Workspace IGC Workspace Webcam Workspace 3DICL Source Generation Workspace Recording Workspace Spur and 3D Synchronization Workspace (play A) ToDo Workspace Socket Workspace WebCam Resolution Workspace Slang Test Workspace Message Names VM Simulation Workspace Version: 3DICC-Plugins-eem.115 Senders of buildCenterRows Slang Test Workspace Workspace
Alas all the closed windows are still present, and still consuming lots of time getting processed at start-up time.
The thing keeping all these instances alive is the TextEditorCommandHistory. Here is the pointer chase for one of the windows, obtained via PluggableSystemWindow someInstance chasePointers
If one uses "chase pointers" in an inspector on all instances of PluggableSystemWindow then the deferred action queue may show up as the thing keeping the window alive. It isn't.
Smalltalk an IdentityDictionary(size 4991) a HandMorph(878960) a TextMorphForEditView(2311672) a SmalltalkEditor a TextEditorCommandHistory {a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand} a TextEditorCommand a Text for '' a PluggableSystemWindow<Monticello Browser>(2275431) '' a RunArray runs: #(1 52 1) values: {{a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)} . {a TextInspectIt} . {a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)}} {{a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)} . {a TextInspectIt} . {a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)}} {a TextInspectIt} a TextInspectIt a PluggableSystemWindow<Monticello Browser>(2275431) _,,,^..^,,,_ best, Eliot
Hi all --
What keeps closed windows alive is the generic Command and CommandHistory (in MorphicExtras-Undo), not the quite local and specific TextEditorCommand(History).
See: - Morph >> #dismissViaHalo
The regular window close button does not fill that history. Just close-via-halo does.
Best, Marcel
Am 30.04.2024 um 17:03 schrieb christoph.thiede@student.hpi.uni-potsdam.de:
Hi Eliot,
could you reproduce this, starting from a fresh image? By opening a workspace, typing something into it, and closing it again, or opening and closing a Monticello browser, I could not reproduce it.
Nevertheless, the issue you are describing sounds familiar to me. Does Extras > Purge Undo Records serve as a workaround for you?
Best, Christoph
Sent from Squeak Inbox Talk
On 2024-04-26T14:35:29-07:00, eliot.miranda@gmail.com wrote:
Hi All,
I'm simulating a VMMaker image generated by closing several windows,
leaving only a single workspace open:
Monticello Browser Transcript In-image Compilation Workspace Message Names Form CameraInterface class Form In-image Compilation Workspace IGC Workspace Webcam Workspace 3DICL Source Generation Workspace Recording Workspace Spur and 3D Synchronization Workspace (play A) ToDo Workspace Socket Workspace WebCam Resolution Workspace Slang Test Workspace Message Names VM Simulation Workspace Version: 3DICC-Plugins-eem.115 Senders of buildCenterRows Slang Test Workspace Workspace
Alas all the closed windows are still present, and still consuming lots of time getting processed at start-up time.
The thing keeping all these instances alive is the TextEditorCommandHistory. Here is the pointer chase for one of the windows, obtained via PluggableSystemWindow someInstance chasePointers
If one uses "chase pointers" in an inspector on all instances of PluggableSystemWindow then the deferred action queue may show up as the thing keeping the window alive. It isn't.
Smalltalk an IdentityDictionary(size 4991) a HandMorph(878960) a TextMorphForEditView(2311672) a SmalltalkEditor a TextEditorCommandHistory {a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand . a TextEditorCommand} a TextEditorCommand a Text for '' a PluggableSystemWindow<Monticello Browser>(2275431) '' a RunArray runs: #(1 52 1) values: {{a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)} . {a TextInspectIt} . {a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)}} {{a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)} . {a TextInspectIt} . {a TextColor code: (Color r: 0.0 g: 0.0 b: 0.5)}} {a TextInspectIt} a TextInspectIt a PluggableSystemWindow<Monticello Browser>(2275431) _,,,^..^,,,_ best, Eliot
squeak-dev@lists.squeakfoundation.org