Squeak-dev December 2021

squeak-dev@lists.squeakfoundation.org

30 participants
390 discussions

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

[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

Tiles error
by Vaidotas Didžbalis 15 Nov '23

15 Nov '23

Hello, Try dragging and dropping the Tile object into the PasteUp (World) and try clicking on it. It disappears when clicked. The same is for Flaps. Version 5.1 is the last one it worked correctly. regards, Vaidotas

2 4

The Trunk: Collections-pre.857.mcz
by commits＠source.squeak.org 09 Nov '23

09 Nov '23

Patrick Rein uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-pre.857.mcz ==================== Summary ==================== Name: Collections-pre.857 Author: pre Time: 4 October 2019, 11:04:30.363303 am UUID: 5ef00b65-3884-c445-b276-0cc01f0b10a1 Ancestors: Collections-pre.856 Adds startOfHeader to Character, adds empty abstract implementations of scanFrom:, writeScanOn: to TextAttribute to allow for Texts which include TextAttributes which do not implement serialization to still be serialized, adds a comment to these methods. =============== Diff against Collections-pre.856 =============== Item was added: + ----- Method: Character class>>startOfHeader (in category 'accessing untypeable characters') ----- + startOfHeader + + ^ self value: 1 ! Item was added: + ----- Method: TextAttribute class>>scanFrom: (in category 'fileIn/Out') ----- + scanFrom: strm + "Read the text attribute properties from the stream. When this method has + been called the concrete TextAttribute class has already been selected via + scanCharacter. (see TextAttribute class>>#newFrom:). + For writing the format see TextAttribute>>#writeScanOn:"! Item was added: + ----- Method: TextAttribute>>writeScanOn: (in category 'fileIn/fileOut') ----- + writeScanOn: strm + "Implement this method for a text attribute to define how it it should be written + to a serialized form of a text object. The form should correspond to the source + file format, i.e. use a scan character to denote its subclass. + As TextAttributes are stored in RunArrays, this method is mostly called from RunArray>>#write scan. + For reading the written information see TextAttribute class>>#scanFrom:" + + "Do nothing because of abstract class"!

8 18

On the rejection of Promises due to errors
by Jakob Reschke 09 Nov '23

09 Nov '23

Hi all, Tony has recently fixed our Promise implementation to make it more Promises/A+ compliant, thank you! In the discussion that lead to this fix [1], I already pointed out a difference between exceptions in Smalltalk and in JavaScript, where the Promises/A+ specification originates: Smalltalk exceptions can be resumed, while JavaScript exceptions cannot be resumed and always unroll the stack. The spec [2] says that if the onFulfilled or onRejected callback of a #then call on a promise throws an exception, then the promise returned by the #then call shall be rejected with the exception thrown. Our current Promise implementation matches this for the blocks supplied to #then:, #ifRejected: or #then:ifRejected, by catching all Errors in the blocks and rejecting the promise. But this does not allow a Squeak user to deal with exceptions in a debugger if they are signalled in the callbacks, because they are caught. The same also applies to #future promises. The latter are not really covered by the Promises/A+ spec (because it does not force the resolution or rejection of a promise that is not the result of a #then, and there is no #future in JavaScript), but futures exhibit the same problem of not being resumable in the debugger. Example: promise := 1 future / 0. "<= inspect it => promise is rejected, regardless of your actions in the debugger" Number compile: 'methodWithTypo ^ self asstring'. promise := 1 future methodWithTypo. "<= inspect it => promise is rejected, no chance to fix the misspelling of asString in the debugger and proceed" I could imagine instead letting all exceptions pass during the future or callback block evaluation, and only reject the promise if the evaluation is eventually curtailed due to the exception (be it an Error or not, think of Warning or ModificationForbidden). Example expectations: promise := 1 future / 0. "<= inspect it, press Proceed in the debugger, => promise is resolved" promise := 1 future / 0. "<= inspect it, press Abandon in the debugger, => promise is rejected" promise := 1 future methodWithTypo. "<= inspect it, fix the typo of asString in the debugger, proceed, => promise is resolved with '1'" It could be done by fulfilling a Promise about aBlock similar to this: [ self resolveWith: aBlock value ] on: Exception do: [ :ex | | resumed | resumed := false. [ | result | result := ex outer. resumed := true. ex resume: result] ifCurtailed: [resumed ifFalse: [self future rejectWith: ex]]] (Find the current implementations here: Promise>>#fulfillWith:passErrors: and Promise>>#then:ifRejected:) Note that the #outer send would only trigger handlers in the Project/World loop, or the defaultAction of the exception. The #future in front of #rejectWith: is there to avoid curtailing the unwind block context of ifCurtailed: itself if there are further errors in the rejection callbacks of the promise. The behavior of non-local exits from unwind contexts is undefined in the Smalltalk ANSI standard (just like resume: or return: in a defaultAction, or not sending resume: or return: in an on:do: exception handler at all -- VA Smalltalk interprets that as resume, while Squeak does return, for example). This implementation would also allow all deferred Notifications to pass and not reject the promise. That is because true notifications just resume silently if they are not handled. promise := [Notification signal: 'hi there'. 42] future value. "<= inspect it => Expected: resolved with 42. Actual (today): it is needlessly rejected with Notification 'hi there'" Pressing Proceed in the debugger on officially non-resumable errors (which is possible) would also not reject the promise. But further errors/debuggers are likely to appear, of which one may eventually be used to abort the execution. If the execution finishes after repeatedly pressing Proceed, then fine, resolve the promise with whatever the outcome was. promise := [self error: 'Fatal error'. 42] future value. "<= inspect it, proceed after the so-called fatal error, => Expected: resolved with 42. Actual: there is no debugger, the promise is immediately rejected." promise := [1 / 0 + 3] future value. "<= Cannot be resumed/proceeded because if ZeroDivide is resumed, it will return the exception, and ZeroDivide does not understand +, which cannot be resumed without changing the code. So you'd have to curtail the block execution => Expected: rejected with ZeroDivide or MessageNotUnderstood (depending on when you press Abandon or recompile the DoIt)." promise := [1 / 0 + 3] future value. "... or instead of changing the code or aborting, you could choose 'return entered value' in one of the debuggers, and thereby complete the evaluation of the block => Expected: resolved with whatever you entered to return in the debugger" Promises with whenRejected:/ifRejected: callbacks would no longer swallow errors, and would only be rejected when the user aborts in the debuggers, or if the future execution catches errors by itself and converts them to rejected promises, so the future promise will also be rejected. This could pose a compatibility problem for existing code. promise := (1 future / 0) then: [:result | result + 3] ifRejected: [:reason | #cancelled]. "<= inspect it => Actual: resolved with #cancelled immediately. Expected with my proposed changes: it would first show the ZeroDivide debugger, which you can abandon to resolve with #cancelled, or proceed to a MessageNotUnderstood +. If you abandon the MNU, the promise would be rejected with the MNU, not #cancelled, in accordance with the Promises/A+ spec." How to get back a catch-all->reject-immediately future under these circumstances: promise := [[1 / 0] on: Error do: [:e | e return: (Promise new rejectWith: e)]] future value. promise := [1 future + 1 then: [:n | [n / 0] on: Error do: [:e | e return: (Promise new rejectWith: e)]] future value. We could also introduce a convenience constructor for immediately-rejected promises like in JavaScript: Promise rejected: e. Or a convenience exception handler: [...] rejectOn: Error. Or [...] rejectIfCurtailed (the fullfill/then methods would probably use this as well). What do you think? As Tom Beckmann has already suggested in the last thread on the topic [1], I could also use a custom class of Promise to get just the behavior I want. But then I cannot solve it for the use of #future. At least not without patching something about the compiler in my package preamble... ;-) [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208546.ht… [2] https://promisesaplus.com/ Kind regards, Jakob

6 19

The Inbox: Morphic-ct.1718.mcz
by commits＠source.squeak.org 16 Oct '23

16 Oct '23

A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1718.mcz ==================== Summary ==================== Name: Morphic-ct.1718 Author: ct Time: 24 January 2021, 5:22:59.352273 pm UUID: f630cc0f-15e2-5642-94f6-6277bb8d7bd4 Ancestors: Morphic-mt.1710 PluggableTextMorph: Fixes #selectAll to keep the current scroll position intact, as it is best practice in most modern editor implementations such as Chromium. I'm very open to refactoring proposals, but otherwise I don't care if you merge this as-is. :-) =============== Diff against Morphic-mt.1710 =============== Item was changed: ----- Method: Editor>>selectAll: (in category 'typing/selecting keys') ----- selectAll: aKeyboardEvent "select everything, invoked by cmd-a. 1/17/96 sw" self insertAndCloseTypeIn. self selectFrom: 1 to: self string size. + morph skipOnceScrollSelectionIntoView. ^ true! Item was changed: ----- Method: PluggableTextMorph>>scrollSelectionIntoView: (in category 'editor access') ----- scrollSelectionIntoView: event "Scroll my text into view. Due to line composition mechanism, we must never use the right of a character block because the lines last character block right value always comes from a global container and is *not* line specific." self rememberSelectionInterval. + (self valueOfProperty: #skipScrollSelectionIntoView ifAbsent: [false]) ifTrue: [ + self removeProperty: #skipScrollSelectionIntoView. + ^ true]. + textMorph editor hasSelection ifFalse: [self scrollToShow: (textMorph editor startBlock withWidth: 1)] ifTrue: [ self scrollToShow: (textMorph editor startBlock topLeft corner: textMorph editor stopBlock bottomLeft). self scrollToShow: (textMorph editor pointBlock withWidth: 1). "Ensure text cursor visibility."]. ^ true! Item was added: + ----- Method: TextMorph>>skipOnceScrollSelectionIntoView (in category 'as yet unclassified') ----- + skipOnceScrollSelectionIntoView + + self owner owner setProperty: #skipScrollSelectionIntoView toValue: true.!

4 4

WeakSet but no WeakIdentitySet?
by Igor Stasenko 26 Aug '23

26 Aug '23

Hello, i need to keep a bunch of CompiledMethods in WeakSet, but i am a bit afraid, that it wont work as i want to, because of CompiledMethod>>= implementation, because a code, which i currently writing doesn't changing a method's bytecode, but changing its trailer instead, and so, this could lead to undesirable effects.. If i could have a WeakIdentitySet... Meanwhile, i think i have nothing else, but just use a degenerate WeakIdentityKeyDictionary , with methods in keys and nils in values. :( -- Best regards, Igor Stasenko AKA sig.

4 3

veryDeepCopy, ImageSegments, and actionMaps
by Ned Konz 17 Aug '23

17 Aug '23

Any Object can have dependents whether or not it has an instance variable to keep track of them (these are kept in the DependentsFields class variable of Object). The only class that keeps its own dependents is Model. Any Object can have an actionMap. These are supplied by EventManager class by default, and are stored in the ActionMaps class variable of EventManager. The only class that keeps its own action maps is Morph. When we veryDeepCopy an object we also copy the global dependents (see DeepCopier>>fixDependents). However, we don't copy the actionMap in those cases where it's held by the EventManager class. When we file out an object that uses DependentsFields out into an ImageSegment, we also file out the dependents (see ImageSegment>>dependentsSave:) if it's in a project. We do this by adding a project parameter called #GlobalDependentsInProject. However, we don't file out the actionMap in those cases where it's held by the EventManager class. My question is this: should we fix these behaviors (copying and serialization) to include these "global action maps" just like we already include the "global dependents"? Or should we discourage the use of the "global action maps"? -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

3 2

The Inbox: Tools-ct.1032.mcz
by commits＠source.squeak.org 15 Aug '23

15 Aug '23

A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-ct.1032.mcz ==================== Summary ==================== Name: Tools-ct.1032 Author: ct Time: 10 March 2021, 6:51:33.356304 pm UUID: 897e4ea2-3740-6a45-a054-d7da65105568 Ancestors: Tools-mt.1030 In the Message Names tool, show definition, comment, and hierarchy for class hits. In particular helpful to find out efficiently whether a selector belongs to a binding or to an actual class. =============== Diff against Tools-mt.1030 =============== Item was changed: ----- Method: MessageNames>>computeMessageList (in category 'search') ----- computeMessageList + | selector | + selectorListIndex = 0 ifTrue: [^ #()]. + + selector := selectorList at: selectorListIndex. + ^ (selector first isUppercase ifTrue: [Smalltalk classNamed: selector]) + ifNotNil: [:class | + class := Smalltalk classNamed: selector. + #(Definition Comment Hierarchy) collect: [:sel | + MethodReference class: class selector: sel] ] + ifNil: [self systemNavigation allImplementorsOf: selector]! - ^ selectorListIndex = 0 - ifTrue: [#()] - ifFalse: [self systemNavigation - allImplementorsOf: (selectorList at: selectorListIndex)]! Item was changed: ----- Method: MessageNames>>selectedMessageName (in category 'message list') ----- selectedMessageName selectorList basicSize = 0 ifTrue: [^ nil]. "Deals with selectorList nil or empty" + ^super selectedMessageName ifNil: [ + "only message name selected" + selectorList at: (selectorListIndex max: 1) ifAbsent: [nil] "If no selection we can still find a selector"]! - ^selectorList at: (selectorListIndex max: 1) ifAbsent: [nil] "If no selection we can still find a selector"! Item was changed: ----- Method: MessageSet>>aboutToStyle: (in category 'code pane') ----- + aboutToStyle: aStyler + "This is a notification that aStyler is about to re-style its text. + Set the classOrMetaClass in aStyler, so that identifiers will be resolved correctly. - aboutToStyle: aPluggableShoutMorphOrView - "This is a notification that aPluggableShoutMorphOrView is about to re-style its text. - Set the classOrMetaClass in aPluggableShoutMorphOrView, so that identifiers - will be resolved correctly. Answer true to allow styling to proceed, or false to veto the styling" | selectedMessageName showingMethod | self showingSource ifFalse: [^false]. selectedMessageName := self selectedMessageName. showingMethod := (#(Comment Definition Hierarchy) includes: selectedMessageName) not. + aStyler parseAMethod: showingMethod. "Hack!! setting classOrMetaClass: to nil allows doit or class definition colouring." + aStyler classOrMetaClass: (showingMethod ifTrue: [self selectedClassOrMetaClass]). - aPluggableShoutMorphOrView classOrMetaClass: (showingMethod ifTrue: [self selectedClassOrMetaClass]). ^(#(Comment Hierarchy) includes: selectedMessageName) not! Item was changed: ----- Method: MessageSet>>selectedMessage (in category 'message list') ----- selectedMessage "Answer the source method for the currently selected message." - self setClassAndSelectorIn: [:class :selector | | source | class ifNil: [^ 'Class vanished']. selector first isUppercase ifTrue: [selector == #Comment ifTrue: + ["currentCompiledMethod := class organization commentRemoteStr." - [currentCompiledMethod := class organization commentRemoteStr. ^ class comment]. selector == #Definition ifTrue: [^ class definition]. selector == #Hierarchy ifTrue: [^ class printHierarchy]]. source := class sourceMethodAt: selector ifAbsent: [currentCompiledMethod := nil. ^ 'Missing']. self showingDecompile ifTrue: [^ self decompiledSourceIntoContents]. currentCompiledMethod := class compiledMethodAt: selector ifAbsent: [nil]. self showingDocumentation ifTrue: [^ self commentContents]. source := self sourceStringPrettifiedAndDiffed. ^ source asText makeSelectorBoldIn: class]!

3 2

The Inbox: Morphic-ct.1641.mcz
by commits＠source.squeak.org 20 May '23

20 May '23

Christoph Thiede uploaded a new version of Morphic to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1641.mcz ==================== Summary ==================== Name: Morphic-ct.1641 Author: ct Time: 7 June 2020, 2:45:17.536284 pm UUID: b90e23e1-ce70-3d49-a8e4-f09af148ef97 Ancestors: Morphic-ct.1638 Refine #isHighFrequentEvent implementation for further event types. Fixes one possible cause of the "color depth = 0" bug. See http://forum.world.st/Image-not-startable-after-save-td5117084.html. Depends indeed on Morphic-ct.1638. =============== Diff against Morphic-ct.1638 =============== Item was added: + ----- Method: DropEvent>>isHighFrequentEvent (in category 'testing') ----- + isHighFrequentEvent + + ^ false! Item was added: + ----- Method: WindowEvent>>isHighFrequentEvent (in category 'testing') ----- + isHighFrequentEvent + + ^ (#(windowClose) includes: self type) not! Item was changed: ----- Method: WorldState>>doSafely:onErrorThat:setErrorFlag:ifFatal:afterErrorDo: (in category 'update cycle') ----- doSafely: aBlock onErrorThat: errorPredicate setErrorFlag: errorFlag ifFatal: fatalErrorBlock afterErrorDo: postErrorBlock "Evaluate aBlock and keep track of errors during morph invocations." | finished classesWithErrors | finished := false. classesWithErrors := IdentitySet new. [finished] whileFalse: [ [aBlock value. finished := true] on: Error, Halt, Warning do: [:ex | | err rcvr errCtxt errMorph | (errorPredicate cull: ex) ifFalse: [ex pass]. err := ex description. rcvr := ex receiver. errCtxt := thisContext. [ errCtxt := errCtxt sender. "Search the sender chain to find the morph causing the problem" [errCtxt notNil and: [(errCtxt receiver isMorph) not]] whileTrue: [errCtxt := errCtxt sender]. "If we're at the root of the context chain then we have a fatal problem" errCtxt ifNil: [^ fatalErrorBlock cull: err]. + errMorph := errCtxt receiver + ] doWhileTrue: [ - errMorph := errCtxt receiver. "If the morph causing the problem has already the error flag set, then search for the next morph above in the caller chain." errMorph hasProperty: errorFlag + ]. - ] whileTrue. errMorph setProperty: errorFlag toValue: true; changed. "Catch all errors, one for each receiver class." (classesWithErrors includes: rcvr class) ifFalse: [ classesWithErrors add: rcvr class. ToolSet debugException: ex]. postErrorBlock cull: err. ]].! Item was changed: ----- Method: WorldState>>processEventsSafely: (in category 'update cycle') ----- processEventsSafely: aHandMorph ^ self doSafely: [aHandMorph processEvents] + onErrorThat: [:error | self currentEvent ifNil: [true] ifNotNil: [:evt | evt isHighFrequentEvent]] - onErrorThat: [:error | ActiveEvent isNil or: [ActiveEvent isHighFrequentEvent]] setErrorFlag: #errorOnEvent ifFatal: [:error | Project current fatalEventHandlingError: error] afterErrorDo: []!

5 6

Jump to page: