Squeak-dev April 2022

squeak-dev@lists.squeakfoundation.org

29 participants
332 discussions

Squeak VM & image package/bundle building?
by tim Rowledge 07 Jul '22

07 Jul '22

We obviously have some system in place that produces the downloadable packages containing the vm & image etc. I haven't so far successfully googled anything that usefully helps me understand *how*. What is the current build setup for these things? Do we have to run platform specific jobs or is it practical to have a single system? I'm interested in how one might build a Mac bundle, for example, that might have a custom name, icons, image file, other resources. I recall some quite long threads about the joy of signing Mac application bundles too. And can Mac & Windows applications run without open windows these days? Again, I recall interesting issues with this years ago but nothing from more recent times. Imagine I want to run a Seaside server; no open windows, write errors to a suitable log, stuff like that. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Furnulum pani nolo = I don't want a toaster.

2 1

A bug in #releaseCriticalSection: preventing correct unwind (in rare situations)
by mail＠jaromir.net 07 Jul '22

07 Jul '22

--==CelesteAttachment21924== Content-type: text/plain;charset=UTF-8 Hi Eliot, all, There's a bug, or rather an omission, in #releaseCriticalSection: causing the following examples unwind incorrectly: Mutex new inspect critical: [self halt] If you run the example in a workspace, a debugger and an inspector opens - please watch Mutex's 'owner' variable; then step into a few times to get right before sending #primitiveExitCriticalSection and terminate the debugger (in the newest images please use debugger's window menu -> terminate process); and observe the owner won't get cleared and will remain blocking the Mutex. Same behavior for Semaphores: Semaphore forMutualExclusion inspect critical: [self halt] Again, watch Semaphore's excessSignals variable in the Inspector, step into a few times until you stand before sending #signal - and terminate the debugged process (from the debuggers menu or from the Process Browser if you like) - the Semaphore won't recharge excessSignals back to 1. The root cause is #releaseCriticalSection: doesn't account for terminating in this particular position of the computation. It can be fixed e.g. by adding an additional condition ('progressedIntoEnsure') - try the examples with the enclosed changeset; both Mutexes and Semaphores work ok now. Best, ~~~ ^[^ Jaromir Sent from Squeak Inbox Talk ["Process-releaseCriticalSection.st"] --==CelesteAttachment21924== Content-transfer-encoding: base64 Content-disposition: attachment;filename="Process-releaseCriticalSection.st" Content-type: application/octet-stream;name="Process-releaseCriticalSection.st" J0Zyb20gU3F1ZWFrNi4wYWxwaGEgb2YgMTcgRGVjZW1iZXIgMjAyMSBbbGF0ZXN0IHVwZGF0 ZTogIzIwODgwXSBvbiAyMSBEZWNlbWJlciAyMDIxIGF0IDY6MDQgcG0nIQ0NIVByb2Nlc3Mg bWV0aG9kc0ZvcjogJ3ByaXZhdGUnIHN0YW1wOiAnamFyIDEyLzIxLzIwMjEgMTY6MzUnIQ1y ZWxlYXNlQ3JpdGljYWxTZWN0aW9uOiBydW5uYWJsZQ0JIkZpZ3VyZSBvdXQgaWYgd2UgYXJl IHRlcm1pbmF0aW5nIGEgcHJvY2VzcyB0aGF0IGlzIGluIHRoZSBlbnN1cmU6IGJsb2NrIG9m IGEgY3JpdGljYWwgc2VjdGlvbi4NCSBJbiB0aGlzIGNhc2UsIGlmIHRoZSBibG9jayBoYXMg bWFkZSBwcm9ncmVzcywgcG9wIHRoZSBzdXNwZW5kZWRDb250ZXh0IHNvIHRoYXQgd2UgbGVh dmUgdGhlDQkgZW5zdXJlOiBibG9jayBpbnNpZGUgdGhlIGNyaXRpY2FsOiB3aXRob3V0IHNp Z25hbGluZyB0aGUgc2VtYXBob3JlL2V4aXRpbmcgdGhlIHByaW1pdGl2ZSBzZWN0aW9uLA0J IHNpbmNlIHByZXN1bWFibHkgdGhpcyBoYXMgYWxyZWFkeSBoYXBwZW5lZC4gIEJ1dCBpZiBp dCBoYXNuJ3QgbWFkZSBwcm9ncmVzcyBidXQgaXMgYmV5b25kIHRoZQ0JIHdhaXQgKHdoaWNo IHdlIGNhbiB0ZWxsIGJ5IHRoZSBvbGRMaXN0IGJlaW5nIG9uZSBvZiB0aGUgcnVubmFibGUg bGlzdHMsIGkuZS4gYSBMaW5rZWRMaXN0LCBub3QgYQ0JIFNlbWFwaG9yZSBvciBNdXRleCwg ZXQgYWwpLCB0aGVuIHRoZSBlbnN1cmU6IGJsb2NrIG5lZWRzIHRvIGJlIHJ1bi4iDQl8IHNl bGVjdG9ySnVzdFNlbnQgfA0JKHN1c3BlbmRlZENvbnRleHQgbWV0aG9kIHByYWdtYUF0OiAj Y3JpdGljYWxTZWN0aW9uKSBpZk5pbDogW15zZWxmXS4NCXNlbGVjdG9ySnVzdFNlbnQgOj0g c3VzcGVuZGVkQ29udGV4dCBzZWxlY3Rvckp1c3RTZW50T3JTZWxmLg0NCSJSZWNlaXZlciBh bmQvb3IgYXJndW1lbnQgYmxvY2tzIG9mIGVuc3VyZTogaW4gU2VtYXBob3JlPj5jcml0aWNh bDogb3IgTXV0ZXg+PiNjcml0aWNhbDoiDQlzdXNwZW5kZWRDb250ZXh0IGlzQ2xvc3VyZUNv bnRleHQgaWZUcnVlOg0JCVtzdXNwZW5kZWRDb250ZXh0IHNlbmRlciBpc1Vud2luZENvbnRl eHQgaWZUcnVlOg0JCQlbfCBub3RXYWl0aW5nQnV0TWFkZU5vUHJvZ3Jlc3MgcHJvZ3Jlc3Nl ZEludG9FbnN1cmUgfA0JCQkiQXZvaWQgcnVubmluZyB0aGUgZW5zdXJlOiBibG9jayB0d2lj ZSwgcG9wcGluZyBpdCBpZiBpdCBoYXMgYWxyZWFkeSBiZWVuIHJ1bi4gSWYgcnVubmFibGUN CQkJIGJ1dCBhdCB0aGUgd2FpdCwgbGVhdmUgaXQgaW4gcGxhY2UuIE4uQi4gTm8gbmVlZCB0 byBjaGVjayBpZiB0aGUgYmxvY2sgcmVjZWl2ZXIgb2YgZW5zdXJlOiBoYXMNCQkJIG5vdCBz dGFydGVkIHRvIHJ1biAodmlhIHN1c3BlbmRlZENvbnRleHQgcGMgPSBzdXNwZW5kZWRDb250 ZXh0IHN0YXJ0cGMpIGJlY2F1c2UgZW5zdXJlOg0JCQkgdXNlcyB2YWx1ZU5vQ29udGV4dFN3 aXRjaCwgYW5kIHNvIHRoZXJlIGlzIG5vIHN1c3BlbnNpb24gcG9pbnQgYmVmb3JlIHRoZSB3 YWl0LiINCQkJIG5vdFdhaXRpbmdCdXRNYWRlTm9Qcm9ncmVzcyA6PQ0JCQkJcnVubmFibGUN CQkJCWFuZDogW3NlbGVjdG9ySnVzdFNlbnQgPT0gI3dhaXQNCQkJCWFuZDogW3N1c3BlbmRl ZENvbnRleHQgc2VuZGVyIHNlbGVjdG9ySnVzdFNlbnRPclNlbGYgPT0gI3ZhbHVlTm9Db250 ZXh0U3dpdGNoXV0uDQkJCSBwcm9ncmVzc2VkSW50b0Vuc3VyZSA6PQ0JCQkJcnVubmFibGUN CQkJCWFuZDogW3N1c3BlbmRlZENvbnRleHQgc2VuZGVyIHNlbGVjdG9ySnVzdFNlbnRPclNl bGYgPT0gI3ZhbHVlXS4NCQkJIChub3RXYWl0aW5nQnV0TWFkZU5vUHJvZ3Jlc3Mgb3I6IFtw cm9ncmVzc2VkSW50b0Vuc3VyZV0pIGlmRmFsc2U6DQkJCQlbc3VzcGVuZGVkQ29udGV4dCA6 PSBzdXNwZW5kZWRDb250ZXh0IGhvbWVdXS4NCQkgXnNlbGZdLg0NCSJFaXRoZXIgU2VtYXBo b3JlPj5jcml0aWNhbDogb3IgTXV0ZXg+PiNjcml0aWNhbDouICBJcyB0aGUgcHJvY2VzcyBz dGlsbCBibG9ja2VkPyAgSWYgc28sIG5vdGhpbmcgZnVydGhlciB0byBkby4iDQlydW5uYWJs ZSBpZkZhbHNlOiBbXnNlbGZdLg0NCSJJZiBzdGlsbCBhdCB0aGUgd2FpdCB0aGUgZW5zdXJl OiBibG9jayBoYXMgbm90IGJlZW4gYWN0aXZhdGVkLCBzbyBzaWduYWwgdG8gcmVzdG9yZS4i DQlzZWxlY3Rvckp1c3RTZW50ID09ICN3YWl0IGlmVHJ1ZToNCQlbc3VzcGVuZGVkQ29udGV4 dCByZWNlaXZlciBzaWduYWxdLg0NCSJJZiBzdGlsbCBhdCB0aGUgbG9jayBwcmltaXRpdmUg YW5kIHRoZSBsb2NrIHByaW1pdGl2ZSBqdXN0IGFjcXVpcmVkIG93bmVyc2hpcCAoaW5kaWNh dGVkIGJ5IGl0IGFuc3dlcmluZyBmYWxzZSkNCSB0aGVuIHRoZSBlbnN1cmUgYmxvY2sgaGFz IG5vdCBiZWVuIGFjdGl2YXRlZCwgc28gZXhwbGljaXRseSBwcmltaXRpdmVFeGl0Q3JpdGlj YWxTZWN0aW9uIHRvIHVubG9jay4iDQkoc2VsZWN0b3JKdXN0U2VudCA9PSAjcHJpbWl0aXZl RW50ZXJDcml0aWNhbFNlY3Rpb24NCSBvcjogW3NlbGVjdG9ySnVzdFNlbnQgPT0gI3ByaW1p dGl2ZVRlc3RBbmRTZXRPd25lcnNoaXBPZkNyaXRpY2FsU2VjdGlvbl0pIGlmVHJ1ZToNCQlb KHN1c3BlbmRlZENvbnRleHQgc3RhY2tQdHIgPiAwDQkJICBhbmQ6IFtzdXNwZW5kZWRDb250 ZXh0IHRvcCA9PSBmYWxzZV0pIGlmVHJ1ZToNCQkJW3N1c3BlbmRlZENvbnRleHQgcmVjZWl2 ZXIgcHJpbWl0aXZlRXhpdENyaXRpY2FsU2VjdGlvbl1dISAhDQ== --==CelesteAttachment21924==-- --=--

3 2

Monticello Repositories
by Eliot Miranda 07 Jul '22

07 Jul '22

Hi all, I want to add and satisfy two requirements for Monticello repositories. The first is that - there is a page on squeak.org that describes how to set up a Monticello repository and either points to the code necessary to build a Monticello repository image, or points to downloadable Monticello repository image & changes files. There is at least two paragraphs on Monticello in the Welcome workspace/Help tool that cover its general power (distributed VCS that can work fully disconnected) and how easy it is to set up. The second is that repositories and repository inspectors are extended to include the equivalent of a README.md, a top-level readme for the entire repository, in which repository maintainers can give high-level, lay-of-the-land information. The README would appear at the top of the list of packages in a repository inspector. The first requirement is for developers who wish to set up private and/or personal Monticello repositories. This is easy to do, but only if one knows how. Currently that information is missing from squeak.org and the Welcome workspace/Help tool. The second requirement is to make loading code from repositories easier. I just had to ask Levente how to load a full configuration from the Cryptography repository because there is no where in the repository, visible from within the image, specifically visible from a repository inspector, to get this info. Can we make this so? _,,,^..^,,,_ (phone)

2 3

Dead primitive 103 makes scrolling truetype fonts very, very slow. Let's get rid of it
by Tony Garnock-Jones 07 Jul '22

07 Jul '22

Hi all, Commenting out "<primitive 103>" in CharacterScanner>>primScanCharactersFrom:to:in:rightX:stopConditions:kern: immediately and dramatically improves the performance of scrolling anything truetype-font-ish on my very slow arm64 cellphone. It's still not *fast* (why is it re-layouting when I just change the TransformMorph's offset??) but it's faster than it was before, which was "lock up the entire UI for ten seconds while thinking about failing primitive 103"-speed. Interestingly, fast x86_64 machines aren't immune either! Running a tally in the same image on my x86_64 pc with a modern VM, and doing the same scrolly thing, showed primitives to be taking a significant chunk of time. Commenting out "<primitive 103>" there immediately eliminated a lot of wasted CPU usage, though the machine is so fast it's not easy to notice the improvement at squishy meatbody sensory refresh rates. So, should I commit a change that comments out "<primitive 103>" for good? I don't see a downside! Is there one? Cheers, Tony

3 20

Review Request: fix-busyWait-precision.1.cs
by christoph.thiede＠student.hpi.uni-potsdam.de 02 Jul '22

02 Jul '22

=============== Summary =============== Change Set: fix-busyWait-precision Date: 28 March 2022 Author: Christoph Thiede Fixes #busyWait for durations < 1 milliSecond. Since the original proposal (Chronology-Core-ct.67), the implementation had been moved from Duration to Delay (Chronology-Core-mt.71). However, Delay has only milliseconds precision, causing shorter durations to be handled as a delayDuration of 0 milliSeconds and leading to this erroneous output: [1 microSeconds busyWait] bench '6,240,000 per second. 160 nanoseconds per run. 0.67973 % GC time.' Moves #busyWait implementation back to Duration and invokes it from Delay. Not sure whether we need the latter hook, though. =============== Diff =============== Delay>>busyWait {delaying} · ct 3/28/2022 22:36 (changed) busyWait - "BEWARE! This method is more precise than #wait, but it sacrifices many CPU cycles for that precision. Also note that the GC runs more often. Also note that only processes with a higher priority can run while waiting. - - The following lists the precision (in milliseconds) of #wait on a Microsoft Surface Pro 6, Windows 10 21H1, OSVM 202104182333: - 100 -> 100 - 50 -> 51.1 ... 102.2% - 10 -> 11.6 ... 105.5% ... maybe use #busyWait - 5 -> 5.93 ... 118.6% ... use #busyWait but check process priorities - 1 -> 1.41 ... 141.0% ... use #busyWait but check process priorities - - As of July 2021, the shortest delay that we can guarantee on all platforms is still 1 millisecond as the value of #utcMicrosecondClock might not change any faster than that. For more information, see http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-July/215928.html" - - "[5 milliSeconds busyWait] bench" + "BEWARE! This method is more precise than #wait, but it sacrifices many CPU cycles for that precision. Also note that the GC runs more often. Also note that only processes with a higher priority can run while waiting. See more detailed commentary in Duration >> #busyWait." - | proceedTime | - proceedTime := Time utcMicrosecondClock + (delayDuration "milliseconds" * 1000). - [Time utcMicrosecondClock >= proceedTime] whileFalse. + ^ self delayDuration microSeconds busyWait Duration>>busyWait {squeak protocol} · ct 3/28/2022 22:39 (changed) busyWait - "BEWARE! This method is more precise than #wait, but it sacrifices many CPU cycles for that precision. Also note that only processes with a higher priority can run while waiting. See more detailed commentary in Delay >> #busyWait." + "BEWARE! This method is more precise than #wait, but it sacrifices many CPU cycles for that precision. Also note that the GC runs more often. Also note that only processes with a higher priority can run while waiting. + + The following lists the precision (in milliseconds) of #wait on a Microsoft Surface Pro 6, Windows 10 21H1, OSVM 202104182333: + 100 -> 100 + 50 -> 51.1 ... 102.2% + 10 -> 11.6 ... 105.5% ... maybe use #busyWait + 5 -> 5.93 ... 118.6% ... use #busyWait but check process priorities + 1 -> 1.41 ... 141.0% ... use #busyWait but check process priorities + + As of July 2021, the shortest delay that we can guarantee on all platforms is still 1 millisecond as the value of #utcMicrosecondClock might not change any faster than that. For more information, see http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-July/215928.html" + + "[5 milliSeconds busyWait] bench" - ^ self asDelay busyWait + | proceedTime | + proceedTime := Time utcMicrosecondClock + self asMicroSeconds. + [Time utcMicrosecondClock >= proceedTime] whileFalse. ["fix-busyWait-precision.1.cs"] --- Sent from Squeak Inbox Talk ["fix-busyWait-precision.1.cs"]

7 16

[PSA] Squeak 6.0 | The Dates
by Marcel Taeumel 02 Jul '22

02 Jul '22

Hi all! -- Let's do this. - Feature Freeze on May 6, 23:59 AOE -> 11 days to go - Beta testing until May 15, 23:59 AOE -> 20 days to go - Picking a release candidate until May 18, 23:59 AOE -> 23 days to go The current state of tests can be found here: - https://github.com/squeak-smalltalk/squeak-app/actions - https://github.com/marceltaeumel/squeak-ffi/actions Download the latest squeak-app bundles from here: - http://files.squeak.org/6.0alpha/ - http://files.squeak.org/6.0beta/ (after May 6) - http://files.squeak.org/6.0rc1/ (after May 15) - http://files.squeak.org/6.0rc2/ - ... Please report bugs here on squeak-dev or on GitHub: - https://github.com/squeak-smalltalk/squeak-object-memory/issues After the Feature Freeze, this will happen in the Trunk Update Stream: - Unload 60Deprecated via postload-script - Adapt "SqueakVersion" to keep build number stable - Add "Load deprecated methods" to preference wizard - Update update map to not include 60Deprecated anymore After the release, this will happen in the Trunk Update Stream: - Add new 61Deprecated package - Trunk open for the features again ! Discuss the critical ones via Inbox as usual Meanwhile, the release versions of all packages will be copied over to source.squeak.org/squeak60. Best, Marcel P.S.: Here is the previous info on the release planning: http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-March/219520.ht…

9 37

The Inbox: Tools-ct.1147.mcz
by commits＠source.squeak.org 24 Jun '22

24 Jun '22

A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-ct.1147.mcz ==================== Summary ==================== Name: Tools-ct.1147 Author: ct Time: 26 April 2022, 12:12:36.942702 pm UUID: 11944f29-f575-7b41-824d-71e945afa0d2 Ancestors: Tools-tpr.1146 Updates workspace styles after toggling #shouldStyle preference. This also improves the liveness in the preference wizard. =============== Diff against Tools-tpr.1146 =============== Item was changed: ----- Method: Workspace class>>shouldStyle: (in category 'preferences') ----- shouldStyle: aBoolean + ShouldStyle := aBoolean. + + self allSubInstancesDo: [:workspace | workspace changed: #style].! - ShouldStyle := aBoolean!

4 3

The Trunk: Tools-tpr.1008.mcz
by commits＠source.squeak.org 22 Jun '22

22 Jun '22

tim Rowledge uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-tpr.1008.mcz ==================== Summary ==================== Name: Tools-tpr.1008 Author: tpr Time: 25 October 2020, 5:52:09.007789 pm UUID: 2ebe15ce-0c25-4b8d-b993-f1c51203dee5 Ancestors: Tools-tpr.1003, Tools-mt.1007 Rework the window label handing of MessageSet/Trace to be a bit more accurate, and to work within the normal style of labels. Instead of assuming the size of the list passed to the MessageSet/Trace is correct, derive it from the post-processing list. We process the list to remove duplicates, which e.g. the #allUnimplementedCalls method produces. This required adding an instvar to M-Set, removing one from M-Trace, setting the new one properly, dumping some dodgy code that used to half-assedly derive the old one, use the proper #changed: #windowTitle to, y'know, change the title, and some faffing with the messageList. As a result we are better placed to make further improvements if/when we develop a way to correctly hightlight multi-part keywords (or indeed, multiple messages) within a single method, which would greatly improve many browsers. This benefits from being accompanied by the single-method change in the System-tpr.1181 package =============== Diff against Tools-mt.1007 =============== Item was changed: CodeHolder subclass: #MessageSet + instanceVariableNames: 'growable messageList messageListFormatted autoSelectString messageListIndex editSelection windowLabel' - instanceVariableNames: 'growable messageList messageListFormatted autoSelectString messageListIndex editSelection' classVariableNames: 'UseUnifiedMessageLabels' poolDictionaries: '' category: 'Tools-Browser'! !MessageSet commentStamp: '<historical>' prior: 0! I represent a query path of the retrieval result of making a query about methods in the system. The result is a set of methods, denoted by a message selector and the class in which the method was found. As a StringHolder, the string I represent is the source code of the currently selected method. I am typically viewed in a Message Set Browser consisting of a MessageListView and a BrowserCodeView.! Item was changed: ----- Method: MessageSet class>>openMessageList:name:autoSelect: (in category 'instance creation') ----- openMessageList: messageList name: labelString autoSelect: autoSelectString "Open a system view for a MessageSet on messageList. + The labelString is passed to the model to use as a base label, depending on the selection state" - 1/24/96 sw: the there-are-no msg now supplied by my sender" | messageSet | messageSet := self messageList: messageList. + messageSet + autoSelectString: autoSelectString; + setInitialLabel: labelString. + ^ToolBuilder open: messageSet! - messageSet autoSelectString: autoSelectString. - ^ToolBuilder open: messageSet label: labelString! Item was changed: ----- Method: MessageSet>>adjustWindowTitleAfterFiltering (in category 'private') ----- adjustWindowTitleAfterFiltering + "Set the title of the receiver's window, if any, to reflect the just-completed filtering. Avoid re-doing it if fitering is re-done" - "Set the title of the receiver's window, if any, to reflect the just-completed filtering" + (windowLabel endsWith: 'Filtered') + ifFalse: [windowLabel := windowLabel , ' Filtered'. + self changed: #windowTitle]! - | aWindow existingLabel newLabel | - - (aWindow := self containingWindow) ifNil: [^ self]. - (existingLabel := aWindow label) isEmptyOrNil ifTrue: [^ self]. - (((existingLabel size < 3) or: [existingLabel last ~~ $]]) or: [(existingLabel at: (existingLabel size - 1)) isDigit not]) ifTrue: [^ self]. - existingLabel size to: 1 by: -1 do: - [:anIndex | ((existingLabel at: anIndex) == $[) ifTrue: - [newLabel := (existingLabel copyFrom: 1 to: anIndex), - 'Filtered: ', - messageList size printString, - ']'. - ^ aWindow setLabel: newLabel]] - - - ! Item was changed: ----- Method: MessageSet>>initializeMessageList: (in category 'private') ----- initializeMessageList: anArray "Initialize my messageList from the given list of MethodReference or string objects. NB: special handling for uniclasses. Do /not/ replace the elements of anArray if they are already MethodReferences, so as to allow users to construct richer systems, such as differencers between existing and edited versions of code." + messageList := Set new. - messageList := OrderedCollection new. anArray do: [:each | each isMethodReference + ifTrue: [messageList add: each] - ifTrue: [messageList addLast: each] ifFalse: [ MessageSet parse: each toClassAndSelector: + [ : class : sel | class ifNotNil: [ messageList add: (MethodReference class: class selector: sel) ] ] ] ]. + messageList := messageList asOrderedCollection sort. - [ : class : sel | class ifNotNil: [ messageList addLast: (MethodReference class: class selector: sel) ] ] ] ]. "Unify labels if wanted." self class useUnifiedMessageLabels ifTrue: [ messageList withIndexDo: [ : each : index | | cls | cls := each actualClass. each stringVersion: (self indentionPrefixOfSize: (self indentionsIn: each stringVersion)) , (cls ifNil: [each asString] ifNotNil: [cls isUniClass ifTrue: [cls typicalInstanceName, ' ', each selector] ifFalse: [ cls name , ' ' , each selector , ' {' , ((cls organization categoryOfElement: each selector) ifNil: ['']) , '}' , ' {', cls category, '}' ] ]) ] ]. messageListIndex := messageList isEmpty ifTrue: [0] ifFalse: [1]. contents := String empty! Item was changed: ----- Method: MessageSet>>messageListIndex: (in category 'message list') ----- messageListIndex: anInteger + "Set the index of the selected item to be anInteger. + Update the message list morph, the text edit morph and the assorted buttons" - "Set the index of the selected item to be anInteger." messageListIndex := anInteger. contents := messageListIndex ~= 0 ifTrue: [self selectedMessage] ifFalse: ['']. self changed: #messageListIndex. "update my selection" self editSelection: #editMessage. self contentsChanged. (messageListIndex ~= 0 and: [ autoSelectString notNil and: [ self contents notEmpty ] ]) ifTrue: [ self changed: #autoSelect ]. self decorateButtons ! Item was added: + ----- Method: MessageSet>>setInitialLabel: (in category 'accessing') ----- + setInitialLabel: aString + "set the base label for the window, as returned by #windowTitle" + + windowLabel := aString! Item was added: + ----- Method: MessageSet>>windowTitle (in category 'user interface') ----- + windowTitle + "just return the basic label for now" + + ^windowLabel! Item was changed: MessageSet subclass: #MessageTrace + instanceVariableNames: 'autoSelectStrings messageSelections anchorIndex' - instanceVariableNames: 'autoSelectStrings messageSelections anchorIndex defaultSelectString' classVariableNames: '' poolDictionaries: '' category: 'Tools-Browser'! !MessageTrace commentStamp: 'cmm 3/2/2010 20:26' prior: 0! A MessageTrace is a MessageSet allowing efficient sender/implementor message following. With implementors indented below, and senders outdended above, message flow is succinctly expressed, hierarchically. My autoSelectStrings and messageSelections are Arrays of Booleans, parallel to my messageList. Each boolean indicates whether that message is selected. Each autoSelectStrings indicates which string should be highlighted in the code for each method in my messageList.! Item was changed: ----- Method: MessageTrace>>browseAllImplementorsOf: (in category 'actions') ----- browseAllImplementorsOf: selectorSymbol | selectorToBrowse | selectorToBrowse := self selection ifNil: [ selectorSymbol ] + ifNotNil: [ self getImplementorNamed: selectorSymbol asSymbol "since we can get passed literals"]. - ifNotNil: [ self getImplementorNamed: selectorSymbol ]. (self hasUnacceptedEdits or: [ Preferences traceMessages not ]) ifTrue: [ super browseAllImplementorsOf: selectorToBrowse ] ifFalse: [ self addChildMethodsNamed: selectorToBrowse ] ! Item was changed: ----- Method: MessageTrace>>initializeMessageList: (in category 'private initializing') ----- initializeMessageList: anArray - messageSelections := (Array new: anArray size withAll: false) asOrderedCollection. super initializeMessageList: anArray. + messageSelections := (Array new: messageList size withAll: false) asOrderedCollection. self messageAt: messageListIndex beSelected: true. "autoSelectStrings is initialized right after this method, in autoSelectString:" ! Item was changed: ----- Method: MessageTrace>>messageListIndex: (in category 'actions') ----- messageListIndex: anInteger + "Set the index of the selected item to be anInteger. + Find the relevant auto select string to use, do my superclass' work and update the window title" + autoSelectStrings ifNotEmpty: [ autoSelectString := anInteger = 0 + ifTrue: [ "clear the autoSelectString" + String empty ] + ifFalse: [autoSelectStrings at: anInteger] + ]. + + anInteger > 0 ifTrue: [ self + messageAt: anInteger + beSelected: true + ]. + super messageListIndex: anInteger. + self changed: #windowTitle - ifTrue: - [ defaultSelectString ifNotNil: [:default| self containingWindow setLabel: default]. - "clear the autoSelectString" - '' ] - ifFalse: - [ messageListIndex := anInteger. - "setting the window label, below, can't wait for this.." - self containingWindow setLabel: (self windowLabelAt: anInteger). - "work out the string to ask the text view to pre-select. We should do better than this; after all the debugger does" - (autoSelectStrings at: anInteger)] ]. - anInteger > 0 ifTrue: - [ self - messageAt: anInteger - beSelected: true ]. - super messageListIndex: anInteger ! Item was changed: ----- Method: MessageTrace>>windowLabelAt: (in category 'private accessing') ----- windowLabelAt: anInteger + "return a suitable window label when there is an actual list item selected; work out what it should be based upon the array of autoSelectStrings or the current selection" + ^(autoSelectStrings at: anInteger) + ifNil: [ 'Implementors of ', - | str | - defaultSelectString ifNil: - [defaultSelectString := self containingWindow label]. - ^(str := autoSelectStrings at: anInteger) - ifNil: - [ 'Implementors of ', (self class parse: self selection + toClassAndSelector: [ :class :selector | selector ]) + ] + ifNotNil: [:str| 'Senders of ', str ] - toClassAndSelector: [ :class :selector | selector ]) ] - ifNotNil: - [ 'Senders of ', str ] ! Item was added: + ----- Method: MessageTrace>>windowTitle (in category 'building') ----- + windowTitle + "set the window label to suit the selection state; + if no selection, use saved widow label and add the number of items in the messageList + if something is selected, use the relevant string provided by windowLabelAt: which considers the index" + + ^messageListIndex = 0 + ifTrue:[String streamContents: [:str| str nextPutAll: windowLabel; + space; + nextPut: $[; + nextPutAll: messageList size asString; + nextPut: $] + ] + ] + ifFalse: [self windowLabelAt: messageListIndex]!

3 5

Unicode
by Thiede, Christoph 15 Jun '22

15 Jun '22

Hi all! :-) After some recent fun with the Unicode class, I found out that its data is quite out of date (for example, the comments do not even "know" that code points can be longer than 4 bytes. Younger characters such as 😺❤🤓 are not categorized correctly, etc. ...). Luckily, there is already some logic to fetch the latest data from www.unicode.org<http://www.unicode.org>. I'm currently reworking this logic because it's not completely automated yet and has some slips, but so long, I have one general question for you: At the moment, we have 30 class variables each for one Unicode category number. These class vars map in alphabetical order to the integers from 0 to: 29. Is this tedious structure really necessary? For different purposes, I would like to get the category name of a specific code point from a client. The current design makes this impossible without writing additional mappings. Tl;dr: I would like to propose to drop these class variables and use Symbols instead. They are comparable like integers, and as they are flyweights, this should not be a performance issue either. Of course, #generalCategoryOf: will have to keep returning numbers, but we could deprecate it and use a new #generalTagOf: in the future. Furthermore, this would also allow us to deal with later added category names (though I don't know whether this will ever happen). Examples: Unicode generalTagOf: $a asUnicode. "#Ll" Unicode class >> isLetterCode: charCode ^ (self generalTagOf: charCode) first = $L Unicode class >> isAlphaNumericCode: charCode | tag| ^ (tag := self generalCategoryOf: charCode) first = $L or: [tag = #Nd] How do you think about this proposal? Please let me know and I will go ahead! :D Best, Christoph

9 26

Re-signalling an already signaled exception
by mail＠jaromir.net 12 Jun '22

12 Jun '22

Hi all, You can signal an already signaled exception; the nested #signal will start searching for an exception handler from the most recently created exception handler. I wonder if this is a legitimate and reasonable interpretation of ANSI's #signal: Quote: The current exception environment is searched for an exception handler whose exception selector matches the signaled exception. The search proceeds from the most recently created exception handler to the oldest exception handler. Repeated #signal would differ from #outer in that #outer starts serching for a handler from the current handler context and not from the most recently created handler context. Here's a motivation example: [1/0] on: Error do: [:ex | [ex signal] on: ZeroDivide do: [Transcript show: #ZeroDivide] ] Would you expect this code to work and pick up the ZeroDivide handler? Current implementation will ignore the ZeroDivide handler and open a debugger as the default action. It because currently a repeated signal is made equivalent to #outer. If you agree with the above interpretation then The Inbox: Kernel-jar.1407 provides its implementation and Tests-jar.464 some tests. The point or a use case is to provide additional (finer, more specific) handlers inside the general handler rather than wrap the general handler inside more specific handlers. More specific handlers can even be inside a method so the readability would not degrade. Here's a simple example: [1/o] on: Error do: [:ex | [[ex signal] on: ZeroDivide do: [Transcript show: #ZeroDivide]] on: MessageNotUnderstood do: [Transcript show: #MNU] ] or even [1/o] on: Error do: [:ex | self dissect: ex] instead of [[1/o] on: ZeroDivide do: [Transcript show: #ZeroDivide]] on: MessageNotUnderstood do: [Transcript show: #MNU] Does this make sense? Thanks for your opinion. best, Jaromir ^[^ -- Sent from Squeak Inbox Talk

6 12

← Newer
1
2
3
4
5
6
7
8
...
34
Older →

Jump to page: