Squeak-dev June 2022

squeak-dev@lists.squeakfoundation.org

30 participants
309 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

The Inbox: PreferenceBrowser-ct.150.mcz
by commits＠source.squeak.org 07 Jul '22

07 Jul '22

A new version of PreferenceBrowser was added to project The Inbox: http://source.squeak.org/inbox/PreferenceBrowser-ct.150.mcz ==================== Summary ==================== Name: PreferenceBrowser-ct.150 Author: ct Time: 20 May 2022, 6:48:44.518499 pm UUID: 3d8cf55a-3022-9643-8df9-fd41f5577848 Ancestors: PreferenceBrowser-mt.149 Proposal: Also search the category list of preferences via the search field. I was so confused that some 'halo' preferences did not appear in the search results. =============== Diff against PreferenceBrowser-mt.149 =============== Item was changed: ----- Method: PreferenceBrowser>>searchPreferencesFor: (in category 'preferences search') ----- searchPreferencesFor: pattern | result | result := pattern asString asLowercase withBlanksTrimmed. result ifEmpty: [^self]. searchResults := self allPreferences select: [:aPreference | ((aPreference name includesSubstring: result caseSensitive: false) or: [aPreference helpString includesSubstring: result caseSensitive: false]) + or: [aPreference codeString includesSubstring: result caseSensitive: false] + or: [aPreference categoryList anySatisfy: [:category | + category includesSubstring: result caseSensitive: false]] ]. - or: [aPreference codeString includesSubstring: result caseSensitive: false] ]. self updateSearchResultsLabel. self selectSearchResultsCategory. self lastExecutedSearch: pattern. !

2 1

Fuel 5.0.5 for Squeak 6
by Max Leske 07 Jul '22

07 Jul '22

Hi all, It's great that you are finally approaching a release. I just checked my repository history and I've had a "SqueakPlatform06" class since February 18, 2018 :). I just updated Fuel to 5.0.5 with some cleanup for Squeak 6 so it should good to go, otherwise, let me know. Cheers, Max

2 1

Modification: do not show Object's methods in protocol browser by default
by Jakob Reschke 07 Jul '22

07 Jul '22

Dear Squeakers, When using the protocol browser, I often exclude the methods inherited from Object because its methods are not interesting to me. On the contrary, they make it harder to find the unique messages of the browsed class's hierarchy. Find attached a patched method that excludes Object automatically. If you think this should enter the Trunk after the release, with or without a preference, let me know. Then I shall post it to the Inbox eventually. Kind regards, Jakob

2 1

The Trunk: Tools-jar.1161.mcz
by commits＠source.squeak.org 03 Jul '22

03 Jul '22

Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/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"!

6 13

Note sharing inside Squeak?
by Jaromir Matas 02 Jul '22

02 Jul '22

Hi all, In your experience, what would be a good place to *share* more detailed information about e.g. a method: like why I had to include this line and that check, which situations must be taken into account, alternative approaches, examples, references to tests etc etc. Ideally reachable from the image. Would such "notesharing" be welcome or rather confusing or even conterproductive? Often I forget why I did this and that and have to check my notes (if I'm lucky to have made them AND find them). I'm aware method comments are definitely not the place; they are meant to be rather terse and polished. Squeak wiki? Squeak Help? They’d have to be linked somehow to the methods, I imagine, to be useful in this regard… Any suggestion welcome :) Best, Jaromir -- Jaromír Matas mail(a)jaromir.net

9 38

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

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

Jump to page: