Squeak-dev February 2023

squeak-dev@lists.squeakfoundation.org

28 participants
108 discussions

Some beginner questions about the EventHandler of a PolygonMorph
by Eduardo Ochs 09 Feb '23

09 Feb '23

Hi list, I asked this question here on the list a few days ago, http://lists.squeakfoundation.org/pipermail/squeak-dev/2023-February/223398… on how to write code that _sends_ certain keyboard events. I think that I got a prototype of an answer for it, that "just" needs some debugging... and then I started to work on ways to debug my prototype. The ideal way to test sending keyboard events would be to have some code that _receives_ and _handles_ keyboard events, and that runs things like "Transcript show: evt" or "evt halt" when it receives a keyboard event. I tried to adapt the code from these wiki pages https://wiki.squeak.org/squeak/1125 Programming Morphs (Active Essay) https://wiki.squeak.org/squeak/1216 Programming morphs - page 7 - keyboard events https://wiki.squeak.org/squeak/3503 Morphic Key Events without much success, and I also tried to modify the keyboard exerciser - i.e., this: "World menu -> objects (o) -> Categories -> Demo -> Exercise Keyboard" KeyboardExerciser new openInWorld. ...and then I saw a way to play with keyboard handlers that does not require creating any classes or modifying any methods, and that can be run entirely from a workspace with "do it"s and "print it" in the right places. It is here: "The first lines were adapted from: https://wiki.squeak.org/squeak/2188 PolygonMorph" a := Array with: 50@100 with: 200@300 with: 100@400. b := (PolygonMorph vertices: a color: Color red borderWidth: 1 borderColor: Color black). World addMorph: b. b beSmoothCurve. b beStraightSegments. b vertices. b vertices at: 1. b vertices at: 1 put: 40@100. b vertices at: 1 put: 50@100. b vertices at: 1 put: 40@100. b computeBounds. b vertices at: 1 put: 50@100. b computeBounds. a at: 1 put: 40@100. b computeBounds. a at: 1 put: 50@100. b computeBounds. b color. b color: Color banana. b color: Color fern. b color: Color red. e := EventHandler new. b eventHandler. b eventHandler: nil. b eventHandler: e. Now how do I change that event handler in interesting ways? Does this make sense? e on: #keyStroke send: #halt to: b. Also, is there a way to transfer the keyboard focus to the PolygonMorph with a "do it" in that workspace? I guess that we need to run the method #newKeyboardFocus:, but how exactly? Anyone has examples to share? Thanks in advance, Eduardo Ochs http://anggtwu.net/eev-squeak.html

2 1

[bug] preserve trash does not work
by Vaidotas Didžbalis 04 Feb '23

04 Feb '23

It works for Squeak6.0 at update: #22104, but does not work update: #22122

1 0

How do I translate "sendKeyboardEvent: CR" to real code?
by Eduardo Ochs 04 Feb '23

04 Feb '23

Hi list, suppose that I am exploring a morph and want to use the debugger to understand what happens when I send a CR to one of its submorphs. I guess that a good way to do that would be to run a one-liner like this in the explorer window, 42 halt. (self submorphs at: 1) sendKeyboardEvent: CR. but this is just pseudo-code, of course... I've spent some hours on the swiki and browsing the source code of methods and classes that looked promising, like these ones, EventSensor>>#processKeyboardEvent: HandMorph>>#generateKeyboardEvent: HandMorph>>#sendKeyboardEvent: KeyboardEvent but I couldn't find any code that generates a keyboard event itself and sends it to a morph... I know how to add a breakpoint to a keyDown: method, but debugging that breakpoint would start the debugger in a place in which a keyboard event had already been generated, and is being processed - and I'm looking for a way to do something that is several steps before that (break)point. Any hints? Translations of the "sendKeyboardEvent: CR" above to real code - either low-level or high-level - would be ideal, but links can help me a lot too, of course... Thanks in advance! Eduardo Ochs http://anggtwu.net/eev-squeak.html

3 2

SWIKI Question (Hopeful question)
by Williams, Bret M. 03 Feb '23

03 Feb '23

We have been running a Squeak Wiki (ComSwiki) for about 24 years. I know it's not supported or developed anymore so this is a shot in the dark. The problem seems to be that the image is not storing history. If I restart it (we run it headless) the history and all of the new links to new pages either disappear or don't work. Are there any SWIKI users out there who could point me in the right direction to fix it? Thanks, Bret

2 1

monticello package loads clearing the transcript and/or resetting the character write limit
by Eliot Miranda 03 Feb '23

03 Feb '23

in recent updates one package load clears the transcript. This is not appreciated ;-) If possible, please avoid doing something like this. _,,,^..^,,,_ best, Eliot

2 1

initializing Miorphic-mt.2080
by Eliot Miranda 03 Feb '23

03 Feb '23

if the Morphic load progress indicator is anything to go by then Miorphic-mt.2080 is a) closing my transcript altogether (where am I supposed to read the Monticello package update comments then?) b) exiting the current Morphic project and dumping me in a root MVC project c) changing ctrl period so that it doesn't interrupt but dumps me in the root MVC project Presumably some error is occurring while initializing that causes the system to flee to mvc (that rhymes). Anyone interested in taking a look? _,,,^..^,,,_ best, Eliot

1 1

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

02 Feb '23

A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-jar.1500.mcz ==================== Summary ==================== Name: Kernel-jar.1500 Author: jar Time: 2 February 2023, 10:04:57.541211 pm UUID: 8add6e35-4849-624a-94f8-0722d7ef8c07 Ancestors: Kernel-tpr.1497 Fix #terminateAggressively and #runUntilErrorOrReturnFrom: bugs. Both bugs combined cause the Debugger MNU in this situation: Run this in the Workspace: p := [ [Semaphore new wait] ensure: [1/0] ] fork Then terminate it like this: [p terminate] fork And then just press Abandon and get the MNU error. =============== Diff against Kernel-tpr.1497 =============== Item was changed: ----- Method: Context>>runUntilErrorOrReturnFrom: (in category 'controlling') ----- runUntilErrorOrReturnFrom: aSender "ASSUMES aSender is a sender of self. Execute self's stack until aSender returns or an unhandled exception is raised. Return a pair containing the new top context and a possibly nil exception. The exception is not nil if it was raised before aSender returned and it was not handled. The exception is returned rather than openning the debugger, giving the caller the choice of how to handle it." "Self is run by jumping directly to it (the active process abandons thisContext and executes self). However, before jumping to self we insert an ensure block under aSender that jumps back to thisContext when evaluated. We also insert an exception handler under aSender that jumps back to thisContext when an unhandled exception is raised. In either case, the inserted ensure and exception handler are removed once control jumps back to thisContext." | error ctxt here topContext | here := thisContext. "Insert ensure and exception handler contexts under aSender" error := nil. ctxt := aSender insertSender: (Context contextOn: UnhandledError do: [:ex | error ifNil: [ error := ex exception. topContext := thisContext. ex resumeUnchecked: here jump] ifNotNil: [ex pass] ]). ctxt := ctxt insertSender: (Context contextEnsure: [error ifNil: [ topContext := thisContext. here jump] ]). self jump. "Control jumps to self" "Control resumes here once above ensure block or exception handler is executed" ^ error ifNil: [ "No error was raised, remove ensure context by stepping until popped" + [ctxt isDead or: [topContext isNil]] whileFalse: [topContext := topContext stepToCallee]. - [ctxt isDead] whileFalse: [topContext := topContext stepToCallee]. {topContext. nil} ] ifNotNil: [ "Error was raised, remove inserted above contexts then return signaler context" aSender terminateTo: ctxt sender. "remove above ensure and handler contexts" {topContext. error} ]! Item was changed: ----- Method: Process>>terminateAggressively (in category 'changing process state') ----- terminateAggressively "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack that have not yet been started. If the process is in the middle of an unwind block, then that unwind block will not be completed, but subsequent unwind blocks will be run. If even those unwind contexts should be continued, send #terminate instead. Note that ill unwind contexts are theoretically able to stall the termination (for instance, by placing a non-local return in an unwind block); however, this is a disrecommended practice. If the process is in the middle of a critical: critical section, release it properly." | oldList bottom tombstone | self isActiveProcess ifTrue: [ "If terminating the active process, suspend it first and terminate it as a suspended process." [self terminate] fork. ^self suspend]. "Always suspend the process first so it doesn't accidentally get woken up. N.B.: If oldList is a LinkedList then the process is runnable. If it is a Semaphore/Mutex et al., then the process is blocked." oldList := self suspend. suspendedContext ifNil: [^ self "Process is already terminated"]. "Release any method marked with the <criticalSection> pragma. The argument is whether the process is runnable." self releaseCriticalSection: (oldList isNil or: [oldList class == LinkedList]). bottom := suspendedContext bottomContext. tombstone := bottom insertSender: [self suspend "terminated"] asContext. suspendedContext := self activateReturn: bottom value: nil. self complete: tombstone ifError: [:ex | + (suspendedContext ifNil: [^self]) privRefresh. "Restart the handler context of UnhandledError so that when the receiver is resumed, its #defaultAction will be reached. See implementation details in #runUntilErrorOrReturnFrom:." - suspendedContext privRefresh. "Restart the handler context of UnhandledError so that when the receiver is resumed, its #defaultAction will be reached. See implementation details in #runUntilErrorOrReturnFrom:." "We're not yet done, resume the receiver to spawn a new debugger on the error." self resume].!

1 0

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

02 Feb '23

A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-jar.1499.mcz ==================== Summary ==================== Name: Kernel-jar.1499 Author: jar Time: 2 February 2023, 3:02:46.508164 pm UUID: e69bd0f7-980e-2f42-90db-171af597b735 Ancestors: Kernel-tpr.1497 Remove code duplicity in Context>>#restart, #resume:through: and #resumeEvaluating: while keeping the current unwind semantics. =============== Diff against Kernel-tpr.1497 =============== Item was changed: ----- Method: Context>>restart (in category 'controlling') ----- restart + "Unwind thisContext to self and resume from beginning. + Execute unwind blocks when unwinding. + ASSUMES self is a sender of thisContext" - "Unwind thisContext to self and resume from beginning. Execute unwind blocks when unwinding. ASSUMES self is a sender of thisContext" + ^self resumeEvaluating: [self privRefresh]! - | ctxt unwindBlock | - self isDead ifTrue: [self cannotReturn: nil to: self]. - self privRefresh. - ctxt := thisContext. - [ ctxt := ctxt findNextUnwindContextUpTo: self. - ctxt isNil - ] whileFalse: [ - (ctxt tempAt: 2) ifNil:[ - ctxt tempAt: 2 put: true. - unwindBlock := ctxt tempAt: 1. - thisContext terminateTo: ctxt. - unwindBlock value]. - ]. - thisContext terminateTo: self. - self jump. - ! Item was changed: ----- Method: Context>>resume:through: (in category 'controlling') ----- resume: value through: firstUnwindCtxt "Unwind thisContext to self and resume with value as result of last send. Execute any unwind blocks while unwinding. ASSUMES self is a sender of thisContext." + | ctxt | - | ctxt unwindBlock | self isDead ifTrue: [self cannotReturn: value to: self]. ctxt := firstUnwindCtxt. + ctxt unwindTo: self safely: false. - [ctxt isNil] whileFalse: - [(ctxt tempAt: 2) ifNil: - [ctxt tempAt: 2 put: true. - unwindBlock := ctxt tempAt: 1. - thisContext terminateTo: ctxt. - unwindBlock value]. - ctxt := ctxt findNextUnwindContextUpTo: self]. thisContext terminateTo: self. ^value ! Item was changed: ----- Method: Context>>resumeEvaluating: (in category 'controlling') ----- resumeEvaluating: aBlock "Unwind thisContext to self and resume with value as result of last send. + Execute unwind blocks when unwinding. + ASSUMES self is a sender of thisContext" - Execute unwind blocks when unwinding. - ASSUMES self is a sender of thisContext" + | ctxt | - | ctxt unwindBlock | self isDead ifTrue: [self cannotReturn: aBlock value to: self]. ctxt := thisContext. + ctxt unwindTo: self safely: false. - [ ctxt := ctxt findNextUnwindContextUpTo: self. - ctxt isNil - ] whileFalse: [ - (ctxt tempAt: 2) ifNil:[ - "(tempAt: 2) refers to complete temporary in ensure: and ifCurtailed: - or any other method marked with <primitive: 198>" - ctxt tempAt: 2 put: true. - unwindBlock := ctxt tempAt: 1. - thisContext terminateTo: ctxt. - unwindBlock value]. - ]. thisContext terminateTo: self. ^ aBlock value !

1 0

Exception reraiseFrom: (needs review)
by Eliot Miranda 02 Feb '23

02 Feb '23

Hi All, Hi Levente, Jaromir, and Context hackers, find attached a change set which supports re-raising a fatal exception, caught inside a critical section, outside the critical section. This is a key facility for debugging systems such as Croquet. I expect it'll also be useful in delimited continuation contexts such as Seaside. The facility is closely related to Context>>copyTo: and Context>>copyTo:bottomContextDo:. The main method is Exception>>copyForReraiseTo: aContext. This implementation is higher quality than Context>>copyTo:[bottomContextDo:]. It copies the stack and it also copies blocks that are created on the copied stack. So the copied stack correctly copies blocks, and hence exception handlers. I'm thinking of adding this to trunk. I would like it to be reviewed carefully before I do so. Both implementation and selector names need reviewing, and tests and more use cases would be nice (I have a use case in Virtend/Croquet). Here's an example usage: | sender error | sender := thisContext sender. Mutex new critical: [[nil new] on: Error do: [:ex| error := ex copyForReraiseTo: sender]]. error reraiseFrom: thisContext A simpler usage would be | home error | home := thisContext. Mutex new critical: [[nil new] on: Error do: [:ex| error := ex copyForReraiseTo: home]]. error outer This doesn't work because ProcessorScheduler>>#debugContext:title:full:contents: (et al) contains self assert: [thisContext hasSender: aContext] and hence we have to stitch the copied stack into the current stack via aContext privSender: signalContext. thisContext privSender: aContext. self outer inside Exception>>reraiseFrom: aContext Maybe adding a flag to Exception and avoiding that assert when the exception is "in reraise mode" is better. I don't know. Given that the main worker method, Context>>#copyTo:atEachStep:, is better than Context>>copyTo:[bottomContextDo:]., these two could be reimplemented in terms of it, e.g.: Context>>copyTo: aContext ^self copyTo: aContext atEachStep: [:originalContext :copiedContext| originalContext sender == aContext ifTrue: [copiedContext privSender: nil]] Context>>copyTo: aContext bottomContextDo: aBlock ^self copyTo: aContext atEachStep: [:originalContext :copiedContext| originalContext sender == aContext ifTrue: [copiedContext privSender: nil. aBlock value: copiedContext]] _,,,^..^,,,_ best, Eliot

3 4

The Trunk: ToolBuilder-Morphic-mt.334.mcz
by commits＠source.squeak.org 01 Feb '23

01 Feb '23

Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk: http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.334.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-mt.334 Author: mt Time: 1 February 2023, 1:44:55.134056 pm UUID: c792ffe3-3a9e-3944-90f1-4cc30bcbaa5d Ancestors: ToolBuilder-Morphic-mt.333 In tree widgets, for now, really collapse all items in the list we are currently filtering to avoid inadvertent walk-down while typing (and updating) the filter. We might want to be able to save-and-restore expanded-state after removing the filter again. Yes, by current design, the tree filter (and search) *does not* care for the current expanded-state of any node in the view. =============== Diff against ToolBuilder-Morphic-mt.333 =============== Item was changed: ----- Method: PluggableTreeMorph>>filterTreeNow (in category 'filtering') ----- filterTreeNow | any | self hasFilter ifFalse: [^ self removeFilter]. "Show all current items again before filtering them out." scroller submorphsDo: [:m | m removeFilter]. "Filter the children of the current parent. Do not filter the parent." any := false. self selectedParentMorph ifNil: [self roots do: [:each | + each collapse. "Avoid inadvertent walk-down. See #treeFilterAppend:." (each applyFilter: lastKeystrokes column: filterColumnIndex) ifTrue: [any := true]]] ifNotNil: [:pm | pm childrenDo: [:each | + each collapse. "Avoid inadvertent walk-down. See #treeFilterAppend:." (each applyFilter: lastKeystrokes column: filterColumnIndex) ifTrue: [any := true]]]. any ifFalse: [ "Remove the last character and try filtering again." lastKeystrokes := lastKeystrokes allButLast: 1. ^ self filterTreeNow]. self adjustSubmorphPositions!

1 0