Marcel Taeumel uploaded a new version of KernelTests to project The Trunk:
http://source.squeak.org/trunk/KernelTests-cmm.423.mcz
==================== Summary ====================
Name: KernelTests-cmm.423
Author: cmm
Time: 31 May 2022, 5:53:42.444296 pm
UUID: a504f011-37fb-4d93-ae2f-c3e1fc832b49
Ancestors: KernelTests-nice.422
#testOutOfMemorySignalExtreme can be stressful on a system that running the Squeak VM unconstrained (which is the default). Therefore, only run it if the vm is explicitly constrained.
Note this requires
=============== Diff against KernelTests-nice.422 ===============
Item was changed:
----- Method: AllocationTest>>testOutOfMemorySignalExtreme (in category 'tests') -----
testOutOfMemorySignalExtreme
+ "Try to allocate more memory than permitted by the -memory vm argument, and check whether the expected error is signaled. Note that current (2017) Spur VMs fail in #new: and #basicNew: with #'bad argument' if given other than a non-negative SmallInteger."
+ Smalltalk heapMemoryLimit ifNotNil:
+ [ : bytes |
+ self
+ should: [ Array new: (bytes // Smalltalk wordSize) + 100 ]
+ raise: OutOfMemory, Error
+ withExceptionDo:
+ [:ex|
+ ex class == Error ifTrue:
+ [self assert: [ex messageText includesSubstring: 'basicNew: with invalid argument' ]]]]!
- "Try to allocate a ridiculous amount of memory and check whether the expected error is signaled. Call Eliot when this test fails, he want your machine. :-)
-
- Note that current (2017) Spur VMs fail in #new: and #basicNew: with #'bad argument' if given other than a non-negative SmallInteger.
-
- Also note that this test can be quite stressful to your machine depending on how your operating system allocates the required memory behind the curtains. Better not triggering some robot fetching a tape from somewhere..."
-
- | sz |
- sz := 1024*1024*1024*1024. "= 1 TiB"
- self should: [Array new: sz]
- raise: OutOfMemory, Error
- withExceptionDo:
- [:ex|
- ex class == Error ifTrue:
- [self assert: [ex messageText includesSubstring: 'basicNew: with invalid argument']]]!
Marcel Taeumel uploaded a new version of Tools to project The Treated Inbox:
http://source.squeak.org/treated/Tools-jar.1159.mcz
==================== Summary ====================
Name: Tools-jar.1159
Author: jar
Time: 29 May 2022, 5:12:52.367993 pm
UUID: bed7f2b8-2dd3-9b45-8262-ff51bc9dd5c3
Ancestors: Tools-mt.1158
Fix an inconsistent Debugger behavior WRT the two alternative abandon/termination modes introduced by Kernel-ct.1434 and Tools-ct.1092
Following up a conversation in http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220675.html
Complemented by ToolsTests-jar.110 fixing the failing/incorrects tests in ToolsTests-ct.107
=============== Diff against Tools-mt.1158 ===============
Item was changed:
CodeHolder subclass: #Debugger
+ instanceVariableNames: 'interruptedProcess contextStack contextStackIndex contextStackList receiverInspector receiverInspectorState contextVariablesInspector contextVariablesInspectorState externalInterrupt proceedValue selectingPC savedCursor isolationHead failedProject labelString message untilExpression terminationMethod'
- instanceVariableNames: 'interruptedProcess contextStack contextStackIndex contextStackList receiverInspector receiverInspectorState contextVariablesInspector contextVariablesInspectorState externalInterrupt proceedValue selectingPC savedCursor isolationHead failedProject labelString message untilExpression'
classVariableNames: 'ContextStackKeystrokes ErrorReportServer FullStackSize InterruptUIProcessIfBlockedOnErrorInBackgroundProcess NotifierStackSize SavedExtent StackSizeLimit WantsAnnotationPane'
poolDictionaries: ''
category: 'Tools-Debugger'!
!Debugger commentStamp: 'mt 12/17/2019 12:19' prior: 0!
I represent the machine state at the time of an interrupted process. I also represent a query path into the state of the process. The debugger is typically viewed through a window that views the stack of suspended contexts, the code for, and execution point in, the currently selected message, and inspectors on both the receiver of the currently selected message, and the variables in the current context.
Special note on recursive errors:
Some errors affect Squeak's ability to present a debugger. This is normally an unrecoverable situation. However, if such an error occurs in an isolation layer, Squeak will attempt to exit from the isolation layer and then present a debugger. Here is the chain of events in such a recovery.
* A recursive error is detected.
* The current project is queried for an isolationHead
* Changes in the isolationHead are revoked
* The parent project of isolated project is returned to
* The debugger is opened there and execution resumes.
If the user closes that debugger, execution continues in the outer project and layer. If, after repairing some damage, the user proceeds from the debugger, then the isolationHead is re-invoked, the failed project is re-entered, and execution resumes in that world.
---
In September 2019, we added MorphicDebugger and MVCDebugger to untangle framework-specific features in our debugger infrastructure. However, this is just an intermediate step. The overall goal would be to remove those two subclasses again while preserving their functionality. Mostly, MVC and Morphic differ in their GUI-process management. This means that "proceed" and "close" work differently depending on the process that is being debugged. --- One idea is to attach that framework-specific information to the process objects. See Process >> #environmentAt: and #environmentAt:put:. Also see ToolSet's #handle* and #debug* methods.!
Item was changed:
----- Method: Debugger>>abandon (in category 'context stack menu') -----
abandon
+ "close the debugger and terminate the debugged process"
- "abandon the debugger from its pre-debug notifier"
+ terminationMethod := #terminateAggressively.
+ self close
+ !
- self close.!
Item was changed:
----- Method: Debugger>>initialize (in category 'initialize') -----
initialize
super initialize.
Smalltalk at: #MessageTally ifPresentAndInMemory: [ :tally |
tally terminateTimerProcess].
externalInterrupt := false.
selectingPC := true.
+ contextStackIndex := 0.
+
+ terminationMethod := #terminateAggressively "debugger's default termination method"!
- contextStackIndex := 0.!
Item was changed:
----- Method: Debugger>>terminateProcess (in category 'context stack menu') -----
terminateProcess
+ "close the debugger and terminate the debugged process"
+ terminationMethod := #terminate.
+ self close
+ !
- interruptedProcess terminate.
- interruptedProcess := nil.
- self close.!
Item was changed:
----- Method: Debugger>>windowIsClosing (in category 'initialize') -----
windowIsClosing
"My window is being closed; clean up. Restart the low space watcher."
contextStack := nil.
receiverInspector := nil.
contextVariablesInspector := nil.
interruptedProcess == nil ifTrue: [^ self].
+ interruptedProcess perform: terminationMethod.
- interruptedProcess terminateAggressively.
interruptedProcess := nil.
Smalltalk installLowSpaceWatcher. "restart low space handler"!
Marcel Taeumel uploaded a new version of Tools to project The Treated Inbox:
http://source.squeak.org/treated/Tools-jar.1161.mcz
==================== Summary ====================
Name: Tools-jar.1161
Author: jar
Time: 9 June 2022, 1:57:46.549529 pm
UUID: f3921b2b-5628-104d-98a9-1e99671344a2
Ancestors: Tools-ct.1160
Fix an inconsistent Debugger behavior WRT the new alternative abandon/terminate/destroy modes introduced by Kernel-ct.1434 and Tools-ct.1092.
The suggestion is to make all three termination methods equal in terms of how the chosen termination mode is propagated to #windowIsClosing. Current asymmetrical approach leads to an incorrect debugger termination via #terminate mode.
Replace termination of the debugged process with an indirect termination via a forked process (otherwise the debugger waits until the debugged process is terminated but if another error is raised during unwind the termination is halted and the assertion fail).
Following up a conversation in http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220675.html
Complemented by ToolsTests-jar.111 fixing the failing/incorrects tests in ToolsTests-ct.107
Please review as I'm no debugger expert and this is just my suggestion.
Superseeds (or replaces) Tools-jar.1159 (please kindly remove from Inbox)
=============== Diff against Tools-ct.1160 ===============
Item was changed:
CodeHolder subclass: #Debugger
+ instanceVariableNames: 'interruptedProcess contextStack contextStackIndex contextStackList receiverInspector receiverInspectorState contextVariablesInspector contextVariablesInspectorState externalInterrupt proceedValue selectingPC savedCursor isolationHead failedProject labelString message untilExpression terminationMethod'
- instanceVariableNames: 'interruptedProcess contextStack contextStackIndex contextStackList receiverInspector receiverInspectorState contextVariablesInspector contextVariablesInspectorState externalInterrupt proceedValue selectingPC savedCursor isolationHead failedProject labelString message untilExpression'
classVariableNames: 'ContextStackKeystrokes ErrorReportServer FullStackSize InterruptUIProcessIfBlockedOnErrorInBackgroundProcess NotifierStackSize SavedExtent StackSizeLimit WantsAnnotationPane'
poolDictionaries: ''
category: 'Tools-Debugger'!
!Debugger commentStamp: 'mt 12/17/2019 12:19' prior: 0!
I represent the machine state at the time of an interrupted process. I also represent a query path into the state of the process. The debugger is typically viewed through a window that views the stack of suspended contexts, the code for, and execution point in, the currently selected message, and inspectors on both the receiver of the currently selected message, and the variables in the current context.
Special note on recursive errors:
Some errors affect Squeak's ability to present a debugger. This is normally an unrecoverable situation. However, if such an error occurs in an isolation layer, Squeak will attempt to exit from the isolation layer and then present a debugger. Here is the chain of events in such a recovery.
* A recursive error is detected.
* The current project is queried for an isolationHead
* Changes in the isolationHead are revoked
* The parent project of isolated project is returned to
* The debugger is opened there and execution resumes.
If the user closes that debugger, execution continues in the outer project and layer. If, after repairing some damage, the user proceeds from the debugger, then the isolationHead is re-invoked, the failed project is re-entered, and execution resumes in that world.
---
In September 2019, we added MorphicDebugger and MVCDebugger to untangle framework-specific features in our debugger infrastructure. However, this is just an intermediate step. The overall goal would be to remove those two subclasses again while preserving their functionality. Mostly, MVC and Morphic differ in their GUI-process management. This means that "proceed" and "close" work differently depending on the process that is being debugged. --- One idea is to attach that framework-specific information to the process objects. See Process >> #environmentAt: and #environmentAt:put:. Also see ToolSet's #handle* and #debug* methods.!
Item was changed:
----- Method: Debugger>>abandon (in category 'context stack menu') -----
abandon
+ "close the debugger and terminate the debugged process"
- "abandon the debugger from its pre-debug notifier"
+ terminationMethod := #terminateAggressively.
+ self close
+ !
- self close.!
Item was changed:
----- Method: Debugger>>initialize (in category 'initialize') -----
initialize
super initialize.
Smalltalk at: #MessageTally ifPresentAndInMemory: [ :tally |
tally terminateTimerProcess].
externalInterrupt := false.
selectingPC := true.
+ contextStackIndex := 0.
+
+ terminationMethod := #terminateAggressively "debugger's default termination method"!
- contextStackIndex := 0.!
Item was changed:
----- Method: Debugger>>terminateProcess (in category 'context stack menu') -----
terminateProcess
+ "close the debugger and terminate the debugged process"
+ terminationMethod := #terminate.
+ self close
+ !
- interruptedProcess terminate.
- interruptedProcess := nil.
- self close.!
Item was changed:
----- Method: Debugger>>windowIsClosing (in category 'initialize') -----
windowIsClosing
"My window is being closed; clean up. Restart the low space watcher."
contextStack := nil.
receiverInspector := nil.
contextVariablesInspector := nil.
interruptedProcess == nil ifTrue: [^ self].
+ [interruptedProcess perform: terminationMethod.
+ interruptedProcess := nil] fork.
- interruptedProcess terminateAggressively.
- interruptedProcess := nil.
Smalltalk installLowSpaceWatcher. "restart low space handler"!
Marcel Taeumel uploaded a new version of Tests to project The Trunk:
http://source.squeak.org/trunk/Tests-jar.476.mcz
==================== Summary ====================
Name: Tests-jar.476
Author: jar
Time: 29 January 2022, 8:45:33.967173 pm
UUID: baedfdf3-299a-bf46-8ab5-61057c90b99c
Ancestors: Tests-ct.475
fix an error in my previous contribution; I used a class instead of an instance of an exception as an argument to #resignalAs:
The test worked because current implementation of #resignalAs allows it but using a class instead of an instance is not consistent with ANSI specification.
=============== Diff against Tests-ct.475 ===============
Item was changed:
----- Method: ExceptionTester>>doubleOuterResignalAsTest (in category 'tests') -----
doubleOuterResignalAsTest
"ExceptionTester new doubleOuterResignalAsTest"
[[self doSomething.
MyResumableTestError signal.
self doYetAnotherThing]
on: MyResumableTestError
do: [:ex | ex outer. self doSomethingExceptional].
self doSomethingElse]
on: MyResumableTestError
+ do: [:ex | ex resignalAs: MyTestNotification new]
- do: [:ex | ex resignalAs: MyTestNotification]
!