Squeak-dev November 2023

squeak-dev@lists.squeakfoundation.org

30 participants
170 discussions

[Simulation errors] ObjectTracer on: true
by Thiede, Christoph 30 Dec '23

30 Dec '23

Hi all! I rarely discovered that much errors with one single command :-) Steps to reproduce Print it: (ObjectTracer on: true) ifTrue: [1] Expected behavior It is printed: 1 Actual behavior The following tracer notifications appear (proceed them all): 1. (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext: 2. #mustBeBoolean 3. (3 more print message called by #logSqueakError:inContext: again, see the next error) 4. Error: Where's the jump? Caused by #mustBeBooleanIn:, #skipBackBeforeJump If you still keep proceeding: 1. (3 more print message called by #logSqueakError:inContext: again, see the next error) 2. Finally, the NonBooleanReceiver error from 2. 3. VM crashes. Summarizing the bugs ObjectTracer traces too much The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged? #mustBeBoolean is sent to boolean proxy This is caused by the simulation of the inlined #ifTrue: call. I don't know whether this is worth to be fixed before Scorch? If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow)<http://forum.world.st/The-Inbox-HelpSystem-Core-ct-123-mcz-tp5105402p511363…>. #mustBoBoolean depends on caller chain It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator. We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender? Best, Christoph

6 11

simplifying debugger/error handler invocation
by Eliot Miranda 20 Dec '23

20 Dec '23

Hi Jaromir, Hi All, in trying to pass the exception raising an error to the debugger (so that it can highlight the relevant return expression) I'm running into the clumsy plumbing from errors to debuggers, i.e. debugProcess:context:label:contents:fullView:, debugWithTitle:full:contents:, debugException:, debugContext:title:full:contents: et al. I think we urgently need to do to this interface what Colin Putney did to the compiler, introducing CompilerCue to hold all the state, including optional state, for a compilation invocation. We need ErrorHandlerCue, or DebuggerCue, or some such. It can take all the parameters of the above, plus any extras we want to add, and then we can reduce the above selectors to handleErrorCue: anErrorCue or handleDebuggerCue: aDebuggerCue and then easily add additional state, such as the exception, to handlers such as the debugger. Anybody willing to pick up that bucket of whitewash and paint the fence? _,,,^..^,,,_ best, Eliot

3 10

Loops on the context stack
by christoph.thiede＠student.hpi.uni-potsdam.de 15 Dec '23

15 Dec '23

Hi all, looking for a new way to crash the image? :-) Here is one: gen := Generator on: [:gen | self assert: gen next isNil. self error]. gen yield: 1. This is a less idiomatic but more comprehensible version: [c := thisContext. [h := thisContext. [h swapSender: thisContext sender. c := thisContext swapSender: c] value. thisContext swapSender: c] value] value. [c := thisContext swapSender: c. self error] value. In a nutshell, the Generator temporarily creates a loop on the stack while switching coroutines. I didn't fully get behind its implementation at the moment, and I acknowledge that I am using the generator in the "wrong" way - usually the #on: block is the producer not the consumer. However, and especially with the recent debate on safe languages in mind, I wonder whether we would be able and willing to make Squeak safe against this phenomen (loops on the stack). The actual crash (or better: hang) comes from primitiveFindHandlerContext, but I assume primitiveFindNextUnwindContext and primitiveTerminateTo would cause a similar effect. A simple fix would be to disable these optional primitives and use the image fallback instead. This makes the method interruptable similar to a convenient infinite loop. However, this is obviously much slower. I wonder whether these primitives could be made aware of possible context stack loops and fail when a loop is detected. When the primitive fails, the fallback code would run so the image would be interruptable again, or even better, we could also detect particular stack loops then: Context>>findNextHandlerContextStarting "Return the next handler marked context, returning nil if there is none. Search starts with self and proceeds up to nil." - | ctx | - <primitive: 197> + | ctx known | ctx := self. + known := IdentitySet new. [ctx isHandlerContext ifTrue:[^ctx]. + (known ifAbsentAdd: ctx) ifFalse: [Processor debugWithTitle: 'Loop on stack detected!' translated full: false]. (ctx := ctx sender) == nil ] whileFalse. ^nil So my questions to you are: Do we want to support this kind of safety (I would like it!)? Is this possible to implement in the VM without a concerning performance impact? Best, Christoph --- Sent from Squeak Inbox Talk

2 2

Some issue with interrupts during delay
by Thiede, Christoph 15 Dec '23

15 Dec '23

For the second time in two days, I was stuck in the following situation after pressing interrupt multiple times and my image froze irrecoverably: [cid:bf8bfc45-aff3-4132-9510-d8802537c162] I don't know what's going on here. Did the interrupt block a critical section that is used by a higher-level process such as the timer event loop? Unfortunately no SqueakDebug.log was produced. How can we investigate & fix this? Best, Christoph

3 4

[BUG] ExternalCommandShell interrupts StartUpList if no stdio is present
by christoph.thiede＠student.hpi.uni-potsdam.de 02 Dec '23

02 Dec '23

Hi Dave, hi all, I noticed that when I start my normal Trunk image on Windows, which normally does not attach any stdio streams, ExternalCommandShell interrupts the startup process with an error from ExternalCommandShell>>start. See the attached debug log. While I understand while this error occurs, I think that it should be handled silently. Most users (including myself a few times ago) will just abandon this debugger, preventing further startup tasks from being run correctly and leaving the image in a partially uninitialized state. Plus, the debugger is slightly annoying, as I am aware indeed whether I started Squeak from a command shell or not. I would prefer an error to be raised only if I actually try to use an ExternalCommandShell. It would be great if something could overthink this. :-) Best, Christoph --- Sent from Squeak Inbox Talk [ExternalCommandShell startup.SqueakDebug.log]

3 4

Squeak 6.0: 60Deprecated-mt.116.mcz
by commits＠source.squeak.org 30 Nov '23

30 Nov '23

Marcel Taeumel uploaded a new version of 60Deprecated to project Squeak 6.0: http://source.squeak.org/squeak60/60Deprecated-mt.116.mcz ==================== Summary ==================== Name: 60Deprecated-mt.116 Author: mt Time: 30 November 2023, 6:07:14.584649 pm UUID: cfa19082-5813-7640-a596-6d9e270907b5 Ancestors: 60Deprecated-ct.115 Improve backwards compatibility with old code using morphic layers. =============== Diff against 60Deprecated-ct.115 =============== Item was changed: ----- Method: Morph>>addMorphInFrontOfLayer: (in category '*60Deprecated-WiW support') ----- addMorphInFrontOfLayer: aMorph self flag: #deprecated. "Use #addMorphFrontInLayer: instead". + ^ self addMorphFrontInLayer: aMorph! - ^ self privateAddMorph: aMorph atIndex: 1!

1 0

The Trunk: 60Deprecated-mt.116.mcz
by commits＠source.squeak.org 30 Nov '23

30 Nov '23

Marcel Taeumel uploaded a new version of 60Deprecated to project The Trunk: http://source.squeak.org/trunk/60Deprecated-mt.116.mcz ==================== Summary ==================== Name: 60Deprecated-mt.116 Author: mt Time: 30 November 2023, 6:07:14.584649 pm UUID: cfa19082-5813-7640-a596-6d9e270907b5 Ancestors: 60Deprecated-ct.115 Improve backwards compatibility with old code using morphic layers. =============== Diff against 60Deprecated-ct.115 =============== Item was changed: ----- Method: Morph>>addMorphInFrontOfLayer: (in category '*60Deprecated-WiW support') ----- addMorphInFrontOfLayer: aMorph self flag: #deprecated. "Use #addMorphFrontInLayer: instead". + ^ self addMorphFrontInLayer: aMorph! - ^ self privateAddMorph: aMorph atIndex: 1!

1 0

FFI: ConfigurationOfFFI-mt.63.mcz
by commits＠source.squeak.org 29 Nov '23

29 Nov '23

Marcel Taeumel uploaded a new version of ConfigurationOfFFI to project FFI: http://source.squeak.org/FFI/ConfigurationOfFFI-mt.63.mcz ==================== Summary ==================== Name: ConfigurationOfFFI-mt.63 Author: mt Time: 29 November 2023, 4:54:02.858887 pm UUID: b8c42bc5-9476-664f-ab9d-8461d60c3a2a Ancestors: ConfigurationOfFFI-mt.62 Minor fix to version 2.1 to make #arm64Check work again in Squeak6.0. While we are at it, include the new goodies from FFI-Libraries-cbc.5 :-) =============== Diff against ConfigurationOfFFI-mt.62 =============== Item was changed: ----- Method: ConfigurationOfFFI>>version21: (in category 'versions') ----- version21: spec <version: '2.1' imports: #('2.0-baseline')> spec for: #common do: [ spec blessing: #release; "for Squeak 6.0 w/ OSVM 2023" package: 'FFI-Pools' with: 'FFI-Pools-mt.39'; package: 'FFI-Kernel' with: 'FFI-Kernel-mt.231'; + package: 'FFI-Libraries' with: 'FFI-Libraries-cbc.5'; - package: 'FFI-Libraries' with: 'FFI-Libraries-mt.4'; package: 'FFI-Callbacks' with: 'FFI-Callbacks-mt.30'; package: 'FFI-Tools' with: 'FFI-Tools-mt.39'; + package: 'FFI-Tests' with: 'FFI-Tests-mt.73'; - package: 'FFI-Tests' with: 'FFI-Tests-eem.72'; package: 'FFI-PoolsTests' with: 'FFI-PoolsTests-mt.11'; package: 'FFI-CallbacksTests' with: 'FFI-CallbacksTests-mt.7'].!

1 0

FFI: ConfigurationOfFFI-mt.62.mcz
by commits＠source.squeak.org 29 Nov '23

29 Nov '23

Marcel Taeumel uploaded a new version of ConfigurationOfFFI to project FFI: http://source.squeak.org/FFI/ConfigurationOfFFI-mt.62.mcz ==================== Summary ==================== Name: ConfigurationOfFFI-mt.62 Author: mt Time: 23 November 2023, 12:00:54.553965 pm UUID: db27676d-365e-ea4d-ab5b-941cf3fb8564 Ancestors: ConfigurationOfFFI-mt.61 Again ... w/o the typo ... SqueakFFI 2.1 for Squeak 6.0 w/ OSVM 2023 (and thus newer FFI plugin) =============== Diff against ConfigurationOfFFI-mt.61 =============== Item was changed: ----- Method: ConfigurationOfFFI>>version21: (in category 'versions') ----- version21: spec <version: '2.1' imports: #('2.0-baseline')> spec for: #common do: [ spec blessing: #release; "for Squeak 6.0 w/ OSVM 2023" package: 'FFI-Pools' with: 'FFI-Pools-mt.39'; package: 'FFI-Kernel' with: 'FFI-Kernel-mt.231'; package: 'FFI-Libraries' with: 'FFI-Libraries-mt.4'; package: 'FFI-Callbacks' with: 'FFI-Callbacks-mt.30'; package: 'FFI-Tools' with: 'FFI-Tools-mt.39'; + package: 'FFI-Tests' with: 'FFI-Tests-eem.72'; - package: 'FFI-Tests' with: 'FFI-Tests-mt.71'; package: 'FFI-PoolsTests' with: 'FFI-PoolsTests-mt.11'; package: 'FFI-CallbacksTests' with: 'FFI-CallbacksTests-mt.7'].!

1 0

FFI: ConfigurationOfFFI-mt.61.mcz
by commits＠source.squeak.org 29 Nov '23

29 Nov '23

Marcel Taeumel uploaded a new version of ConfigurationOfFFI to project FFI: http://source.squeak.org/FFI/ConfigurationOfFFI-mt.61.mcz ==================== Summary ==================== Name: ConfigurationOfFFI-mt.61 Author: mt Time: 23 November 2023, 11:59:43.950965 am UUID: 9ee49f01-a6b9-8140-b95b-8cd8fb264b42 Ancestors: ConfigurationOfFFI-mt.60 SqueakFFI 2.1 for Squeak 6.0 w/ OSVM 2023 (and thus newer FFI plugin) =============== Diff against ConfigurationOfFFI-mt.60 =============== Item was changed: ----- Method: ConfigurationOfFFI>>stable: (in category 'symbolic versions') ----- stable: spec <symbolicVersion: #'stable'> spec for: #squeakCommon version: '1.5'. spec for: #pharo version: '1.7'. spec for: #'pharo3.x' version: '1.8'. spec for: #'pharo4.x' version: '1.9'. spec for: #'pharo5.x' version: '1.10.1'. spec for: #'squeak' version: '1.12'. spec for: #'squeak5.x' version: '1.13'. + spec for: #'squeak6.0.x' version: '2.1'. - spec for: #'squeak6.0.x' version: '2.0'. spec for: #'squeak6.1.x' version: '3.0'. "Latest stable tag for Squeak Trunk" ! Item was added: + ----- Method: ConfigurationOfFFI>>version21: (in category 'versions') ----- + version21: spec + <version: '2.1' imports: #('2.0-baseline')> + + spec for: #common do: [ + spec + blessing: #release; "for Squeak 6.0 w/ OSVM 2023" + package: 'FFI-Pools' with: 'FFI-Pools-mt.39'; + package: 'FFI-Kernel' with: 'FFI-Kernel-mt.231'; + package: 'FFI-Libraries' with: 'FFI-Libraries-mt.4'; + package: 'FFI-Callbacks' with: 'FFI-Callbacks-mt.30'; + + package: 'FFI-Tools' with: 'FFI-Tools-mt.39'; + + package: 'FFI-Tests' with: 'FFI-Tests-mt.71'; + package: 'FFI-PoolsTests' with: 'FFI-PoolsTests-mt.11'; + package: 'FFI-CallbacksTests' with: 'FFI-CallbacksTests-mt.7'].!

1 0

Jump to page: