Squeak-dev February 2024

squeak-dev@lists.squeakfoundation.org

32 participants
107 discussions

Please ignore | Test (mailing list membership)
by Christoph Thiede 06 Feb '24

06 Feb '24

Will this message, sent from my secondary e-mail address as set up in postman, be accepted to the list (squeak-dev)? To any moderator who is requested to manually review this message, please reject it. Sorry for the noise! Best, Christoph

1 0

Is MCDiffyVersion counter productive?
by Nicolas Cellier 06 Feb '24

06 Feb '24

Hi all, I have noticed that upgrading an image to be on par with trunk was becoming incredibly slow. Notably, there were very long pauses with information dialog telling 'snapshotting...'. So I have interrupted the process and watched thru debugger... That was due to long chains of .mcd: each element is involving a new directory scan of the bloated package-cache... For example, a single MCWorkingCopy>>findSnapshotWithVersionInfo: System-ct.1444 leads to catastrophic MessageTally spyOn: [snapshot := MCPatcher apply: patch to: self baseSnapshot]. - 143610 tallies, 188827 msec. **Tree** -------------------------------- Process: (40) 56225: nil -------------------------------- 99.2% {187281ms} [] MorphicProject>>spawnNewProcess 99.2% {187281ms} PasteUpMorph>>doOneCycle ...snip... **Leaves** 80.6% {152119ms} UnixFileDirectory(FileDirectory)>>directoryContentsFor:do: 5.2% {9861ms} DirectoryEntry class>>fromArray:directory: 1.5% {2849ms} WriteStream>>nextPut: Each MCCacheRepository(MCRepository)>>versionWithInfo: costs about 3 to 4 seconds! It's clear that I should better clean some cache, but I wonder about the overall .mcd/.mcz strategy. Network latency is clearly not dominating my own costs! Nicolas

3 5

Re: The Inbox: System-dtl.1446.mcz
by Jaromir Matas 04 Feb '24

04 Feb '24

Hi Dave, This is cool :) I'd like to ask you a few questions if you don't mind: 1. I can't see any implementor of #freeSomeSpace (and it wasn't there even before your changes) - why's that? 2. I can't see any senders of #registerCleaner: - does it mean the system doesn't use this or what am I missing? 3. If I'm not mistaken the condition in #safeToInstall is equivalent to: safeToInstall "Free space must be above threshold before starting low space watcher" ^SmalltalkgarbageCollectMost>SmalltalklowSpaceThreshold or:[SmalltalkgarbageCollect>SmalltalklowSpaceThreshold] - which is (at least to me) a bit better decipherable. 4. I've noticed you replaced `LowSpaceWatcher install` with `LowSpaceWatcher default start` in #lowSpaceWatcher - nice, no need to terminate explicitly; I just wonder why to nil the lowSpaceProcess variable in #disableVirtualMachineNotifications. Thanks a lot, it's a joy to read the refactored code :) best -- Jaromir

3 7

infinite recursion on updating
by Eliot Miranda 03 Feb '24

03 Feb '24

Hi All, I'm guessing there's some package ordering update missing to ensure the new debugger cue is defined. I just attempted to update a VMMaker image and got the following infinite recursion: 0x1465199e8 s UndefinedObject>handleSignal: 0x1186898e0: a(n) UndefinedObject 0x146518030 s MessageNotUnderstood(Exception)>signal 0x146517c30: a(n) MessageNotUnderstood 0x146517818 s UndefinedObject(Object)>doesNotUnderstand: new 0x1186898e0: a(n) UndefinedObject 0x146517c78 s ProcessorScheduler>debugContext:title:full:contents: 0x11869afe0: a(n) ProcessorScheduler 0x1465180e8 s ECToolSet class(StandardToolSet class)>handleError: 0x1195d6c88: a(n) ECToolSet 0x146518500 s ToolSet class>handleError: 0x118a26690: a(n) ToolSet 0x146518900 s UnhandledError>defaultAction 0x146518e50: a(n) UnhandledError 0x146518d98 s UndefinedObject>handleSignal: 0x1186898e0: a(n) UndefinedObject 0x1465191d0 s UnhandledError(Exception)>signal 0x146518e50: a(n) UnhandledError 0x146519668 s UnhandledError class>signalForException: 0x118a27df8: a(n) UnhandledError 0x146519aa0 s MessageNotUnderstood(Error)>defaultAction 0x1465185b8: a(n) MessageNotUnderstood 0x146519f38 s MessageNotUnderstood>defaultAction 0x1465185b8: a(n) MessageNotUnderstood 0x14651a370 s UndefinedObject>handleSignal: 0x1186898e0: a(n) UndefinedObject 0x1465189b8 s MessageNotUnderstood(Exception)>signal 0x1465185b8: a(n) MessageNotUnderstood 0x1465181a0 s UndefinedObject(Object)>doesNotUnderstand: new 0x1186898e0: a(n) UndefinedObject 0x146518600 s ProcessorScheduler>debugContext:title:full:contents: 0x11869afe0: a(n) ProcessorScheduler 0x146518a70 s ECToolSet class(StandardToolSet class)>handleError: 0x1195d6c88: a(n) ECToolSet 0x146518e88 s ToolSet class>handleError: 0x118a26690: a(n) ToolSet 0x146519288 s UnhandledError>defaultAction 0x1465197d8: a(n) UnhandledError 0x146519720 s UndefinedObject>handleSignal: 0x1186898e0: a(n) UndefinedObject 0x146519b58 s UnhandledError(Exception)>signal 0x1465197d8: a(n) UnhandledError 0x146519ff0 s UnhandledError class>signalForException: 0x118a27df8: a(n) UnhandledError 0x14651a428 s MessageNotUnderstood(Error)>defaultAction 0x146518f40: a(n) MessageNotUnderstood 0x14651a8c0 s MessageNotUnderstood>defaultAction 0x146518f40: a(n) MessageNotUnderstood 0x14651acf8 s UndefinedObject>handleSignal: 0x1186898e0: a(n) UndefinedObject 0x146519340 s MessageNotUnderstood(Exception)>signal 0x146518f40: a(n) MessageNotUnderstood 0x146518b28 s UndefinedObject(Object)>doesNotUnderstand: new 0x1186898e0: a(n) UndefinedObject 0x146518f88 s ProcessorScheduler>debugContext:title:full:contents: 0x11869afe0: a(n) ProcessorScheduler 0x1465193f8 s ECToolSet class(StandardToolSet class)>handleError: 0x1195d6c88: a(n) ECToolSet 0x146519810 s ToolSet class>handleError: 0x118a26690: a(n) ToolSet 0x146519c10 s UnhandledError>defaultAction 0x14651a160: a(n) UnhandledError 0x14651a0a8 s UndefinedObject>handleSignal: 0x1186898e0: a(n) UndefinedObject 0x14651a4e0 s UnhandledError(Exception)>signal 0x14651a160: a(n) UnhandledError 0x14651a978 s UnhandledError class>signalForException: 0x118a27df8: a(n) UnhandledError 0x14651adb0 s MessageNotUnderstood(Error)>defaultAction 0x1465198c8: a(n) MessageNotUnderstood 0x14651b248 s MessageNotUnderstood>defaultAction 0x1465198c8: a(n) MessageNotUnderstood 0x14651b680 s UndefinedObject>handleSignal: 0x1186898e0: a(n) UndefinedObject 0x146519cc8 s MessageNotUnderstood(Exception)>signal 0x1465198c8: a(n) MessageNotUnderstood 0x1465194b0 s UndefinedObject(Object)>doesNotUnderstand: new 0x1186898e0: a(n) UndefinedObject 0x146519910 s ProcessorScheduler>debugContext:title:full:contents: 0x11869afe0: a(n) ProcessorScheduler _,,,^..^,,,_ best, Eliot

7 30

The Inbox: Kernel-jar.1555.mcz
by commits＠source.squeak.org 02 Feb '24

02 Feb '24

A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-jar.1555.mcz ==================== Summary ==================== Name: Kernel-jar.1555 Author: jar Time: 2 February 2024, 10:28:00.518051 pm UUID: 2b2e05af-0a76-dd48-ac77-04c73f5dbda0 Ancestors: Kernel-mt.1551 apply a similar modification that was applied to #contextEnsure: in Kernel-jar.1553 =============== Diff against Kernel-mt.1551 =============== Item was changed: ----- Method: Context class>>contextOn:do: (in category 'special context creation') ----- contextOn: exceptionClass do: block "Create an #on:do: context that is ready to return from executing its receiver. As ctxt is *not* a top context as required by #jump, we need to put a (fake) return value (nil) on its stack. Otherwise, #jump will pop something different from the stack. Concretely, this caused the bug described in [1] (Scenario 1) because the latest stack top was the closure vector {chain}. This closure vector was accidently popped away so that in the final return statement, #pushRemoteTemp:inVectorAt: raised an error subscript bounds (because the next stack item was not variable). Read the linked bug report for more details. [1] http://forum.world.st/BUG-s-in-Context-control-jump-runUntilErrorOrReturnFr…" | ctxt chain | ctxt := thisContext. + [chain := thisContext sender. - [chain := thisContext sender cut: ctxt. ctxt push: nil. "fake return value" ctxt jump] on: exceptionClass do: block. "jump above will resume here without unwinding chain" + ^ chain privSender: nil + "nil chain's sender after the jump rather than before to prevent unwind failure during termination, see bug report [2]: + + [2] https://github.com/squeak-smalltalk/squeak-object-memory/issues/112"! - ^ chain!

1 0

lowMemoryWatcher--a different question
by Hal Eden 02 Feb '24

02 Feb '24

Hi all. i’ve been wanting to send this for a while but haven’t been receiving the squeak lists, so i wasn’t sure if it might have been discussed as part of the low-memory-watcher discussion. i was working to get my subscription to the mailing working to no avail. however, i have reviewed the archives and it doesn’t appear that this aspect has been raised. btw, i finally registered with my gmail address instead, so i’m getting the list again. since i’m seeing some traffic on lowSpaceWatcher, i thought i’d send this along. we are running an ancient swiki server (squeak 3.7, swiki 1.5—same as wiki.squeak.org, i guess) and we will occasionally have it go into a low space condition displaying the “space is low” debug window even though the Memory Usage Morph indicates there is a reasonable amount of memory available. in addition i don’t seem to be able to escape out of the “space is low” debug window once this happens. i’m not asking for a fix to an old Squeak version, just wondering what might be a reasonable approach here and whether the insights might still inform current systems. in looking at what might cause this, it seems that this is triggered when a “new:” (rather “basicNew:”) primitive fails. i understand that the VM primitive only returns success or failure, so the reason why it fails is assumed to be low memory, thus the low space condition trigger. of course, i haven’t been able to get this to happen in production since i started looking into it, so i don’t have any debug traces to look at and trace back the real cause. so i tried Array new: <a very large number> and was able to trigger the condition, and indeed the memory variables still show space available (Smalltalk bytesLeft is still much greater than Smalltalk lowSpaceThreshold), which would seem to indicate that the issue is not “low memory” but “impossible request” (i know this is somewhat of a distinction without a difference, since if a new: request fails it is effectively an “impossible request” but the difference i see is that the request is much larger than is usual in the system, and this occurs when memoryLeft is much greater than lowSpaceThreshold, i.e., space is NOT low) i imagine that when this happens within a swiki/comanche request, it is caused by someone trying to overflow a buffer or something using http. when i do it from a workspace, the "space is low” debug window is triggered, but i am able to abandon it. what i wonder is whether some other error should be raised in this case rather than signalling low memory. if one were to check the state of the memory variables before signalling "out of memory” it might avoid this. but i’m not sure what error should be raised in this case. i guess some report of an “impossible” request in the web log might be useful. i haven’t been able to replicate this in newer versions of squeak with a more robust memory handling system, since it seems to rely more on virtual memory than on some sort of fixed allocation. but the code appears to do the same thing if “basicNew:” fails, so perhaps insights might be applicable here although it seems very difficult to trigger in new systems. (of course, i don’t think anyone has ported the swiki to newer systems?) anyway, your insights would be appreciated. hal

3 5

The Inbox: KernelTests-jar.418.mcz
by commits＠source.squeak.org 01 Feb '24

01 Feb '24

A new version of KernelTests was added to project The Inbox: http://source.squeak.org/inbox/KernelTests-jar.418.mcz ==================== Summary ==================== Name: KernelTests-jar.418 Author: jar Time: 20 December 2021, 9:37:26.122961 pm UUID: 229ac303-0cfa-2d45-8d4e-e2b19b88cba8 Ancestors: KernelTests-ct.415 add a test (expected failure) to document a bug in #priority via a failing test case. The bug was summarized in http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217473… and discussed in http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-td5126894.html and most likely requires a new primitive to fix it correctly. An interim fix was proposed in Kernel-jar.1368 to show the desirable functionality that satisfies this test. =============== Diff against KernelTests-ct.415 =============== Item was added: + ----- Method: ProcessTest>>expectedFailures (in category 'failures') ----- + expectedFailures + + ^ #(testDecreaseActiveProcessPriority)! Item was added: + ----- Method: ProcessTest>>testDecreaseActiveProcessPriority (in category 'tests') ----- + testDecreaseActiveProcessPriority + "test whether #priority: reschedules active process to allow higher priority processes run; + presently (12/2021) the test fails and is here to remind about the #priority bug discussed + in http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217473… + and http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-td5126894.html" + + | val oldPriority oldPreemptionYields | + val := nil. + oldPriority := Processor activePriority. + oldPreemptionYields := Smalltalk processPreemptionYields. + + [ + Processor activeProcess priority: oldPriority + 2. + [ val := false ] forkAt: oldPriority + 1. + [ val := true ] forkAt: oldPriority. + Processor activeProcess priority: oldPriority. + "depending on processPreemptionYields value the active process should be placed + either at the beginning or the end of the quiescentProcessLists at: oldPriority" + self assert: val = Smalltalk processPreemptionYields. + + "test both alternative settings (true/false) of processPreemptionYields" + val := nil. + Smalltalk processPreemptionYields: oldPreemptionYields not. + + Processor activeProcess priority: oldPriority + 2. + [ val := false ] forkAt: oldPriority + 1. + [ val := true ] forkAt: oldPriority. + Processor activeProcess priority: oldPriority. + self assert: val = Smalltalk processPreemptionYields. + + ] ensure: [ + "make sure processPreemptionYields is reset to its original value even if the test fails" + Smalltalk processPreemptionYields: oldPreemptionYields. + self assert: Smalltalk processPreemptionYields equals: oldPreemptionYields]!

3 4