From frank-lesser at lesser-software.com Fri Jan 1 09:37:38 2021 From: frank-lesser at lesser-software.com (Frank Lesser) Date: Fri, 1 Jan 2021 10:37:38 +0100 Subject: [squeak-dev] [offtopic] Smalltalk puzzles In-Reply-To: References: Message-ID: <625de794-70d2-2a49-93da-0dc583532b6f@lesser-software.com> Happy new year, I have published 2 new puzzles #SmalltalkPuzzle on my twitter @LesserFrank. Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Fri Jan 1 18:00:50 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Fri, 1 Jan 2021 18:00:50 +0000 Subject: [squeak-dev] Fwd: [OpenSmalltalk/opensmalltalk-vm] Trouble running OSVM in an Ubuntu 20/aarch64 docker (raspi) (#544) In-Reply-To: References: <1609352251-e5fe5cf9bc6eae7a6a88106269547f22@pckswarms.ch> <5b2c27a3e2b64e5dbfcfd3b41b555e1f@student.hpi.uni-potsdam.de> <223637412.155972.1609341080692.JavaMail.administrator@n4.nabble.com> <1609352459-5256fcd7eb69c2aa1bfee8434efb77f3@pckswarms.ch>, Message-ID: <3bdb5f914f0d4dc08061f0344fef19d9@student.hpi.uni-potsdam.de> Hm, it still fails with the mprotect permission denied error :( ________________________________ Von: Squeak-dev im Auftrag von K K Subbu Gesendet: Donnerstag, 31. Dezember 2020 07:48:07 An: squeak-dev at lists.squeakfoundation.org Betreff: Re: [squeak-dev] Fwd: [OpenSmalltalk/opensmalltalk-vm] Trouble running OSVM in an Ubuntu 20/aarch64 docker (raspi) (#544) On 30/12/20 11:50 pm, Bruce O'Neel wrote: > sudo apt-get install uuid-dev libcairo2-dev libpango1.0-dev > libgl1-mesa-dev libgl1-mesa-glx libssl-dev > > sudo apt install libevdev-dev > ... I think that is the minimal set necessary. pango-dev requires cairo and mesa-dev requires mesa-glx respectively, so a minimal set of packages would be: $ sudo apt-get install uuid-dev libpango1.0-dev libgl1-mesa-dev libssl-dev libevdev-dev HTH .. Subbu -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Fri Jan 1 18:37:44 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 1 Jan 2021 10:37:44 -0800 Subject: [squeak-dev] Fwd: [OpenSmalltalk/opensmalltalk-vm] Trouble running OSVM in an Ubuntu 20/aarch64 docker (raspi) (#544) In-Reply-To: <3bdb5f914f0d4dc08061f0344fef19d9@student.hpi.uni-potsdam.de> References: <1609352251-e5fe5cf9bc6eae7a6a88106269547f22@pckswarms.ch> <5b2c27a3e2b64e5dbfcfd3b41b555e1f@student.hpi.uni-potsdam.de> <223637412.155972.1609341080692.JavaMail.administrator@n4.nabble.com> <1609352459-5256fcd7eb69c2aa1bfee8434efb77f3@pckswarms.ch> <3bdb5f914f0d4dc08061f0344fef19d9@student.hpi.uni-potsdam.de> Message-ID: > On 2021-01-01, at 10:00 AM, Thiede, Christoph wrote: > > Hm, it still fails with the mprotect permission denied error :( Are we seeing some aspect of container things restricting access? Compare to my recent 'Illegal Instruction' isue on a container on the phone. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim "I love deadlines. I love the whooshing noise they make as they go by." Douglas Adams, R.I.P. From commits at source.squeak.org Fri Jan 1 18:53:01 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 1 Jan 2021 18:53:01 0000 Subject: [squeak-dev] The Inbox: Kernel-ct.1367.mcz Message-ID: A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1367.mcz ==================== Summary ==================== Name: Kernel-ct.1367 Author: ct Time: 1 January 2021, 7:52:56.88819 pm UUID: 8d4215d9-34ed-4dc1-835f-a3d538a05403 Ancestors: Kernel-mt.1364 Fixes simulation of the #perform:... primitives 83, 84, and 100 for all edge cases. If the primitive is called with the wrong arguments, the primitive must fail but not the simulator. For further reference, see also the implementation of primitive 188 (primitiveExecuteMethodArgsArray) just a few lines below. :-) Tests are following right now, I am looking forward to your review! =============== Diff against Kernel-mt.1364 =============== Item was changed: ----- Method: Context>>doPrimitive:method:receiver:args: (in category 'private') ----- doPrimitive: primitiveIndex method: meth receiver: receiver args: arguments "Simulate a primitive method whose index is primitiveIndex. The simulated receiver and arguments are given as arguments to this message. If successful, push result and return resuming context, else ^ {errCode, PrimitiveFailToken}. Any primitive which provokes execution needs to be intercepted and simulated to avoid execution running away." | value | "Judicious use of primitive 19 (a null primitive that doesn't do anything) prevents the debugger from entering various run-away activities such as spawning a new process, etc. Injudicious use results in the debugger not being able to debug interesting code, such as the debugger itself. Hence use primitive 19 with care :-)" "SystemNavigation new browseAllSelect: [:m| m primitive = 19]" primitiveIndex = 19 ifTrue: [ Processor activeProcess debug: self title:'Code simulation error' full: false]. + - ((primitiveIndex between: 201 and: 222) and: [(self objectClass: receiver) includesBehavior: BlockClosure]) ifTrue: [(primitiveIndex = 206 or: [primitiveIndex = 208]) ifTrue: "[Full]BlockClosure>>valueWithArguments:" [^receiver simulateValueWithArguments: arguments first caller: self]. ((primitiveIndex between: 201 and: 209) "[Full]BlockClosure>>value[:value:...]" or: [primitiveIndex between: 221 and: 222]) ifTrue: "[Full]BlockClosure>>valueNoContextSwitch[:]" [^receiver simulateValueWithArguments: arguments caller: self]]. primitiveIndex = 83 ifTrue: "afr 9/11/1998 19:50" "Object>>perform:[with:...]" + [| selector | + selector := arguments at: 1 ifAbsent: + [^ self class primitiveFailTokenFor: #'bad argument']. + arguments size - 1 = selector numArgs ifFalse: + [^ self class primitiveFailTokenFor: #'bad number of arguments']. + ^self send: selector to: receiver with: arguments allButFirst]. - [^self send: arguments first to: receiver with: arguments allButFirst]. primitiveIndex = 84 ifTrue: "afr 9/11/1998 19:50 & eem 8/18/2009 17:04" "Object>>perform:withArguments:" + [| selector args | + arguments size = 2 ifFalse: + [^ self class primitiveFailTokenFor: #'bad argument']. + selector := arguments first. + args := arguments second. + args isArray ifFalse: + [^ self class primitiveFailTokenFor: #'bad argument']. + args size = selector numArgs ifFalse: + [^ self class primitiveFailTokenFor: #'bad number of arguments']. + ^self send: selector to: receiver with: args]. - [^self send: arguments first to: receiver with: (arguments at: 2) lookupIn: (self objectClass: receiver)]. primitiveIndex = 100 ifTrue: "eem 8/18/2009 16:57" "Object>>perform:withArguments:inSuperclass:" + [| selector args superclass | + arguments size = 3 ifFalse: + [^ self class primitiveFailTokenFor: #'bad argument']. + selector := arguments first. + args := arguments second. + args isArray ifFalse: + [^ self class primitiveFailTokenFor: #'bad argument']. + args size = selector numArgs ifFalse: + [^ self class primitiveFailTokenFor: #'bad number of arguments']. + superclass := arguments third. + ((self objectClass: receiver) includesBehavior: superclass) ifFalse: + [^ self class primitiveFailTokenFor: #'bad argument']. + ^self send: selector to: receiver with: args lookupIn: superclass]. - [^self send: arguments first to: receiver with: (arguments at: 2) lookupIn: (arguments at: 3)]. "Mutex>>primitiveEnterCriticalSection Mutex>>primitiveTestAndSetOwnershipOfCriticalSection" (primitiveIndex = 186 or: [primitiveIndex = 187]) ifTrue: [| effective | effective := Processor activeProcess effectiveProcess. "active == effective" value := primitiveIndex = 186 ifTrue: [receiver primitiveEnterCriticalSectionOnBehalfOf: effective] ifFalse: [receiver primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf: effective]. ^(self isPrimFailToken: value) ifTrue: [value] ifFalse: [self push: value]]. primitiveIndex = 188 ifTrue: "Object>>withArgs:executeMethod: CompiledMethod class>>receiver:withArguments:executeMethod: VMMirror>>ifFail:object:with:executeMethod: et al" [| n args methodArg thisReceiver | ((n := arguments size) between: 2 and: 4) ifFalse: [^self class primitiveFailTokenFor: #'unsupported operation']. ((self objectClass: (args := arguments at: n - 1)) == Array and: [(self objectClass: (methodArg := arguments at: n)) includesBehavior: CompiledMethod]) ifFalse: [^self class primitiveFailTokenFor: #'bad argument']. methodArg numArgs = args size ifFalse: [^self class primitiveFailTokenFor: #'bad number of arguments']. thisReceiver := arguments at: n - 2 ifAbsent: [receiver]. methodArg primitive > 0 ifTrue: [methodArg isQuick ifTrue: [^self push: (methodArg valueWithReceiver: thisReceiver arguments: args)]. ^self doPrimitive: methodArg primitive method: meth receiver: thisReceiver args: args]. ^Context sender: self receiver: thisReceiver method: methodArg arguments: args]. primitiveIndex = 118 ifTrue: "[receiver:]tryPrimitive:withArgs:; avoid recursing in the VM" [(arguments size = 3 and: [(self objectClass: arguments second) == SmallInteger and: [(self objectClass: arguments last) == Array]]) ifTrue: [^self doPrimitive: arguments second method: meth receiver: arguments first args: arguments last]. (arguments size = 2 and: [(self objectClass: arguments first) == SmallInteger and: [(self objectClass: arguments last) == Array]]) ifFalse: [^self class primitiveFailTokenFor: nil]. ^self doPrimitive: arguments first method: meth receiver: receiver args: arguments last]. value := primitiveIndex = 120 "FFI method" ifTrue: [(meth literalAt: 1) tryInvokeWithArguments: arguments] ifFalse: [primitiveIndex = 117 "named primitives" ifTrue: [self tryNamedPrimitiveIn: meth for: receiver withArgs: arguments] ifFalse: "should use self receiver: receiver tryPrimitive: primitiveIndex withArgs: arguments but this is only in later VMs (and appears to be broken)" [receiver tryPrimitive: primitiveIndex withArgs: arguments]]. ^(self isPrimFailToken: value) ifTrue: [value] ifFalse: [self push: value]! From commits at source.squeak.org Fri Jan 1 18:59:15 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 1 Jan 2021 18:59:15 0000 Subject: [squeak-dev] The Inbox: KernelTests-ct.382.mcz Message-ID: Christoph Thiede uploaded a new version of KernelTests to project The Inbox: http://source.squeak.org/inbox/KernelTests-ct.382.mcz ==================== Summary ==================== Name: KernelTests-ct.382 Author: ct Time: 1 January 2021, 7:59:13.17819 pm UUID: 812293dd-db7d-4c03-a33d-8b6f4354d1fa Ancestors: KernelTests-ct.375, KernelTests-tonyg.381 Tests simulation of #perform:... primitives 83, 84, and 100. Complements Kernel-ct.1367. Depends indeed not only on KernelTests-tonyg.381 but also on KernelTests-ct.375, it would be nice if we could get the latter merged soon, this has already been causing too many merge conflicts in the past. :-) =============== Diff against KernelTests-ct.375 =============== Item was added: + ----- Method: ContextTest>>testPrimitive100 (in category 'tests') ----- + testPrimitive100 + + { + {#isNil. {}. Object}. "valid 0-arg message" + {#=. {true}. UndefinedObject}. "valid unary message" + {#ifNil:ifNotNil:. {[2]. [:x | x]}. Object}. "valid binary message" + {}. "missing selector" + {#isNil}. "missing arguments" + {#isNil. 'not an array'}. "invalid arguments" + {#isNil. {}}. "missing lookupClass" + {#isNil. {'excess arg'}. Object}. "too many arguments" + {#=. {}. UndefinedObject}. "missing argument" + {#isNil. {}. Boolean}. "lookupClass not in inheritance chain" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 100 withArgs: args]) + equals: (nil tryPrimitive: 100 withArgs: args)].! Item was added: + ----- Method: ContextTest>>testPrimitive83 (in category 'tests') ----- + testPrimitive83 + + { + {#isNil}. "valid 0-arg message" + {#=. true}. "valid unary message" + {#ifNil:ifNotNil:. [2]. [:x | x]}. "valid binary message" + {}. "missing selector" + {#isNil. 'excess arg'}. "too many arguments" + {#=}. "missing argument" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 83 withArgs: args]) + equals: (nil tryPrimitive: 83 withArgs: args)].! Item was added: + ----- Method: ContextTest>>testPrimitive84 (in category 'tests') ----- + testPrimitive84 + + { + {#isNil. {}}. "valid 0-arg message" + {#=. {true}}. "valid unary message" + {#ifNil:ifNotNil:. {[2]. [:x | x]}}. "valid binary message" + {}. "missing selector" + {#isNil}. "missing arguments" + {#isNil. 'not an array'}. "invalid arguments" + {#isNil. {'excess arg'}}. "too many arguments" + {#=. {}}. "missing argument" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 84 withArgs: args]) + equals: (nil tryPrimitive: 84 withArgs: args)].! From Christoph.Thiede at student.hpi.uni-potsdam.de Fri Jan 1 19:07:27 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Fri, 1 Jan 2021 19:07:27 +0000 Subject: [squeak-dev] Bug in primitivePerform (was: The Inbox: KernelTests-ct.382.mcz) In-Reply-To: References: Message-ID: <2fc7d04d1fea4cbfb1aa7f0663a3f2de@student.hpi.uni-potsdam.de> Hi all, please note that primitive 83 is currently crashing the VM (tested with VMMaker.oscog-eem.2850) when called without any arguments, so #testPrimitive83 in the patch below will break the test execution at the moment. However, primitive 84 works well, so to me this looks like a trivial mistake only. I have (still!) not yet made myself the gift of exploring VMMaker, so I won't be able to fix a patch at the moment. But if someone can solve this, it would be great if you could give me a short pointer to the corresponding VMMaker patch because studying small interesting patches appear as a very nice way to explore an unknown framework to me. :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von commits at source.squeak.org Gesendet: Freitag, 1. Januar 2021 19:59 Uhr An: squeak-dev at lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: KernelTests-ct.382.mcz Christoph Thiede uploaded a new version of KernelTests to project The Inbox: http://source.squeak.org/inbox/KernelTests-ct.382.mcz ==================== Summary ==================== Name: KernelTests-ct.382 Author: ct Time: 1 January 2021, 7:59:13.17819 pm UUID: 812293dd-db7d-4c03-a33d-8b6f4354d1fa Ancestors: KernelTests-ct.375, KernelTests-tonyg.381 Tests simulation of #perform:... primitives 83, 84, and 100. Complements Kernel-ct.1367. Depends indeed not only on KernelTests-tonyg.381 but also on KernelTests-ct.375, it would be nice if we could get the latter merged soon, this has already been causing too many merge conflicts in the past. :-) =============== Diff against KernelTests-ct.375 =============== Item was added: + ----- Method: ContextTest>>testPrimitive100 (in category 'tests') ----- + testPrimitive100 + + { + {#isNil. {}. Object}. "valid 0-arg message" + {#=. {true}. UndefinedObject}. "valid unary message" + {#ifNil:ifNotNil:. {[2]. [:x | x]}. Object}. "valid binary message" + {}. "missing selector" + {#isNil}. "missing arguments" + {#isNil. 'not an array'}. "invalid arguments" + {#isNil. {}}. "missing lookupClass" + {#isNil. {'excess arg'}. Object}. "too many arguments" + {#=. {}. UndefinedObject}. "missing argument" + {#isNil. {}. Boolean}. "lookupClass not in inheritance chain" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 100 withArgs: args]) + equals: (nil tryPrimitive: 100 withArgs: args)].! Item was added: + ----- Method: ContextTest>>testPrimitive83 (in category 'tests') ----- + testPrimitive83 + + { + {#isNil}. "valid 0-arg message" + {#=. true}. "valid unary message" + {#ifNil:ifNotNil:. [2]. [:x | x]}. "valid binary message" + {}. "missing selector" + {#isNil. 'excess arg'}. "too many arguments" + {#=}. "missing argument" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 83 withArgs: args]) + equals: (nil tryPrimitive: 83 withArgs: args)].! Item was added: + ----- Method: ContextTest>>testPrimitive84 (in category 'tests') ----- + testPrimitive84 + + { + {#isNil. {}}. "valid 0-arg message" + {#=. {true}}. "valid unary message" + {#ifNil:ifNotNil:. {[2]. [:x | x]}}. "valid binary message" + {}. "missing selector" + {#isNil}. "missing arguments" + {#isNil. 'not an array'}. "invalid arguments" + {#isNil. {'excess arg'}}. "too many arguments" + {#=. {}}. "missing argument" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 84 withArgs: args]) + equals: (nil tryPrimitive: 84 withArgs: args)].! -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Fri Jan 1 19:24:55 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 1 Jan 2021 19:24:55 0000 Subject: [squeak-dev] The Trunk: KernelTests-eem.390.mcz Message-ID: Eliot Miranda uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-eem.390.mcz ==================== Summary ==================== Name: KernelTests-eem.390 Author: eem Time: 1 January 2021, 11:24:53.814816 am UUID: 82abce52-6291-4621-8946-3575c4f4f9c3 Ancestors: KernelTests-ct.389 Add a test to check Float's constants. Add a utility (e.g for package prologs) to answer whether the test passes. At least in my image Float fmax had become NaN. =============== Diff against KernelTests-ct.389 =============== Item was added: + ----- Method: FloatTest class>>testClassConstantsPasses (in category 'utilities') ----- + testClassConstantsPasses + "Answer if testClassConstants passes. This can be used in e.g. the Kernel Package prolog + to test if Float initialize needs to be run." + [self new testClassConstants] + on: TestResult failure + do: [:ex| ^false]. + ^true! Item was added: + ----- Method: FloatTest>>testClassConstants (in category 'tests - characterization') ----- + testClassConstants + + "Test all the class constants that are floats to check that they are valid. + Sometimes compiler bugs mean that the initialization method is incorrect, etc" + | expectedVariables unexpectedVariables "these two are for determining if this test is correct, not its results" + finiteVariables infiniteVariables nanVariables | + finiteVariables := #(Pi Halfpi Twopi ThreePi RadiansPerDegree Ln2 Ln10 Sqrt2 E Epsilon MaxVal MaxValLn NegativeZero). + infiniteVariables := #(Infinity NegativeInfinity). + nanVariables := #(NaN). + expectedVariables := Set new. + unexpectedVariables := Set new. + Float classPool keysAndValuesDo: + [:name :value| + value isFloat + ifTrue: + [(finiteVariables includes: name) ifTrue: + [expectedVariables add: name. + self assert: value isFinite. + self deny: value isInfinite. + self deny: value isNaN]. + (infiniteVariables includes: name) ifTrue: + [expectedVariables add: name. + self deny: value isFinite. + self assert: value isInfinite. + self deny: value isNaN]. + (nanVariables includes: name) ifTrue: + [expectedVariables add: name. + self deny: value isFinite. + self deny: value isInfinite. + self assert: value isNaN]. + (expectedVariables includes: name) ifFalse: + [unexpectedVariables add: name]] + ifFalse: + [self deny: ((finiteVariables includes: name) or: [(infiniteVariables includes: name) or: [nanVariables includes: name]])]]! From Christoph.Thiede at student.hpi.uni-potsdam.de Fri Jan 1 19:28:34 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Fri, 1 Jan 2021 19:28:34 +0000 Subject: [squeak-dev] Two new curious Context/primitive questions :-) Message-ID: Hi all, hi Eliot, new year, new simulation fun, and I have collected two new questions about the Context implementation which I'd love to get answered here: First, I was confused by the following: (BlockClosure >> #numArgs) primitive. "266" (Context >> #pc) primitive. "0" What makes Context so special that it cannot be compiled with quick accessor methods? Second, Context >> #isPrimFailToken: attracted my attention multiple times when looking at different #timeProfile results of simulation sessions. In the expression [100000 factorial] it takes up more than 44% of the whole execution time! I have no idea why it could be so slow, but this message is sent really often, which is at least 2 times per simulation of a special message send. Would there be an easy change to resolve this bottleneck and speed up the simulation by 40% or more? Would it be possible to provide a primitive for this method? Or do you see any other way to optimize it? Best, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Fri Jan 1 19:29:39 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 1 Jan 2021 19:29:39 0000 Subject: [squeak-dev] The Trunk: KernelTests-eem.391.mcz Message-ID: Eliot Miranda uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-eem.391.mcz ==================== Summary ==================== Name: KernelTests-eem.391 Author: eem Time: 1 January 2021, 11:29:37.785901 am UUID: 26cca588-616d-452b-9894-287b0f7e677e Ancestors: KernelTests-eem.390 Oops. remember to include the meta part of the test. =============== Diff against KernelTests-eem.390 =============== Item was changed: ----- Method: FloatTest>>testClassConstants (in category 'tests - characterization') ----- testClassConstants "Test all the class constants that are floats to check that they are valid. Sometimes compiler bugs mean that the initialization method is incorrect, etc" | expectedVariables unexpectedVariables "these two are for determining if this test is correct, not its results" finiteVariables infiniteVariables nanVariables | finiteVariables := #(Pi Halfpi Twopi ThreePi RadiansPerDegree Ln2 Ln10 Sqrt2 E Epsilon MaxVal MaxValLn NegativeZero). infiniteVariables := #(Infinity NegativeInfinity). nanVariables := #(NaN). expectedVariables := Set new. unexpectedVariables := Set new. Float classPool keysAndValuesDo: [:name :value| value isFloat ifTrue: [(finiteVariables includes: name) ifTrue: [expectedVariables add: name. self assert: value isFinite. self deny: value isInfinite. self deny: value isNaN]. (infiniteVariables includes: name) ifTrue: [expectedVariables add: name. self deny: value isFinite. self assert: value isInfinite. self deny: value isNaN]. (nanVariables includes: name) ifTrue: [expectedVariables add: name. self deny: value isFinite. self deny: value isInfinite. self assert: value isNaN]. (expectedVariables includes: name) ifFalse: [unexpectedVariables add: name]] ifFalse: + [self deny: ((finiteVariables includes: name) or: [(infiniteVariables includes: name) or: [nanVariables includes: name]])]]. + "Now check that test itself is working as intended..." + self assert: unexpectedVariables isEmpty. + self assert: expectedVariables = (finiteVariables, infiniteVariables, nanVariables) asSet! - [self deny: ((finiteVariables includes: name) or: [(infiniteVariables includes: name) or: [nanVariables includes: name]])]]! From commits at source.squeak.org Fri Jan 1 20:17:43 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 1 Jan 2021 20:17:43 0000 Subject: [squeak-dev] The Trunk: KernelTests-eem.392.mcz Message-ID: Eliot Miranda uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-eem.392.mcz ==================== Summary ==================== Name: KernelTests-eem.392 Author: eem Time: 1 January 2021, 12:17:42.043127 pm UUID: c803a1d3-a439-4bac-8fc6-de85912285d9 Ancestors: KernelTests-eem.391 Add a FloatTest to compare all literal float contants in methods with those from a fresh compile, failing if any differ. Add a utility method to answer teh set of methods that cause the test to fail (FloatTest>>methodsMaybeContainingBrokenCompiledConstants). =============== Diff against KernelTests-eem.391 =============== Item was added: + ----- Method: FloatTest>>floatLiteralsIn: (in category 'private') ----- + floatLiteralsIn: method + | floatLiterals | + floatLiterals := OrderedCollection new. + method allLiteralsDo: + [:lit| lit isFloat ifTrue: [floatLiterals addLast: lit]]. + ^floatLiterals! Item was added: + ----- Method: FloatTest>>methodContainsFloatLiteral: (in category 'private') ----- + methodContainsFloatLiteral: method + method isQuick ifFalse: + [method allLiteralsDo: + [:lit| lit isFloat ifTrue: [^true]]]. + ^false! Item was added: + ----- Method: FloatTest>>methodsMaybeContainingBrokenCompiledConstants (in category 'private') ----- + methodsMaybeContainingBrokenCompiledConstants + "Answer a set of all methods in the system which contain float constants that differ from those obtaiuned by + recompiling. These may indicate an old compiler issue, or indeed an issue with the current compiler. This is a + variant of testCompiledConstants used for collecting the set of methods rather than testing that none exist." + | identifiedPatients | + identifiedPatients := IdentitySet new. + CurrentReadOnlySourceFiles cacheDuring: + [self systemNavigation allSelectorsAndMethodsDo: + [:class :selector :method| + (self methodContainsFloatLiteral: method) ifTrue: + [| newMethodAndNode newLiterals oldLiterals | + newMethodAndNode := class compile: method getSource asString notifying: nil trailer: CompiledMethodTrailer empty ifFail: nil. + newLiterals := self floatLiteralsIn: newMethodAndNode method. + oldLiterals := self floatLiteralsIn: method. + "Convenience doit for recompiling broken methods:..." + "class recompile: selector" + newLiterals size = oldLiterals size + ifFalse: [identifiedPatients add: method] + ifTrue: + [newLiterals with: oldLiterals do: + [:new :old| + (new asIEEE64BitWord = old asIEEE64BitWord + or: [new isNaN and: old isNaN]) ifFalse: + [identifiedPatients add: method]]]]]]. + ^identifiedPatients! Item was added: + ----- Method: FloatTest>>testCompiledConstants (in category 'tests') ----- + testCompiledConstants + "Test that any methods containing a floating point literal have been correctly compiled." + CurrentReadOnlySourceFiles cacheDuring: + [self systemNavigation allSelectorsAndMethodsDo: + [:class :selector :method| + (self methodContainsFloatLiteral: method) ifTrue: + [| newMethodAndNode newLiterals oldLiterals | + newMethodAndNode := class compile: method getSource asString notifying: nil trailer: CompiledMethodTrailer empty ifFail: nil. + newLiterals := self floatLiteralsIn: newMethodAndNode method. + oldLiterals := self floatLiteralsIn: method. + "Convenience doit for recompiling broken methods:..." + "class recompile: selector" + self assert: newLiterals size = oldLiterals size. + newLiterals with: oldLiterals do: + [:new :old| + self assert: (new asIEEE64BitWord = old asIEEE64BitWord + or: [new isNaN and: old isNaN])]]]]! From eliot.miranda at gmail.com Fri Jan 1 21:22:39 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 1 Jan 2021 13:22:39 -0800 Subject: [squeak-dev] Two new curious Context/primitive questions :-) In-Reply-To: References: Message-ID: Hi Christoph, happy new year!! On Fri, Jan 1, 2021 at 11:28 AM Thiede, Christoph < Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > Hi all, hi Eliot, > > > new year, new simulation fun, and I have collected two new questions about > the Context implementation which I'd love to get answered here: > > > First, I was confused by the following: > > (BlockClosure >> #numArgs) primitive. "266" > (Context >> #pc) primitive. "0" > What makes Context so special that it cannot be compiled with quick > accessor methods? > The gory details are here: http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ But that's full of implementation detail. Let me try and explain at a higher level. Contexts are wonderful but very expensive. Any VM that actually creates contexts for every method or block activation will inevitably run slowly. There are two overheads here. One is the basic overhead of allocating and reclaiming the contexts that are created. The other is the cost of moving the outgoing receiver and arguments from the sending context to the new context. A fast VM must avoid these overheads, and the key solution is to use a stack frame organization as is used in conventional language implementations. The key here is that with stack frames the receiver and incoming arguments do not have to be moved; they stay where they are and a new frame is built underneath them which includes them as the incoming receiver and arguments; stack frames overlap outgoing and incoming arguments. But crucially, in addition the VM must still create contexts if and when they are needed. If not, this would no longer be a Smalltalk-80 implementation. Now one could imagine a VM which converted stack frames to contexts whenever a method or block activation was accessed using thisContext (or thisContext sender etc which access contexts by following the sdender field). But that would be very slow. Instead, the fastest approach is to try and keep stack frames as stack frames for as long as possible. For this to work contexts have to be able to function as "proxy objects" for stack frames. The VM does indeed create contexts when one uses thisContext, or even when one creates a block, but internally the context is in a very special state, a state in which it points at a stack frame. Some terminology is useful. Peter Deutsch used "volatile", "hybrid" and "stable". I like "single", "married", "widowed" and "divorced" (Peter's scheme didn't have "widowed" which is the key to why my scheme is faster, and why the closure implementation is as it is). When a stack frame is created it is "single". It has a slot within it to refer to a context object if it is needed, but the slot is nil. When a stack frame needs a context object one is created and the two are "married". When a method or block returns its stack frame is discarded; the stack frame has died and if it was married its context becomes "widowed". (*) When space is needed for new stack frames all reclaimed stack frames are "divorced" from their contexts. The stack frame state is written to the context object and the context object no longer acts as a proxy; it is a fully fledged normal stack object. (*) (*) Stack frames exist in a small memory zone organized as stack pages, the stack zone. The size of the stack zone is set at startup, and its size is either the VM's defaut oir set by a value that persists in the image header (see vmParameterAt: 43). Since the system may run out of stack pages (a deep call stack, many active processes), the VM makes new pages available by purging the least recently used pages to the heap in the form of context objects. All the frames in the least recently used stack page are divorced at the same time. A context must be created for each frame that is not yet married. (*) The reason why Peter's original scheme is slower is that at return time the VM has to check for being married and copy state to the hybrid context, making it stable. This has to be done because a closure's outer temporary variables are stored in the lexically enclosing stack frame, and so have to be made to persist in the stable context or their values will be stale. In my (lisp-derived) closure implementation there are no such references to outer temporary variables; values are either copied if they do not change, or stored in an Array (the "indirection vector"), which can then be copied. Note that divorce is a process. Once divorced a context is single and free to function as a context does. Indeed when the system starts up it loads an image which only contains single contexts. All contexts are divorced on snapshot. So now, finally, we can answer your question. Why is (Context>>#pc), a method that simply answers an instance variable, not compiled as a quick method with a primitive that answers that variable? "married" and "widowed" contexts are proxies for stack frames. Only the instance variables they contain which do not change can be fetched from the context object itself; these are the receiver, arguments, closureOrNil, and method. sender, pc, stackp and other stack contents may change as execution proceeds. These mutable values must be fetched from the stack frame itself, if it still exists. All accesses to sender, pc, stackp, and stack contents (Context>>at:[put:]) must be mediated. A married or widowed context has its sender field set to the frame pointer of its stack frame, encoded as a SmallInteger. You can never see this from the image (except via a special xRay primitive). By following the frame pointer encoded in the sender field the VM can detect if the frame is still live. If so, the relevant values are synthesized or fetched from the stack frame itself. If not, the context is widowed and "mourns"; it is changed into a context with a nil sender field, a nil pc, and a stackp that points at the last argument. How is this mediation done? One design could be to require that all image level accesses to Context inst vars are through primitives. This feels contrived to me. Instead, inst var access is via inst var access bytcodes. But if we do this naively we would have to check in all inst var access bytecodes whose index is the same as sender (0), pc (1) & stackp (2). This would slow down inst var access enormously. Instead we observe that inst var access bytecodes pushReceiverVariable:, popIntoReceiverVariable: have short forms for the most frequently used (indexes 0 to 15 for push, indexes 0 to 7 for popInto). By arranging that we only use the long forms for accessing inst vars in Context, and superclasses and subclasses, we only have to check in the long forms and the check is cheap. We check that the index is <= 2, because all other inst var accesses with these indices will use the short-form bytecodes. By arranging that Context's inst vars are *not* accessed by quick primitives we do not have to duplicate this machinery in quick primitive dispatch, which would also slow things down. Hence Context>>pc is compiled as a vanilla method and its inst var access bytecode is the long form: 25 pushRcvr: 1 27 <5C> returnTop 'Nuff said > Second, Context >> #isPrimFailToken: attracted my attention multiple > times when looking at different #timeProfile results of simulation > sessions. In the expression [100000 factorial] it takes up more than 44% of > the whole execution time! > I have no idea why it could be so slow, but this message is sent really > often, which is at least 2 times per simulation of a special message send. > Would there be an easy change to resolve this bottleneck and speed > up the simulation by 40% or more? > Would it be possible to provide a primitive for this method? Or do you see > any other way to optimize it? > It's not slow, so much as it has to be used all the time to check whether a send has invoked a primitive which has failed. Its function is to support primitive error codes. Without it we can simply check for nil. But with it we need a container that both reliably distinguishes a primitive failure result from all other objects in the system, and holds onto the primitive failure code. It may indeed be able to reduce the overhead by only testing when absolutely necessary. It may be that reimplementing the scheme is faster. For example, one could imagine a class whose instances are the only objects to answer #isPrimFailToken, which would be faster than a one argument message send. But beware, because if one was debugging the debugger one mustn't confuse a PrimFailToken created in the simulation for a PrimFailToken created by the simulation. Remember to distinguish between price and value. Implementing the context-to-stack mapping scheme outlined above was very costly, but its value is very high. It allows us to have contexts, with all their utility, while reducing their costs significantly. Similarly, and closely related, being able to simulate execution is costly but hugely valuable. If the price is 40% of simulated execution then it is a price worth paying. Best, > Christoph > Happy New Year! _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Fri Jan 1 21:34:28 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 1 Jan 2021 13:34:28 -0800 Subject: [squeak-dev] Two new curious Context/primitive questions :-) In-Reply-To: References: Message-ID: errata: On Fri, Jan 1, 2021 at 1:22 PM Eliot Miranda wrote: Hi Christoph, happy new year!! On Fri, Jan 1, 2021 at 11:28 AM Thiede, Christoph < Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > Hi all, hi Eliot, > > new year, new simulation fun, and I have collected two new questions about > the Context implementation which I'd love to get answered here: > > First, I was confused by the following: > (BlockClosure >> #numArgs) primitive. "266" > (Context >> #pc) primitive. "0" > > What makes Context so special that it cannot be compiled with quick > accessor methods? > The gory details are here: http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ But that's full of implementation detail. Let me try and explain at a higher level. Contexts are wonderful but very expensive. Any VM that actually creates contexts for every method or block activation will inevitably run slowly. There are two overheads here. One is the basic overhead of allocating and reclaiming the contexts that are created. The other is the cost of moving the outgoing receiver and arguments from the sending context to the new context. A fast VM must avoid these overheads, and the key solution is to use a stack frame organization as is used in conventional language implementations. The key here is that with stack frames the receiver and incoming arguments do not have to be moved; they stay where they are and a new frame is built underneath them which includes them as the incoming receiver and arguments; stack frames overlap outgoing and incoming arguments. But crucially, in addition the VM must still create contexts if and when they are needed. If not, this would no longer be a Smalltalk-80 implementation. Now one could imagine a VM which converted stack frames to contexts whenever a method or block activation was accessed using thisContext (or thisContext sender etc which access contexts by following the sender field). But that would be very slow. Instead, the fastest approach is to try and keep stack frames as stack frames for as long as possible. For this to work contexts have to be able to function as "proxy objects" for stack frames. The VM does indeed create contexts when one uses thisContext, or even when one creates a block, but internally the context is in a very special state, a state in which it points at a stack frame. Some terminology is useful. Peter Deutsch used "volatile", "hybrid" and "stable". I like "single", "married", "widowed" and "divorced" (Peter's scheme didn't have "widowed" which is the key to why my scheme is faster, and why the closure implementation is as it is). When a stack frame is created it is "single". It has a slot within it to refer to a context object if it is needed, but the slot is nil. When a stack frame needs a context object one is created and the two are "married". When a method or block returns its stack frame is discarded; the stack frame has died and if it was married its context becomes "widowed". (*) When space is needed for new stack frames all reclaimed stack frames are "divorced" from their contexts. The stack frame state is written to the context object and the context object no longer acts as a proxy; it is a fully fledged normal stack object. (*) (*) Stack frames exist in a small memory zone organized as stack pages, the stack zone. The size of the stack zone is set at startup, and its size is either the VM's default or set by a value that persists in the image header (see vmParameterAt: 43). Since the system may run out of stack pages (a deep call stack, many active processes), the VM makes new pages available by purging the least recently used pages to the heap in the form of context objects. All the frames in the least recently used stack page are divorced at the same time. A context must be created for each frame that is not yet married. A page is big enough to hold on average about 40 method activations; since activations are of different sizes and change size as execution proceeds, the number of activations per full page varies. (*) The reason why Peter's original scheme is slower is that in HPS at return time the VM has to check for a frame being hybrid and copy state to the hybrid context, making it stable. This has to be done because a closure's outer temporary variables are stored in the lexically enclosing stack frame, and so have to be made to persist in the stable context or their values will be stale. In my (lisp-derived) closure implementation there are no such references to outer temporary variables; values are either copied if they do not change, or stored in an Array (the "indirection vector"), which can then be copied. Note that divorce is a process. Once divorced a context is single and free to function as a context does. Indeed when the system starts up it loads an image which only contains single contexts. All contexts are divorced on snapshot. Divorced contexts are amnesiacs. So now, finally, we can answer your question. Why is (Context>>#pc), a method that simply answers an instance variable, not compiled as a quick method with a primitive that answers that variable? "married" and "widowed" contexts are proxies for stack frames. Only the instance variables they contain which do not change can be fetched from the context object itself; these are the receiver, arguments, closureOrNil, and method. sender, pc, stackp and other stack contents may change as execution proceeds. These mutable values must be fetched from the stack frame itself, if it still exists. All accesses to sender, pc, stackp, and stack contents (Context>>at:[put:]) must be mediated. A married or widowed context has its sender field set to the frame pointer of its stack frame, encoded as a SmallInteger. You can never see this from the image (except via a special xRay primitive). By following the frame pointer encoded in the sender field the VM can detect if the frame is still live. If so, the relevant values are synthesized or fetched from the stack frame itself. If not, the context is widowed and "mourns"; it is changed into a context with a nil sender field, a nil pc, and a stackp that points at the last argument. How is this mediation done? One design could be to require that all image level accesses to Context inst vars are through primitives. This feels contrived to me. Instead, inst var access is via inst var access bytcodes. But if we do this naively we would have to check in all inst var access bytecodes whose index is the same as sender (0), pc (1) & stackp (2). This would slow down inst var access enormously. Instead we observe that inst var access bytecodes pushReceiverVariable:, popIntoReceiverVariable: have short forms for the most frequently used (indexes 0 to 15 for push, indexes 0 to 7 for popInto). By arranging that we only use the long forms for accessing inst vars in Context, and superclasses and subclasses, we only have to check in the long forms and the check is cheap. We check that the index is <= 2, because all other inst var accesses with these indices will use the short-form bytecodes. By arranging that Context's inst vars are *not* accessed by quick primitives we do not have to duplicate this machinery in quick primitive dispatch, which would also slow things down. Hence Context>>pc is compiled as a vanilla method and its inst var access bytecode is the long form: 25 pushRcvr: 1 27 <5C> returnTop 'Nuff said Second, Context >> #isPrimFailToken: attracted my attention multiple times > when looking at different #timeProfile results of simulation sessions. In > the expression [100000 factorial] it takes up more than 44% of the whole > execution time! > I have no idea why it could be so slow, but this message is sent really > often, which is at least 2 times per simulation of a special message send. > Would there be an easy change to resolve this bottleneck and speed > up the simulation by 40% or more? > Would it be possible to provide a primitive for this method? Or do you see > any other way to optimize it? > It's not slow so much as that it has to be used all the time to check whether a send has invoked a primitive which has failed. Its function is to support primitive error codes. Before primitive error codes (IIRC) we simply checked for nil. But with primitive error codes we need a container that both reliably distinguishes a primitive failure result from all other objects in the system, and holds onto the primitive failure code. It may indeed be able to reduce the overhead by only testing when absolutely necessary. It may be that reimplementing the scheme is faster. For example, one could imagine a class whose instances are the only objects to answer #isPrimFailToken, which would be faster than a one argument message send. But beware, because if one was debugging the debugger one mustn't confuse a PrimFailToken created in the simulation for a PrimFailToken created by the simulation. Remember to distinguish between price and value. Implementing the context-to-stack mapping scheme outlined above was very costly, but its value is very high. It allows us to have contexts, with all their utility, while reducing their costs significantly. Similarly, and closely related, being able to simulate execution is costly but hugely valuable. If the price is 40% of simulated execution then it is a price worth paying. Best, > Christoph > Happy New Year! _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Sat Jan 2 00:18:27 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Sat, 2 Jan 2021 00:18:27 +0000 Subject: [squeak-dev] Two new curious Context/primitive questions :-) In-Reply-To: References: , Message-ID: <9ea2e9b8c16341ceaa49089d4631a229@student.hpi.uni-potsdam.de> Hi Eliot, once again I am very pleasantly surprised by your professional and detailed answer which was a joy to read! > 'Nuff said No further questions. This was very interesting! It also gives me a possible explanation for why one cannot execute a context subinstance without any problems. That's because the marriage between stack frame and context objects is hard-coded based on the Context class (specialObjects at: 11), isn't it? > But beware, because if one was debugging the debugger one mustn't confuse a PrimFailToken created in the simulation for a PrimFailToken created by the simulation. Hm, aren't we already in a very similar situation? I had planned to write a separate message for this issue, but here is my case: {Context primitiveFailTokenFor: nil} at: 1. "{an Object . nil}" Context runSimulated: [{Context primitiveFailTokenFor: nil} at: 1]. "⚡ Error: subscript is out of bounds: 1" Now one could argue that this is not a very likely situation to occur ever in "production", but the same could be said for a hypothetical #isPrimFailToken selector, and above all, it precludes an ideal, i.e. completely transparent simulation machinery ... So I would like to suggest to find a different solution for this problem anyway, provided that you support this idea in general. An alternative I could imagine would be the SetElement pattern from Collections which is completely transparent. But this would probably be too expensive for simulation purposes (because we would need to instantiate one object per simulated primitive call), right? Why not encode a failing primitive via a changed control flow? Couldn't we pass an additional failBlock argument to #doPrimitive:method:receiver:args:, #tryPrimitive:withArgs:/#tryNamedPrimitiveIn:for:withArgs:, and #simulateValueWithArguments:caller: (and analogously to ExternalFunction >> #tryInvokeWithArguments: and the critsect primitive methods on Mutex)? Then we could rewrite #send:to:with:lookupIn: like this (pseudo): send: selector to: rcvr with: arguments lookupIn: lookupClass "Simulate the action of sending a message with selector and arguments to rcvr. The argument, lookupClass, is the class in which to lookup the message. This is the receiver's class for normal messages, but for super messages it will be some specific class related to the source method." | meth primFailCode val ctxt | (meth := lookupClass lookupSelector: selector) ifNil: [selector == #doesNotUnderstand: ifTrue: [self error: 'Recursive message not understood!' translated]. ^self send: #doesNotUnderstand: to: rcvr with: {(Message selector: selector arguments: arguments) lookupClass: lookupClass} lookupIn: lookupClass]. meth isCompiledMethod ifFalse: ["Object as Methods (OaM) protocol: 'The contract is that, when the VM encounters an ordinary object (rather than a compiled method) in the method dictionary during lookup, it sends it the special selector #run:with:in: providing the original selector, arguments, and receiver.'. DOI: 10.1145/2991041.2991062." ^self send: #run:with:in: to: meth with: {selector. arguments. rcvr}]. meth numArgs = arguments size ifFalse: [^ self error: ('Wrong number of arguments in simulated message {1}' translated format: {selector})]. (primIndex := meth primitive) > 0 ifTrue: - [val := self doPrimitive: primIndex method: meth receiver: rcvr args: arguments. - (self isPrimFailToken: val) ifFalse: - [^val]]. + [val := self doPrimitive: primIndex method: meth receiver: rcvr args: arguments ifFail: + [:code | primFailCode := code]. + primFailCode ifNil: [^ val]]. (selector == #doesNotUnderstand: and: [lookupClass == ProtoObject]) ifTrue: [^self error: ('Simulated message {1} not understood' translated format: {arguments first selector})]. ctxt := Context sender: self receiver: rcvr method: meth arguments: arguments. - (primIndex isInteger and: [primIndex > 0]) ifTrue: - [ctxt failPrimitiveWith: val]. + primFailCode ifNotNil: + [ctxt failPrimitiveWith: primFailCode]. ^ctxt Current senders of #primitiveFailTokenFor: could then evaluate the failBlock if the primitive fails. Do you think this approach would be worth a try? :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Eliot Miranda Gesendet: Freitag, 1. Januar 2021 22:34:28 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Two new curious Context/primitive questions :-) errata: On Fri, Jan 1, 2021 at 1:22 PM Eliot Miranda > wrote: Hi Christoph, happy new year!! On Fri, Jan 1, 2021 at 11:28 AM Thiede, Christoph > wrote: Hi all, hi Eliot, new year, new simulation fun, and I have collected two new questions about the Context implementation which I'd love to get answered here: First, I was confused by the following: (BlockClosure >> #numArgs) primitive. "266" (Context >> #pc) primitive. "0" What makes Context so special that it cannot be compiled with quick accessor methods? The gory details are here: http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ But that's full of implementation detail. Let me try and explain at a higher level. Contexts are wonderful but very expensive. Any VM that actually creates contexts for every method or block activation will inevitably run slowly. There are two overheads here. One is the basic overhead of allocating and reclaiming the contexts that are created. The other is the cost of moving the outgoing receiver and arguments from the sending context to the new context. A fast VM must avoid these overheads, and the key solution is to use a stack frame organization as is used in conventional language implementations. The key here is that with stack frames the receiver and incoming arguments do not have to be moved; they stay where they are and a new frame is built underneath them which includes them as the incoming receiver and arguments; stack frames overlap outgoing and incoming arguments. But crucially, in addition the VM must still create contexts if and when they are needed. If not, this would no longer be a Smalltalk-80 implementation. Now one could imagine a VM which converted stack frames to contexts whenever a method or block activation was accessed using thisContext (or thisContext sender etc which access contexts by following the sender field). But that would be very slow. Instead, the fastest approach is to try and keep stack frames as stack frames for as long as possible. For this to work contexts have to be able to function as "proxy objects" for stack frames. The VM does indeed create contexts when one uses thisContext, or even when one creates a block, but internally the context is in a very special state, a state in which it points at a stack frame. Some terminology is useful. Peter Deutsch used "volatile", "hybrid" and "stable". I like "single", "married", "widowed" and "divorced" (Peter's scheme didn't have "widowed" which is the key to why my scheme is faster, and why the closure implementation is as it is). When a stack frame is created it is "single". It has a slot within it to refer to a context object if it is needed, but the slot is nil. When a stack frame needs a context object one is created and the two are "married". When a method or block returns its stack frame is discarded; the stack frame has died and if it was married its context becomes "widowed". (*) When space is needed for new stack frames all reclaimed stack frames are "divorced" from their contexts. The stack frame state is written to the context object and the context object no longer acts as a proxy; it is a fully fledged normal stack object. (*) (*) Stack frames exist in a small memory zone organized as stack pages, the stack zone. The size of the stack zone is set at startup, and its size is either the VM's default or set by a value that persists in the image header (see vmParameterAt: 43). Since the system may run out of stack pages (a deep call stack, many active processes), the VM makes new pages available by purging the least recently used pages to the heap in the form of context objects. All the frames in the least recently used stack page are divorced at the same time. A context must be created for each frame that is not yet married. A page is big enough to hold on average about 40 method activations; since activations are of different sizes and change size as execution proceeds, the number of activations per full page varies. (*) The reason why Peter's original scheme is slower is that in HPS at return time the VM has to check for a frame being hybrid and copy state to the hybrid context, making it stable. This has to be done because a closure's outer temporary variables are stored in the lexically enclosing stack frame, and so have to be made to persist in the stable context or their values will be stale. In my (lisp-derived) closure implementation there are no such references to outer temporary variables; values are either copied if they do not change, or stored in an Array (the "indirection vector"), which can then be copied. Note that divorce is a process. Once divorced a context is single and free to function as a context does. Indeed when the system starts up it loads an image which only contains single contexts. All contexts are divorced on snapshot. Divorced contexts are amnesiacs. So now, finally, we can answer your question. Why is (Context>>#pc), a method that simply answers an instance variable, not compiled as a quick method with a primitive that answers that variable? "married" and "widowed" contexts are proxies for stack frames. Only the instance variables they contain which do not change can be fetched from the context object itself; these are the receiver, arguments, closureOrNil, and method. sender, pc, stackp and other stack contents may change as execution proceeds. These mutable values must be fetched from the stack frame itself, if it still exists. All accesses to sender, pc, stackp, and stack contents (Context>>at:[put:]) must be mediated. A married or widowed context has its sender field set to the frame pointer of its stack frame, encoded as a SmallInteger. You can never see this from the image (except via a special xRay primitive). By following the frame pointer encoded in the sender field the VM can detect if the frame is still live. If so, the relevant values are synthesized or fetched from the stack frame itself. If not, the context is widowed and "mourns"; it is changed into a context with a nil sender field, a nil pc, and a stackp that points at the last argument. How is this mediation done? One design could be to require that all image level accesses to Context inst vars are through primitives. This feels contrived to me. Instead, inst var access is via inst var access bytcodes. But if we do this naively we would have to check in all inst var access bytecodes whose index is the same as sender (0), pc (1) & stackp (2). This would slow down inst var access enormously. Instead we observe that inst var access bytecodes pushReceiverVariable:, popIntoReceiverVariable: have short forms for the most frequently used (indexes 0 to 15 for push, indexes 0 to 7 for popInto). By arranging that we only use the long forms for accessing inst vars in Context, and superclasses and subclasses, we only have to check in the long forms and the check is cheap. We check that the index is <= 2, because all other inst var accesses with these indices will use the short-form bytecodes. By arranging that Context's inst vars are *not* accessed by quick primitives we do not have to duplicate this machinery in quick primitive dispatch, which would also slow things down. Hence Context>>pc is compiled as a vanilla method and its inst var access bytecode is the long form: 25 pushRcvr: 1 27 <5C> returnTop 'Nuff said Second, Context >> #isPrimFailToken: attracted my attention multiple times when looking at different #timeProfile results of simulation sessions. In the expression [100000 factorial] it takes up more than 44% of the whole execution time! I have no idea why it could be so slow, but this message is sent really often, which is at least 2 times per simulation of a special message send. Would there be an easy change to resolve this bottleneck and speed up the simulation by 40% or more? Would it be possible to provide a primitive for this method? Or do you see any other way to optimize it? It's not slow so much as that it has to be used all the time to check whether a send has invoked a primitive which has failed. Its function is to support primitive error codes. Before primitive error codes (IIRC) we simply checked for nil. But with primitive error codes we need a container that both reliably distinguishes a primitive failure result from all other objects in the system, and holds onto the primitive failure code. It may indeed be able to reduce the overhead by only testing when absolutely necessary. It may be that reimplementing the scheme is faster. For example, one could imagine a class whose instances are the only objects to answer #isPrimFailToken, which would be faster than a one argument message send. But beware, because if one was debugging the debugger one mustn't confuse a PrimFailToken created in the simulation for a PrimFailToken created by the simulation. Remember to distinguish between price and value. Implementing the context-to-stack mapping scheme outlined above was very costly, but its value is very high. It allows us to have contexts, with all their utility, while reducing their costs significantly. Similarly, and closely related, being able to simulate execution is costly but hugely valuable. If the price is 40% of simulated execution then it is a price worth paying. Best, Christoph Happy New Year! _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Sat Jan 2 01:39:27 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 1 Jan 2021 17:39:27 -0800 Subject: [squeak-dev] Bug in primitivePerform (was: The Inbox: KernelTests-ct.382.mcz) In-Reply-To: <2fc7d04d1fea4cbfb1aa7f0663a3f2de@student.hpi.uni-potsdam.de> References: <2fc7d04d1fea4cbfb1aa7f0663a3f2de@student.hpi.uni-potsdam.de> Message-ID: Hi Christoph, On Fri, Jan 1, 2021 at 11:07 AM Thiede, Christoph < Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > Hi all, > > > please note that primitive 83 is currently crashing the VM (tested with > VMMaker.oscog-eem.2850) when called without any arguments, so #testPrimitive83 > in the patch below will break the test execution at the moment. > However, primitive 84 works well, so to me this looks like a trivial > mistake only. > Hang on. When would one include primitive 83 in a method that takes no arguments? Implementing e.g. Object>>perform "Invoke the perform primitive with no arguments cuz there's nothing to perform" self error: 'you don''t say' makes no sense. IMO the VM isn't obligated to implement checking for nonsensical definitions. That would slow the VM down unnecessarily. Instead one should *never* use primitive 843 in a method that takes no arguments. Hence in your simulation tests you can exclude the case where someone tries tryPrimitive: 83 withArguments: #() because it constitutes undefined behaviour and the VM crashing is IMO to be expected. > I have (still!) not yet made myself the gift of exploring VMMaker, so I > won't be able to fix a patch at the moment. But if someone can solve this, > it would be great if you could give me a short pointer to the corresponding > VMMaker patch because studying small interesting patches appear as a very > nice way to explore an unknown framework to me. :-) > > Best, > Christoph > > ------------------------------ > *Von:* Squeak-dev im > Auftrag von commits at source.squeak.org > *Gesendet:* Freitag, 1. Januar 2021 19:59 Uhr > *An:* squeak-dev at lists.squeakfoundation.org > *Betreff:* [squeak-dev] The Inbox: KernelTests-ct.382.mcz > > Christoph Thiede uploaded a new version of KernelTests to project The > Inbox: > http://source.squeak.org/inbox/KernelTests-ct.382.mcz > > ==================== Summary ==================== > > Name: KernelTests-ct.382 > Author: ct > Time: 1 January 2021, 7:59:13.17819 pm > UUID: 812293dd-db7d-4c03-a33d-8b6f4354d1fa > Ancestors: KernelTests-ct.375, KernelTests-tonyg.381 > > Tests simulation of #perform:... primitives 83, 84, and 100. Complements > Kernel-ct.1367. > > Depends indeed not only on KernelTests-tonyg.381 but also on > KernelTests-ct.375, it would be nice if we could get the latter merged > soon, this has already been causing too many merge conflicts in the past. > :-) > > =============== Diff against KernelTests-ct.375 =============== > > Item was added: > + ----- Method: ContextTest>>testPrimitive100 (in category 'tests') ----- > + testPrimitive100 > + > + { > + {#isNil. {}. Object}. "valid 0-arg message" > + {#=. {true}. UndefinedObject}. "valid unary message" > + {#ifNil:ifNotNil:. {[2]. [:x | x]}. Object}. "valid > binary message" > + {}. "missing selector" > + {#isNil}. "missing arguments" > + {#isNil. 'not an array'}. "invalid arguments" > + {#isNil. {}}. "missing lookupClass" > + {#isNil. {'excess arg'}. Object}. "too many arguments" > + {#=. {}. UndefinedObject}. "missing argument" > + {#isNil. {}. Boolean}. "lookupClass not in inheritance > chain" > + } do: [:args | > + self > + assert: (Context runSimulated: [nil tryPrimitive: > 100 withArgs: args]) > + equals: (nil tryPrimitive: 100 withArgs: args)].! > > Item was added: > + ----- Method: ContextTest>>testPrimitive83 (in category 'tests') ----- > + testPrimitive83 > + > + { > + {#isNil}. "valid 0-arg message" > + {#=. true}. "valid unary message" > + {#ifNil:ifNotNil:. [2]. [:x | x]}. "valid binary message" > + {}. "missing selector" > + {#isNil. 'excess arg'}. "too many arguments" > + {#=}. "missing argument" > + } do: [:args | > + self > + assert: (Context runSimulated: [nil tryPrimitive: > 83 withArgs: args]) > + equals: (nil tryPrimitive: 83 withArgs: args)].! > > Item was added: > + ----- Method: ContextTest>>testPrimitive84 (in category 'tests') ----- > + testPrimitive84 > + > + { > + {#isNil. {}}. "valid 0-arg message" > + {#=. {true}}. "valid unary message" > + {#ifNil:ifNotNil:. {[2]. [:x | x]}}. "valid binary > message" > + {}. "missing selector" > + {#isNil}. "missing arguments" > + {#isNil. 'not an array'}. "invalid arguments" > + {#isNil. {'excess arg'}}. "too many arguments" > + {#=. {}}. "missing argument" > + } do: [:args | > + self > + assert: (Context runSimulated: [nil tryPrimitive: > 84 withArgs: args]) > + equals: (nil tryPrimitive: 84 withArgs: args)].! > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Sat Jan 2 01:45:53 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 1 Jan 2021 17:45:53 -0800 Subject: [squeak-dev] Two new curious Context/primitive questions :-) In-Reply-To: <9ea2e9b8c16341ceaa49089d4631a229@student.hpi.uni-potsdam.de> References: <9ea2e9b8c16341ceaa49089d4631a229@student.hpi.uni-potsdam.de> Message-ID: Hi Christoph, On Fri, Jan 1, 2021 at 4:18 PM Thiede, Christoph < Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > Hi Eliot, > > > once again I am very pleasantly surprised by your professional and > detailed answer which was a joy to read! > > > > 'Nuff said > > No further questions. This was very interesting! > It also gives me a possible explanation for why one cannot execute a > context subinstance without any problems. That's because the marriage > between stack frame and context objects is hard-coded based on the Context > class (specialObjects at: 11), isn't it? > Indeed. One may be able to go the other way, create a stack of contexts whose class is different. These should retain their class because the associated stack frames will be married to them. But going the other way is not supported. > > But beware, because if one was debugging the debugger one mustn't > confuse a PrimFailToken created in the simulation for a PrimFailToken > created by the simulation. > > Hm, aren't we already in a very similar situation? I had planned to write > a separate message for this issue, but here is my case: > > {Context primitiveFailTokenFor: nil} at: 1. "{an Object . nil}" > Context runSimulated: [{Context primitiveFailTokenFor: nil} at: 1]. > "⚡ Error: subscript is out of bounds: 1" > > Now one could argue that this is not a very likely situation to occur ever > in "production", but the same could be said for a hypothetical #isPrimFailToken > selector, and above all, it precludes an ideal, i.e. completely transparent > simulation machinery ... > So I would like to suggest to find a different solution for this problem > anyway, provided that you support this idea in general. > > An alternative I could imagine would be the SetElement pattern from > Collections which is completely transparent. But this would probably be too > expensive for simulation purposes (because we would need to instantiate one > object per simulated primitive call), right? > Not sure. If instantiation can be deferred until failure then things should be OK. > Why not encode a failing primitive via a changed control flow? Couldn't we > pass an additional failBlock argument to # > doPrimitive:method:receiver:args:, #tryPrimitive:withArgs:/#tryNamedPrimitiveIn:for:withArgs:, > and #simulateValueWithArguments:caller: (and analogously to > ExternalFunction >> #tryInvokeWithArguments: and the critsect primitive > methods on Mutex)? > We can, but remember that passing a block is in fact hiding an allocation, maybe two. Mentioning a block in code causes it to be allocated and if not already done so, causes allocation of the lexically enclosing context. > Then we could rewrite #send:to:with:lookupIn: like this (pseudo): > > send: selector to: rcvr with: arguments lookupIn: lookupClass > "Simulate the action of sending a message with selector and arguments > to rcvr. The argument, lookupClass, is the class in which to lookup the > message. This is the receiver's class for normal messages, but for super > messages it will be some specific class related to the source method." > > | meth primFailCode val ctxt | > (meth := lookupClass lookupSelector: selector) ifNil: > [selector == #doesNotUnderstand: ifTrue: > [self error: 'Recursive message not understood!' translated]. > ^self send: #doesNotUnderstand: > to: rcvr > with: {(Message selector: selector arguments: arguments) > lookupClass: lookupClass} > lookupIn: lookupClass]. > > meth isCompiledMethod ifFalse: > ["Object as Methods (OaM) protocol: 'The contract is that, when > the VM encounters an ordinary object (rather than a compiled method) in the > method dictionary during lookup, it sends it the special selector > #run:with:in: providing the original selector, arguments, and receiver.'. > DOI: 10.1145/2991041.2991062." > ^self send: #run:with:in: > to: meth > with: {selector. arguments. rcvr}]. > > meth numArgs = arguments size ifFalse: > [^ self error: ('Wrong number of arguments in simulated message > {1}' translated format: {selector})]. > (primIndex := meth primitive) > 0 ifTrue: > - [val := self doPrimitive: primIndex method: meth receiver: rcvr > args: arguments. > - (self isPrimFailToken: val) ifFalse: > - [^val]]. > + [val := self doPrimitive: primIndex method: meth receiver: rcvr > args: arguments ifFail: > + [:code | primFailCode := code]. > + primFailCode ifNil: [^ val]]. > > (selector == #doesNotUnderstand: and: [lookupClass == ProtoObject]) > ifTrue: > [^self error: ('Simulated message {1} not understood' translated > format: {arguments first selector})]. > > ctxt := Context sender: self receiver: rcvr method: meth arguments: > arguments. > - (primIndex isInteger and: [primIndex > 0]) ifTrue: > - [ctxt failPrimitiveWith: val]. > + primFailCode ifNotNil: > + [ctxt failPrimitiveWith: primFailCode]. > > ^ctxt > > > Current senders of #primitiveFailTokenFor: could then evaluate the > failBlock if the primitive fails. > Do you think this approach would be worth a try? :-) > Definitely. It might eliminate multiple tests. I think you should definitely try it. It looks nice to me. Thank you! > > Best, > Christoph > ------------------------------ > *Von:* Squeak-dev im > Auftrag von Eliot Miranda > *Gesendet:* Freitag, 1. Januar 2021 22:34:28 > *An:* The general-purpose Squeak developers list > *Betreff:* Re: [squeak-dev] Two new curious Context/primitive questions > :-) > > errata: > > On Fri, Jan 1, 2021 at 1:22 PM Eliot Miranda > wrote: > Hi Christoph, > > happy new year!! > > On Fri, Jan 1, 2021 at 11:28 AM Thiede, Christoph < > Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > >> Hi all, hi Eliot, >> >> new year, new simulation fun, and I have collected two new questions >> about the Context implementation which I'd love to get answered here: >> >> First, I was confused by the following: >> (BlockClosure >> #numArgs) primitive. "266" >> (Context >> #pc) primitive. "0" >> >> What makes Context so special that it cannot be compiled with quick >> accessor methods? >> > > The gory details are here: > http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ > > But that's full of implementation detail. Let me try and explain at a > higher level. > > Contexts are wonderful but very expensive. Any VM that actually creates > contexts for every method or block activation will inevitably run slowly. > There are two overheads here. One is the basic overhead of allocating and > reclaiming the contexts that are created. The other is the cost of moving > the outgoing receiver and arguments from the sending context to the new > context. A fast VM must avoid these overheads, and the key solution is to > use a stack frame organization as is used in conventional language > implementations. The key here is that with stack frames the receiver and > incoming arguments do not have to be moved; they stay where they are and a > new frame is built underneath them which includes them as the incoming > receiver and arguments; stack frames overlap outgoing and incoming > arguments. > > But crucially, in addition the VM must still create contexts if and when > they are needed. If not, this would no longer be a Smalltalk-80 > implementation. Now one could imagine a VM which converted stack frames to > contexts whenever a method or block activation was accessed using > thisContext (or thisContext sender etc which access contexts by following > the sender field). But that would be very slow. Instead, the fastest > approach is to try and keep stack frames as stack frames for as long as > possible. For this to work contexts have to be able to function as "proxy > objects" for stack frames. The VM does indeed create contexts when one > uses thisContext, or even when one creates a block, but internally the > context is in a very special state, a state in which it points at a stack > frame. > > Some terminology is useful. Peter Deutsch used "volatile", "hybrid" and > "stable". I like "single", "married", "widowed" and "divorced" (Peter's > scheme didn't have "widowed" which is the key to why my scheme is faster, > and why the closure implementation is as it is). > > When a stack frame is created it is "single". It has a slot within it to > refer to a context object if it is needed, but the slot is nil. > When a stack frame needs a context object one is created and the two are > "married". > When a method or block returns its stack frame is discarded; the stack > frame has died and if it was married its context becomes "widowed". (*) > When space is needed for new stack frames all reclaimed stack frames are > "divorced" from their contexts. The stack frame state is written to the > context object and the context object no longer acts as a proxy; it is a > fully fledged normal stack object. (*) > > (*) Stack frames exist in a small memory zone organized as stack pages, > the stack zone. The size of the stack zone is set at startup, and its size > is either the VM's default or set by a value that persists in the image > header (see vmParameterAt: 43). Since the system may run out of stack > pages (a deep call stack, many active processes), the VM makes new pages > available by purging the least recently used pages to the heap in the form > of context objects. All the frames in the least recently used stack page > are divorced at the same time. A context must be created for each frame > that is not yet married. A page is big enough to hold on average about 40 > method activations; since activations are of different sizes and change > size as execution proceeds, the number of activations per full page varies. > > (*) The reason why Peter's original scheme is slower is that in HPS at > return time the VM has to check for a frame being hybrid and copy state > to the hybrid context, making it stable. This has to be done because a > closure's outer temporary variables are stored in the lexically enclosing > stack frame, and so have to be made to persist in the stable context or > their values will be stale. In my (lisp-derived) closure implementation > there are no such references to outer temporary variables; values are > either copied if they do not change, or stored in an Array (the > "indirection vector"), which can then be copied. > > Note that divorce is a process. Once divorced a context is single and > free to function as a context does. Indeed when the system starts up it > loads an image which only contains single contexts. All contexts are > divorced on snapshot. Divorced contexts are amnesiacs. > > > So now, finally, we can answer your question. Why is (Context>>#pc), a > method that simply answers an instance variable, not compiled as a quick > method with a primitive that answers that variable? "married" and > "widowed" contexts are proxies for stack frames. Only the instance > variables they contain which do not change can be fetched from the > context object itself; these are the receiver, arguments, closureOrNil, and > method. sender, pc, stackp and other stack contents may change as execution > proceeds. These mutable values must be fetched from the stack frame itself, > if it still exists. > > All accesses to sender, pc, stackp, and stack contents > (Context>>at:[put:]) must be mediated. A married or widowed context has > its sender field set to the frame pointer of its stack frame, encoded as a > SmallInteger. You can never see this from the image (except via a special > xRay primitive). By following the frame pointer encoded in the sender field > the VM can detect if the frame is still live. If so, the relevant > values are synthesized or fetched from the stack frame itself. If not, the > context is widowed and "mourns"; it is changed into a context with a nil > sender field, a nil pc, and a stackp that points at the last argument. > > How is this mediation done? One design could be to require that all image > level accesses to Context inst vars are through primitives. This feels > contrived to me. Instead, inst var access is via inst var access > bytcodes. But if we do this naively we would have to check in all inst var > access bytecodes whose index is the same as sender (0), pc (1) & stackp > (2). This would slow down inst var access enormously. Instead we observe > that inst var access bytecodes pushReceiverVariable:, > popIntoReceiverVariable: have short forms for the most frequently used > (indexes 0 to 15 for push, indexes 0 to 7 for popInto). By arranging that > we only use the long forms for accessing inst vars in Context, and > superclasses and subclasses, we only have to check in the long forms and > the check is cheap. We check that the index is <= 2, because all other > inst var accesses with these indices will use the short-form bytecodes. > > By arranging that Context's inst vars are *not* accessed by quick > primitives we do not have to duplicate this machinery in quick primitive > dispatch, which would also slow things down. Hence Context>>pc is compiled > as a vanilla method and its inst var access bytecode is the long form: > > 25 pushRcvr: 1 > 27 <5C> returnTop > > 'Nuff said > > Second, Context >> #isPrimFailToken: attracted my attention multiple >> times when looking at different #timeProfile results of simulation >> sessions. In the expression [100000 factorial] it takes up more than 44% of >> the whole execution time! >> I have no idea why it could be so slow, but this message is sent really >> often, which is at least 2 times per simulation of a special message send. >> Would there be an easy change to resolve this bottleneck and speed >> up the simulation by 40% or more? >> Would it be possible to provide a primitive for this method? Or do you >> see any other way to optimize it? >> > > It's not slow so much as that it has to be used all the time to check > whether a send has invoked a primitive which has failed. Its function is > to support primitive error codes. Before primitive error codes (IIRC) we > simply checked for nil. But with primitive error codes we need a > container that both reliably distinguishes a primitive failure result from > all other objects in the system, and holds onto the primitive failure > code. It may indeed be able to reduce the overhead by only testing when > absolutely necessary. It may be that reimplementing the scheme is faster. > > For example, one could imagine a class whose instances are the only > objects to answer #isPrimFailToken, which would be faster than a one > argument message send. But beware, because if one was debugging the > debugger one mustn't confuse a PrimFailToken created in the simulation for > a PrimFailToken created by the simulation. > Remember to distinguish between price and value. Implementing the > context-to-stack mapping scheme outlined above was very costly, but its > value is very high. It allows us to have contexts, with all their utility, > while reducing their costs significantly. Similarly, and closely related, > being able to simulate execution is costly but hugely valuable. If the > price is 40% of simulated execution then it is a price worth paying. > > Best, >> Christoph >> > > Happy New Year! > > _,,,^..^,,,_ > best, Eliot > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa at codefrau.net Sat Jan 2 05:28:35 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Fri, 1 Jan 2021 21:28:35 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: <20201231174700.GA6669@shell.msen.com> References: <26679313-2E4A-4BDA-9993-CCC738C6A01D@gmail.com> <20201231174700.GA6669@shell.msen.com> Message-ID: Hi Dave, I haven’t actually tried it but it seems on a slow platform this would delay the first-time startup by however long those benchmarks take, right? IsLowPerformance is used to determine if the full wizard is shown or a cheaper one. Vanessa On Thu 31. Dec 2020 at 09:47, David T. Lewis wrote: > On Tue, Dec 22, 2020 at 02:07:30PM -0800, Vanessa Freudenberg wrote: > > (dropping vm-dev) > > > > On Tue, Dec 22, 2020 at 1:57 PM Eliot Miranda > > wrote: > > > > > > > > On Tue, Dec 22, 2020 at 1:44 PM Vanessa Freudenberg < > vanessa at codefrau.net> > > > wrote: > > > > > >> > > >> I like measuring all-over performance, and not adding any extra work. > > >> > > >> Like, DateAndTime is pretty early in the startup list. It could > remember > > >> the time its startup was invoked. Another class that comes later > could set > > >> a LowPerformance flag if it took longer than x ms since DateAndTime > was > > >> initialized. > > >> > > >> I just tried that with ProcessorScheduler (see attachment). On Safari > and > > >> a 5.3 image I get ImageStartMS = 133 ms, on Chrome 250 ms. On a fast > VM I > > >> get 5 ms. So maybe if that takes longer than say 50 ms it could be > > >> considered low performance? > > >> > > > > > > Works for me. I would record and provide an accessor for > ImageStartUsecs > > > (a class variable in SmalltalkImage, using microseconds :-) ). Then > one > > > can either use isLowerPerformance or the actual time for a more > "nuanced" > > > view. > > > > > > > Good idea. It also should use class vars not globals, etc. > > > > I didn't mean to use this as is, just to do a quick proof of concept. > And I > > didn't see Dave's take come through yet ... or are announcements from > > squeaksource broken? > > > > Vanessa > > I'm not sure if the inbox announcement came out on email (I did not see > it either), but my take on this was in System-dtl.1207.mcz in the inbox. > It uses a value computed once per session on first reference, so it should > have no effect on startup time. > > The actual logic to determine a "slow platform" is this: > > (Time millisecondsToRun:[ 25 benchFib ]) > 200 > or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ] > > Perhaps someone with a Raspberry Pi can check and see if this is > reasonable? It does indicate that SqueakJS is "slow" when running > in Chrome on my Linux box, and the compiled VMs are "fast". > > Dave > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Sat Jan 2 05:38:33 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 1 Jan 2021 21:38:33 -0800 Subject: [squeak-dev] Sound mixing makes nasty noises In-Reply-To: <53e1d7b6-13c0-999e-7a4e-149d3515bb21@gmx.net> References: <108F5892-289F-445E-8DC4-579C610CEB74@rowledge.org> <7C8655DA-7CA9-4133-90EE-BDA202681583@rowledge.org> <33a18d48-1644-9324-4bd2-e6a64da94a16@gmx.net> <80778164-F339-4986-BD6C-489757CBD0F1@rowledge.org> <78a26136-ac80-3bd7-3f6d-cbaee7d6fd15@gmx.net> <2A486FD7-778B-47EF-BC2D-48E964529E33@rowledge.org> <363580ae-43cf-36a9-9c6c-3c5649913dac@gmx.net> <5618d556-9ee8-f8dc-26b3-1dc5f613a7b2@gmx.net> <1a8f5722-17aa-06e9-bf95-b3d29336d3c5@gmail.com> <43dc69bf-c8fc-9c38-f898-a2f79c8273e2@gmx.net> <4cfccf9d-aa05-60df-fc70-7ce8b8665516@gmx.net> <7d413507-ad63-0631-f197-71c43978fd82@gmx.net> <53e1d7b6-13c0-999e-7a4e-149d3515bb21@gmx.net> Message-ID: <7F0AA22E-C3D5-47B1-B594-3DF53DC6EE99@rowledge.org> The Great Saga marches onward... I've hacked the playLoop to also save the samples sent to SoundPlayer class>>#primSoundPlaySamples:from:startingAt: in a SamplesSound with a big buffer. Running sample sound snippets results in a saveable sample that I can then play in various ways on other machines. Right now it appears to strongly suggest that the samples being created by Squeak are just fine; make horrible noises on the pulse-Pi, copy the generated .wav to an alsa-Pi and it sounds fine. Play the .wav on my iMac via iTunes and it sounds fine. try to play the .wav via VLC media player on the pulse-Pi and if anything it sounds worse. VLC player on the alsa Pi sounds very similar to the iTunes/iMac. More testing to try but I'm leaning towards the pulse system on the Pi being borked. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim To err is human; to really foul things up requires a computer. From tim at rowledge.org Sat Jan 2 05:43:02 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 1 Jan 2021 21:43:02 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: <26679313-2E4A-4BDA-9993-CCC738C6A01D@gmail.com> <20201231174700.GA6669@shell.msen.com> Message-ID: On a Pi 4 - > > (Time millisecondsToRun:[ 25 benchFib ]) > 200 > or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ] 19mS & 143mS I don't see an issue with possibly slowing down the first startup to test performance as long as a) it isn't a multi-second delay b) it says what it is doing "Checking system performance in order to provide advice on suitable setup options" would be apropos. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful random insult:- Not all his dogs are barking. From eliot.miranda at gmail.com Sat Jan 2 08:20:32 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 2 Jan 2021 00:20:32 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: Message-ID: <87CFADF2-958F-42A3-AB5C-99E1AA8A3795@gmail.com> > On Jan 1, 2021, at 9:43 PM, tim Rowledge wrote: > > On a Pi 4 - >> >> (Time millisecondsToRun:[ 25 benchFib ]) > 200 >> or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ] > > 19mS & 143mS > > I don't see an issue with possibly slowing down the first startup to test performance as long as > a) it isn't a multi-second delay > b) it says what it is doing > "Checking system performance in order to provide advice on suitable setup options" > would be apropos. I’m sorry but it’s completely unacceptable. 19ms is an age. Simple Unix commands are done in that time. 50 of those and a second has elapsed. Imagine one is using a Smalltalk script with the Unix find command and one can not do better than 50 applications per second. We know that we can derive a meaningful performance figure from existing work. Why are we even considering adding unnecessary overhead? > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Useful random insult:- Not all his dogs are barking. > > > From leves at caesar.elte.hu Sat Jan 2 12:00:03 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sat, 2 Jan 2021 13:00:03 +0100 (CET) Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: <87CFADF2-958F-42A3-AB5C-99E1AA8A3795@gmail.com> References: <87CFADF2-958F-42A3-AB5C-99E1AA8A3795@gmail.com> Message-ID: Perhaps it's sufficient to measure the uptime and estimate the machine's performance based on that value. On slower machines it should take longer to get to the same point in the startup process. By uptime I mean what's shown in the VM stats: | vmStartTime uptime | vmStartTime := Smalltalk vmParameterAt: 20. uptime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur VMs" ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000] ifFalse: [Time eventMillisecondClock]. which may be simplified to: | uptime | uptime := Time utcMicrosecondClock - (Smalltalk vmParameterAt: 20) + 500 // 1000. Levente On Sat, 2 Jan 2021, Eliot Miranda wrote: > > >> On Jan 1, 2021, at 9:43 PM, tim Rowledge wrote: >> >> On a Pi 4 - >>> >>> (Time millisecondsToRun:[ 25 benchFib ]) > 200 >>> or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ] >> >> 19mS & 143mS >> >> I don't see an issue with possibly slowing down the first startup to test performance as long as >> a) it isn't a multi-second delay >> b) it says what it is doing >> "Checking system performance in order to provide advice on suitable setup options" >> would be apropos. > > I’m sorry but it’s completely unacceptable. 19ms is an age. Simple Unix commands are done in that time. 50 of those and a second has elapsed. Imagine one is using a Smalltalk script with the Unix find command and one can not do better than 50 applications per second. > > We know that we can derive a meaningful performance figure from existing work. Why are we even considering adding unnecessary overhead? > >> >> tim >> -- >> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim >> Useful random insult:- Not all his dogs are barking. >> >> >> From lists at fniephaus.com Sat Jan 2 12:13:27 2021 From: lists at fniephaus.com (Fabio Niephaus) Date: Sat, 2 Jan 2021 13:13:27 +0100 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: <26679313-2E4A-4BDA-9993-CCC738C6A01D@gmail.com> <20201231174700.GA6669@shell.msen.com> Message-ID: On Sat, 2 Jan 2021 at 6:28 am, Vanessa Freudenberg wrote: > Hi Dave, > > I haven’t actually tried it but it seems on a slow platform this would > delay the first-time startup by however long those benchmarks take, right? > > IsLowPerformance is used to determine if the full wizard is shown or a > cheaper one. > The wizard unfortunately takes a lot of time snapshotting a preview of the world on startup. Marcel said that this can be avoided with lazily initializing the preview (it's not even shown in the initial overlay). This would also eliminate the noticeable delay on startup when running on OpenSmalltalkVM. Fabio > Vanessa > > On Thu 31. Dec 2020 at 09:47, David T. Lewis wrote: > >> On Tue, Dec 22, 2020 at 02:07:30PM -0800, Vanessa Freudenberg wrote: >> > (dropping vm-dev) >> > >> > On Tue, Dec 22, 2020 at 1:57 PM Eliot Miranda >> > wrote: >> > >> > > >> > > On Tue, Dec 22, 2020 at 1:44 PM Vanessa Freudenberg < >> vanessa at codefrau.net> >> > > wrote: >> > > >> > >> >> > >> I like measuring all-over performance, and not adding any extra work. >> > >> >> > >> Like, DateAndTime is pretty early in the startup list. It could >> remember >> > >> the time its startup was invoked. Another class that comes later >> could set >> > >> a LowPerformance flag if it took longer than x ms since DateAndTime >> was >> > >> initialized. >> > >> >> > >> I just tried that with ProcessorScheduler (see attachment). On >> Safari and >> > >> a 5.3 image I get ImageStartMS = 133 ms, on Chrome 250 ms. On a fast >> VM I >> > >> get 5 ms. So maybe if that takes longer than say 50 ms it could be >> > >> considered low performance? >> > >> >> > > >> > > Works for me. I would record and provide an accessor for >> ImageStartUsecs >> > > (a class variable in SmalltalkImage, using microseconds :-) ). Then >> one >> > > can either use isLowerPerformance or the actual time for a more >> "nuanced" >> > > view. >> > > >> > >> > Good idea. It also should use class vars not globals, etc. >> > >> > I didn't mean to use this as is, just to do a quick proof of concept. >> And I >> > didn't see Dave's take come through yet ... or are announcements from >> > squeaksource broken? >> > >> > Vanessa >> >> I'm not sure if the inbox announcement came out on email (I did not see >> it either), but my take on this was in System-dtl.1207.mcz in the inbox. >> It uses a value computed once per session on first reference, so it should >> have no effect on startup time. >> >> The actual logic to determine a "slow platform" is this: >> >> (Time millisecondsToRun:[ 25 benchFib ]) > 200 >> or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ] >> >> Perhaps someone with a Raspberry Pi can check and see if this is >> reasonable? It does indicate that SqueakJS is "slow" when running >> in Chrome on my Linux box, and the compiled VMs are "fast". >> >> Dave >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at fniephaus.com Sat Jan 2 12:49:13 2021 From: lists at fniephaus.com (Fabio Niephaus) Date: Sat, 2 Jan 2021 13:49:13 +0100 Subject: [squeak-dev] FullBlockClosures and ignoreOuterContext? In-Reply-To: <7025C3AB-804F-4065-B50E-04AFA77AAFA4@gmail.com> References: <7025C3AB-804F-4065-B50E-04AFA77AAFA4@gmail.com> Message-ID: On Tue, 22 Dec 2020 at 9:35 am, Eliot Miranda wrote: > Hi Fabio, > > > On Dec 20, 2020, at 1:27 PM, Fabio Niephaus wrote: > > > > Hi Eliot, > > > >> On Tue, Dec 15, 2020 at 3:06 AM Eliot Miranda > wrote: > >> > >> Hi Fabio, > >> > >>> On Mon, Dec 14, 2020 at 1:33 PM Fabio Niephaus > wrote: > >>> > >>> Hi all, > >>> > >>> While digging through the implementation of FullBlockClosure with > >>> Hernan, we were wondering about full closures that ignore their > >>> outerContext. We noticed that the following method has two senders: > >>> > EncoderForSistaV1>>#genPushFullClosure:numCopied:receiverOnStack:ignoreOuterContext: > >>> > >>> One of them seems to be the only one in use, and it's passing in false > >>> as defaults for both receiverOnstack and ignoreOuterContext. The other > >>> sender > (BytecodeEncoder>>#sizePushFullClosure:numCopied:receiverOnStack:ignoreOuterContext:), > >>> in turn, doesn't seem to have any further senders. > >>> > >>> Unless we missed something, it looks like the outerContext will never > >>> be ignored at the moment. Similarly, the receiver is never on the > >>> stack. Is this something only Scorch can do or is this just "not yet > >>> implemented"? > >>> > >>> When can the outerContext be ignored? > >> > >> > >> When the Sista optimizer determines that it isn't needed. i.e. this > option is nover used in vanilla code but exists for an optimizing compiler > to avoid the overhead in cases where it wants to avoid inlining but knows > there is no real suspension point during some evaluation. Now, whether > we'll ever use this facility I can't say, but it was certainly in Clément's > mind to do so at some point. > >>> > > > > Ok, thanks for the info! > > > >>> When does it make sense to pop the receiver from the stack? > >> > >> > >> The point isn't really to pop the receiver from the stack. The point > is to be able to take the closures receiver form the stack rather than it > being implicitly the receiver of the current method. If closure creation > gets inlined by the optimizer then there will be potentially a mismatch > between the current method's receiver and an inlined closure's receiver, > which necessitates having the facility to specify a distinct receiver. > >> > > > > Makes sense, thanks! > > > >> > >>> > >>> And where can we find the latest version > >>> of Scorch. Is it still the one at [1]? > >> > >> > >> http://smalltalkhub.com/mc/ClementBera/Scorch/main > > > > Oh, isn't smalltalkhub read-only these days? > > If it is then things need to move once time is found to work on the code > again. > > > > >> > >> If you're interested in looking at Scorch I'm very interested in > collaborating. And there ius one significant modification to perform first > which will make development much easier, and that is to restructure the > interface between the optimizer and the image via mirrors, allowing the > optimizer to be mated with an image being simulated, rather than having to > be a full peer of the image it is optimizing. > > > > Since we turned on full closures and Sista in Squeak, I could no > > longer use trunk images on top of TruffleSqueak. I finally decided to > > bite the bullet and worked on support for both in the last two weeks. > > It's not that I don't want to collaborate and help evolve Scorch (it's > > a fascinating project!). It's just that I don't have the time to work > > on any significant contributions in that direction. Nonetheless, I'd > > love to see someone working on it again. > > Ah ok, makes sense. Now you’ve implemented the Sista set I’m curious how > you evaluate the design. I've actually worked on another implementation for SqueakJS in the meantime (see [1]) ... here are some quick thoughts: - I like that bytecodes are ordered by the number of bytes they consume (1, 2, 3). This makes implementations a bit easier to read (e.g. looking up the number of bytes per bytecode is very simple). - I noticed that some parts are still unfinished and I couldn't always guess what the plan was. Bytecodes 0x52 and 0x5E, for example, take the extension bytes under consideration. Right now, however, they only do something if the corresponding extension is 0. That's a bit odd, but I'm guessing the plan was to add more controls...not sure which though. Extension bytes in general are a nice concept. - FullBlockClosures are very much in line with how language implementation frameworks (Truffle, RPython) imagine closures. It was therefore quite easy to support them in TruffleSqueak. However, and as I found out in this thread, the implementation is also unfinished. Right now, the outer context is never ignored, so the overhead is comparable to old closures. I thought the Squeak compiler would ignore the outer context if non-local returns are not present. Maybe that's something we should try out next? - In terms of performance, Sista makes almost no difference in TruffleSqueak. For tinyBenchmarks, the compiler output is even identical. Therefore, it seems the Graal compiler can optimise Sista just as good as the old bytecode set, which is an interesting result. I expect to observe the same when running with Scorch. The optimisations done by Scorch are probably quite similar to what Graal does, only on a much higher level and then Graal would only have less to do. The main difference though is that Scorch optimisations are persisted within the image, which could greatly improve warmup. Fabio [1] https://github.com/codefrau/SqueakJS/blob/deaf0a5ca0b02d3dc9608fee6b7d9d544a4962da/vm.interpreter.js#L351 > > Eliot > _,,,^..^,,,_ (phone) > > > > > Fabio > > > >>> > >>> Cheers, > >>> Fabio > >>> > >>> [1] https://github.com/clementbera/Scorch > >> > >> > >> _,,,^..^,,,_ > >> best, Eliot > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smalltalk at stefan-marr.de Sat Jan 2 14:18:11 2021 From: smalltalk at stefan-marr.de (Stefan Marr) Date: Sat, 2 Jan 2021 14:18:11 +0000 Subject: [squeak-dev] FullBlockClosures and ignoreOuterContext? In-Reply-To: References: <7025C3AB-804F-4065-B50E-04AFA77AAFA4@gmail.com> Message-ID: <79B53113-8C25-4223-A84C-0DFBEF6698B5@stefan-marr.de> Hi Fabio: > On 2 Jan 2021, at 12:49, Fabio Niephaus wrote: > > - In terms of performance, Sista makes almost no difference in TruffleSqueak. I would expect a benefit in terms of cold-code/interpreter performance. Do you see any benefits here? > which could greatly improve warmup. Less run-time work for optimizers is one possible benefit, but I would expect the interpreter itself to also shows some performance difference. For instance, I’d assume there’s less needed for run-time specialization in the Truffle interpreter, and the Truffle interpreter code being less polymorphic. Is that the case/measurable? Best regards Stefan -- Stefan Marr School of Computing, University of Kent https://stefan-marr.de/research/ From lewis at mail.msen.com Sat Jan 2 16:41:39 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 2 Jan 2021 11:41:39 -0500 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: <26679313-2E4A-4BDA-9993-CCC738C6A01D@gmail.com> <20201231174700.GA6669@shell.msen.com> Message-ID: <20210102164139.GA73785@shell.msen.com> Hi Vanessa, On Fri, Jan 01, 2021 at 09:28:35PM -0800, Vanessa Freudenberg wrote: > Hi Dave, > > I haven???t actually tried it but it seems on a slow platform this would > delay the first-time startup by however long those benchmarks take, right? > No, it would run at most one time per session, and then only if someone sends #isLowerPerformance. I think thas means it would affect the run time of the first unit test that someone runs after starting the image, but otherwise no impact. Certainly it would not be noticable to humans. I like Levente's suggestion also. Dave From lewis at mail.msen.com Sat Jan 2 17:01:37 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 2 Jan 2021 12:01:37 -0500 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: <87CFADF2-958F-42A3-AB5C-99E1AA8A3795@gmail.com> Message-ID: <20210102170137.GB73785@shell.msen.com> On Sat, Jan 02, 2021 at 01:00:03PM +0100, Levente Uzonyi wrote: > >> > >>On Jan 1, 2021, at 9:43 PM, tim Rowledge wrote: > >> > >>???On a Pi 4 - > >>> > >>>(Time millisecondsToRun:[ 25 benchFib ]) > 200 > >>> or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ] > >> > >>19mS & 143mS > >> That certainly does not sound "slow" to me :-) Would you want the Pi 4 to be treated as slow, or is this a case of the PI arm platform actually moving into the "fast" category? > Perhaps it's sufficient to measure the uptime and estimate the machine's > performance based on that value. On slower machines it should take longer > to get to the same point in the startup process. > > By uptime I mean what's shown in the VM stats: > > | vmStartTime uptime | > vmStartTime := Smalltalk vmParameterAt: 20. > uptime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur > VMs" > ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000] > ifFalse: [Time eventMillisecondClock]. > > which may be simplified to: > > | uptime | > uptime := Time utcMicrosecondClock - (Smalltalk vmParameterAt: 20) + 500 // > 1000. > > > Levente This is a good simple approach that might give a better overall measure of "slow" in the case of Raspberry Pi. However, I don't think that VM parameter 20 is implemented on SqueakJS. Dave From eliot.miranda at gmail.com Sat Jan 2 17:34:03 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 2 Jan 2021 09:34:03 -0800 Subject: [squeak-dev] FullBlockClosures and ignoreOuterContext? Message-ID: Hi Stefan, > On Jan 2, 2021, at 6:18 AM, Stefan Marr via Squeak-dev wrote: > > Hi Fabio: > >> On 2 Jan 2021, at 12:49, Fabio Niephaus wrote: >> - In terms of performance, Sista makes almost no difference in TruffleSqueak. > > I would expect a benefit in terms of cold-code/interpreter performance. > Do you see any benefits here? There are two things here, one going on, the other not going on. Sista, the adaptive optimizer architecture, includes Scorch, the image-level speculative compiler. Scorch is not (yet) in use. Clément is at Google and I don’t have the cycles to work on it. But Sista and Scorch require the SistaV1 bytecode set, which is a set capable of expressing normal Smalltalk and optimizations, and a set that lifts limits on maximum method size, supports separate method objects for closures, etc. In Squeak we’ve moved to using the SistaV1 bytecode set but are of the order of six months to a year of engineering effort away from putting Sista the architecture into production. Doing so depends on a more productive development architecture, using the vm simulator and mirrors to allow Scorch to live alongside the simulator and optimize the image being simulated, not the current image, hence insulating the current image from bugs in Scorch. This could be a really interesting PhD and I’d love to collaborate. But if the community simply waits for me to do the work it’ll be years before its complete. I have a very full plate. Of course nothing will happen from Potsdam; they get their funding from Oracle, from Mario as I understand of, and right now that prevents competent people such as Fabio from working on Scorch itself and has them merely spectating, waiting to take advantage of something no one is putting resource into. It’s a frustrating and tragic situation. [I say tragic because my understanding of Shakespeare’s tragedies is that they are all driven by character] Some creativity on behalf of us all seems necessary if this work isn’t going to go to waste. I’m extremely frustrated with this situation. If people can’t find a way of collaborating with me and only find ways of finding what are effectively disruptive efforts then the project will eventually wither and die. I’m working for 3dIcc.com and we’re teetering on the brink. If we can get customers we can survive and I can become self-funding and may, in the remaining eight years to my seventieth birthday, have time to complete Sista; I certainly want to. But if the community could somehow find one or two people of Clément’s abilities to join me directly in the work, rather than simply spectating a body in a coma, then there is a good chance that Sista could be in production within a year or two. Yes I’m angry and frustrated. You would be too. > >> which could greatly improve warmup. > > Less run-time work for optimizers is one possible benefit, but I would expect the interpreter itself to also shows some performance difference. > For instance, I’d assume there’s less needed for run-time specialization in the Truffle interpreter, and the Truffle interpreter code being less polymorphic. > Is that the case/measurable? > > Best regards > Stefan > > > -- > Stefan Marr > School of Computing, University of Kent > https://stefan-marr.de/research/ HNY!! Eliot _,,,^..^,,,_ (phone) From tim at rowledge.org Sat Jan 2 18:29:36 2021 From: tim at rowledge.org (tim Rowledge) Date: Sat, 2 Jan 2021 10:29:36 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: <87CFADF2-958F-42A3-AB5C-99E1AA8A3795@gmail.com> References: <87CFADF2-958F-42A3-AB5C-99E1AA8A3795@gmail.com> Message-ID: <503BB967-397E-4385-BB41-DB88664BE816@rowledge.org> > On 2021-01-02, at 12:20 AM, Eliot Miranda wrote: > > > I’m sorry but it’s completely unacceptable. This is for deciding what options to have the welcome to your new image wizard suggest, right? In *that context* a single frame cycle delay spent being helpful to a new user seems very reasonable. Now, in an image set up to be used within some scripty-command-line-doit, absolutely not. I'm fairly sure nobody was suggesting that. If there is a problem where the wizard is getting invoked at an annoying time (for example, your scripts for building a vmmaker image) then ther must be a decent way to make it skip the whole thing. Might it be appropriate to say that if any commandline input is provided then the wizard stage is skipped completely? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Vescere bracis meis. = Eat my shorts. From digit at sonic.net Sat Jan 2 18:44:39 2021 From: digit at sonic.net (Tim Johnson) Date: Sat, 2 Jan 2021 10:44:39 -0800 (Pacific Standard Time) Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) Message-ID: Hi, First, before the rest of this complain-y message: **Happy 2021 to everybody!** Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale? In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation. Squot: https://github.com/hpi-swa/Squot/issues/266 Seaside: https://github.com/SeasideSt/Seaside/issues/1195 Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature. "To add an accessor method and a mutator method" (2015) https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html See also: "simple accessor and mutator methods" (1998) http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html and: ST/X's asMutator (in protocol 'converting') https://live.exept.de/ClassDoc/classDocOf,CharacterArray So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts? Thanks, Tim From eliot.miranda at gmail.com Sat Jan 2 19:09:20 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 2 Jan 2021 11:09:20 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: Message-ID: <232DD506-C99A-44B3-8608-508DBAA676E4@gmail.com> > On Jan 2, 2021, at 4:00 AM, Levente Uzonyi wrote: > > Perhaps it's sufficient to measure the uptime and estimate the machine's performance based on that value. On slower machines it should take longer to get to the same point in the startup process. > > By uptime I mean what's shown in the VM stats: > > | vmStartTime uptime | > vmStartTime := Smalltalk vmParameterAt: 20. > uptime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur VMs" > ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000] > ifFalse: [Time eventMillisecondClock]. > > which may be simplified to: > > | uptime | > uptime := Time utcMicrosecondClock - (Smalltalk vmParameterAt: 20) + 500 // 1000. Exactly. +1. And further: uptimeUsecs ^ Time utcMicrosecondClock - (Smalltalk vmParameterAt: 20) > > > Levente > >> On Sat, 2 Jan 2021, Eliot Miranda wrote: >> >> >> >>>> On Jan 1, 2021, at 9:43 PM, tim Rowledge wrote: >>> On a Pi 4 - >>>> (Time millisecondsToRun:[ 25 benchFib ]) > 200 >>>> or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ] >>> 19mS & 143mS >>> I don't see an issue with possibly slowing down the first startup to test performance as long as >>> a) it isn't a multi-second delay >>> b) it says what it is doing >>> "Checking system performance in order to provide advice on suitable setup options" >>> would be apropos. >> >> I’m sorry but it’s completely unacceptable. 19ms is an age. Simple Unix commands are done in that time. 50 of those and a second has elapsed. Imagine one is using a Smalltalk script with the Unix find command and one can not do better than 50 applications per second. >> >> We know that we can derive a meaningful performance figure from existing work. Why are we even considering adding unnecessary overhead? >> >>> tim >>> -- >>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim >>> Useful random insult:- Not all his dogs are barking. > From eliot.miranda at gmail.com Sat Jan 2 19:10:45 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 2 Jan 2021 11:10:45 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: <20210102164139.GA73785@shell.msen.com> References: <20210102164139.GA73785@shell.msen.com> Message-ID: <72890B34-07D6-4408-9691-0F328854DE43@gmail.com> > On Jan 2, 2021, at 8:41 AM, David T. Lewis wrote: > > Hi Vanessa, > >> On Fri, Jan 01, 2021 at 09:28:35PM -0800, Vanessa Freudenberg wrote: >> Hi Dave, >> >> I haven???t actually tried it but it seems on a slow platform this would >> delay the first-time startup by however long those benchmarks take, right? >> > > No, it would run at most one time per session, and then only if someone > sends #isLowerPerformance. I think thas means it would affect the run time > of the first unit test that someone runs after starting the image, but > otherwise no impact. Certainly it would not be noticable to humans. David, put this delay in every startup and use Squeak as a scripting language and apply the script to every file in your home directory and yes, it would be noticeable to humans. > > I like Levente's suggestion also. > > Dave > > From eliot.miranda at gmail.com Sat Jan 2 19:26:23 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 2 Jan 2021 11:26:23 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: <503BB967-397E-4385-BB41-DB88664BE816@rowledge.org> References: <503BB967-397E-4385-BB41-DB88664BE816@rowledge.org> Message-ID: <80A9B68D-3F18-4EB6-B6B8-7E1AEAACCBF1@gmail.com> Tim, > On Jan 2, 2021, at 10:29 AM, tim Rowledge wrote: > >  > >> On 2021-01-02, at 12:20 AM, Eliot Miranda wrote: >> >> >> I’m sorry but it’s completely unacceptable. > > This is for deciding what options to have the welcome to your new image wizard suggest, right? In *that context* a single frame cycle delay spent being helpful to a new user seems very reasonable. > > Now, in an image set up to be used within some scripty-command-line-doit, absolutely not. I'm fairly sure nobody was suggesting that. If there is a problem where the wizard is getting invoked at an annoying time (for example, your scripts for building a vmmaker image) then ther must be a decent way to make it skip the whole thing. Might it be appropriate to say that if any commandline input is provided then the wizard stage is skipped completely? We’re talking at cross purposes. The Wizard is but one client of isSlowMachine (or whatever the selector is). If it’s a generally useful facility (and it’s been there for 40 years so maybe it is) then it is present in *every* context. And in many contexts adding 20ms to startup, let alone 150, is too slow. At DarkPlace at the turn of the C or so we got start time down to around 80ms after it being in the 400ms range of the machines of the time. Machines are much faster now. In a typical OpenSmalltalk-vm repository clone there are about 10,000 .c files (not .h, .cc, .m etc; just .c files). On my 2.9GHz MBP doing find . -name ‘*.c’ >/dev/null takes 1 second. Doing find . -name ‘*.c’ -exec grep NOTTHERE \{} \; >/dev/null takes 28 seconds. Adding 20ms to the startup time of grep would add 200 seconds, a 700% overhead. 20ms is unacceptable if it’s unnecessary. > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Useful Latin Phrases:- Vescere bracis meis. = Eat my shorts. > > > From lewis at mail.msen.com Sat Jan 2 19:56:49 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 2 Jan 2021 14:56:49 -0500 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: <72890B34-07D6-4408-9691-0F328854DE43@gmail.com> References: <20210102164139.GA73785@shell.msen.com> <72890B34-07D6-4408-9691-0F328854DE43@gmail.com> Message-ID: <20210102195649.GA3733@shell.msen.com> Hi Eliot, On Sat, Jan 02, 2021 at 11:10:45AM -0800, Eliot Miranda wrote: > > > > On Jan 2, 2021, at 8:41 AM, David T. Lewis wrote: > > > > ???Hi Vanessa, > > > >> On Fri, Jan 01, 2021 at 09:28:35PM -0800, Vanessa Freudenberg wrote: > >> Hi Dave, > >> > >> I haven???t actually tried it but it seems on a slow platform this would > >> delay the first-time startup by however long those benchmarks take, right? > >> > > > > No, it would run at most one time per session, and then only if someone > > sends #isLowerPerformance. I think thas means it would affect the run time > > of the first unit test that someone runs after starting the image, but > > otherwise no impact. Certainly it would not be noticable to humans. > > David, put this delay in every startup and use Squeak as a scripting > language and apply the script to every file in your home directory and > yes, it would be noticeable to humans. > I does *not* do that. Apparently I am not doing a good job of explaining. Dave > > > > I like Levente's suggestion also. > > > > Dave > > > > > From tim at rowledge.org Sat Jan 2 22:14:03 2021 From: tim at rowledge.org (tim Rowledge) Date: Sat, 2 Jan 2021 14:14:03 -0800 Subject: [squeak-dev] Sound mixing makes nasty noises In-Reply-To: <7F0AA22E-C3D5-47B1-B594-3DF53DC6EE99@rowledge.org> References: <108F5892-289F-445E-8DC4-579C610CEB74@rowledge.org> <7C8655DA-7CA9-4133-90EE-BDA202681583@rowledge.org> <33a18d48-1644-9324-4bd2-e6a64da94a16@gmx.net> <80778164-F339-4986-BD6C-489757CBD0F1@rowledge.org> <78a26136-ac80-3bd7-3f6d-cbaee7d6fd15@gmx.net> <2A486FD7-778B-47EF-BC2D-48E964529E33@rowledge.org> <363580ae-43cf-36a9-9c6c-3c5649913dac@gmx.net> <5618d556-9ee8-f8dc-26b3-1dc5f613a7b2@gmx.net> <1a8f5722-17aa-06e9-bf95-b3d29336d3c5@gmail.com> <43dc69bf-c8fc-9c38-f898-a2f79c8273e2@gmx.net> <4cfccf9d-aa05-60df-fc70-7ce8b8665516@gmx.net> <7d413507-ad63-0631-f197-71c43978fd82@gmx.net> <53e1d7b6-13c0-999e-7a4e-149d3515bb21@gmx.net> <7F0AA22E-C3D5-47B1-B594-3DF53DC6EE99@rowledge.org> Message-ID: <969D7126-6604-451B-9147-C533A5CC229A@rowledge.org> > On 2021-01-01, at 9:38 PM, tim Rowledge wrote: > > The Great Saga marches onward... Attached is a changeset that has the hacked playLoop and a rather long preamble that *should* explain it. Basically, make a global BigBuffer, change playLoop to write samples to BigBuffer if it is not nil and not full. Inspect the SampledSound that owns a big buffer and use the included code snippets (that magically appear in the inspector, woo-hoo!) to point BigBuffer at a .. buffer... make some noises and the set BigBuffer to nil to stop recording. Save the processed samples as a WAV file and try them on other machines and setups. You can load WAV files 'as sound' from the Squeak FileList, or play them with iTunes, VLC, whatever. -------------- next part -------------- A non-text attachment was scrubbed... Name: SoundTestingPulseAudio.1.cs Type: application/octet-stream Size: 3063 bytes Desc: not available URL: -------------- next part -------------- tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim "How many Motie Mediators does it take to chage a lightbulb?” "Are you insane? Only Crazy Eddie would want to change *anything*!" From tim at rowledge.org Sun Jan 3 00:53:51 2021 From: tim at rowledge.org (tim Rowledge) Date: Sat, 2 Jan 2021 16:53:51 -0800 Subject: [squeak-dev] Sound mixing makes nasty noises In-Reply-To: <969D7126-6604-451B-9147-C533A5CC229A@rowledge.org> References: <108F5892-289F-445E-8DC4-579C610CEB74@rowledge.org> <7C8655DA-7CA9-4133-90EE-BDA202681583@rowledge.org> <33a18d48-1644-9324-4bd2-e6a64da94a16@gmx.net> <80778164-F339-4986-BD6C-489757CBD0F1@rowledge.org> <78a26136-ac80-3bd7-3f6d-cbaee7d6fd15@gmx.net> <2A486FD7-778B-47EF-BC2D-48E964529E33@rowledge.org> <363580ae-43cf-36a9-9c6c-3c5649913dac@gmx.net> <5618d556-9ee8-f8dc-26b3-1dc5f613a7b2@gmx.net> <1a8f5722-17aa-06e9-bf95-b3d29336d3c5@gmail.com> <43dc69bf-c8fc-9c38-f898-a2f79c8273e2@gmx.net> <4cfccf9d-aa05-60df-fc70-7ce8b8665516@gmx.net> <7d413507-ad63-0631-f197-71c43978fd82@gmx.net> <53e1d7b6-13c0-999e-7a4e-149d3515bb21@gmx.net> <7F0AA22E-C3D5-47B1-B594-3DF53DC6EE99@rowledge.org> <969D7126-6604-451B-9147-C533A5CC229A@rowledge.org> Message-ID: <168FEC9C-506C-4922-8DB7-73B9DB54D0F9@rowledge.org> > On 2021-01-02, at 2:14 PM, tim Rowledge wrote: > > > >> On 2021-01-01, at 9:38 PM, tim Rowledge wrote: >> >> The Great Saga marches onward... The recently update pulse libraries for Pi seem to have removed a lot of the especially ugly graunching, which is nice to hear. It's still quite nasty when using full volume range sounds and playing multiple sounds simultaneously though; maybe some use of MixedSound might help but it remains true that the alsa setup doesn't do this. I've also realised that there is a definite buffer-size aliasing problem regardless of the alsa/pulse setup. Given that the normal buffer size is set to 120mS worth of samples, consider this snippet |snd volume dur| volume:= 100. dur := 120. 10 timesRepeat: [ snd := FMSound new. snd setPitch: (AbstractSound pitchForMIDIKey: 60) dur: 1000 loudness: ((volume / 100.0) within: 0.0 and: 1.0). snd play. dur milliSeconds wait. snd stopGracefully. snd := FMSound new. snd setPitch: (AbstractSound pitchForMIDIKey: 58) dur: 1000 loudness: ((volume / 100.0) within: 0.0 and: 1.0). snd play. dur milliSeconds wait. snd stopGracefully] This makes a nice dee-dah-dee-dah... sequence, very cleanly. Change 'dur' to 150 and try again...on either sound library the second version is incorrect and more dee-dah-de-da-dee-daaah-d-dah.. sort of choppy. 300 is less awful but still wrong. 240 is fine, as one might imagine. Just whose idea was generating sounds with computers? I want a word... tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Flabbergasted (adj.), appalled over how much weight you have gained. From kksubbu.ml at gmail.com Sun Jan 3 07:02:38 2021 From: kksubbu.ml at gmail.com (K K Subbu) Date: Sun, 3 Jan 2021 12:32:38 +0530 Subject: [squeak-dev] Sound mixing makes nasty noises In-Reply-To: <168FEC9C-506C-4922-8DB7-73B9DB54D0F9@rowledge.org> References: <80778164-F339-4986-BD6C-489757CBD0F1@rowledge.org> <78a26136-ac80-3bd7-3f6d-cbaee7d6fd15@gmx.net> <2A486FD7-778B-47EF-BC2D-48E964529E33@rowledge.org> <363580ae-43cf-36a9-9c6c-3c5649913dac@gmx.net> <5618d556-9ee8-f8dc-26b3-1dc5f613a7b2@gmx.net> <1a8f5722-17aa-06e9-bf95-b3d29336d3c5@gmail.com> <43dc69bf-c8fc-9c38-f898-a2f79c8273e2@gmx.net> <4cfccf9d-aa05-60df-fc70-7ce8b8665516@gmx.net> <7d413507-ad63-0631-f197-71c43978fd82@gmx.net> <53e1d7b6-13c0-999e-7a4e-149d3515bb21@gmx.net> <7F0AA22E-C3D5-47B1-B594-3DF53DC6EE99@rowledge.org> <969D7126-6604-451B-9147-C533A5CC229A@rowledge.org> <168FEC9C-506C-4922-8DB7-73B9DB54D0F9@rowledge.org> Message-ID: On 03/01/21 6:23 am, tim Rowledge wrote: > I've also realised that there is a definite buffer-size aliasing > problem regardless of the alsa/pulse setup. > > Given that the normal buffer size is set to 120mS worth of samples, > consider this snippet On Pi, the cpu gets throttled based on temperature and power rail voltage levels. This may cause variations in sound latency. You can monitor actual latency on your sink/playback/output device with: ---- ~$ pactl list sinks | grep -i 'sink\|latency' Sink #0 Latency: 75611 usec, configured 76000 usec Flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY ---- HTH .. Subbu From lewis at mail.msen.com Sun Jan 3 16:11:43 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 3 Jan 2021 11:11:43 -0500 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: <20210102195649.GA3733@shell.msen.com> References: <20210102164139.GA73785@shell.msen.com> <72890B34-07D6-4408-9691-0F328854DE43@gmail.com> <20210102195649.GA3733@shell.msen.com> Message-ID: <20210103161143.GA96454@shell.msen.com> On Sat, Jan 02, 2021 at 02:56:49PM -0500, David T. Lewis wrote: > Hi Eliot, > > On Sat, Jan 02, 2021 at 11:10:45AM -0800, Eliot Miranda wrote: > > > > > > > On Jan 2, 2021, at 8:41 AM, David T. Lewis wrote: > > > > > > ???Hi Vanessa, > > > > > >> On Fri, Jan 01, 2021 at 09:28:35PM -0800, Vanessa Freudenberg wrote: > > >> Hi Dave, > > >> > > >> I haven???t actually tried it but it seems on a slow platform this would > > >> delay the first-time startup by however long those benchmarks take, right? > > >> > > > > > > No, it would run at most one time per session, and then only if someone > > > sends #isLowerPerformance. I think thas means it would affect the run time > > > of the first unit test that someone runs after starting the image, but > > > otherwise no impact. Certainly it would not be noticable to humans. > > > > David, put this delay in every startup and use Squeak as a scripting > > language and apply the script to every file in your home directory and > > yes, it would be noticeable to humans. > > > > I does *not* do that. Apparently I am not doing a good job of explaining. > > Regarding startup time, I'm afraid that my explanation did not come across well in email, and I apologize for not being clear. Let me try once more by just quoting the code. At startup time, there is a new class var SlowPlatform that is set to nil. Otherwise nothing new is done during image startup processing: SmalltalkImage>>startUp: resuming resuming ifTrue: [LastStats := nil. SlowPlatform := nil. SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event:] Later on, the class var is lazy initialized if and only if someone needs to check for isLowerPerformance: SmalltalkImage>>isLowerPerformance "Some operations - TestCases for example - need an idea of the typical performance of the system on which they are being performed." ^ SlowPlatform ifNil: [ SlowPlatform := (Time millisecondsToRun:[ 25 benchFib ]) > 200 or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ]] That's all I meant to suggest. Sorry for the confusion, Dave From commits at source.squeak.org Sun Jan 3 19:35:08 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 3 Jan 2021 19:35:08 0000 Subject: [squeak-dev] The Inbox: ST80-ct.264.mcz Message-ID: A new version of ST80 was added to project The Inbox: http://source.squeak.org/inbox/ST80-ct.264.mcz ==================== Summary ==================== Name: ST80-ct.264 Author: ct Time: 3 January 2021, 8:34:46.789366 pm UUID: 69dbd2d8-5dbf-f043-8ff4-893f45185436 Ancestors: ST80-mt.262 Proposal: Add inspect item to ST80 window blue-button menu. =============== Diff against ST80-mt.262 =============== Item was changed: ----- Method: StandardSystemController class>>initialize (in category 'class initialization') ----- initialize "StandardSystemController initialize" ScheduledBlueButtonMenu := SelectionMenu labels: 'edit label choose color... two-tone/full color move frame full screen collapse + inspect controller close' lines: #(3 7) + selections: #(label chooseColor toggleTwoTone move reframe fullScreen collapse inspect close). - selections: #(label chooseColor toggleTwoTone move reframe fullScreen collapse close). VBorderCursor := Cursor extent: 16 at 16 fromArray: #( 2r1010000000000000 2r1010000000000000 2r1010000000000000 2r1010000000000000 2r1010000000000000 2r1010010000100000 2r1010110000110000 2r1011111111111000 2r1010110000110000 2r1010010000100000 2r1010000000000000 2r1010000000000000 2r1010000000000000 2r1010000000000000 2r1010000000000000 2r1010000000000000) offset: 0 at 0. HBorderCursor := Cursor extent: 16 at 16 fromArray: #( 2r1111111111111111 2r0000000000000000 2r1111111111111111 2r0000000100000000 2r0000001110000000 2r0000011111000000 2r0000000100000000 2r0000000100000000 2r0000000100000000 2r0000000100000000 2r0000011111000000 2r0000001110000000 2r0000000100000000 2r0000000000000000 2r0000000000000000 2r0000000000000000) offset: 0 at 0.! From commits at source.squeak.org Sun Jan 3 19:44:39 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 3 Jan 2021 19:44:39 0000 Subject: [squeak-dev] The Inbox: Tools-ct.1021.mcz Message-ID: A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-ct.1021.mcz ==================== Summary ==================== Name: Tools-ct.1021 Author: ct Time: 3 January 2021, 8:44:07.705149 pm UUID: de36bf14-60b2-d745-9ade-df88c56b645c Ancestors: Tools-mt.1019 Hotfix for fatal error in MVC projects when switching from an explorer to an inspector. Regression since Tools-mt.998 (elimination of 'Active' variables): [Project current world] now consistently answers a ControlManager instance in an MVC project rather than nil. Unfortunately, ControlManager does not implement the stepping protocol like Morphic does ... For now, let ObjectExplorer >> #world only answer actually steppable, i.e. morphic worlds, so stepping is disabled safely in MVC. Note that, however, at a later point we might want to talk about stepping support for MVC again ... maybe? The Process Browser already supports it. :-) =============== Diff against Tools-mt.1019 =============== Item was changed: ----- Method: ObjectExplorer>>release (in category 'monitoring') ----- release + self world ifNotNil: [ :world | world stopStepping: self selector: #step ]. - self world ifNotNil: [ self world stopStepping: self selector: #step ]. super release.! Item was changed: ----- Method: ObjectExplorer>>stopMonitoring (in category 'monitoring') ----- stopMonitoring monitorList := nil. + self world ifNotNil: [ :world | world stopStepping: self selector: #step].! - self world stopStepping: self selector: #step! Item was changed: ----- Method: ObjectExplorer>>world (in category 'monitoring') ----- world + | project | + project := Project current. + project isMorphic ifFalse: [^ nil]. + ^ project world! - ^ Project current world! From commits at source.squeak.org Sun Jan 3 19:53:38 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 3 Jan 2021 19:53:38 0000 Subject: [squeak-dev] The Trunk: Tools-ct.1021.mcz Message-ID: Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-ct.1021.mcz ==================== Summary ==================== Name: Tools-ct.1021 Author: ct Time: 3 January 2021, 8:44:07.705149 pm UUID: de36bf14-60b2-d745-9ade-df88c56b645c Ancestors: Tools-mt.1019 Hotfix for fatal error in MVC projects when switching from an explorer to an inspector. Regression since Tools-mt.998 (elimination of 'Active' variables): [Project current world] now consistently answers a ControlManager instance in an MVC project rather than nil. Unfortunately, ControlManager does not implement the stepping protocol like Morphic does ... For now, let ObjectExplorer >> #world only answer actually steppable, i.e. morphic worlds, so stepping is disabled safely in MVC. Note that, however, at a later point we might want to talk about stepping support for MVC again ... maybe? The Process Browser already supports it. :-) =============== Diff against Tools-mt.1019 =============== Item was changed: ----- Method: ObjectExplorer>>release (in category 'monitoring') ----- release + self world ifNotNil: [ :world | world stopStepping: self selector: #step ]. - self world ifNotNil: [ self world stopStepping: self selector: #step ]. super release.! Item was changed: ----- Method: ObjectExplorer>>stopMonitoring (in category 'monitoring') ----- stopMonitoring monitorList := nil. + self world ifNotNil: [ :world | world stopStepping: self selector: #step].! - self world stopStepping: self selector: #step! Item was changed: ----- Method: ObjectExplorer>>world (in category 'monitoring') ----- world + | project | + project := Project current. + project isMorphic ifFalse: [^ nil]. + ^ project world! - ^ Project current world! From commits at source.squeak.org Sun Jan 3 19:56:08 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 3 Jan 2021 19:56:08 0000 Subject: [squeak-dev] The Trunk: Tools-eem.1022.mcz Message-ID: Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-eem.1022.mcz ==================== Summary ==================== Name: Tools-eem.1022 Author: eem Time: 3 January 2021, 11:56:05.837731 am UUID: 67d66d1d-d650-45f4-8a72-1dd88c6d8ba4 Ancestors: Tools-ct.1021 Less verbosity in ObjectExplorer>>#world =============== Diff against Tools-ct.1021 =============== Item was changed: ----- Method: ObjectExplorer>>world (in category 'monitoring') ----- world - | project | + ^(project := Project current) isMorphic ifTrue: [project world]! - project := Project current. - project isMorphic ifFalse: [^ nil]. - ^ project world! From Christoph.Thiede at student.hpi.uni-potsdam.de Sun Jan 3 20:06:25 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Sun, 3 Jan 2021 20:06:25 +0000 Subject: [squeak-dev] The Trunk: Tools-eem.1022.mcz In-Reply-To: References: Message-ID: Thanks for the fast merge! --- Concerning this refactoring, I'm not sure whether it actually improves readability. :-) It might be a few byte steps faster, but that should not be our ultimate goal in all high-level domain-specific packages. Your version only implicitly shows that nil should be returned if the project is morphic. And the assignment expression ... not convinced, again. There have been enough discussions about it when they added the feature to Python 3, but I think it's true that doing multiple things in one statement is rather confusing than intuitive. That's no big deal, of course, I'm only mentioning it because you explicitly uploaded this refactoring. I would have rather expect the reciprocal changeset as a refactoring that conforms to my own personal taste of coding style. :-) Have a nice weekend, Christoph ________________________________ Von: Squeak-dev im Auftrag von commits at source.squeak.org Gesendet: Sonntag, 3. Januar 2021 20:56:08 An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org Betreff: [squeak-dev] The Trunk: Tools-eem.1022.mcz Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-eem.1022.mcz ==================== Summary ==================== Name: Tools-eem.1022 Author: eem Time: 3 January 2021, 11:56:05.837731 am UUID: 67d66d1d-d650-45f4-8a72-1dd88c6d8ba4 Ancestors: Tools-ct.1021 Less verbosity in ObjectExplorer>>#world =============== Diff against Tools-ct.1021 =============== Item was changed: ----- Method: ObjectExplorer>>world (in category 'monitoring') ----- world - | project | + ^(project := Project current) isMorphic ifTrue: [project world]! - project := Project current. - project isMorphic ifFalse: [^ nil]. - ^ project world! -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Mon Jan 4 01:20:36 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun, 3 Jan 2021 17:20:36 -0800 Subject: [squeak-dev] The Trunk: Tools-eem.1022.mcz In-Reply-To: References: Message-ID: Hi Christoph, On Sun, Jan 3, 2021 at 12:06 PM Thiede, Christoph < Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > Thanks for the fast merge! > > > --- > > > Concerning this refactoring, I'm not sure whether it actually improves > readability. :-) > I hear you but I feel very very srtingly on the matter. If one does not know that ifTrue: answers nil if the receiver is false, etc, then one is not fully literate. The version you wrote is four times longer and to my eyes much clumsier. So forgive me but I think it important to use the idiom correctly. Not using it is like speaking pidgin. To a great extent the system is a literary construction and we write ugly code at out peril. It is the start of a slippery slope towards newspeak ;-) It might be a few byte steps faster, but that should not be our ultimate > goal in all high-level domain-specific packages. > > Your version only implicitly shows that nil should be returned if the > project is morphic. > > And the assignment expression ... not convinced, again. There have been > enough discussions about it when they added the feature to Python 3, but I > think it's true that doing multiple things in one statement is rather > confusing than intuitive. > > > That's no big deal, of course, I'm only mentioning it because you > explicitly uploaded this refactoring. I would have rather expect the > reciprocal changeset as a refactoring that conforms to my own personal > taste of coding style. :-) > > > Have a nice weekend, > > Christoph > ------------------------------ > *Von:* Squeak-dev im > Auftrag von commits at source.squeak.org > *Gesendet:* Sonntag, 3. Januar 2021 20:56:08 > *An:* squeak-dev at lists.squeakfoundation.org; > packages at lists.squeakfoundation.org > *Betreff:* [squeak-dev] The Trunk: Tools-eem.1022.mcz > > Eliot Miranda uploaded a new version of Tools to project The Trunk: > http://source.squeak.org/trunk/Tools-eem.1022.mcz > > ==================== Summary ==================== > > Name: Tools-eem.1022 > Author: eem > Time: 3 January 2021, 11:56:05.837731 am > UUID: 67d66d1d-d650-45f4-8a72-1dd88c6d8ba4 > Ancestors: Tools-ct.1021 > > Less verbosity in ObjectExplorer>>#world > > =============== Diff against Tools-ct.1021 =============== > > Item was changed: > ----- Method: ObjectExplorer>>world (in category 'monitoring') ----- > world > - > | project | > + ^(project := Project current) isMorphic ifTrue: [project world]! > - project := Project current. > - project isMorphic ifFalse: [^ nil]. > - ^ project world! > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Mon Jan 4 01:31:58 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 3 Jan 2021 17:31:58 -0800 Subject: [squeak-dev] Sound mixing makes nasty noises In-Reply-To: References: <80778164-F339-4986-BD6C-489757CBD0F1@rowledge.org> <78a26136-ac80-3bd7-3f6d-cbaee7d6fd15@gmx.net> <2A486FD7-778B-47EF-BC2D-48E964529E33@rowledge.org> <363580ae-43cf-36a9-9c6c-3c5649913dac@gmx.net> <5618d556-9ee8-f8dc-26b3-1dc5f613a7b2@gmx.net> <1a8f5722-17aa-06e9-bf95-b3d29336d3c5@gmail.com> <43dc69bf-c8fc-9c38-f898-a2f79c8273e2@gmx.net> <4cfccf9d-aa05-60df-fc70-7ce8b8665516@gmx.net> <7d413507-ad63-0631-f197-71c43978fd82@gmx.net> <53e1d7b6-13c0-999e-7a4e-149d3515bb21@gmx.net> <7F0AA22E-C3D5-47B1-B594-3DF53DC6EE99@rowledge.org> <969D7126-6604-451B-9147-C533A5CC229A@rowledge.org> <168FEC9C-506C-4922-8DB7-73B9DB54D0F9@rowledge.org> Message-ID: <5E89B2CF-035A-4C06-BCF3-F90331E0B871@rowledge.org> Hi, so yes, a Pi does indeed throttle when it gets hot - but hot is > 60C core temperature and believe me, none of my Pi ever get anywhere near that. Nor are they suffering low-voltage problems right now; I had a nasty issue with a failing PSU some time last year, or last century, whenever we think 2020 was. All fixed now with bigger margins on the supply. It really does appear to be an issue with the basic design of the unix sound handling prims. Without digging too deep (because I'm knackered this weekend) it looks to me as if the unix sound prims are all single buffer stuff, whereas the Mac one appears double-buffered. For Windows I can't tell because none of the code makes any sense to me. For RISC OS there is a curious OS level buffering system that I vaguely understood for about 10 minutes 10 years ago. Currently we by default create 120mSecs worth of buffer, fill it up and send it out to be played. Supposedly we can work out how many slots are free to refilled at any time but what does that even mean? It depends upon the details of the OS sound handling; if the OS takes a copy of the squeak buffer then in a sense said squeak buffer is now completely empty and ready to be filled completely. But what if the next attempt to pass a buffer finds that the OS cannot accept any more samples just yet? How complicated can we make this? Even on a Mac you can trivially see the effect of some level of aliasing in the combination of the size of the buffer and the lengths of the 'notes' played by that snippet. Just try playing it with 'dur' set to 120 and then 150. Then edit the SoundPlayer class>>#initialize method to change the BufferMSecs value, then try again. It's really audible. But be careful - it appears to be possible to break the sound player completely by changing the BufferMSecs by much. The problem seems to me that the interface is really set up for streaming not short chunk work. The Squeak side of it was designed 20 years ago on the basis of machines barely 1% as fast as the slowest machines we generally use these days (I'd guess a Raspberry Pi Zero would count for that) and has barely changed. We probably ought to do a lot better now. > On 2021-01-02, at 11:02 PM, K K Subbu wrote: > > You can monitor actual latency on your sink/playback/output device with: > ---- > ~$ pactl list sinks | grep -i 'sink\|latency' That's seriously cool, thanks. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk! From commits at source.squeak.org Mon Jan 4 02:13:29 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 4 Jan 2021 02:13:29 0000 Subject: [squeak-dev] The Trunk: Kernel-eem.1365.mcz Message-ID: Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.1365.mcz ==================== Summary ==================== Name: Kernel-eem.1365 Author: eem Time: 3 January 2021, 6:13:25.987938 pm UUID: 1e125cb0-86f1-451b-b288-d89c06b9f267 Ancestors: Kernel-mt.1364 Context>>#doPrimitive:method:receiver:args: shoukld not send effectiveProcess to Processor activeProcess. The send is done inside Processor>>#activeProcess. Make sure CompiledBlock understands anyAndAllMessages so that implementors/senders doesn't crash inside the debugger with a block selected. =============== Diff against Kernel-mt.1364 =============== Item was added: + ----- Method: CompiledBlock>>anyAndAllMessages (in category 'literals') ----- + anyAndAllMessages + ^self homeMethod anyAndAllMessages! Item was changed: ----- Method: Context>>doPrimitive:method:receiver:args: (in category 'private') ----- doPrimitive: primitiveIndex method: meth receiver: receiver args: arguments "Simulate a primitive method whose index is primitiveIndex. The simulated receiver and arguments are given as arguments to this message. If successful, push result and return resuming context, else ^ {errCode, PrimitiveFailToken}. Any primitive which provokes execution needs to be intercepted and simulated to avoid execution running away." | value | "Judicious use of primitive 19 (a null primitive that doesn't do anything) prevents the debugger from entering various run-away activities such as spawning a new process, etc. Injudicious use results in the debugger not being able to debug interesting code, such as the debugger itself. Hence use primitive 19 with care :-)" "SystemNavigation new browseAllSelect: [:m| m primitive = 19]" + primitiveIndex = 19 ifTrue: + [Processor activeProcess - primitiveIndex = 19 ifTrue: [ - Processor activeProcess debug: self title:'Code simulation error' full: false]. ((primitiveIndex between: 201 and: 222) and: [(self objectClass: receiver) includesBehavior: BlockClosure]) ifTrue: [(primitiveIndex = 206 or: [primitiveIndex = 208]) ifTrue: "[Full]BlockClosure>>valueWithArguments:" [^receiver simulateValueWithArguments: arguments first caller: self]. ((primitiveIndex between: 201 and: 209) "[Full]BlockClosure>>value[:value:...]" or: [primitiveIndex between: 221 and: 222]) ifTrue: "[Full]BlockClosure>>valueNoContextSwitch[:]" [^receiver simulateValueWithArguments: arguments caller: self]]. primitiveIndex = 83 ifTrue: "afr 9/11/1998 19:50" "Object>>perform:[with:...]" [^self send: arguments first to: receiver with: arguments allButFirst]. primitiveIndex = 84 ifTrue: "afr 9/11/1998 19:50 & eem 8/18/2009 17:04" "Object>>perform:withArguments:" [^self send: arguments first to: receiver with: (arguments at: 2) lookupIn: (self objectClass: receiver)]. primitiveIndex = 100 ifTrue: "eem 8/18/2009 16:57" "Object>>perform:withArguments:inSuperclass:" [^self send: arguments first to: receiver with: (arguments at: 2) lookupIn: (arguments at: 3)]. "Mutex>>primitiveEnterCriticalSection Mutex>>primitiveTestAndSetOwnershipOfCriticalSection" (primitiveIndex = 186 or: [primitiveIndex = 187]) ifTrue: + ["Transcript + cr; + nextPutAll: 'Processor activeProcess '; + nextPutAll: (Processor activeProcess == receiver owningProcess ifTrue: [#==] ifFalse: [#~~]); + nextPutAll: ' owner'; + flush." + value := primitiveIndex = 186 + ifTrue: [receiver primitiveEnterCriticalSectionOnBehalfOf: Processor activeProcess] + ifFalse: [receiver primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf: Processor activeProcess]. - [| effective | - effective := Processor activeProcess effectiveProcess. - "active == effective" - value := primitiveIndex = 186 - ifTrue: [receiver primitiveEnterCriticalSectionOnBehalfOf: effective] - ifFalse: [receiver primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf: effective]. ^(self isPrimFailToken: value) ifTrue: [value] ifFalse: [self push: value]]. primitiveIndex = 188 ifTrue: "Object>>withArgs:executeMethod: CompiledMethod class>>receiver:withArguments:executeMethod: VMMirror>>ifFail:object:with:executeMethod: et al" [| n args methodArg thisReceiver | ((n := arguments size) between: 2 and: 4) ifFalse: [^self class primitiveFailTokenFor: #'unsupported operation']. ((self objectClass: (args := arguments at: n - 1)) == Array and: [(self objectClass: (methodArg := arguments at: n)) includesBehavior: CompiledMethod]) ifFalse: [^self class primitiveFailTokenFor: #'bad argument']. methodArg numArgs = args size ifFalse: [^self class primitiveFailTokenFor: #'bad number of arguments']. thisReceiver := arguments at: n - 2 ifAbsent: [receiver]. methodArg primitive > 0 ifTrue: [methodArg isQuick ifTrue: [^self push: (methodArg valueWithReceiver: thisReceiver arguments: args)]. ^self doPrimitive: methodArg primitive method: meth receiver: thisReceiver args: args]. ^Context sender: self receiver: thisReceiver method: methodArg arguments: args]. primitiveIndex = 118 ifTrue: "[receiver:]tryPrimitive:withArgs:; avoid recursing in the VM" [(arguments size = 3 and: [(self objectClass: arguments second) == SmallInteger and: [(self objectClass: arguments last) == Array]]) ifTrue: [^self doPrimitive: arguments second method: meth receiver: arguments first args: arguments last]. (arguments size = 2 and: [(self objectClass: arguments first) == SmallInteger and: [(self objectClass: arguments last) == Array]]) ifFalse: [^self class primitiveFailTokenFor: nil]. ^self doPrimitive: arguments first method: meth receiver: receiver args: arguments last]. value := primitiveIndex = 120 "FFI method" ifTrue: [(meth literalAt: 1) tryInvokeWithArguments: arguments] ifFalse: [primitiveIndex = 117 "named primitives" ifTrue: [self tryNamedPrimitiveIn: meth for: receiver withArgs: arguments] ifFalse: "should use self receiver: receiver tryPrimitive: primitiveIndex withArgs: arguments but this is only in later VMs (and appears to be broken)" [receiver tryPrimitive: primitiveIndex withArgs: arguments]]. ^(self isPrimFailToken: value) ifTrue: [value] ifFalse: [self push: value]! From kksubbu.ml at gmail.com Mon Jan 4 05:16:45 2021 From: kksubbu.ml at gmail.com (K K Subbu) Date: Mon, 4 Jan 2021 10:46:45 +0530 Subject: [squeak-dev] Sound mixing makes nasty noises In-Reply-To: <5E89B2CF-035A-4C06-BCF3-F90331E0B871@rowledge.org> References: <2A486FD7-778B-47EF-BC2D-48E964529E33@rowledge.org> <363580ae-43cf-36a9-9c6c-3c5649913dac@gmx.net> <5618d556-9ee8-f8dc-26b3-1dc5f613a7b2@gmx.net> <1a8f5722-17aa-06e9-bf95-b3d29336d3c5@gmail.com> <43dc69bf-c8fc-9c38-f898-a2f79c8273e2@gmx.net> <4cfccf9d-aa05-60df-fc70-7ce8b8665516@gmx.net> <7d413507-ad63-0631-f197-71c43978fd82@gmx.net> <53e1d7b6-13c0-999e-7a4e-149d3515bb21@gmx.net> <7F0AA22E-C3D5-47B1-B594-3DF53DC6EE99@rowledge.org> <969D7126-6604-451B-9147-C533A5CC229A@rowledge.org> <168FEC9C-506C-4922-8DB7-73B9DB54D0F9@rowledge.org> <5E89B2CF-035A-4C06-BCF3-F90331E0B871@rowledge.org> Message-ID: <754fe548-3abe-5bfb-eb78-efd712475f37@gmail.com> On 04/01/21 7:01 am, tim Rowledge wrote: > It depends upon the details of the OS sound handling; if the OS takes > a copy of the squeak buffer then in a sense said squeak buffer is now > completely empty and ready to be filled completely. But what if the > next attempt to pass a buffer finds that the OS cannot accept any > more samples just yet? How complicated can we make this? Latency could be introduced in any layer - driver, kernel, library, app. * aplay plays local files well that rules out any latency issues in lib/kernel/driver layers. * PulseAudio introduces another buffering layer with its audio server app. pactl should reveal this. * Squeak also uses its own buffers. As an app, it could be subject to fair-share scheduling. As an interpreter, Squeak would be CPU intensive workload. If there are other CPU intensive loads, then its scheduling latency may impact audio play. In addition to pactl, I would also have vmstat running in a separate terminal to reveal CPU/RAM/IO spikes. $ vmstat 5 HTH .. Subbu From commits at source.squeak.org Mon Jan 4 12:15:57 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 4 Jan 2021 12:15:57 0000 Subject: [squeak-dev] The Trunk: PreferenceBrowser-mt.109.mcz Message-ID: Marcel Taeumel uploaded a new version of PreferenceBrowser to project The Trunk: http://source.squeak.org/trunk/PreferenceBrowser-mt.109.mcz ==================== Summary ==================== Name: PreferenceBrowser-mt.109 Author: mt Time: 4 January 2021, 1:15:55.86444 pm UUID: 42f005a2-2686-4bda-8d58-486b6881ae54 Ancestors: PreferenceBrowser-mt.108 Speed up preference wizard open about 10x =============== Diff against PreferenceBrowser-mt.108 =============== Item was changed: ----- Method: PreferenceWizardMorph>>initialize (in category 'initialization') ----- initialize super initialize. isFullScreen := false. self hasLowPerformance ifTrue: [self color: self defaultColor] ifFalse: [self color: (self defaultColor alpha: 0.75)]. self setProperty: #indicateKeyboardFocus toValue: #never. - Preferences enable: #systemWindowEmbedOK. - - titleMorph := ('Welcome to Squeak' translated asText - addAttribute: (TextColor color: self defaultTextColor); - addAttribute: (TextFontReference toFont: (StrikeFont familyName: 'Darkmap DejaVu Sans' pointSize: 20)); - yourself) asMorph lock. - titleMorph margins: (10 at 0 corner: 10 at 10). - titleMorph layoutFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0) offsets: (0@ 0 corner: 0 @ titleMorph height)). - self - initializePages; - initializeButtons; - initializeControlMorph; - initializePreviewWorld; - initializeForLowPerformance. - - self changeProportionalLayout; layoutInset: 20; cellGap: 10; + cellPositioning: #center. + - cellPositioning: #center; - addAllMorphs: {titleMorph. buttonRowMorph. controlMorph. previewWorld. startButton. skipButton. lowPerformanceMorph}. - self addKeyboardCaptureFilter: self.! Item was changed: + ----- Method: PreferenceWizardMorph>>initializeButtons (in category 'initialization - playfield') ----- - ----- Method: PreferenceWizardMorph>>initializeButtons (in category 'initialization') ----- initializeButtons buttonRowMorph := Morph new color: Color transparent; changeTableLayout; listDirection: #leftToRight; cellGap: 10; layoutInset: (0 at 20 corner: 0 at 0); vResizing: #shrinkWrap; hResizing: #spaceFill; yourself. buttonRowMorph addAllMorphs: { previousButton := self createButton action: #previous; label: 'Previous' translated. pagesLabel := (self createLabel: '0 / 0') hResizing: #shrinkWrap; margins: (20 at 0 corner: 20 at 0); fullBounds; yourself. nextButton := self createButton action: #next; label: 'Next' translated. self createHorizontalSpacer. self createButton action: #accept; label: 'Done' translated}. - buttonRowMorph fullBounds. + buttonRowMorph layoutFrame: (LayoutFrame fractions: (0 @ 1 corner: 1 @ 1) offsets: (0@ buttonRowMorph height negated corner: 0 @ 0)).! - buttonRowMorph layoutFrame: (LayoutFrame fractions: (0 @ 1 corner: 1 @ 1) offsets: (0@ buttonRowMorph height negated corner: 0 @ 0)). - - - - startButton := (self createButton action: #showPlayfield; label: 'Configure' translated). - skipButton := (self createButton action: #showSqueak; label: 'Skip' translated). - - (startButton width max: skipButton width) in: [:w | - startButton hResizing: #rigid; width: w. - skipButton hResizing: #rigid; width: w. - - startButton layoutFrame: (LayoutFrame fractions: (0.5 @ 0.6 corner: 0.5 @ 0.6) offsets: (2*w negated @ 0 corner: 0 @ 0)). - skipButton layoutFrame: (LayoutFrame fractions: (0.5 @ 0.6 corner: 0.5 @ 0.6) offsets: (0@ 0 corner: 2*w @ 0))].! Item was changed: + ----- Method: PreferenceWizardMorph>>initializeControlMorph (in category 'initialization - playfield') ----- - ----- Method: PreferenceWizardMorph>>initializeControlMorph (in category 'initialization') ----- initializeControlMorph controlMorph := Morph new color: Color transparent; changeTableLayout; listDirection: #topToBottom; hResizing: #spaceFill; vResizing: #spaceFill; layoutInset: (0 at 0 corner: 10 at 0); layoutFrame: (LayoutFrame fractions: (0.0 @ 0 corner: 0.3 @ 1.0) offsets: (0@ titleMorph height corner: 0 @ buttonRowMorph height negated)); yourself. controlMorph addMorph: (self createLabel: 'Please take a few minutes and configure the look-and-feel of the environment. You can always adjust these settings later. You can see the effects of these settings in the live and editable windows to the right.' translated).! Item was removed: - ----- Method: PreferenceWizardMorph>>initializeForLowPerformance (in category 'initialization') ----- - initializeForLowPerformance - - lowPerformanceMorph := TextMorph new lock.! Item was changed: + ----- Method: PreferenceWizardMorph>>initializePages (in category 'initialization - playfield') ----- - ----- Method: PreferenceWizardMorph>>initializePages (in category 'initialization') ----- initializePages pages := OrderedCollection new. currentPageIndex := 0. self initializePage01Themes; initializePage02Visuals; initializePage02bVisualsMore; initializePage03Interaction; initializePage04InteractionMore; initializePage05Tools.! Item was added: + ----- Method: PreferenceWizardMorph>>initializePlayfield (in category 'initialization') ----- + initializePlayfield + + self + initializePages; + initializeButtons; + initializeControlMorph; + initializePreviewWorld. + + self + addAllMorphs: {titleMorph. buttonRowMorph. controlMorph. previewWorld. startButton. skipButton. lowPerformanceMorph}.! Item was changed: + ----- Method: PreferenceWizardMorph>>initializePreviewWorld (in category 'initialization - playfield') ----- - ----- Method: PreferenceWizardMorph>>initializePreviewWorld (in category 'initialization') ----- initializePreviewWorld | w1 w2 w3 | + Preferences enable: #systemWindowEmbedOK. previewWorld := PasteUpMorph new hResizing: #spaceFill; vResizing: #spaceFill; viewBox: (0 at 0 corner: 500 at 500); layoutFrame: (LayoutFrame fractions: (0.3 @ 0 corner: 1.0 @ 1.0) offsets: (0@ titleMorph height corner: 0 @ buttonRowMorph height negated)); fillStyle: Project current world fillStyle; borderWidth: 2; borderColor: Color white; cornerStyle: (self hasLowPerformance ifTrue: [#square] ifFalse: [#rounded]); yourself. w1 := (ToolSet browse: Morph selector: #drawOn:) dependents detect: [:ea | ea isSystemWindow]. w2 := ToolSet browseMessageSet: (SystemNavigation default allCallsOn: #negated) name: 'Senders' translated autoSelect: 'negated'. w3 := (Workspace new contents: '3+4 "Select and hit [CMD]+[P]."') openLabel: 'Workspace'. {w1. w2. w3} do: [:ea | ea makeUnclosable. previewWorld addMorph: ea]. self updateWindowBounds.! Item was added: + ----- Method: PreferenceWizardMorph>>initializeWelcome (in category 'initialization') ----- + initializeWelcome + + titleMorph := ('Welcome to Squeak' translated asText + addAttribute: (TextColor color: self defaultTextColor); + addAttribute: (TextFontReference toFont: (StrikeFont familyName: 'Darkmap DejaVu Sans' pointSize: 20)); + yourself) asMorph lock. + titleMorph margins: (10 at 0 corner: 10 at 10). + titleMorph layoutFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0) offsets: (0@ 0 corner: 0 @ titleMorph height)). + + startButton := (self createButton action: #showPlayfield; label: 'Configure' translated). + skipButton := (self createButton action: #showSqueak; label: 'Skip' translated). + + (startButton width max: skipButton width) in: [:w | + startButton hResizing: #rigid; width: w. + skipButton hResizing: #rigid; width: w. + + startButton layoutFrame: (LayoutFrame fractions: (0.5 @ 0.6 corner: 0.5 @ 0.6) offsets: (2*w negated @ 0 corner: 0 @ 0)). + skipButton layoutFrame: (LayoutFrame fractions: (0.5 @ 0.6 corner: 0.5 @ 0.6) offsets: (0@ 0 corner: 2*w @ 0))]. + + lowPerformanceMorph := TextMorph new lock. + + self addAllMorphs: {titleMorph. startButton. skipButton. lowPerformanceMorph}.! Item was changed: ----- Method: PreferenceWizardMorph>>isInPlayfield (in category 'testing') ----- isInPlayfield + ^ previewWorld notNil and: [previewWorld visible]! - ^ previewWorld visible! Item was changed: ----- Method: PreferenceWizardMorph>>showPlayfield (in category 'actions') ----- showPlayfield + previewWorld ifNil: [self initializePlayfield]. + startButton hide. skipButton hide. lowPerformanceMorph hide. isFullScreen := true. self step. titleMorph layoutFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0) offsets: (0@ 0 corner: 0 @ titleMorph height)). self refreshWorld. 500 milliSeconds wait. controlMorph show. previewWorld show. buttonRowMorph show. self next. self refreshWorld. ! Item was changed: ----- Method: PreferenceWizardMorph>>showWelcome (in category 'actions') ----- showWelcome + self isInPlayfield ifTrue: [^ self "Not possible to go back due to fast-init strategy."]. + titleMorph ifNil: [self initializeWelcome]. + titleMorph layoutFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0.65) offsets: (0 @0 corner: 0 at 0)). isFullScreen := false. self height: titleMorph fullBounds height * 4. - controlMorph hide. - previewWorld hide. - buttonRowMorph hide. - - titleMorph show. - startButton show. - skipButton show. self hasLowPerformance ifFalse: [lowPerformanceMorph hide] ifTrue: [lowPerformanceMorph show]. self hasLowPerformance ifTrue: [Cursor wait showWhile: [self adjustSettingsForLowPerformance]]. self refreshWorld. ! Item was changed: ----- Method: PreferenceWizardMorph>>updateWindowBounds (in category 'layout') ----- updateWindowBounds | windows offset margin extentToUse pointsToUse | isFullScreen == false ifTrue: [^ self]. + previewWorld ifNil: [^ self]. self fullBounds. margin := 20 at 20. extentToUse := (previewWorld extent - (margin * 2)) // 3 * (1.8 @ 1.5). pointsToUse := { previewWorld center - (previewWorld extent // (5.5 @ 4.5)). previewWorld center + (previewWorld width // 5.5 @ 0). previewWorld center + (0 @ (previewWorld width // 5))}. windows := previewWorld submorphs. offset := 50 at 50. windows reversed withIndexDo: [:ea :i | ea extent: extentToUse; center: (pointsToUse atWrap: i). offset := offset + (50 at 50)].! From commits at source.squeak.org Mon Jan 4 12:30:49 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 4 Jan 2021 12:30:49 0000 Subject: [squeak-dev] The Trunk: PreferenceBrowser-mt.110.mcz Message-ID: Marcel Taeumel uploaded a new version of PreferenceBrowser to project The Trunk: http://source.squeak.org/trunk/PreferenceBrowser-mt.110.mcz ==================== Summary ==================== Name: PreferenceBrowser-mt.110 Author: mt Time: 4 January 2021, 1:30:47.80744 pm UUID: c536a6cc-a1e2-4634-bebc-7e27aa40b27b Ancestors: PreferenceBrowser-mt.109 Fixes minor slip in wizard's last update. Sorry for the noise. =============== Diff against PreferenceBrowser-mt.109 =============== Item was changed: ----- Method: PreferenceWizardMorph>>adjustSettingsForLowPerformance (in category 'support') ----- adjustSettingsForLowPerformance self updateLowPerformanceLabel: 'Please wait, optimizing performance...' translated. self refreshWorld. self stateGradients "flat look" ifFalse: [self toggleGradients]. self stateBlinkingCursor ifTrue: [self toggleBlinkingCursor]. self stateFastDrag ifFalse: [self toggleFastDrag]. self stateSoftShadows ifTrue: [self toggleSoftShadows]. self stateHardShadows ifTrue: [self toggleHardShadows]. self stateRoundedWindowLook ifTrue: [self toggleRoundedWindowLook]. self stateRoundedButtonLook ifTrue: [self toggleRoundedButtonLook]. self stateAttachToolsToMouse ifTrue: [self toggleAttachToolsToMouse]. self stateToolAndMenuIcons ifTrue: [self toggleToolAndMenuIcons]. self stateSmartHorizontalSplitters ifTrue: [self toggleSmartHorizontalSplitters]. self stateSmartVerticalSplitters ifTrue: [self toggleSmartVerticalSplitters]. PluggableListMorph highlightHoveredRow: false; filterableLists: false; highlightPreSelection: true; "Feedback is important!!" flashOnErrors: false. TheWorldMainDockingBar showSecondsInClock: false. Preferences disable: #balloonHelpInMessageLists. "Set simple background." + self currentWorld setAsBackground: MorphicProject defaultFill. - Project current world setAsBackground: MorphicProject defaultFill. - previewWorld fillStyle: Project current world fillStyle. "Done." self updateLowPerformanceLabel: 'Settings were adjusted for optimal performance.' translated.! From lists at fniephaus.com Mon Jan 4 14:53:26 2021 From: lists at fniephaus.com (Fabio Niephaus) Date: Mon, 4 Jan 2021 15:53:26 +0100 Subject: [squeak-dev] The Trunk: PreferenceBrowser-mt.109.mcz In-Reply-To: References: Message-ID: Thank you, Marcel! This is great! Fabio On Mon, Jan 4, 2021 at 1:16 PM wrote: > > Marcel Taeumel uploaded a new version of PreferenceBrowser to project The Trunk: > http://source.squeak.org/trunk/PreferenceBrowser-mt.109.mcz > > ==================== Summary ==================== > > Name: PreferenceBrowser-mt.109 > Author: mt > Time: 4 January 2021, 1:15:55.86444 pm > UUID: 42f005a2-2686-4bda-8d58-486b6881ae54 > Ancestors: PreferenceBrowser-mt.108 > > Speed up preference wizard open about 10x > > =============== Diff against PreferenceBrowser-mt.108 =============== > > Item was changed: > ----- Method: PreferenceWizardMorph>>initialize (in category 'initialization') ----- > initialize > > super initialize. > > isFullScreen := false. > > self hasLowPerformance > ifTrue: [self color: self defaultColor] > ifFalse: [self color: (self defaultColor alpha: 0.75)]. > > self setProperty: #indicateKeyboardFocus toValue: #never. > > - Preferences enable: #systemWindowEmbedOK. > - > - titleMorph := ('Welcome to Squeak' translated asText > - addAttribute: (TextColor color: self defaultTextColor); > - addAttribute: (TextFontReference toFont: (StrikeFont familyName: 'Darkmap DejaVu Sans' pointSize: 20)); > - yourself) asMorph lock. > - titleMorph margins: (10 at 0 corner: 10 at 10). > - titleMorph layoutFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0) offsets: (0@ 0 corner: 0 @ titleMorph height)). > - > self > - initializePages; > - initializeButtons; > - initializeControlMorph; > - initializePreviewWorld; > - initializeForLowPerformance. > - > - self > changeProportionalLayout; > layoutInset: 20; > cellGap: 10; > + cellPositioning: #center. > + > - cellPositioning: #center; > - addAllMorphs: {titleMorph. buttonRowMorph. controlMorph. previewWorld. startButton. skipButton. lowPerformanceMorph}. > - > self addKeyboardCaptureFilter: self.! > > Item was changed: > + ----- Method: PreferenceWizardMorph>>initializeButtons (in category 'initialization - playfield') ----- > - ----- Method: PreferenceWizardMorph>>initializeButtons (in category 'initialization') ----- > initializeButtons > > buttonRowMorph := Morph new > color: Color transparent; > changeTableLayout; > listDirection: #leftToRight; > cellGap: 10; > layoutInset: (0 at 20 corner: 0 at 0); > vResizing: #shrinkWrap; > hResizing: #spaceFill; > yourself. > > buttonRowMorph addAllMorphs: { > previousButton := self createButton action: #previous; label: 'Previous' translated. > pagesLabel := (self createLabel: '0 / 0') hResizing: #shrinkWrap; margins: (20 at 0 corner: 20 at 0); fullBounds; yourself. > nextButton := self createButton action: #next; label: 'Next' translated. > self createHorizontalSpacer. > self createButton action: #accept; label: 'Done' translated}. > > - > buttonRowMorph fullBounds. > + buttonRowMorph layoutFrame: (LayoutFrame fractions: (0 @ 1 corner: 1 @ 1) offsets: (0@ buttonRowMorph height negated corner: 0 @ 0)).! > - buttonRowMorph layoutFrame: (LayoutFrame fractions: (0 @ 1 corner: 1 @ 1) offsets: (0@ buttonRowMorph height negated corner: 0 @ 0)). > - > - > - > - startButton := (self createButton action: #showPlayfield; label: 'Configure' translated). > - skipButton := (self createButton action: #showSqueak; label: 'Skip' translated). > - > - (startButton width max: skipButton width) in: [:w | > - startButton hResizing: #rigid; width: w. > - skipButton hResizing: #rigid; width: w. > - > - startButton layoutFrame: (LayoutFrame fractions: (0.5 @ 0.6 corner: 0.5 @ 0.6) offsets: (2*w negated @ 0 corner: 0 @ 0)). > - skipButton layoutFrame: (LayoutFrame fractions: (0.5 @ 0.6 corner: 0.5 @ 0.6) offsets: (0@ 0 corner: 2*w @ 0))].! > > Item was changed: > + ----- Method: PreferenceWizardMorph>>initializeControlMorph (in category 'initialization - playfield') ----- > - ----- Method: PreferenceWizardMorph>>initializeControlMorph (in category 'initialization') ----- > initializeControlMorph > > controlMorph := Morph new > color: Color transparent; > changeTableLayout; > listDirection: #topToBottom; > hResizing: #spaceFill; > vResizing: #spaceFill; > layoutInset: (0 at 0 corner: 10 at 0); > layoutFrame: (LayoutFrame fractions: (0.0 @ 0 corner: 0.3 @ 1.0) offsets: (0@ titleMorph height corner: 0 @ buttonRowMorph height negated)); > yourself. > > controlMorph addMorph: (self createLabel: 'Please take a few minutes and configure the look-and-feel of the environment. You can always adjust these settings later. You can see the effects of these settings in the live and editable windows to the right.' translated).! > > Item was removed: > - ----- Method: PreferenceWizardMorph>>initializeForLowPerformance (in category 'initialization') ----- > - initializeForLowPerformance > - > - lowPerformanceMorph := TextMorph new lock.! > > Item was changed: > + ----- Method: PreferenceWizardMorph>>initializePages (in category 'initialization - playfield') ----- > - ----- Method: PreferenceWizardMorph>>initializePages (in category 'initialization') ----- > initializePages > > pages := OrderedCollection new. > currentPageIndex := 0. > > self > initializePage01Themes; > initializePage02Visuals; > initializePage02bVisualsMore; > initializePage03Interaction; > initializePage04InteractionMore; > initializePage05Tools.! > > Item was added: > + ----- Method: PreferenceWizardMorph>>initializePlayfield (in category 'initialization') ----- > + initializePlayfield > + > + self > + initializePages; > + initializeButtons; > + initializeControlMorph; > + initializePreviewWorld. > + > + self > + addAllMorphs: {titleMorph. buttonRowMorph. controlMorph. previewWorld. startButton. skipButton. lowPerformanceMorph}.! > > Item was changed: > + ----- Method: PreferenceWizardMorph>>initializePreviewWorld (in category 'initialization - playfield') ----- > - ----- Method: PreferenceWizardMorph>>initializePreviewWorld (in category 'initialization') ----- > initializePreviewWorld > > | w1 w2 w3 | > + Preferences enable: #systemWindowEmbedOK. > > previewWorld := PasteUpMorph new > hResizing: #spaceFill; > vResizing: #spaceFill; > viewBox: (0 at 0 corner: 500 at 500); > layoutFrame: (LayoutFrame fractions: (0.3 @ 0 corner: 1.0 @ 1.0) offsets: (0@ titleMorph height corner: 0 @ buttonRowMorph height negated)); > fillStyle: Project current world fillStyle; > borderWidth: 2; > borderColor: Color white; > cornerStyle: (self hasLowPerformance ifTrue: [#square] ifFalse: [#rounded]); > yourself. > > w1 := (ToolSet browse: Morph selector: #drawOn:) dependents detect: [:ea | ea isSystemWindow]. > w2 := ToolSet browseMessageSet: (SystemNavigation default allCallsOn: #negated) name: 'Senders' translated autoSelect: 'negated'. > w3 := (Workspace new contents: '3+4 "Select and hit [CMD]+[P]."') openLabel: 'Workspace'. > > {w1. w2. w3} do: [:ea | > ea makeUnclosable. > previewWorld addMorph: ea]. > > self updateWindowBounds.! > > Item was added: > + ----- Method: PreferenceWizardMorph>>initializeWelcome (in category 'initialization') ----- > + initializeWelcome > + > + titleMorph := ('Welcome to Squeak' translated asText > + addAttribute: (TextColor color: self defaultTextColor); > + addAttribute: (TextFontReference toFont: (StrikeFont familyName: 'Darkmap DejaVu Sans' pointSize: 20)); > + yourself) asMorph lock. > + titleMorph margins: (10 at 0 corner: 10 at 10). > + titleMorph layoutFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0) offsets: (0@ 0 corner: 0 @ titleMorph height)). > + > + startButton := (self createButton action: #showPlayfield; label: 'Configure' translated). > + skipButton := (self createButton action: #showSqueak; label: 'Skip' translated). > + > + (startButton width max: skipButton width) in: [:w | > + startButton hResizing: #rigid; width: w. > + skipButton hResizing: #rigid; width: w. > + > + startButton layoutFrame: (LayoutFrame fractions: (0.5 @ 0.6 corner: 0.5 @ 0.6) offsets: (2*w negated @ 0 corner: 0 @ 0)). > + skipButton layoutFrame: (LayoutFrame fractions: (0.5 @ 0.6 corner: 0.5 @ 0.6) offsets: (0@ 0 corner: 2*w @ 0))]. > + > + lowPerformanceMorph := TextMorph new lock. > + > + self addAllMorphs: {titleMorph. startButton. skipButton. lowPerformanceMorph}.! > > Item was changed: > ----- Method: PreferenceWizardMorph>>isInPlayfield (in category 'testing') ----- > isInPlayfield > > + ^ previewWorld notNil and: [previewWorld visible]! > - ^ previewWorld visible! > > Item was changed: > ----- Method: PreferenceWizardMorph>>showPlayfield (in category 'actions') ----- > showPlayfield > > + previewWorld ifNil: [self initializePlayfield]. > + > startButton hide. > skipButton hide. > lowPerformanceMorph hide. > isFullScreen := true. > self step. > > titleMorph layoutFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0) offsets: (0@ 0 corner: 0 @ titleMorph height)). > > self refreshWorld. > 500 milliSeconds wait. > > controlMorph show. > previewWorld show. > buttonRowMorph show. > > self next. > self refreshWorld. > > ! > > Item was changed: > ----- Method: PreferenceWizardMorph>>showWelcome (in category 'actions') ----- > showWelcome > > + self isInPlayfield ifTrue: [^ self "Not possible to go back due to fast-init strategy."]. > + titleMorph ifNil: [self initializeWelcome]. > + > titleMorph layoutFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0.65) offsets: (0 @0 corner: 0 at 0)). > isFullScreen := false. > self height: titleMorph fullBounds height * 4. > > - controlMorph hide. > - previewWorld hide. > - buttonRowMorph hide. > - > - titleMorph show. > - startButton show. > - skipButton show. > self hasLowPerformance > ifFalse: [lowPerformanceMorph hide] > ifTrue: [lowPerformanceMorph show]. > > self hasLowPerformance > ifTrue: [Cursor wait showWhile: [self adjustSettingsForLowPerformance]]. > > self refreshWorld. > ! > > Item was changed: > ----- Method: PreferenceWizardMorph>>updateWindowBounds (in category 'layout') ----- > updateWindowBounds > > | windows offset margin extentToUse pointsToUse | > isFullScreen == false ifTrue: [^ self]. > + previewWorld ifNil: [^ self]. > > self fullBounds. > > margin := 20 at 20. > extentToUse := (previewWorld extent - (margin * 2)) // 3 * (1.8 @ 1.5). > pointsToUse := { > previewWorld center - (previewWorld extent // (5.5 @ 4.5)). > previewWorld center + (previewWorld width // 5.5 @ 0). > previewWorld center + (0 @ (previewWorld width // 5))}. > > windows := previewWorld submorphs. > offset := 50 at 50. > > windows reversed withIndexDo: [:ea :i | > ea > extent: extentToUse; > center: (pointsToUse atWrap: i). > offset := offset + (50 at 50)].! > > From lewis at mail.msen.com Mon Jan 4 15:09:03 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 4 Jan 2021 10:09:03 -0500 Subject: [squeak-dev] Sound mixing makes nasty noises In-Reply-To: <754fe548-3abe-5bfb-eb78-efd712475f37@gmail.com> References: <7d413507-ad63-0631-f197-71c43978fd82@gmx.net> <53e1d7b6-13c0-999e-7a4e-149d3515bb21@gmx.net> <7F0AA22E-C3D5-47B1-B594-3DF53DC6EE99@rowledge.org> <969D7126-6604-451B-9147-C533A5CC229A@rowledge.org> <168FEC9C-506C-4922-8DB7-73B9DB54D0F9@rowledge.org> <5E89B2CF-035A-4C06-BCF3-F90331E0B871@rowledge.org> <754fe548-3abe-5bfb-eb78-efd712475f37@gmail.com> Message-ID: <20210104150903.GA25391@shell.msen.com> On Mon, Jan 04, 2021 at 10:46:45AM +0530, K K Subbu wrote: > On 04/01/21 7:01 am, tim Rowledge wrote: > >It depends upon the details of the OS sound handling; if the OS takes > >a copy of the squeak buffer then in a sense said squeak buffer is now > >completely empty and ready to be filled completely. But what if the > >next attempt to pass a buffer finds that the OS cannot accept any > >more samples just yet? How complicated can we make this? > > Latency could be introduced in any layer - driver, kernel, library, app. > > * aplay plays local files well that rules out any latency issues in > lib/kernel/driver layers. > * PulseAudio introduces another buffering layer with its audio server > app. pactl should reveal this. > * Squeak also uses its own buffers. As an app, it could be subject to > fair-share scheduling. As an interpreter, Squeak would be CPU intensive > workload. If there are other CPU intensive loads, then its scheduling > latency may impact audio play. > > In addition to pactl, I would also have vmstat running in a separate > terminal to reveal CPU/RAM/IO spikes. > $ vmstat 5 > > HTH .. Subbu > Hi Subbu, I have been using Linux for many years, but I am always learning new things from the tips and explanations that you provide here. So thank you :-) Dave From lewis at mail.msen.com Mon Jan 4 15:12:37 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 4 Jan 2021 10:12:37 -0500 Subject: [squeak-dev] The Trunk: PreferenceBrowser-mt.109.mcz In-Reply-To: References: Message-ID: <20210104151237.GB25391@shell.msen.com> On Mon, Jan 04, 2021 at 12:15:57PM +0000, commits at source.squeak.org wrote: > Marcel Taeumel uploaded a new version of PreferenceBrowser to project The Trunk: > http://source.squeak.org/trunk/PreferenceBrowser-mt.109.mcz > > ==================== Summary ==================== > > Name: PreferenceBrowser-mt.109 > Author: mt > Time: 4 January 2021, 1:15:55.86444 pm > UUID: 42f005a2-2686-4bda-8d58-486b6881ae54 > Ancestors: PreferenceBrowser-mt.108 > > Speed up preference wizard open about 10x > Yay! Thank you. Dave From vanessa at codefrau.net Tue Jan 5 03:58:14 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Mon, 4 Jan 2021 19:58:14 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: <20210103161143.GA96454@shell.msen.com> References: <20210102164139.GA73785@shell.msen.com> <72890B34-07D6-4408-9691-0F328854DE43@gmail.com> <20210102195649.GA3733@shell.msen.com> <20210103161143.GA96454@shell.msen.com> Message-ID: On Sun, Jan 3, 2021 at 8:11 AM David T. Lewis wrote: > On Sat, Jan 02, 2021 at 02:56:49PM -0500, David T. Lewis wrote: > > Hi Eliot, > > > > On Sat, Jan 02, 2021 at 11:10:45AM -0800, Eliot Miranda wrote: > > > > > > > > > > On Jan 2, 2021, at 8:41 AM, David T. Lewis > wrote: > > > > > > > > ???Hi Vanessa, > > > > > > > >> On Fri, Jan 01, 2021 at 09:28:35PM -0800, Vanessa Freudenberg wrote: > > > >> Hi Dave, > > > >> > > > >> I haven???t actually tried it but it seems on a slow platform this > would > > > >> delay the first-time startup by however long those benchmarks take, > right? > > > >> > > > > > > > > No, it would run at most one time per session, and then only if > someone > > > > sends #isLowerPerformance. I think thas means it would affect the > run time > > > > of the first unit test that someone runs after starting the image, > but > > > > otherwise no impact. Certainly it would not be noticable to humans. > > > > > > David, put this delay in every startup and use Squeak as a scripting > > > language and apply the script to every file in your home directory and > > > yes, it would be noticeable to humans. > > > > > > > I does *not* do that. Apparently I am not doing a good job of explaining. > > > > > > Regarding startup time, I'm afraid that my explanation did not come across > well in email, and I apologize for not being clear. > > Let me try once more by just quoting the code. At startup time, there is > a new class var SlowPlatform that is set to nil. Otherwise nothing new > is done during image startup processing: > > SmalltalkImage>>startUp: resuming > resuming ifTrue: > [LastStats := nil. > SlowPlatform := nil. > SystemChangeNotifier uniqueInstance notify: Smalltalk > ofAllSystemChangesUsing: #event:] > > Later on, the class var is lazy initialized if and only if someone needs > to check for isLowerPerformance: > > SmalltalkImage>>isLowerPerformance > "Some operations - TestCases for example - need an idea of the > typical performance > of the system on which they are being performed." > ^ SlowPlatform > ifNil: [ SlowPlatform := (Time millisecondsToRun:[ 25 > benchFib ]) > 200 > or: [ (Time millisecondsToRun: [ 64 benchmark ]) > > 200 ]] > > That's all I meant to suggest. > > Sorry for the confusion, > > Dave > Hi Dave, you are correct for someone who prepares an image that they use over and over again. However, for someone using a fresh image that was just created using ReleaseBuilder, there will be a isLowerPerformance send on startup (via ReleaseBuilder class>>startUp: with a DeferredTask set by prepareEnvironment to open the PreferenceWizardMorph which uses its own hasLowPerformance method to try to make things faster). Compare this 5.3 image with disabled wizard: https://squeak.js.org/run/#url=https://freudenbergs.de/vanessa/squeakjs&zip=[Squeak5.3-19452-64bit.zip,SqueakV50.sources.zip]&wizard=false to the latest trunk (very slow because Sista so no JIT): https://squeak.js.org/run/#zip=https://files.squeak.org/6.0alpha/Squeak6.0alpha-20147-32bit/Squeak6.0alpha-20147-32bit.zip and that even has isLowerPerformance = true because we did fix the platform name check! If it was using your code then the "Time millisecondsToRun:[ 25 benchFib ]" would add 600 ms to the startup. Luckily it would bypass the "Time millisecondsToRun: [ 64 benchmark ]" which would take 4 seconds. So I'm in favor of Levente's idea, he proposed this: | vmStartTime uptime | vmStartTime := Smalltalk vmParameterAt: 20. uptime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur VMs" ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000] ifFalse: [Time eventMillisecondClock]. ... which works in SqueakJS because of the eventMillisecondClock fallback (vmParameter 20 is 0). We just would have to decide where in the startup sequence to put this check, which is slightly tricky. An obvious place would be in #recordStartupStamp - I just tried it: recordStartupStamp | vmStartTime | vmStartTime := Smalltalk vmParameterAt: 20. StartupTime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur VMs" ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000] ifFalse: [Time eventMillisecondClock]. StartupStamp := '----STARTUP----', Time dateAndTimeNow printString, ' as ', self imageName. ... and StartupTime is about 3000 ms. Then isLowerPerformance would become ^StartupTime > LowerPerformanceThreshold where LowerPerformanceThreshold would maybe default to 500? What's the StartupTime of e.g. a raspberry pi? Vanessa -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Tue Jan 5 04:06:06 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon, 4 Jan 2021 20:06:06 -0800 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: <20210102164139.GA73785@shell.msen.com> <72890B34-07D6-4408-9691-0F328854DE43@gmail.com> <20210102195649.GA3733@shell.msen.com> <20210103161143.GA96454@shell.msen.com> Message-ID: On Mon, Jan 4, 2021 at 7:58 PM Vanessa Freudenberg wrote: > On Sun, Jan 3, 2021 at 8:11 AM David T. Lewis wrote: > >> On Sat, Jan 02, 2021 at 02:56:49PM -0500, David T. Lewis wrote: >> > Hi Eliot, >> > >> > On Sat, Jan 02, 2021 at 11:10:45AM -0800, Eliot Miranda wrote: >> > > >> > > >> > > > On Jan 2, 2021, at 8:41 AM, David T. Lewis >> wrote: >> > > > >> > > > ???Hi Vanessa, >> > > > >> > > >> On Fri, Jan 01, 2021 at 09:28:35PM -0800, Vanessa Freudenberg >> wrote: >> > > >> Hi Dave, >> > > >> >> > > >> I haven???t actually tried it but it seems on a slow platform this >> would >> > > >> delay the first-time startup by however long those benchmarks >> take, right? >> > > >> >> > > > >> > > > No, it would run at most one time per session, and then only if >> someone >> > > > sends #isLowerPerformance. I think thas means it would affect the >> run time >> > > > of the first unit test that someone runs after starting the image, >> but >> > > > otherwise no impact. Certainly it would not be noticable to humans. >> > > >> > > David, put this delay in every startup and use Squeak as a scripting >> > > language and apply the script to every file in your home directory and >> > > yes, it would be noticeable to humans. >> > > >> > >> > I does *not* do that. Apparently I am not doing a good job of >> explaining. >> > >> > >> >> Regarding startup time, I'm afraid that my explanation did not come across >> well in email, and I apologize for not being clear. >> >> Let me try once more by just quoting the code. At startup time, there is >> a new class var SlowPlatform that is set to nil. Otherwise nothing new >> is done during image startup processing: >> >> SmalltalkImage>>startUp: resuming >> resuming ifTrue: >> [LastStats := nil. >> SlowPlatform := nil. >> SystemChangeNotifier uniqueInstance notify: Smalltalk >> ofAllSystemChangesUsing: #event:] >> >> Later on, the class var is lazy initialized if and only if someone needs >> to check for isLowerPerformance: >> >> SmalltalkImage>>isLowerPerformance >> "Some operations - TestCases for example - need an idea of the >> typical performance >> of the system on which they are being performed." >> ^ SlowPlatform >> ifNil: [ SlowPlatform := (Time millisecondsToRun:[ 25 >> benchFib ]) > 200 >> or: [ (Time millisecondsToRun: [ 64 benchmark ]) >> > 200 ]] >> >> That's all I meant to suggest. >> >> Sorry for the confusion, >> >> Dave >> > > Hi Dave, > > you are correct for someone who prepares an image that they use over and > over again. > > However, for someone using a fresh image that was just created using > ReleaseBuilder, there will be a isLowerPerformance send on startup (via > ReleaseBuilder class>>startUp: with a DeferredTask set by > prepareEnvironment to open the PreferenceWizardMorph which uses its > own hasLowPerformance method to try to make things faster). > > Compare this 5.3 image with disabled wizard: > > > https://squeak.js.org/run/#url=https://freudenbergs.de/vanessa/squeakjs&zip=[Squeak5.3-19452-64bit.zip,SqueakV50.sources.zip]&wizard=false > > to the latest trunk (very slow because Sista so no JIT): > > > https://squeak.js.org/run/#zip=https://files.squeak.org/6.0alpha/Squeak6.0alpha-20147-32bit/Squeak6.0alpha-20147-32bit.zip > > and that even has isLowerPerformance = true because we did fix the > platform name check! > > If it was using your code then the "Time millisecondsToRun:[ 25 benchFib > ]" would add 600 ms to the startup. Luckily it would bypass the "Time > millisecondsToRun: [ 64 benchmark ]" which would take 4 seconds. > > So I'm in favor of Levente's idea, he proposed this: > > | vmStartTime uptime | > vmStartTime := Smalltalk vmParameterAt: 20. > uptime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur > VMs" > ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000] > ifFalse: [Time eventMillisecondClock]. > > ... which works in SqueakJS because of the eventMillisecondClock fallback > (vmParameter 20 is 0). > > We just would have to decide where in the startup sequence to put this > check, which is slightly tricky. An obvious place would be in > #recordStartupStamp - I just tried it: > > recordStartupStamp > | vmStartTime | > vmStartTime := Smalltalk vmParameterAt: 20. > StartupTime := vmStartTime ~= 0 "utcMicrosecondClock at startup in > later Spur VMs" > ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000] > ifFalse: [Time eventMillisecondClock]. > StartupStamp := '----STARTUP----', Time dateAndTimeNow printString, > ' as ', self imageName. > > ... and StartupTime is about 3000 ms. > Gob smacked. This is embarrassing. This needs to be a preference. I don't mind it being on by default. But I think both STARTUP and QUIT/No SAVE stamps need to be optional. I for one find it really annoying that QUIT/No SAVE stamps are added when nothing has occurred (a pain if one's image is under version control, for example). So I find myself using the Mac's Force Quit, or ctrl-c on the command line. > Then isLowerPerformance would become > > ^StartupTime > LowerPerformanceThreshold > > where LowerPerformanceThreshold would maybe default to 500? What's the > StartupTime of e.g. a raspberry pi? > > Vanessa > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 08:22:02 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 09:22:02 +0100 Subject: [squeak-dev] [Vm-dev] some stupid failures In-Reply-To: References: Message-ID: Hi Nicolas. > Do we really want to keep this kind of test? Such benchmarks (and benchmark-like tests) should at least average over several runs and only fail as a test if something actually got slower on average. Or something like that. A single misbehaving run should not be the reason for such a test failure. Maybe we can tweak #should:notTakeMoreThan: to evaluate the block several times? But then it cannot fail early on as it is doing now ... Hmmm... Best, Marcel Am 05.01.2021 09:08:46 schrieb Nicolas Cellier : Hi all, sometimes, some build fail for just 1 test... Here https://travis-ci.com/github/OpenSmalltalk/opensmalltalk-vm/jobs/468407844 a squeak.stack.v3 RenderBugz ✗ #testSetForward (7ms) TestFailure: Block evaluation took more than the expected 0:00:00:00.004 RenderBugz(TestCase)>>assert:description: RenderBugz(TestCase)>>should:notTakeMoreThan: RenderBugz(TestCase)>>should:notTakeMoreThanMilliseconds: RenderBugz>>shouldntTakeLong: RenderBugz>>testSetForward ...shouldntTakeLong: [ t forwardDirection: 180.0 . self assert: ( t forwardDirection = 0.0 ) ] RenderBugz(TestCase)>>performTest 4ms, really? On C.I. infrastructure, anything can happen... Do we really want to keep this kind of test? We eventually could once startup performance is known (see isLowerPerformance discussion on squeak-dev), but in the interim, I suggest we neutralize this specific test in Smalltalk-CI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 08:58:22 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 09:58:22 +0100 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: <20210102164139.GA73785@shell.msen.com> <72890B34-07D6-4408-9691-0F328854DE43@gmail.com> <20210102195649.GA3733@shell.msen.com> <20210103161143.GA96454@shell.msen.com> Message-ID: Hi all! At the time of writing, the wizard has a hard-coded list of somewhat costly preferences to turn off via #adjustSettingsForLowPerformance. We should check and update that list from time to time. The check for #isLowerPerformance may also be useful outside the scope of preferences. Well, maybe we can make it check the *remaining* resources for new workload to come. That is, there may already be a Squeak process eating up 99% of the image's resources. Then, any call to #isLowerPerformance should answer "true", of course. Even though we might be on a powerful machine. The current workload matters for the upcoming operations. Note that the current workload is expected to be low at image-startup time. ;-) So, somehow deriving a performance figure at that time makes sense to me. Here is a summary of your suggestions: A) Estimate processor mips from platform specs + eem o mt B) Take extra measurement via #timeToRun when checking #isLowerPerformance, may be cached + dtl + tpr o codefrau - eem  - mt C) Profile image start-up via VM parameter 20 or similarly cheap timestamps + ul + codefrau + eem + dtl + mt All in all, we should follow up on Levente's suggestion. Note that I recently fixed the wizard startup in both Trunk and 5.3 to be 10x faster. Next step is to have the wizard be opened already in a fresh image -- to further speed up the first start. Best, Marcel Am 05.01.2021 05:06:33 schrieb Eliot Miranda : On Mon, Jan 4, 2021 at 7:58 PM Vanessa Freudenberg wrote: On Sun, Jan 3, 2021 at 8:11 AM David T. Lewis wrote: On Sat, Jan 02, 2021 at 02:56:49PM -0500, David T. Lewis wrote: > Hi Eliot, > > On Sat, Jan 02, 2021 at 11:10:45AM -0800, Eliot Miranda wrote: > > > > > > > On Jan 2, 2021, at 8:41 AM, David T. Lewis wrote: > > > > > > ???Hi Vanessa, > > > > > >> On Fri, Jan 01, 2021 at 09:28:35PM -0800, Vanessa Freudenberg wrote: > > >> Hi Dave, > > >> > > >> I haven???t actually tried it but it seems on a slow platform this would > > >> delay the first-time startup by however long those benchmarks take, right? > > >> > > > > > > No, it would run at most one time per session, and then only if someone > > > sends #isLowerPerformance. I think thas means it would affect the run time > > > of the first unit test that someone runs after starting the image, but > > > otherwise no impact. Certainly it would not be noticable to humans. > > > > David, put this delay in every startup and use Squeak as a scripting > > language and apply the script to every file in your home directory and > > yes, it would be noticeable to humans. > > > > I does *not* do that. Apparently I am not doing a good job of explaining. > > Regarding startup time, I'm afraid that my explanation did not come across well in email, and I apologize for not being clear. Let me try once more by just quoting the code. At startup time, there is a new class var SlowPlatform that is set to nil. Otherwise nothing new is done during image startup processing: SmalltalkImage>>startUp: resuming         resuming ifTrue:                 [LastStats := nil.                 SlowPlatform := nil.                 SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event:] Later on, the class var is lazy initialized if and only if someone needs to check for isLowerPerformance: SmalltalkImage>>isLowerPerformance         "Some operations - TestCases for example - need an idea of the typical performance         of the system on which they are being performed."         ^ SlowPlatform                 ifNil: [ SlowPlatform := (Time millisecondsToRun:[ 25 benchFib ]) > 200                         or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ]] That's all I meant to suggest. Sorry for the confusion, Dave Hi Dave,  you are correct for someone who prepares an image that they use over and over again. However, for someone using a fresh image that was just created using ReleaseBuilder, there will be a isLowerPerformance send on startup (via ReleaseBuilder class>>startUp: with a DeferredTask set by prepareEnvironment to open the PreferenceWizardMorph which uses its own hasLowPerformance method to try to make things faster). Compare this 5.3 image with disabled wizard: https://squeak.js.org/run/#url=https://freudenbergs.de/vanessa/squeakjs&zip=[Squeak5.3-19452-64bit.zip,SqueakV50.sources.zip]&wizard=false [https://squeak.js.org/run/#url=https://freudenbergs.de/vanessa/squeakjs&zip=[Squeak5.3-19452-64bit.zip,SqueakV50.sources.zip]&wizard=false] to the latest trunk (very slow because Sista so no JIT): https://squeak.js.org/run/#zip=https://files.squeak.org/6.0alpha/Squeak6.0alpha-20147-32bit/Squeak6.0alpha-20147-32bit.zip [https://squeak.js.org/run/#zip=https://files.squeak.org/6.0alpha/Squeak6.0alpha-20147-32bit/Squeak6.0alpha-20147-32bit.zip] and that even has isLowerPerformance = true because we did fix the platform name check! If it was using your code then the "Time millisecondsToRun:[ 25 benchFib ]" would add 600 ms to the startup. Luckily it would bypass the "Time millisecondsToRun: [ 64 benchmark ]" which would take 4 seconds. So I'm in favor of Levente's idea, he proposed this: | vmStartTime uptime | vmStartTime := Smalltalk vmParameterAt: 20. uptime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur VMs"         ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000]         ifFalse: [Time eventMillisecondClock]. ... which works in SqueakJS because of the eventMillisecondClock fallback (vmParameter 20 is 0). We just would have to decide where in the startup sequence to put this check, which is slightly tricky. An obvious place would be in #recordStartupStamp - I just tried it: recordStartupStamp       | vmStartTime |       vmStartTime := Smalltalk vmParameterAt: 20.       StartupTime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur VMs"             ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000]             ifFalse: [Time eventMillisecondClock].       StartupStamp := '----STARTUP----', Time dateAndTimeNow printString, ' as ', self imageName. ... and StartupTime is about 3000 ms. Gob smacked.  This is embarrassing.  This needs to be a preference.  I don't mind it being on by default.  But I think both STARTUP and QUIT/No SAVE stamps need to be optional.  I for one find it really annoying that QUIT/No SAVE stamps are added when nothing has occurred (a pain if one's image is under version control, for example).  So I find myself using the Mac's Force Quit, or ctrl-c on the command line. Then isLowerPerformance would become       ^StartupTime > LowerPerformanceThreshold where LowerPerformanceThreshold would maybe default to 500? What's the StartupTime of e.g. a raspberry pi?  Vanessa -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Tue Jan 5 10:40:03 2021 From: gettimothy at zoho.com (gettimothy) Date: Tue, 05 Jan 2021 05:40:03 -0500 Subject: [squeak-dev] XTreams XTFileSystemReadingWritingTest >> setUp fails due to FileSystem change (?) Message-ID: <176d221dd6b.f0dd47ef76919.34776683134965456@zoho.com> Hi Folks, /home/wm/usr/src/smalltalk/squeak6.0alpha/shared/Squeak6.0alpha-19802-64bit.image Squeak6.0alpha latest update: #19885 Current Change Set: WikitextParser Image format 68021 (64 bit) XTFileSystemReadingWritingTest >> setup file := FileSystem workingDirectory / (self class name , '-' , testSelector). super setUp. DNU on that "workingDirectory" send. Browsing via monticello, all my local are in sync with the repo. Ideas on how to patch this correctly much appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 10:42:54 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 11:42:54 +0100 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: References: Message-ID: Hi Tim! :-) > So: what is the long term strategy here? After methods are deprecated > and removed from the image, when those methods served the purpose of > compatibility with 3rd party packages and other Smalltalks, is it expected > that each outside package will either (a) maintain its own compatibility > layer, like Grease, or (b) implement the removed methods via class > extensions, thus possibly introducing conflicts? (a), I suppose, which is common for maintaining compatibility with several Smalltalk dialects and versions. Note that clients can turn off deprecation warnings before loading any not-updated package. When, at some point, a certain deprecation package is not in the release (or trunk) anymore, clients can re-load those packages as they remain available through source.squeak.org/trunk Best, Marcel Am 02.01.2021 19:44:49 schrieb Tim Johnson : Hi, First, before the rest of this complain-y message: **Happy 2021 to everybody!** Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale? In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation. Squot: https://github.com/hpi-swa/Squot/issues/266 Seaside: https://github.com/SeasideSt/Seaside/issues/1195 Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature. "To add an accessor method and a mutator method" (2015) https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html See also: "simple accessor and mutator methods" (1998) http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html and: ST/X's asMutator (in protocol 'converting') https://live.exept.de/ClassDoc/classDocOf,CharacterArray So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts? Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Tue Jan 5 10:43:26 2021 From: gettimothy at zoho.com (gettimothy) Date: Tue, 05 Jan 2021 05:43:26 -0500 Subject: [squeak-dev] similar issue in XTMemoryFileSystemReadingWringTest Message-ID: <176d224f53c.ad1dc12d76965.5735163504676736758@zoho.com> setUp fileSystem := FileSystem memory. file := fileSystem workingDirectory / (self class name , '-' , testSelector). super setUp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 11:00:39 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 12:00:39 +0100 Subject: [squeak-dev] Bug in primitivePerform (was: The Inbox: KernelTests-ct.382.mcz) In-Reply-To: References: <2fc7d04d1fea4cbfb1aa7f0663a3f2de@student.hpi.uni-potsdam.de> Message-ID: >  IMO the VM isn't obligated to implement checking for nonsensical definitions.  That would slow the VM down unnecessarily.  Instead one should *never* use primitive 83 in a method that takes no arguments. +1 Best, Marcel Am 02.01.2021 02:39:55 schrieb Eliot Miranda : Hi Christoph, On Fri, Jan 1, 2021 at 11:07 AM Thiede, Christoph wrote: Hi all, please note that primitive 83 is currently crashing the VM (tested with VMMaker.oscog-eem.2850) when called without any arguments, so #testPrimitive83 in the patch below will break the test execution at the moment. However, primitive 84 works well, so to me this looks like a trivial mistake only. Hang on.  When would one include primitive 83 in a method that takes no arguments?  Implementing e.g. Object>>perform     "Invoke the perform primitive with no arguments cuz there's nothing to perform"        self error: 'you don''t say' makes no sense.  IMO the VM isn't obligated to implement checking for nonsensical definitions.  That would slow the VM down unnecessarily.  Instead one should *never* use primitive 843 in a method that takes no arguments. Hence in your simulation tests you can exclude the case where someone tries tryPrimitive: 83 withArguments: #() because it constitutes undefined behaviour and the VM crashing is IMO to be expected. I have (still!) not yet made myself the gift of exploring VMMaker, so I won't be able to fix a patch at the moment. But if someone can solve this, it would be great if you could give me a short pointer to the corresponding VMMaker patch because studying small interesting patches appear as a very nice way to explore an unknown framework to me. :-) Best, Christoph Von: Squeak-dev im Auftrag von commits at source.squeak.org [mailto:commits at source.squeak.org] Gesendet: Freitag, 1. Januar 2021 19:59 Uhr An: squeak-dev at lists.squeakfoundation.org [mailto:squeak-dev at lists.squeakfoundation.org] Betreff: [squeak-dev] The Inbox: KernelTests-ct.382.mcz   Christoph Thiede uploaded a new version of KernelTests to project The Inbox: http://source.squeak.org/inbox/KernelTests-ct.382.mcz [http://source.squeak.org/inbox/KernelTests-ct.382.mcz] ==================== Summary ==================== Name: KernelTests-ct.382 Author: ct Time: 1 January 2021, 7:59:13.17819 pm UUID: 812293dd-db7d-4c03-a33d-8b6f4354d1fa Ancestors: KernelTests-ct.375, KernelTests-tonyg.381 Tests simulation of #perform:... primitives 83, 84, and 100. Complements Kernel-ct.1367. Depends indeed not only on KernelTests-tonyg.381 but also on KernelTests-ct.375, it would be nice if we could get the latter merged soon, this has already been causing too many merge conflicts in the past. :-) =============== Diff against KernelTests-ct.375 =============== Item was added: + ----- Method: ContextTest>>testPrimitive100 (in category 'tests') ----- + testPrimitive100 + +        { +                {#isNil. {}. Object}. "valid 0-arg message" +                {#=. {true}. UndefinedObject}. "valid unary message" +                {#ifNil:ifNotNil:. {[2]. [:x | x]}. Object}. "valid binary message" +                {}. "missing selector" +                {#isNil}. "missing arguments" +                {#isNil. 'not an array'}. "invalid arguments" +                {#isNil. {}}. "missing lookupClass" +                {#isNil. {'excess arg'}. Object}. "too many arguments" +                {#=. {}. UndefinedObject}. "missing argument" +                {#isNil. {}. Boolean}. "lookupClass not in inheritance chain" +        } do: [:args | +                self +                        assert: (Context runSimulated: [nil tryPrimitive: 100 withArgs: args]) +                        equals: (nil tryPrimitive: 100 withArgs: args)].! Item was added: + ----- Method: ContextTest>>testPrimitive83 (in category 'tests') ----- + testPrimitive83 + +        { +                {#isNil}. "valid 0-arg message" +                {#=. true}. "valid unary message" +                {#ifNil:ifNotNil:. [2]. [:x | x]}. "valid binary message" +                {}. "missing selector" +                {#isNil. 'excess arg'}. "too many arguments" +                {#=}. "missing argument" +        } do: [:args | +                self +                        assert: (Context runSimulated: [nil tryPrimitive: 83 withArgs: args]) +                        equals: (nil tryPrimitive: 83 withArgs: args)].! Item was added: + ----- Method: ContextTest>>testPrimitive84 (in category 'tests') ----- + testPrimitive84 + +        { +                {#isNil. {}}. "valid 0-arg message" +                {#=. {true}}. "valid unary message" +                {#ifNil:ifNotNil:. {[2]. [:x | x]}}. "valid binary message" +                {}. "missing selector" +                {#isNil}. "missing arguments" +                {#isNil. 'not an array'}. "invalid arguments" +                {#isNil. {'excess arg'}}. "too many arguments" +                {#=. {}}. "missing argument" +        } do: [:args | +                self +                        assert: (Context runSimulated: [nil tryPrimitive: 84 withArgs: args]) +                        equals: (nil tryPrimitive: 84 withArgs: args)].! -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Tue Jan 5 11:09:26 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue, 5 Jan 2021 12:09:26 +0100 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: References: Message-ID: Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- Narf. -t > On 2. Jan 2021, at 19:44, Tim Johnson wrote: > > Hi, > > First, before the rest of this complain-y message: > > **Happy 2021 to everybody!** > > Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html > > Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale? > > In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation. > > Squot: https://github.com/hpi-swa/Squot/issues/266 > Seaside: https://github.com/SeasideSt/Seaside/issues/1195 > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 > > I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature. > > "To add an accessor method and a mutator method" (2015) > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d > > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html > > See also: "simple accessor and mutator methods" (1998) > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html > > and: ST/X's asMutator (in protocol 'converting') > https://live.exept.de/ClassDoc/classDocOf,CharacterArray > > So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts? > > Thanks, > Tim > > > From marcel.taeumel at hpi.de Tue Jan 5 11:10:44 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 12:10:44 +0100 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: References: Message-ID: >Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- Narf. Well, there is also the idea of "convenience methods" ... #asMutator could be one of those. Not sure how this affects GraphQL. Chris? Best, Marcel Am 05.01.2021 12:09:38 schrieb Tobias Pape : Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- Narf. -t > On 2. Jan 2021, at 19:44, Tim Johnson wrote: > > Hi, > > First, before the rest of this complain-y message: > > **Happy 2021 to everybody!** > > Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html > > Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale? > > In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation. > > Squot: https://github.com/hpi-swa/Squot/issues/266 > Seaside: https://github.com/SeasideSt/Seaside/issues/1195 > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 > > I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature. > > "To add an accessor method and a mutator method" (2015) > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d > > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html > > See also: "simple accessor and mutator methods" (1998) > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html > > and: ST/X's asMutator (in protocol 'converting') > https://live.exept.de/ClassDoc/classDocOf,CharacterArray > > So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts? > > Thanks, > Tim > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Tue Jan 5 11:12:56 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue, 5 Jan 2021 12:12:56 +0100 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: References: Message-ID: <74DDA3D0-E109-440B-A794-415EC59E47D5@gmx.de> > On 5. Jan 2021, at 12:10, Marcel Taeumel wrote: > > >Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- > Narf. > > Well, there is also the idea of "convenience methods" ... #asMutator could be one of those. Tim shows that it is essentially widespread, more than a convenience. lets just put it back… > Not sure how this affects GraphQL. Chris? > > Best, > Marcel >> Am 05.01.2021 12:09:38 schrieb Tobias Pape : >> >> >> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- >> Narf. >> >> -t >> >> > On 2. Jan 2021, at 19:44, Tim Johnson wrote: >> > >> > Hi, >> > >> > First, before the rest of this complain-y message: >> > >> > **Happy 2021 to everybody!** >> > >> > Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here: >> > >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html >> > >> > Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale? >> > >> > In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation. >> > >> > Squot: https://github.com/hpi-swa/Squot/issues/266 >> > Seaside: https://github.com/SeasideSt/Seaside/issues/1195 >> > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator >> > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 >> > >> > I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature. >> > >> > "To add an accessor method and a mutator method" (2015) >> > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d >> > >> > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html >> > >> > See also: "simple accessor and mutator methods" (1998) >> > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html >> > >> > and: ST/X's asMutator (in protocol 'converting') >> > https://live.exept.de/ClassDoc/classDocOf,CharacterArray >> > >> > So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts? >> > >> > Thanks, >> > Tim >> > >> > >> > >> >> >> > From marcel.taeumel at hpi.de Tue Jan 5 11:15:24 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 12:15:24 +0100 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: <74DDA3D0-E109-440B-A794-415EC59E47D5@gmx.de> References: <74DDA3D0-E109-440B-A794-415EC59E47D5@gmx.de> Message-ID: Hi Tobias. > lets just put it back… And adding a test that ensures that the Squeak image will not use it but #asSimpleSetter. Then would make it a "convenience" method. I would avoid supporting the mixed use. Biggest issue with #asMutator is that there is no #asSimpleGetter equivalent. Best, Marcel Am 05.01.2021 12:13:08 schrieb Tobias Pape : > On 5. Jan 2021, at 12:10, Marcel Taeumel wrote: > > >Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- > Narf. > > Well, there is also the idea of "convenience methods" ... #asMutator could be one of those. Tim shows that it is essentially widespread, more than a convenience. lets just put it back… > Not sure how this affects GraphQL. Chris? > > Best, > Marcel >> Am 05.01.2021 12:09:38 schrieb Tobias Pape : >> >> >> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- >> Narf. >> >> -t >> >> > On 2. Jan 2021, at 19:44, Tim Johnson wrote: >> > >> > Hi, >> > >> > First, before the rest of this complain-y message: >> > >> > **Happy 2021 to everybody!** >> > >> > Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here: >> > >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html >> > >> > Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale? >> > >> > In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation. >> > >> > Squot: https://github.com/hpi-swa/Squot/issues/266 >> > Seaside: https://github.com/SeasideSt/Seaside/issues/1195 >> > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator >> > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 >> > >> > I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature. >> > >> > "To add an accessor method and a mutator method" (2015) >> > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d >> > >> > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html >> > >> > See also: "simple accessor and mutator methods" (1998) >> > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html >> > >> > and: ST/X's asMutator (in protocol 'converting') >> > https://live.exept.de/ClassDoc/classDocOf,CharacterArray >> > >> > So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts? >> > >> > Thanks, >> > Tim >> > >> > >> > >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Tue Jan 5 11:55:45 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue, 5 Jan 2021 12:55:45 +0100 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: References: <74DDA3D0-E109-440B-A794-415EC59E47D5@gmx.de> Message-ID: > On 5. Jan 2021, at 12:15, Marcel Taeumel wrote: > > Hi Tobias. > > > lets just put it back… > > And adding a test that ensures that the Squeak image will not use it but #asSimpleSetter. Then would make it a "convenience" method. I would avoid supporting the mixed use. Biggest issue with #asMutator is that there is no #asSimpleGetter equivalent. > so? not everything has to be two-ways xD > Best, > Marcel >> Am 05.01.2021 12:13:08 schrieb Tobias Pape : >> >> >> >> > On 5. Jan 2021, at 12:10, Marcel Taeumel wrote: >> > >> > >Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- >> > Narf. >> > >> > Well, there is also the idea of "convenience methods" ... #asMutator could be one of those. >> >> Tim shows that it is essentially widespread, more than a convenience. >> lets just put it back… >> >> > Not sure how this affects GraphQL. Chris? >> > >> > Best, >> > Marcel >> >> Am 05.01.2021 12:09:38 schrieb Tobias Pape : >> >> >> >> >> >> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- >> >> Narf. >> >> >> >> -t >> >> >> >> > On 2. Jan 2021, at 19:44, Tim Johnson wrote: >> >> > >> >> > Hi, >> >> > >> >> > First, before the rest of this complain-y message: >> >> > >> >> > **Happy 2021 to everybody!** >> >> > >> >> > Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here: >> >> > >> >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html >> >> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html >> >> > >> >> > Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale? >> >> > >> >> > In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation. >> >> > >> >> > Squot: https://github.com/hpi-swa/Squot/issues/266 >> >> > Seaside: https://github.com/SeasideSt/Seaside/issues/1195 >> >> > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator >> >> > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 >> >> > >> >> > I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature. >> >> > >> >> > "To add an accessor method and a mutator method" (2015) >> >> > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d >> >> > >> >> > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html >> >> > >> >> > See also: "simple accessor and mutator methods" (1998) >> >> > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html >> >> > >> >> > and: ST/X's asMutator (in protocol 'converting') >> >> > https://live.exept.de/ClassDoc/classDocOf,CharacterArray >> >> > >> >> > So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts? >> >> > >> >> > Thanks, >> >> > Tim >> >> > >> >> > >> >> > >> >> >> >> >> >> >> > >> >> >> > From gettimothy at zoho.com Tue Jan 5 11:56:07 2021 From: gettimothy at zoho.com (gettimothy) Date: Tue, 05 Jan 2021 06:56:07 -0500 Subject: [squeak-dev] follow up to previous email. work in progress on "terse guide to XTreams Parsing Syntax" cheat sheet. Message-ID: <176d267833a.f23a67dd77658.7030712600930868161@zoho.com> Hi Levente. Regarding my previous letter, I am almost certain that "consume" means a match has been made and eat the string. "Yield" means  "invoke the callback" or "return the section of a AST for that rule. anyhoo, I have been going through your old emails and cross checking with:https://nim-lang.org/docs/pegs.html and have come up with a preliminary "terse guide" to the syntax. I would like to expand this into tests/examples for others to use going forward. Eventually this will make its way to a SqueakBook when/if I get some time. Anyhoo, if you could peruse it and see if anything jumps out at you that is incorrect/incomplete.  Much appreciated. t p.s. I have cc'd squeak-dev in case anybody else finds this interesting. XTreams https://code.google.com/archive/p/xtreams/wikis/Parsing.wiki https://nim-lang.org/docs/pegs.html A  < - E  Rule: Bind the expression  E  to the nonterminal symbol  A . Left recursive rules are not possible and crash the matching engine. \ddd  Character with decimal code ddd \" , etc Literal  " , etc. PEG: Literal <- QUOTE LiteralEntity{QUOTE}/ DOUBLE_QUOTE LiteralEntity{DOUBLE_QUOTE} A ... Z  Sequence: Apply expressions  A , ...,  Z , in this order, to consume consecutive portions of the text ahead, as long as they succeed. Indicate success if all succeeded. Otherwise do not consume any text and indicate failure. The sequence's precedence is higher than that of Ordered Choice:  A B / C  means  (A B) / Z  and not  A (B / Z) . A / ... / Z  Ordered Choice: Apply expressions  A , ...,  Z , in this order, to the text ahead, until one of them succeeds and possibly consumes some text. Indicate success if one of expressions succeeded. Otherwise do not consume any text and indicate failure. The Ordered Choice precedence is lower than that of Sequence:  A B / C  means  (A B) / Z  and not  A (B / Z) . (E)  Grouping: Parenthesis can be used to change operator priority. (A B) / Z  vs.  A (B / Z) . {E}     Cardinality:  Stop Expression A <- B{C} to accept A,  means, accept any number of B up until E comes. Consume E too, but don't yield it. So, such expression accepts: BE, BBE, BBBE, BBBBE, etc, and yields B, BB, BBB, BBBB, etc. A <- B{1,"\n"} means that a A consists of one or more Bs. The parser will  read B's up until "\n" appears on the stream, which is a carriage return character. E? Cardinality: Zero or One  E E*  Cardinality Zero or more: E Apply expression  E  repeatedly to match the text ahead, as long as it succeeds. Consume the matched text (if any). Always indicate success. E* Cardinality: Matches zero or more E. E+ Cardinality: Matches one or more E Apply expression  E  repeatedly to match the text ahead, as long as it succeeds. Consume the matched text (if any) and indicate success if there was at least one match. Otherwise indicate failure. E{m} Cardinality: Matches m repetitions of E. B{3}, which is a shorthand for BBB. B{E} means, accept any number of B up until E comes. Consume E too, but don't yield it. So, such expression accepts: BE, BBE, BBBE, BBBBE, etc, and yields B, BB, BBB, BBBB, etc. E{m,n} Cardinality: Matches from m to n repetitions of E. B{1,3} means B 1 to 3 times, so it accepts B, BB, and BBB. [A-Za-z]+ Cardinality: EXAMPLE: Matches one or more alphabetical characters. $  Anchor: Matches at the end of the input. No character is consumed. Same as  !. . !. = $ Anchor: Matches at the end of the input. No character is consumed. Same as  $ ^  Anchor: Matches at the start of the input. No character is consumed. &E  And predicate: Indicate success if expression  E  matches the text ahead; otherwise indicate failure. Do not consume any text. !E  Not predicate: Indicate failure if expression E matches the text ahead; otherwise indicate success. Do not consume any text. [s]  Character class: If the character ahead appears in the string  s , consume it and indicate success. Otherwise indicate failure. [a-b]  Character range: If the character ahead is one from the range  a  through  b , consume it and indicate success. Otherwise indicate failure. 's'  String: If the text ahead is the string  s , consume it and indicate success. Otherwise indicate failure. .  Any character: If there is a character ahead, consume it and indicate success. Otherwise (that is, at the end of input) indicate failure. "BELOW PROBABLY NOT IN PEG" _  Any Unicode character: If there is an UTF-8 character ahead, consume it and indicate success. Otherwise indicate failure. @E  Search: Shorthand for  (!E .)* E . (Search loop for the pattern  E .) {@} E  Captured Search: Shorthand for  {(!E .)*} E . (Search loop for the pattern  E .) Everything until and exluding  E  is captured. @@ E  Same as  {@} E . \identifier  Built-in macro for a longer expression. $i  Back reference to the  i th capture.  i  counts from 1. i's'  String match ignoring case. y's'  String match ignoring style. v's'  Verbatim string match: Use this to override a global  \i  or  \y  modifier. i$j  String match ignoring case for back reference. y$j  String match ignoring style for back reference. v$j  Verbatim string match for back reference. -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Jan 5 12:09:11 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 5 Jan 2021 12:09:11 0000 Subject: [squeak-dev] The Inbox: Monticello-mt.734.mcz Message-ID: A new version of Monticello was added to project The Inbox: http://source.squeak.org/inbox/Monticello-mt.734.mcz ==================== Summary ==================== Name: Monticello-mt.734 Author: mt Time: 5 January 2021, 1:09:08.981865 pm UUID: 93fdf435-68a1-4ace-a7a9-d9d86fb3118f Ancestors: Monticello-mt.733 Alternative fix for the problem addressed in Monticello-nice.734 =============== Diff against Monticello-mt.733 =============== Item was added: + ----- Method: MCAncestry>>isWorkingAncestry (in category 'testing') ----- + isWorkingAncestry + ^ false! Item was added: + ----- Method: MCVersionHistoryBrowser>>package (in category 'accessing') ----- + package + ^ package! Item was changed: ----- Method: MCVersionHistoryBrowser>>selectedSnapshot (in category 'accessing') ----- selectedSnapshot + ^ self selectedInfo isWorkingAncestry + ifTrue: [self package snapshot] + ifFalse: [self snapshotForInfo: self selectedInfo]! - ^ self snapshotForInfo: self selectedInfo! Item was added: + ----- Method: MCWorkingAncestry>>isWorkingAncestry (in category 'testing') ----- + isWorkingAncestry + ^ true! From marcel.taeumel at hpi.de Tue Jan 5 12:09:48 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 13:09:48 +0100 Subject: [squeak-dev] The Inbox: Monticello-nice.734.mcz In-Reply-To: References: Message-ID: Hi Nicolas. > If you can think of nicer fix, please raise voice. I just put Monticello-mt.734 into the inbox. Please take a look and decide for yourself. :-) Best, Marcel Am 30.12.2020 15:57:30 schrieb commits at source.squeak.org : A new version of Monticello was added to project The Inbox: http://source.squeak.org/inbox/Monticello-nice.734.mcz ==================== Summary ==================== Name: Monticello-nice.734 Author: nice Time: 30 December 2020, 3:57:21.60758 pm UUID: 863f642a-7795-4eb6-aa6b-76a5af3a8504 Ancestors: Monticello-mt.733 Workaround version history browser bug when 'working copy' is selected. The snapshot is searched in repositoryGroup, and logically, none is found. Note that the self selectedInfo isKindOf: MCWorkingCopyAncestry, which does not behave as a regular MCVersionInfo, it does not even answer to versionName... This somehow accelerate the failure thru an ifError: [] handling, but at the end, the selectedSnapshot is still nil which makes the 'view changes from...' menu fail. The workaround is not very nice, it use implicit knowledge that 'working copy' will be at top of list (index = 1). If you can think of nicer fix, please raise voice. =============== Diff against Monticello-mt.733 =============== Item was changed: ----- Method: MCVersionHistoryBrowser>>selectedSnapshot (in category 'accessing') ----- selectedSnapshot + index = 1 ifTrue: [^package snapshot]. ^ self snapshotForInfo: self selectedInfo! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 12:13:13 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 13:13:13 +0100 Subject: [squeak-dev] cannot browse Monticello change from to any of its ancestors In-Reply-To: References: Message-ID: Hi Nicolas. > I do not know if it was broken recently or if it never worked ... Well, I always use the [Changes] button for that same result, never the history browser. See Monticello-mt.734 for an alternative to Monticello-nice.734. Best, Marcel Am 30.12.2020 10:12:13 schrieb Nicolas Cellier : Hi MC experts, when spawning history of a dirty package, then selecting the , then trying to view changes from one of the ancestors via pop up menu, the operation ends up with a 'MessageNotUnderstood: UndefinedObject>>snapshot'. The problem is that: MCWorkingHistoryBrowser>>selectedSnapshot ^ self snapshotForInfo: self selectedInfo will use a MCWorkingCopyAncestry as the selectedInfo... But a MCWorkingCopyAncestry lacks essential messages of a regular MCVersionInfo, like versionName etc... This will cause an Error, caught at upper level, and result in nil (no repository holds the 'working copy', there is no point in searching...). I have no idea how to fix it, presumably we should catch early that we're dealing with 'working copy' and use appropriate snapshot for it... I do not know if it was broken recently or if it never worked, but this is a useful feature when there are several ancestors, so help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.cellier.aka.nice at gmail.com Tue Jan 5 12:17:12 2021 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Tue, 5 Jan 2021 13:17:12 +0100 Subject: [squeak-dev] The Inbox: Monticello-mt.734.mcz In-Reply-To: References: Message-ID: +1, that works. However, some other (sub)instance may pretend being a working copy ancestry, see MCVersionInfo>>name... A great source of head scratching ;) Le mar. 5 janv. 2021 à 13:09, a écrit : > A new version of Monticello was added to project The Inbox: > http://source.squeak.org/inbox/Monticello-mt.734.mcz > > ==================== Summary ==================== > > Name: Monticello-mt.734 > Author: mt > Time: 5 January 2021, 1:09:08.981865 pm > UUID: 93fdf435-68a1-4ace-a7a9-d9d86fb3118f > Ancestors: Monticello-mt.733 > > Alternative fix for the problem addressed in Monticello-nice.734 > > =============== Diff against Monticello-mt.733 =============== > > Item was added: > + ----- Method: MCAncestry>>isWorkingAncestry (in category 'testing') ----- > + isWorkingAncestry > + ^ false! > > Item was added: > + ----- Method: MCVersionHistoryBrowser>>package (in category 'accessing') > ----- > + package > + ^ package! > > Item was changed: > ----- Method: MCVersionHistoryBrowser>>selectedSnapshot (in category > 'accessing') ----- > selectedSnapshot > + ^ self selectedInfo isWorkingAncestry > + ifTrue: [self package snapshot] > + ifFalse: [self snapshotForInfo: self selectedInfo]! > - ^ self snapshotForInfo: self selectedInfo! > > Item was added: > + ----- Method: MCWorkingAncestry>>isWorkingAncestry (in category > 'testing') ----- > + isWorkingAncestry > + ^ true! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 12:17:50 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 13:17:50 +0100 Subject: [squeak-dev] The Inbox: System-dtl.1209.mcz In-Reply-To: References: Message-ID: Hi Dave. > Provide vmParameterAt:default: to handle primitive failure on reading VM parameters. Hmm... #vmParameterAt:ifAbsent: would be "more idiomatic"? Best, Marcel Am 28.12.2020 16:50:22 schrieb commits at source.squeak.org : David T. Lewis uploaded a new version of System to project The Inbox: http://source.squeak.org/inbox/System-dtl.1209.mcz ==================== Summary ==================== Name: System-dtl.1209 Author: dtl Time: 28 December 2020, 10:50:06.875257 am UUID: 25efba24-561f-4c53-97d9-95438edfce90 Ancestors: System-eem.1207 Provide vmParameterAt:default: to handle primitive failure on reading VM parameters. Supply default parameter values to mock possibly missing elements in the parameters array. Remove two unnecessary isRunningCog checks and an ifNotNil: Remove inappropriate halt in sendMouseWheelEvents: Let supportsMultipleBytecodeSets and supportsReadOnlyObjects work on any VM. =============== Diff against System-eem.1207 =============== Item was changed: ----- Method: SmalltalkImage>>isRunningCog (in category 'system attributes') ----- isRunningCog "Answers if we're running on a Cog VM (JIT or StackInterpreter)" + ^(self vmParameterAt: 42 default: nil) - ^(self vmParameterAt: 42) ifNil: [false] ifNotNil: [:numStackPages| numStackPages > 0]! Item was changed: ----- Method: SmalltalkImage>>isRunningCogit (in category 'system attributes') ----- isRunningCogit "Answers if we're running on the Cog JIT" + ^(self vmParameterAt: 46 default: nil) - ^(self vmParameterAt: 46) ifNil: [false] ifNotNil: [:machineCodeZoneSize| machineCodeZoneSize > 0]! Item was changed: ----- Method: SmalltalkImage>>lowSpaceThreshold (in category 'memory space') ----- lowSpaceThreshold "Answer the low space threshold. When the amount of free memory (after garbage collection) falls below this limit, the system is in serious danger of completely exhausting memory and crashing. This limit should be made high enough to allow the user open a debugger to diagnose a problem or to save the image. In a stack-based VM such as Cog contexts for activations in the stack zone will have to be created as the debugger opens, requiring additional headroom." | slotsForDebugger slotsForContextsOnStackPages | slotsForDebugger := 65536. "Arbitrary guess" slotsForContextsOnStackPages := + (self vmParameterAt: 42 default: nil) - (self vmParameterAt: 42) ifNil: [0] ifNotNil: [:numStackPages| | headerSize numActivationsPerPage maxContextSize | numActivationsPerPage := 40. "Design goal of the Cog & Stack VMs" headerSize := 8 / self wordSize. "64-bits for Spur" maxContextSize := thisContext class instSize + CompiledMethod fullFrameSize + headerSize. numStackPages * numActivationsPerPage * maxContextSize]. ^slotsForDebugger + slotsForContextsOnStackPages * self wordSize! Item was changed: ----- Method: SmalltalkImage>>maxExternalSemaphores (in category 'vm parameters') ----- maxExternalSemaphores + "The size of table where external semaphores are registered. Only in Cog, + other VMs are expected to answer nil if present in the parameters array." + ^self vmParameterAt: 49 default: nil! - "The size of table where external semaphores are registered. Only in Cog" - self isRunningCog ifFalse: [^nil]. - ^self vmParameterAt: 49! Item was changed: ----- Method: SmalltalkImage>>maxExternalSemaphores: (in category 'vm parameters') ----- maxExternalSemaphores: aSize "Changes the size of table where external semaphores are registered. The size can only grow, and will always be the next power of two larger than the parameter. Setting this at any time other than start-up can potentially lose requests. i.e. during the realloc new storage is allocated, the old contents are copied and then pointers are switched. Requests occurring during copying won't be seen if they occur to indices already copied. The intended use is to set the table to some adequate maximum at start-up" - self isRunningCog ifFalse: [^0]. "The vm-header field is a short, maximum 64k entries. Well, on most platforms anyways " (aSize 16rFFFF]) ifTrue: [^self error: 'maxExternalSemaphores: is limited to 16rFFFF']. + ^[self vmParameterAt: 49 put: aSize] on: Error do: [0].! - ^self vmParameterAt: 49 put: aSize! Item was changed: ----- Method: SmalltalkImage>>processPreemptionYields (in category 'system attributes') ----- processPreemptionYields "Answer whether the VM causes a process to yield on process preemption, i.e. to put a preempted process at the back of its run queue. If the parameter is unavailable (non-Cog VMs) or bit 2 (4) is 0 then preemption yields." + ^((self vmParameterAt: 48 default: [^true]) allMask: 4) not + ! - ^(([self vmParameterAt: 48] - on: Error - do: [:ex| ^true]) allMask: 4) not! Item was changed: ----- Method: SmalltalkImage>>sendMouseWheelEvents (in category 'system attributes') ----- sendMouseWheelEvents "The Cog VM can be instructed to deliver mouse wheel events as mouse wheel events. By default mouse wheel events are mapped to arrow events. This flag persists across snapshots, stored in the image header." + ^(self vmParameterAt: 48 default: 0) anyMask: 32! - ^(self vmParameterAt: 48) anyMask: 32! Item was changed: ----- Method: SmalltalkImage>>supportsMultipleBytecodeSets (in category 'system attributes') ----- supportsMultipleBytecodeSets "Answer whether the VM supports multiple bytecodeSets." "SmalltalkImage current supportsMultipleBytecodeSets" + ^(self vmParameterAt: 65 default: nil) - ^(self vmParameterAt: 65) ifNil: [false] ifNotNil: [:param| "In older VMs this is a boolean answering the vm-internal MULTIPLE_BYTECODE_SETS define" param isInteger "In newer VMs it is a set of integer flags, bit 0 of which is the vm-internal MULTIPLE_BYTECODE_SETS define" ifTrue: [param anyMask: 1] ifFalse: [param]]! Item was changed: ----- Method: SmalltalkImage>>supportsQueueingFinalization (in category 'system attributes') ----- supportsQueueingFinalization "Answer whether the VM queues individual weak arrays for finalization, instead of signalling the finalization semaphore once for all arrays and having the WeakRegistry mechanism finalize all weak arrays, whether they need to or not." "SmalltalkImage current supportsQueueingFinalization" + ^(self vmParameterAt: 48 default: 0) anyMask: 16! - ^(self vmParameterAt: 48) anyMask: 16! Item was changed: ----- Method: SmalltalkImage>>supportsReadOnlyObjects (in category 'system attributes') ----- supportsReadOnlyObjects "Answer whether the VM observes the per-object read-only flag and consequently aborts writes to inst vars of, and fails primitives that attempt to modify, read-only objects." "SmalltalkImage current supportsReadOnlyObjects" + ^(self vmParameterAt: 65 default: nil) - ^(self vmParameterAt: 65) ifNil: [false] ifNotNil: [:param| "In older VMs this is a boolean answering the vm-internal MULTIPLE_BYTECODE_SETS define" param isInteger "In newer VMs it is a set of integer flags, bit 1 of which is the vm-internal IMMUTABILITY define" ifTrue: [param anyMask: 2] ifFalse: [false]]! Item was added: + ----- Method: SmalltalkImage>>vmParameterAt:default: (in category 'vm parameters') ----- + vmParameterAt: parameterIndex default: defaultValueOrBlock + "Answer a VM parameter or defaultValueOrBlock value if out of range." + + ^defaultValueOrBlock value! Item was changed: ----- Method: SmalltalkImage>>wordSize (in category 'image') ----- wordSize "Answer the size in bytes of an object pointer or word in the object memory. The value does not change for a given image, but may be modified by a SystemTracer when converting the image to another format. The value is cached in WordSize to avoid the performance overhead of repeatedly consulting the VM." "Smalltalk wordSize" + ^ WordSize ifNil: [WordSize := self vmParameterAt: 40 default: 4]! - ^ WordSize ifNil: [WordSize := [self vmParameterAt: 40] on: Error do: [4]]! -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Jan 5 12:23:14 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 5 Jan 2021 12:23:14 0000 Subject: [squeak-dev] The Inbox: Monticello-mt.735.mcz Message-ID: A new version of Monticello was added to project The Inbox: http://source.squeak.org/inbox/Monticello-mt.735.mcz ==================== Summary ==================== Name: Monticello-mt.735 Author: mt Time: 5 January 2021, 1:23:12.398865 pm UUID: b2a82046-9f24-4838-896b-6f669aa8a65d Ancestors: Monticello-mt.734 Consider version infos being working copies "in disguise" :-) =============== Diff against Monticello-mt.734 =============== Item was changed: ----- Method: MCAncestry>>isWorkingAncestry (in category 'testing') ----- isWorkingAncestry + + ^ self name = self nameForWorkingCopy! - ^ false! Item was added: + ----- Method: MCAncestry>>nameForWorkingCopy (in category 'ancestry') ----- + nameForWorkingCopy + + ^ ''! Item was changed: ----- Method: MCVersionInfo>>name (in category 'accessing') ----- name + ^ name ifNil: [self nameForWorkingCopy]! - ^ name ifNil: ['']! Item was changed: ----- Method: MCWorkingAncestry>>name (in category 'testing') ----- name + ^ self nameForWorkingCopy! - ^ ''! From marcel.taeumel at hpi.de Tue Jan 5 12:24:11 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 13:24:11 +0100 Subject: [squeak-dev] The Inbox: Monticello-mt.734.mcz In-Reply-To: References: Message-ID: Hi Nicolas. See Monticello-mt.735 :-) I think that this is just old code. Maybe MCVersionInfo was reused in that way before MCWorkingAncestry got added. Best, Marcel Am 05.01.2021 13:17:33 schrieb Nicolas Cellier : +1, that works. However, some other (sub)instance may pretend being a working copy ancestry, see MCVersionInfo>>name... A great source of head scratching ;) Le mar. 5 janv. 2021 à 13:09, a écrit : A new version of Monticello was added to project The Inbox: http://source.squeak.org/inbox/Monticello-mt.734.mcz [http://source.squeak.org/inbox/Monticello-mt.734.mcz] ==================== Summary ==================== Name: Monticello-mt.734 Author: mt Time: 5 January 2021, 1:09:08.981865 pm UUID: 93fdf435-68a1-4ace-a7a9-d9d86fb3118f Ancestors: Monticello-mt.733 Alternative fix for the problem addressed in Monticello-nice.734 =============== Diff against Monticello-mt.733 =============== Item was added: + ----- Method: MCAncestry>>isWorkingAncestry (in category 'testing') ----- + isWorkingAncestry +       ^ false! Item was added: + ----- Method: MCVersionHistoryBrowser>>package (in category 'accessing') ----- + package +       ^ package! Item was changed:   ----- Method: MCVersionHistoryBrowser>>selectedSnapshot (in category 'accessing') -----   selectedSnapshot +       ^ self selectedInfo isWorkingAncestry +               ifTrue: [self package snapshot] +               ifFalse: [self snapshotForInfo: self selectedInfo]! -       ^ self snapshotForInfo: self selectedInfo! Item was added: + ----- Method: MCWorkingAncestry>>isWorkingAncestry (in category 'testing') ----- + isWorkingAncestry +       ^ true! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 12:25:36 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 13:25:36 +0100 Subject: [squeak-dev] The Inbox: Monticello-mt.734.mcz In-Reply-To: References: Message-ID: MCVersionInfo >> #name originated in 7/11/2003 MCWorkingAncestry >> #name origintaed in 2/13/2004 Best, Marcel Am 05.01.2021 13:24:11 schrieb Marcel Taeumel : Hi Nicolas. See Monticello-mt.735 :-) I think that this is just old code. Maybe MCVersionInfo was reused in that way before MCWorkingAncestry got added. Best, Marcel Am 05.01.2021 13:17:33 schrieb Nicolas Cellier : +1, that works. However, some other (sub)instance may pretend being a working copy ancestry, see MCVersionInfo>>name... A great source of head scratching ;) Le mar. 5 janv. 2021 à 13:09, a écrit : A new version of Monticello was added to project The Inbox: http://source.squeak.org/inbox/Monticello-mt.734.mcz [http://source.squeak.org/inbox/Monticello-mt.734.mcz] ==================== Summary ==================== Name: Monticello-mt.734 Author: mt Time: 5 January 2021, 1:09:08.981865 pm UUID: 93fdf435-68a1-4ace-a7a9-d9d86fb3118f Ancestors: Monticello-mt.733 Alternative fix for the problem addressed in Monticello-nice.734 =============== Diff against Monticello-mt.733 =============== Item was added: + ----- Method: MCAncestry>>isWorkingAncestry (in category 'testing') ----- + isWorkingAncestry +       ^ false! Item was added: + ----- Method: MCVersionHistoryBrowser>>package (in category 'accessing') ----- + package +       ^ package! Item was changed:   ----- Method: MCVersionHistoryBrowser>>selectedSnapshot (in category 'accessing') -----   selectedSnapshot +       ^ self selectedInfo isWorkingAncestry +               ifTrue: [self package snapshot] +               ifFalse: [self snapshotForInfo: self selectedInfo]! -       ^ self snapshotForInfo: self selectedInfo! Item was added: + ----- Method: MCWorkingAncestry>>isWorkingAncestry (in category 'testing') ----- + isWorkingAncestry +       ^ true! -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Tue Jan 5 12:30:14 2021 From: gettimothy at zoho.com (gettimothy) Date: Tue, 05 Jan 2021 07:30:14 -0500 Subject: [squeak-dev] multitasking now available in Squeak6.0? Message-ID: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> Hi folks, I just updated my Squeak6.0 and on a whim I am running all the tests to see what happens. Interestingly, while the tests are running (and no information/progress bar popup is in place) I clicked on the World and the World menu popped up. Is squeak now able to multi-task? cheers, t -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 12:33:32 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 13:33:32 +0100 Subject: [squeak-dev] multitasking now available in Squeak6.0? In-Reply-To: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> References: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> Message-ID: Hi Timothy. > Is squeak now able to multi-task? No, but some tests do process all pending user-input events from Morphic but just wanting to process the deferred UI messages ... or trigger a redrawing or something like that. Just the usual "multi-tasking illusion" ^__^ Best, Marcel Am 05.01.2021 13:30:26 schrieb gettimothy via Squeak-dev : Hi folks, I just updated my Squeak6.0 and on a whim I am running all the tests to see what happens. Interestingly, while the tests are running (and no information/progress bar popup is in place) I clicked on the World and the World menu popped up. Is squeak now able to multi-task? cheers, t -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Tue Jan 5 14:25:49 2021 From: gettimothy at zoho.com (gettimothy) Date: Tue, 05 Jan 2021 09:25:49 -0500 Subject: [squeak-dev] multitasking now available in Squeak6.0? In-Reply-To: References: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> Message-ID: <176d2f08f14.d2d7a27b79360.8094089263564030730@zoho.com> heh.... I came back to the image after the tests had run and I have 4 "images" running simultaneously! David T. Lewis.... my first thought is your OSProcess thing (which I have not tried out yet) that let's us spawn multiple images. BTW, I hope someday I can run Squeak and have all the tools available as typical X windows apps. cheers. t ---- On Tue, 05 Jan 2021 07:33:32 -0500 Marcel Taeumel wrote ---- Hi Timothy. > Is squeak now able to multi-task? No, but some tests do process all pending user-input events from Morphic but just wanting to process the deferred UI messages ... or trigger a redrawing or something like that. Just the usual "multi-tasking illusion" ^__^ Best, Marcel Am 05.01.2021 13:30:26 schrieb gettimothy via Squeak-dev : Hi folks, I just updated my Squeak6.0 and on a whim I am running all the tests to see what happens. Interestingly, while the tests are running (and no information/progress bar popup is in place) I clicked on the World and the World menu popped up. Is squeak now able to multi-task? cheers, t -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 14:33:59 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 15:33:59 +0100 Subject: [squeak-dev] multitasking now available in Squeak6.0? In-Reply-To: <176d2f08f14.d2d7a27b79360.8094089263564030730@zoho.com> References: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> <176d2f08f14.d2d7a27b79360.8094089263564030730@zoho.com> Message-ID: Hi Timothy. OSProcess allows you to fork the running VM process with the image from within the image -- at least on Unix-based platforms. So you can easily run all tests "in background" with dedicated OS threads. The result can be communicated back to the "main" image via inter-process communication, which OSProcess also provides. > BTW, I hope someday I can run Squeak and have all the tools available as typical X windows apps. There is already the HostWindowPlugin, which enables users to spawn new host windows -- but Morphic is not able to make good use of it at the moment. Its big central world is too monolithic at the moment. I have some ideas on how to split that up and -- for example -- assign morphs within a world to various host windows. Such morphs could the SystemWindows or just those window's contents. ... not breaking the powerful halo-inspection mechanics, of course. ;-) Best, Marcel Am 05.01.2021 15:25:55 schrieb gettimothy : heh.... I came back to the image after the tests had run and I have 4 "images" running simultaneously! David T. Lewis.... my first thought is your OSProcess thing (which I have not tried out yet) that let's us spawn multiple images. BTW, I hope someday I can run Squeak and have all the tools available as typical X windows apps. cheers. t ---- On Tue, 05 Jan 2021 07:33:32 -0500 Marcel Taeumel wrote ---- Hi Timothy. > Is squeak now able to multi-task? No, but some tests do process all pending user-input events from Morphic but just wanting to process the deferred UI messages ... or trigger a redrawing or something like that. Just the usual "multi-tasking illusion" ^__^ Best, Marcel Am 05.01.2021 13:30:26 schrieb gettimothy via Squeak-dev : Hi folks, I just updated my Squeak6.0 and on a whim I am running all the tests to see what happens. Interestingly, while the tests are running (and no information/progress bar popup is in place) I clicked on the World and the World menu popped up. Is squeak now able to multi-task? cheers, t -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Tue Jan 5 14:35:06 2021 From: gettimothy at zoho.com (gettimothy) Date: Tue, 05 Jan 2021 09:35:06 -0500 Subject: [squeak-dev] multitasking now available in Squeak6.0? In-Reply-To: References: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> Message-ID: <176d2f90dbb.fc6d9c4679485.9161327966914032894@zoho.com> here is the screenshot... ---- On Tue, 05 Jan 2021 07:33:32 -0500 Marcel Taeumel wrote ---- Hi Timothy. > Is squeak now able to multi-task? No, but some tests do process all pending user-input events from Morphic but just wanting to process the deferred UI messages ... or trigger a redrawing or something like that. Just the usual "multi-tasking illusion" ^__^ Best, Marcel Am 05.01.2021 13:30:26 schrieb gettimothy via Squeak-dev : Hi folks, I just updated my Squeak6.0 and on a whim I am running all the tests to see what happens. Interestingly, while the tests are running (and no information/progress bar popup is in place) I clicked on the World and the World menu popped up. Is squeak now able to multi-task? cheers, t -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MegaMultiSuperSqueak.png Type: image/png Size: 1339478 bytes Desc: not available URL: From herbertkoenig at gmx.net Tue Jan 5 15:00:57 2021 From: herbertkoenig at gmx.net (Herbert) Date: Tue, 5 Jan 2021 16:00:57 +0100 Subject: [squeak-dev] multitasking now available in Squeak6.0? In-Reply-To: References: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> <176d2f08f14.d2d7a27b79360.8094089263564030730@zoho.com> Message-ID: <7f7fbe4c-3ba4-f8f0-bb8e-7f8c982432d0@gmx.net> Hi Marcel, Am 05.01.21 um 15:33 schrieb Marcel Taeumel: > > There is already the HostWindowPlugin, which enables users to spawn > new host windows -- but Morphic is not able to make good use of it at > the moment. Its big central world is too monolithic at the moment. I > have some ideas on how to split that up and -- for example -- assign > morphs within a world to various host windows. Such morphs could the > SystemWindows or just those window's contents. ... not breaking the > powerful halo-inspection mechanics, of course. ;-) > What happens, in that scenario when I switch projects? Would be cool, if I could have one host window from the previous project still open, while working in the current project. Would be uncool if it hinders the use of projects. I think this would need a lot of thought. Changes in a host window spawned from an inactive project? Or just close all host windows when leaving a project? Auto spawn all associated host windows on project entry? Change project only in the main host window? Or each host window = a project? (I'd like this!) Cheers, Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 15:10:07 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 16:10:07 +0100 Subject: [squeak-dev] multitasking now available in Squeak6.0? In-Reply-To: <7f7fbe4c-3ba4-f8f0-bb8e-7f8c982432d0@gmx.net> References: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> <176d2f08f14.d2d7a27b79360.8094089263564030730@zoho.com> <7f7fbe4c-3ba4-f8f0-bb8e-7f8c982432d0@gmx.net> Message-ID: Hi Herbert. > What happens, in that scenario when I switch projects? Well, Morphic projects cannot yet run in the background. This would imply undefined behavior for host windows, too, if not closed upon switching projects. :-)  Well, if you would want to keep those host windows open, there is no need to work with multiple Squeak/Morphic projects anymore since you could organize your open tools with host windows in the host environment and rely on the support of multiple desktops in that host environment. Makes sense?  ... of course, this would pull out valuable information of your current work state out of the image into the host environment. Save & quit could be tricky. Hmm... Not sure whether the position of a host window can be restored to fill those virtual host desktops again. Best, Marcel Am 05.01.2021 16:01:10 schrieb Herbert : Hi Marcel, Am 05.01.21 um 15:33 schrieb Marcel Taeumel: There is already the HostWindowPlugin, which enables users to spawn new host windows -- but Morphic is not able to make good use of it at the moment. Its big central world is too monolithic at the moment. I have some ideas on how to split that up and -- for example -- assign morphs within a world to various host windows. Such morphs could the SystemWindows or just those window's contents. ... not breaking the powerful halo-inspection mechanics, of course. ;-) What happens, in that scenario when I switch projects? Would be cool, if I could have one host window from the previous project still open, while working in the current project. Would be uncool if it hinders the use of projects. I think this would need a lot of thought. Changes in a host window spawned from an inactive project? Or just close all host windows when leaving a project? Auto spawn all associated host windows on project entry? Change project only in the main host window? Or each host window = a project? (I'd like this!) Cheers, Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From herbertkoenig at gmx.net Tue Jan 5 15:21:34 2021 From: herbertkoenig at gmx.net (Herbert) Date: Tue, 5 Jan 2021 16:21:34 +0100 Subject: [squeak-dev] multitasking now available in Squeak6.0? In-Reply-To: References: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> <176d2f08f14.d2d7a27b79360.8094089263564030730@zoho.com> <7f7fbe4c-3ba4-f8f0-bb8e-7f8c982432d0@gmx.net> Message-ID: <89aaba72-1af1-f298-421c-482a1d258719@gmx.net> Hi Marcel, I have projects with documentation (objects from the object catalog, some of them half alive). Projects are very important to me and you mentioned you want to keep halos functional. If host windows = IDE only that's a big step back imo. Unless a host window is just a project and clicking just does 'jump to project' in Squeak. Cheers, Herbert Am 05.01.21 um 16:10 schrieb Marcel Taeumel: > Hi Herbert. > > > What happens, in that scenario when I switch projects? > > Well, Morphic projects cannot yet run in the background. This would > imply undefined behavior for host windows, too, if not closed upon > switching projects. :-) > > Well, if you would want to keep those host windows open, there is no > need to work with multiple Squeak/Morphic projects anymore since you > could organize your open tools with host windows in the host > environment and rely on the support of multiple desktops in that host > environment. Makes sense?  ... of course, this would pull out valuable > information of your current work state out of the image into the host > environment. Save & quit could be tricky. Hmm... Not sure whether the > position of a host window can be restored to fill those virtual host > desktops again. > > Best, > Marcel >> >> Am 05.01.2021 16:01:10 schrieb Herbert : >> >> Hi Marcel, >> >> >> Am 05.01.21 um 15:33 schrieb Marcel Taeumel: >>> >>> There is already the HostWindowPlugin, which enables users to spawn >>> new host windows -- but Morphic is not able to make good use of it >>> at the moment. Its big central world is too monolithic at the >>> moment. I have some ideas on how to split that up and -- for example >>> -- assign morphs within a world to various host windows. Such morphs >>> could the SystemWindows or just those window's contents. ... not >>> breaking the powerful halo-inspection mechanics, of course. ;-) >>> >> What happens, in that scenario when I switch projects? Would be cool, >> if I could have one host window from the previous project still open, >> while working in the current project. Would be uncool if it hinders >> the use of projects. >> >> I think this would need a lot of thought. Changes in a host window >> spawned from an inactive project? Or just close all host windows when >> leaving a project? Auto spawn all associated host windows on project >> entry? Change project only in the main host window? Or each host >> window = a project? (I'd like this!) >> >> Cheers, >> >> >> Herbert >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 5 15:25:09 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 5 Jan 2021 16:25:09 +0100 Subject: [squeak-dev] multitasking now available in Squeak6.0? In-Reply-To: <89aaba72-1af1-f298-421c-482a1d258719@gmx.net> References: <176d286be2f.f08b655177969.1505627131050081329@zoho.com> <176d2f08f14.d2d7a27b79360.8094089263564030730@zoho.com> <7f7fbe4c-3ba4-f8f0-bb8e-7f8c982432d0@gmx.net> <89aaba72-1af1-f298-421c-482a1d258719@gmx.net> Message-ID: Hi Herbert. This is just shallow brainstorming. :-) > I have projects with documentation (objects from the object catalog, some of them half alive). Those could be integrated into any existing project and then "packaged" into a host window. But I am talking implementation detail here.  Of course, projects should keep on working. They are useful to organize pieces of information in the image. Best, Marcel Am 05.01.2021 16:21:45 schrieb Herbert : Hi Marcel, I have projects with documentation (objects from the object catalog, some of them half alive). Projects are very important to me and you mentioned you want to keep halos functional. If host windows = IDE only that's a big step back imo. Unless a host window is just a project and clicking just does 'jump to project' in Squeak. Cheers, Herbert Am 05.01.21 um 16:10 schrieb Marcel Taeumel: Hi Herbert. > What happens, in that scenario when I switch projects? Well, Morphic projects cannot yet run in the background. This would imply undefined behavior for host windows, too, if not closed upon switching projects. :-)  Well, if you would want to keep those host windows open, there is no need to work with multiple Squeak/Morphic projects anymore since you could organize your open tools with host windows in the host environment and rely on the support of multiple desktops in that host environment. Makes sense?  ... of course, this would pull out valuable information of your current work state out of the image into the host environment. Save & quit could be tricky. Hmm... Not sure whether the position of a host window can be restored to fill those virtual host desktops again. Best, Marcel Am 05.01.2021 16:01:10 schrieb Herbert [mailto:herbertkoenig at gmx.net]: Hi Marcel, Am 05.01.21 um 15:33 schrieb Marcel Taeumel: There is already the HostWindowPlugin, which enables users to spawn new host windows -- but Morphic is not able to make good use of it at the moment. Its big central world is too monolithic at the moment. I have some ideas on how to split that up and -- for example -- assign morphs within a world to various host windows. Such morphs could the SystemWindows or just those window's contents. ... not breaking the powerful halo-inspection mechanics, of course. ;-) What happens, in that scenario when I switch projects? Would be cool, if I could have one host window from the previous project still open, while working in the current project. Would be uncool if it hinders the use of projects. I think this would need a lot of thought. Changes in a host window spawned from an inactive project? Or just close all host windows when leaving a project? Auto spawn all associated host windows on project entry? Change project only in the main host window? Or each host window = a project? (I'd like this!) Cheers, Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Tue Jan 5 16:28:54 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Tue, 5 Jan 2021 11:28:54 -0500 Subject: [squeak-dev] [Vm-dev] The Trunk: System-codefrau.1205.mcz In-Reply-To: References: <20210102164139.GA73785@shell.msen.com> <72890B34-07D6-4408-9691-0F328854DE43@gmail.com> <20210102195649.GA3733@shell.msen.com> <20210103161143.GA96454@shell.msen.com> Message-ID: <20210105162854.GA70441@shell.msen.com> On Tue, Jan 05, 2021 at 09:58:22AM +0100, Marcel Taeumel wrote: > Hi all! > > At the time of writing, the wizard has a hard-coded list of somewhat costly preferences to turn off via #adjustSettingsForLowPerformance. We should check and update that list from time to time. > > The check for #isLowerPerformance may also be useful outside the scope of preferences. Well, maybe we can make it check the *remaining* resources for new workload to come. That is, there may already be a Squeak process eating up 99% of the image's resources. Then, any call to #isLowerPerformance should answer "true", of course. Even though we might be on a powerful machine. The current workload matters for the upcoming operations. > > Note that the current workload is expected to be low at image-startup time. ;-) So, somehow deriving a performance figure at that time makes sense to me. > > Here is a summary of your suggestions: > > A) Estimate processor mips from platform specs > + eem > o mt > > B) Take extra measurement via #timeToRun when checking #isLowerPerformance, may be cached > + dtl > + tpr > o codefrau > - eem?? > - mt > > C) Profile image start-up via VM parameter 20 or similarly cheap timestamps > + ul > + codefrau > + eem > + dtl > + mt > > All in all, we should follow up on Levente's suggestion. > +1 for using Levente's approach Dave From ron at usmedrec.com Tue Jan 5 16:58:46 2021 From: ron at usmedrec.com (Ron Teitelbaum) Date: Tue, 5 Jan 2021 11:58:46 -0500 Subject: [squeak-dev] [Vm-dev] some stupid failures In-Reply-To: References: Message-ID: Seems like more of a warning and not a failure. All the best, Ron Teitelbaum On Tue, Jan 5, 2021 at 3:22 AM Marcel Taeumel wrote: > Hi Nicolas. > > > Do we really want to keep this kind of test? > > Such benchmarks (and benchmark-like tests) should at least average over > several runs and only fail as a test if something actually got slower on > average. Or something like that. A single misbehaving run should not be the > reason for such a test failure. > > Maybe we can tweak #should:notTakeMoreThan: to evaluate the block several > times? But then it cannot fail early on as it is doing now ... Hmmm... > > Best, > Marcel > > Am 05.01.2021 09:08:46 schrieb Nicolas Cellier < > nicolas.cellier.aka.nice at gmail.com>: > > Hi all, > sometimes, some build fail for just 1 test... > > Here > https://travis-ci.com/github/OpenSmalltalk/opensmalltalk-vm/jobs/468407844 > a squeak.stack.v3 > > RenderBugz > ✗ #testSetForward (7ms) > TestFailure: Block evaluation took more than the expected 0:00:00:00.004 > RenderBugz(TestCase)>>assert:description: > RenderBugz(TestCase)>>should:notTakeMoreThan: > RenderBugz(TestCase)>>should:notTakeMoreThanMilliseconds: > RenderBugz>>shouldntTakeLong: > RenderBugz>>testSetForward ...shouldntTakeLong: [ t forwardDirection: > 180.0 . > self assert: ( t forwardDirection = 0.0 ) ] > RenderBugz(TestCase)>>performTest > > 4ms, really? On C.I. infrastructure, anything can happen... > Do we really want to keep this kind of test? > We eventually could once startup performance is known (see > isLowerPerformance discussion on squeak-dev), but in the interim, I > suggest we neutralize this specific test in Smalltalk-CI. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Tue Jan 5 17:01:54 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue, 5 Jan 2021 09:01:54 -0800 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: <74DDA3D0-E109-440B-A794-415EC59E47D5@gmx.de> References: <74DDA3D0-E109-440B-A794-415EC59E47D5@gmx.de> Message-ID: <7D834606-8837-4F82-83BC-BE396E600A5B@gmail.com> > On Jan 5, 2021, at 3:13 AM, Tobias Pape wrote: > >  > >>> On 5. Jan 2021, at 12:10, Marcel Taeumel wrote: >>> >>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- >> Narf. >> >> Well, there is also the idea of "convenience methods" ... #asMutator could be one of those. > > Tim shows that it is essentially widespread, more than a convenience. > lets just put it back… +1 > >> Not sure how this affects GraphQL. Chris? >> >> Best, >> Marcel >>> Am 05.01.2021 12:09:38 schrieb Tobias Pape : >>> >>> >>> Had I known the widespread understanding of #asMutator, I had objected more strongly against its removal -.- >>> Narf. >>> >>> -t >>> >>>> On 2. Jan 2021, at 19:44, Tim Johnson wrote: >>>> >>>> Hi, >>>> >>>> First, before the rest of this complain-y message: >>>> >>>> **Happy 2021 to everybody!** >>>> >>>> Now to shamefully bring up a closed matter: in 2019 there was some discussion on the mailing list that led to the deprecation of #asMutator. Some portions of the discussion can be seen here: >>>> >>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html >>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html >>>> >>>> Part of the argument was that "asMutator" and the notion of "mutators" was not seen elsewhere in the image, and that it conflicted with work someone was doing with GraphQL (?) which has its own notion of "mutators". Was there other rationale? >>>> >>>> In the meantime, various teams and projects will have to adapt their code. And, users have been coping with various packages not loading seamlessly in Squeak 5.3 due to this deprecation. >>>> >>>> Squot: https://github.com/hpi-swa/Squot/issues/266 >>>> Seaside: https://github.com/SeasideSt/Seaside/issues/1195 >>>> Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator >>>> HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 >>>> >>>> I'm sorry for bringing up a settled matter, and for grandstanding a bit ("at what price progress?"), but: was #asMutator deprecated because of the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, I (respectfully) have a hard time accepting part of that argument. A quick Google search turns up much literature. >>>> >>>> "To add an accessor method and a mutator method" (2015) >>>> https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d >>>> >>>> ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" (2007) https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html >>>> >>>> See also: "simple accessor and mutator methods" (1998) >>>> http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html >>>> >>>> and: ST/X's asMutator (in protocol 'converting') >>>> https://live.exept.de/ClassDoc/classDocOf,CharacterArray >>>> >>>> So: what is the long term strategy here? After methods are deprecated and removed from the image, when those methods served the purpose of compatibility with 3rd party packages and other Smalltalks, is it expected that each outside package will either (a) maintain its own compatibility layer, like Grease, or (b) implement the removed methods via class extensions, thus possibly introducing conflicts? >>>> >>>> Thanks, >>>> Tim >>>> >>>> >>>> >>> >>> >>> >> > > > From eliot.miranda at gmail.com Tue Jan 5 17:06:16 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue, 5 Jan 2021 09:06:16 -0800 Subject: [squeak-dev] The Inbox: System-dtl.1209.mcz In-Reply-To: References: Message-ID: <4DEBAA31-A3C4-43C8-B10D-228DD768B5AF@gmail.com> > On Jan 5, 2021, at 4:18 AM, Marcel Taeumel wrote: > >  > Hi Dave. > > > Provide vmParameterAt:default: to handle primitive failure on reading VM parameters. > > Hmm... #vmParameterAt:ifAbsent: would be "more idiomatic"? or vmParameterAt:ifFail: No matter which selector I like this very much. It’s a good idea Dave. Just upload to trunk what you like best. > > Best, > Marcel >> Am 28.12.2020 16:50:22 schrieb commits at source.squeak.org : >> >> David T. Lewis uploaded a new version of System to project The Inbox: >> http://source.squeak.org/inbox/System-dtl.1209.mcz >> >> ==================== Summary ==================== >> >> Name: System-dtl.1209 >> Author: dtl >> Time: 28 December 2020, 10:50:06.875257 am >> UUID: 25efba24-561f-4c53-97d9-95438edfce90 >> Ancestors: System-eem.1207 >> >> Provide vmParameterAt:default: to handle primitive failure on reading VM parameters. >> Supply default parameter values to mock possibly missing elements in the parameters array. >> Remove two unnecessary isRunningCog checks and an ifNotNil: >> Remove inappropriate halt in sendMouseWheelEvents: >> Let supportsMultipleBytecodeSets and supportsReadOnlyObjects work on any VM. >> >> =============== Diff against System-eem.1207 =============== >> >> Item was changed: >> ----- Method: SmalltalkImage>>isRunningCog (in category 'system attributes') ----- >> isRunningCog >> "Answers if we're running on a Cog VM (JIT or StackInterpreter)" >> >> + ^(self vmParameterAt: 42 default: nil) >> - ^(self vmParameterAt: 42) >> ifNil: [false] >> ifNotNil: [:numStackPages| numStackPages > 0]! >> >> Item was changed: >> ----- Method: SmalltalkImage>>isRunningCogit (in category 'system attributes') ----- >> isRunningCogit >> "Answers if we're running on the Cog JIT" >> >> + ^(self vmParameterAt: 46 default: nil) >> - ^(self vmParameterAt: 46) >> ifNil: [false] >> ifNotNil: [:machineCodeZoneSize| machineCodeZoneSize > 0]! >> >> Item was changed: >> ----- Method: SmalltalkImage>>lowSpaceThreshold (in category 'memory space') ----- >> lowSpaceThreshold >> "Answer the low space threshold. When the amount of free memory (after garbage collection) >> falls below this limit, the system is in serious danger of completely exhausting memory and >> crashing. This limit should be made high enough to allow the user open a debugger to diagnose >> a problem or to save the image. In a stack-based VM such as Cog contexts for activations in >> the stack zone will have to be created as the debugger opens, requiring additional headroom." >> >> | slotsForDebugger slotsForContextsOnStackPages | >> slotsForDebugger := 65536. "Arbitrary guess" >> slotsForContextsOnStackPages := >> + (self vmParameterAt: 42 default: nil) >> - (self vmParameterAt: 42) >> ifNil: [0] >> ifNotNil: >> [:numStackPages| | headerSize numActivationsPerPage maxContextSize | >> numActivationsPerPage := 40. "Design goal of the Cog & Stack VMs" >> headerSize := 8 / self wordSize. "64-bits for Spur" >> maxContextSize := thisContext class instSize + CompiledMethod fullFrameSize + headerSize. >> numStackPages * numActivationsPerPage * maxContextSize]. >> ^slotsForDebugger + slotsForContextsOnStackPages * self wordSize! >> >> Item was changed: >> ----- Method: SmalltalkImage>>maxExternalSemaphores (in category 'vm parameters') ----- >> maxExternalSemaphores >> + "The size of table where external semaphores are registered. Only in Cog, >> + other VMs are expected to answer nil if present in the parameters array." >> + ^self vmParameterAt: 49 default: nil! >> - "The size of table where external semaphores are registered. Only in Cog" >> - self isRunningCog ifFalse: [^nil]. >> - ^self vmParameterAt: 49! >> >> Item was changed: >> ----- Method: SmalltalkImage>>maxExternalSemaphores: (in category 'vm parameters') ----- >> maxExternalSemaphores: aSize >> "Changes the size of table where external semaphores are registered. >> The size can only grow, and will always be the next power of two larger than the parameter. >> >> Setting this at any time other than start-up can potentially lose requests. >> i.e. during the realloc new storage is allocated, >> the old contents are copied and then pointers are switched. >> Requests occurring during copying won't be seen if they occur to indices already copied. >> The intended use is to set the table to some adequate maximum at start-up" >> >> - self isRunningCog ifFalse: [^0]. >> "The vm-header field is a short, maximum 64k entries. Well, on most platforms anyways " >> (aSize < 0 or: [aSize > 16rFFFF]) ifTrue: [^self error: 'maxExternalSemaphores: is limited to 16rFFFF']. >> + ^[self vmParameterAt: 49 put: aSize] on: Error do: [0].! >> - ^self vmParameterAt: 49 put: aSize! >> >> Item was changed: >> ----- Method: SmalltalkImage>>processPreemptionYields (in category 'system attributes') ----- >> processPreemptionYields >> "Answer whether the VM causes a process to yield on process preemption, >> i.e. to put a preempted process at the back of its run queue. If the parameter >> is unavailable (non-Cog VMs) or bit 2 (4) is 0 then preemption yields." >> >> + ^((self vmParameterAt: 48 default: [^true]) allMask: 4) not >> + ! >> - ^(([self vmParameterAt: 48] >> - on: Error >> - do: [:ex| ^true]) allMask: 4) not! >> >> Item was changed: >> ----- Method: SmalltalkImage>>sendMouseWheelEvents (in category 'system attributes') ----- >> sendMouseWheelEvents >> "The Cog VM can be instructed to deliver mouse wheel events as mouse wheel events. >> By default mouse wheel events are mapped to arrow events. >> This flag persists across snapshots, stored in the image header." >> >> + ^(self vmParameterAt: 48 default: 0) anyMask: 32! >> - ^(self vmParameterAt: 48) anyMask: 32! >> >> Item was changed: >> ----- Method: SmalltalkImage>>supportsMultipleBytecodeSets (in category 'system attributes') ----- >> supportsMultipleBytecodeSets >> "Answer whether the VM supports multiple bytecodeSets." >> "SmalltalkImage current supportsMultipleBytecodeSets" >> >> + ^(self vmParameterAt: 65 default: nil) >> - ^(self vmParameterAt: 65) >> ifNil: [false] >> ifNotNil: >> [:param| "In older VMs this is a boolean answering the vm-internal MULTIPLE_BYTECODE_SETS define" >> param isInteger "In newer VMs it is a set of integer flags, bit 0 of which is the vm-internal MULTIPLE_BYTECODE_SETS define" >> ifTrue: [param anyMask: 1] >> ifFalse: [param]]! >> >> Item was changed: >> ----- Method: SmalltalkImage>>supportsQueueingFinalization (in category 'system attributes') ----- >> supportsQueueingFinalization >> "Answer whether the VM queues individual weak arrays for finalization, instead >> of signalling the finalization semaphore once for all arrays and having the >> WeakRegistry mechanism finalize all weak arrays, whether they need to or not." >> "SmalltalkImage current supportsQueueingFinalization" >> >> + ^(self vmParameterAt: 48 default: 0) anyMask: 16! >> - ^(self vmParameterAt: 48) anyMask: 16! >> >> Item was changed: >> ----- Method: SmalltalkImage>>supportsReadOnlyObjects (in category 'system attributes') ----- >> supportsReadOnlyObjects >> "Answer whether the VM observes the per-object read-only flag and consequently aborts >> writes to inst vars of, and fails primitives that attempt to modify, read-only objects." >> "SmalltalkImage current supportsReadOnlyObjects" >> >> + ^(self vmParameterAt: 65 default: nil) >> - ^(self vmParameterAt: 65) >> ifNil: [false] >> ifNotNil: >> [:param| "In older VMs this is a boolean answering the vm-internal MULTIPLE_BYTECODE_SETS define" >> param isInteger "In newer VMs it is a set of integer flags, bit 1 of which is the vm-internal IMMUTABILITY define" >> ifTrue: [param anyMask: 2] >> ifFalse: [false]]! >> >> Item was added: >> + ----- Method: SmalltalkImage>>vmParameterAt:default: (in category 'vm parameters') ----- >> + vmParameterAt: parameterIndex default: defaultValueOrBlock >> + "Answer a VM parameter or defaultValueOrBlock value if out of range." >> + >> + ^defaultValueOrBlock value! >> >> Item was changed: >> ----- Method: SmalltalkImage>>wordSize (in category 'image') ----- >> wordSize >> "Answer the size in bytes of an object pointer or word in the object memory. >> The value does not change for a given image, but may be modified by a SystemTracer >> when converting the image to another format. The value is cached in WordSize to >> avoid the performance overhead of repeatedly consulting the VM." >> >> "Smalltalk wordSize" >> >> + ^ WordSize ifNil: [WordSize := self vmParameterAt: 40 default: 4]! >> - ^ WordSize ifNil: [WordSize := [self vmParameterAt: 40] on: Error do: [4]]! >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Tue Jan 5 17:16:27 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Tue, 5 Jan 2021 12:16:27 -0500 Subject: [squeak-dev] The Inbox: System-dtl.1209.mcz In-Reply-To: <4DEBAA31-A3C4-43C8-B10D-228DD768B5AF@gmail.com> References: <4DEBAA31-A3C4-43C8-B10D-228DD768B5AF@gmail.com> Message-ID: <20210105171627.GB70441@shell.msen.com> On Tue, Jan 05, 2021 at 09:06:16AM -0800, Eliot Miranda wrote: > > > > On Jan 5, 2021, at 4:18 AM, Marcel Taeumel wrote: > > > > ??? > > Hi Dave. > > > > > Provide vmParameterAt:default: to handle primitive failure on reading VM parameters. > > > > Hmm... #vmParameterAt:ifAbsent: would be "more idiomatic"? > > or vmParameterAt:ifFail: > > No matter which selector I like this very much. It???s a good idea Dave. Just upload to trunk what you like best. > Thanks, I will follow up in the next day or so. The inbox submission had an embarrassing error, so I already moved it to treated. I'll tidy it up and resubmit to trunk. Dave From lewis at mail.msen.com Tue Jan 5 17:24:42 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Tue, 5 Jan 2021 12:24:42 -0500 Subject: [squeak-dev] The Inbox: System-dtl.1209.mcz In-Reply-To: References: Message-ID: <20210105172442.GC70441@shell.msen.com> On Tue, Jan 05, 2021 at 01:17:50PM +0100, Marcel Taeumel wrote: > Hi Dave. > > >??Provide vmParameterAt:default: to handle primitive failure on reading VM parameters. > > Hmm... #vmParameterAt:ifAbsent: would be "more idiomatic"? > I was not sure about this either. It tried "ifAbsent" and "onError" but ifAbsent sounded too much like collection behavior, and onError just looked strange. In the end I decided that what we are really trying to do is supply a default in the case of a VM that does not know about a VM parameter, so that's how I ended up with vmParameterAt:default: Dave From vanessa at codefrau.net Tue Jan 5 19:51:46 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Tue, 5 Jan 2021 11:51:46 -0800 Subject: [squeak-dev] The Inbox: System-dtl.1209.mcz In-Reply-To: <20210105172442.GC70441@shell.msen.com> References: <20210105172442.GC70441@shell.msen.com> Message-ID: On Tue, Jan 5, 2021 at 9:24 AM David T. Lewis wrote: > On Tue, Jan 05, 2021 at 01:17:50PM +0100, Marcel Taeumel wrote: > > Hi Dave. > > > > >??Provide vmParameterAt:default: to handle primitive failure on reading > VM parameters. > > > > Hmm... #vmParameterAt:ifAbsent: would be "more idiomatic"? > > > > I was not sure about this either. It tried "ifAbsent" and "onError" > but ifAbsent sounded too much like collection behavior, and onError > just looked strange. In the end I decided that what we are really > trying to do is supply a default in the case of a VM that does not know > about a VM parameter, so that's how I ended up with vmParameterAt:default: > > Dave > I had the same reaction though, especially since you allow passing a block which is evaluated only if the primitive fails. Maybe thinking of it as being equivalent to Smalltalk getVMParameters at: index ifAbsent: [...] would make the "... ifAbsent:" more palatable? Vanessa -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Jan 5 19:53:10 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 5 Jan 2021 19:53:10 0000 Subject: [squeak-dev] The Trunk: Monticello-mt.734.mcz Message-ID: Nicolas Cellier uploaded a new version of Monticello to project The Trunk: http://source.squeak.org/trunk/Monticello-mt.734.mcz ==================== Summary ==================== Name: Monticello-mt.734 Author: mt Time: 5 January 2021, 1:09:08.981865 pm UUID: 93fdf435-68a1-4ace-a7a9-d9d86fb3118f Ancestors: Monticello-mt.733 Alternative fix for the problem addressed in Monticello-nice.734 =============== Diff against Monticello-mt.733 =============== Item was added: + ----- Method: MCAncestry>>isWorkingAncestry (in category 'testing') ----- + isWorkingAncestry + ^ false! Item was added: + ----- Method: MCVersionHistoryBrowser>>package (in category 'accessing') ----- + package + ^ package! Item was changed: ----- Method: MCVersionHistoryBrowser>>selectedSnapshot (in category 'accessing') ----- selectedSnapshot + ^ self selectedInfo isWorkingAncestry + ifTrue: [self package snapshot] + ifFalse: [self snapshotForInfo: self selectedInfo]! - ^ self snapshotForInfo: self selectedInfo! Item was added: + ----- Method: MCWorkingAncestry>>isWorkingAncestry (in category 'testing') ----- + isWorkingAncestry + ^ true! From commits at source.squeak.org Tue Jan 5 19:53:21 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 5 Jan 2021 19:53:21 0000 Subject: [squeak-dev] The Trunk: Monticello-mt.735.mcz Message-ID: Nicolas Cellier uploaded a new version of Monticello to project The Trunk: http://source.squeak.org/trunk/Monticello-mt.735.mcz ==================== Summary ==================== Name: Monticello-mt.735 Author: mt Time: 5 January 2021, 1:23:12.398865 pm UUID: b2a82046-9f24-4838-896b-6f669aa8a65d Ancestors: Monticello-mt.734 Consider version infos being working copies "in disguise" :-) =============== Diff against Monticello-mt.734 =============== Item was changed: ----- Method: MCAncestry>>isWorkingAncestry (in category 'testing') ----- isWorkingAncestry + + ^ self name = self nameForWorkingCopy! - ^ false! Item was added: + ----- Method: MCAncestry>>nameForWorkingCopy (in category 'ancestry') ----- + nameForWorkingCopy + + ^ ''! Item was changed: ----- Method: MCVersionInfo>>name (in category 'accessing') ----- name + ^ name ifNil: [self nameForWorkingCopy]! - ^ name ifNil: ['']! Item was changed: ----- Method: MCWorkingAncestry>>name (in category 'testing') ----- name + ^ self nameForWorkingCopy! - ^ ''! From lecteur at zogotounga.net Tue Jan 5 19:58:42 2021 From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=) Date: Tue, 5 Jan 2021 20:58:42 +0100 Subject: [squeak-dev] [ANN] Update on my current work Message-ID: Hello all, I have just released an updated image of my current work, including the development snapshot of a 2.5D adventure game engine: http://www.zogotounga.net/comp/squeak/rogue.htm See details and demos in the image. -- New stuff (that I can think of right now): improved controls tactical navigation a different representation for dark areas incremental floor textures nicer baobabs! many more monsters, better animated spiders and rock golems a recursive dungeon floor spawner terrains (water, lava) doors utility methods for color tweaking, better gradient fills dice-rolling improvements again, this is all described or demo-ed in the image itself -- Best, Stef From asqueaker at gmail.com Tue Jan 5 21:59:29 2021 From: asqueaker at gmail.com (Chris Muller) Date: Tue, 5 Jan 2021 15:59:29 -0600 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: References: Message-ID: Hi Tim, First, before the rest of this complain-y message: > > **Happy 2021 to everybody!** > To you as well! > Now to shamefully bring up a closed matter: in 2019 there was some > discussion on the mailing list that led to the deprecation of #asMutator. > Some portions of the discussion can be seen here: > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html > > Part of the argument was that "asMutator" and the notion of "mutators" was > not seen elsewhere in the image, and that it conflicted with work someone > was doing with GraphQL (?) which has its own notion of "mutators". Was > there other rationale? > Yes, the conflict is in the design of the language of the system and its API. Smalltalkers have forever used the terms, "getters and setters," not "getters and mutators". GraphQL, OTOH, provides a first-class, formal definition of a "mutation". (BTW, I never did announce the GraphQL engine, but it's on squeaksource, a solid and complete package). > In the meantime, various teams and projects will have to adapt their code. > And, users have been coping with various packages not loading seamlessly > in Squeak 5.3 due to this deprecation. > > Squot: https://github.com/hpi-swa/Squot/issues/266 > Seaside: https://github.com/SeasideSt/Seaside/issues/1195 > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 As mentioned in the original discussion, besides #isMutator being simply wrong in many cases (e.g., #at:, #indexOf:, etc.), this additional word feels application-specific. The systems above are all specific, external applications. I would recommend introducing the "mutator" lingo into Grease for Squeak and keep it out of the core library. We should stick with as minimal a set of words as possible. "Getters and setters," is the lingo. Otherwise, where does it end? Every word has several synonyms. It starts to get messy quickly. > I'm sorry for bringing up a settled matter, and for grandstanding a bit > ("at what price progress?"), but: was #asMutator deprecated because of > the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, > I (respectfully) have a hard time accepting part of that argument. A > quick Google search turns up much literature. > > "To add an accessor method and a mutator method" (2015) > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d > > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" > (2007) > > https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html > > See also: "simple accessor and mutator methods" (1998) > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html > > and: ST/X's asMutator (in protocol 'converting') > https://live.exept.de/ClassDoc/classDocOf,CharacterArray > > > These links and high-profile name look impressive until you follow them and look at their usage of "mutator" in context. As you pointed out, the first two of the four links refer to the same, single, idle usage in a single sentence. Not a "definition" of any sort. And the third is just the name of a one temporary variable. Pretty weak as an argument for inclusion. That leaves just the last one, a more obscure Smalltalk, unrelated to Squeak? I'm not familiar with that project, but they might be interested in switching to the "getters and setters" linguistic. > So: what is the long term strategy here? After methods are deprecated > and removed from the image, when those methods served the purpose of > compatibility with 3rd party packages and other Smalltalks, is it expected > that each outside package will either (a) maintain its own compatibility > layer, like Grease, or (b) implement the removed methods via class > extensions, thus possibly introducing conflicts? > Yes. Both. The code must target a specific version of Squeak (to be reliable), so it can be easily done without package conflicts. Even real, unavoidable conflicts are not something to necessarily abhor -- it's usually due to flexing of Smalltalk muscles, being able to run with a modified system is one of its beautiful and powerful features. - Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From asqueaker at gmail.com Tue Jan 5 22:08:38 2021 From: asqueaker at gmail.com (Chris Muller) Date: Tue, 5 Jan 2021 16:08:38 -0600 Subject: [squeak-dev] Revisiting the deprecation of #asMutator vs #asSimpleSetter in 5.3 (sorry) In-Reply-To: References: Message-ID: > #isMutator being simply wrong in many cases (e.g., #at:, #indexOf:, etc.), this additional word feels application-specific. More than a "feeling," but that is actually the reason. You can't send #isMutator to any Symbol and get a meaningful answer in any general sense. Only in the context of some application-specific "code generator" or whatever -- where the code knows it's dealing with getters and setters -- that anyone could rely on it. IOW, application-specific. On Sat, Jan 2, 2021 at 12:44 PM Tim Johnson wrote: > Hi, > > First, before the rest of this complain-y message: > > **Happy 2021 to everybody!** > > Now to shamefully bring up a closed matter: in 2019 there was some > discussion on the mailing list that led to the deprecation of #asMutator. > Some portions of the discussion can be seen here: > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201810.html > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-March/201843.html > > Part of the argument was that "asMutator" and the notion of "mutators" was > not seen elsewhere in the image, and that it conflicted with work someone > was doing with GraphQL (?) which has its own notion of "mutators". Was > there other rationale? > > In the meantime, various teams and projects will have to adapt their code. > And, users have been coping with various packages not loading seamlessly > in Squeak 5.3 due to this deprecation. > > Squot: https://github.com/hpi-swa/Squot/issues/266 > Seaside: https://github.com/SeasideSt/Seaside/issues/1195 > Also Seaside: https://github.com/SeasideSt/Seaside/search?q=asMutator > HPI "Home Desktop System": http://wiki.squeak.org/squeak/2860 > > I'm sorry for bringing up a settled matter, and for grandstanding a bit > ("at what price progress?"), but: was #asMutator deprecated because of > the argument that "mutators" are alien to Smalltalk and/or Squeak? If so, > I (respectfully) have a hard time accepting part of that argument. A > quick Google search turns up much literature. > > "To add an accessor method and a mutator method" (2015) > https://medium.com/smalltalk-talk/getting-the-message-667d77ff78d > > ^ the above quotes & cites Alan Lovejoy's "Smalltalk: Getting The Message" > (2007) > > https://web.archive.org/web/20150908201317/http://www.smalltalk.org/articles/article_20100320_a3_Getting_The_Message.html > > See also: "simple accessor and mutator methods" (1998) > http://www.esug.org/data/Smalltalk/Historical/pocketst/whitepaper.html > > and: ST/X's asMutator (in protocol 'converting') > https://live.exept.de/ClassDoc/classDocOf,CharacterArray > > So: what is the long term strategy here? After methods are deprecated > and removed from the image, when those methods served the purpose of > compatibility with 3rd party packages and other Smalltalks, is it expected > that each outside package will either (a) maintain its own compatibility > layer, like Grease, or (b) implement the removed methods via class > extensions, thus possibly introducing conflicts? > > Thanks, > Tim > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Wed Jan 6 00:16:29 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Wed, 6 Jan 2021 00:16:29 +0000 Subject: [squeak-dev] Two new curious Context/primitive questions :-) In-Reply-To: References: <9ea2e9b8c16341ceaa49089d4631a229@student.hpi.uni-potsdam.de>, Message-ID: Hi Eliot, thanks for the feedback! This is an exciting task and I'll put it onto my list, I'm looking forward to tackling it ... :-) > We can, but remember that passing a block is in fact hiding an allocation, maybe two. Mentioning a block in code causes it to be allocated and if not already done so, causes allocation of the lexically enclosing context. That's correct, but I believe that it could be possible to waive any closure variables but only use block arguments, block returns, and method returns. This should be relatively fast, shouldn't it? Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Eliot Miranda Gesendet: Samstag, 2. Januar 2021 02:45:53 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Two new curious Context/primitive questions :-) Hi Christoph, On Fri, Jan 1, 2021 at 4:18 PM Thiede, Christoph > wrote: Hi Eliot, once again I am very pleasantly surprised by your professional and detailed answer which was a joy to read! > 'Nuff said No further questions. This was very interesting! It also gives me a possible explanation for why one cannot execute a context subinstance without any problems. That's because the marriage between stack frame and context objects is hard-coded based on the Context class (specialObjects at: 11), isn't it? Indeed. One may be able to go the other way, create a stack of contexts whose class is different. These should retain their class because the associated stack frames will be married to them. But going the other way is not supported. > But beware, because if one was debugging the debugger one mustn't confuse a PrimFailToken created in the simulation for a PrimFailToken created by the simulation. Hm, aren't we already in a very similar situation? I had planned to write a separate message for this issue, but here is my case: {Context primitiveFailTokenFor: nil} at: 1. "{an Object . nil}" Context runSimulated: [{Context primitiveFailTokenFor: nil} at: 1]. "⚡ Error: subscript is out of bounds: 1" Now one could argue that this is not a very likely situation to occur ever in "production", but the same could be said for a hypothetical #isPrimFailToken selector, and above all, it precludes an ideal, i.e. completely transparent simulation machinery ... So I would like to suggest to find a different solution for this problem anyway, provided that you support this idea in general. An alternative I could imagine would be the SetElement pattern from Collections which is completely transparent. But this would probably be too expensive for simulation purposes (because we would need to instantiate one object per simulated primitive call), right? Not sure. If instantiation can be deferred until failure then things should be OK. Why not encode a failing primitive via a changed control flow? Couldn't we pass an additional failBlock argument to #doPrimitive:method:receiver:args:, #tryPrimitive:withArgs:/#tryNamedPrimitiveIn:for:withArgs:, and #simulateValueWithArguments:caller: (and analogously to ExternalFunction >> #tryInvokeWithArguments: and the critsect primitive methods on Mutex)? We can, but remember that passing a block is in fact hiding an allocation, maybe two. Mentioning a block in code causes it to be allocated and if not already done so, causes allocation of the lexically enclosing context. Then we could rewrite #send:to:with:lookupIn: like this (pseudo): send: selector to: rcvr with: arguments lookupIn: lookupClass "Simulate the action of sending a message with selector and arguments to rcvr. The argument, lookupClass, is the class in which to lookup the message. This is the receiver's class for normal messages, but for super messages it will be some specific class related to the source method." | meth primFailCode val ctxt | (meth := lookupClass lookupSelector: selector) ifNil: [selector == #doesNotUnderstand: ifTrue: [self error: 'Recursive message not understood!' translated]. ^self send: #doesNotUnderstand: to: rcvr with: {(Message selector: selector arguments: arguments) lookupClass: lookupClass} lookupIn: lookupClass]. meth isCompiledMethod ifFalse: ["Object as Methods (OaM) protocol: 'The contract is that, when the VM encounters an ordinary object (rather than a compiled method) in the method dictionary during lookup, it sends it the special selector #run:with:in: providing the original selector, arguments, and receiver.'. DOI: 10.1145/2991041.2991062." ^self send: #run:with:in: to: meth with: {selector. arguments. rcvr}]. meth numArgs = arguments size ifFalse: [^ self error: ('Wrong number of arguments in simulated message {1}' translated format: {selector})]. (primIndex := meth primitive) > 0 ifTrue: - [val := self doPrimitive: primIndex method: meth receiver: rcvr args: arguments. - (self isPrimFailToken: val) ifFalse: - [^val]]. + [val := self doPrimitive: primIndex method: meth receiver: rcvr args: arguments ifFail: + [:code | primFailCode := code]. + primFailCode ifNil: [^ val]]. (selector == #doesNotUnderstand: and: [lookupClass == ProtoObject]) ifTrue: [^self error: ('Simulated message {1} not understood' translated format: {arguments first selector})]. ctxt := Context sender: self receiver: rcvr method: meth arguments: arguments. - (primIndex isInteger and: [primIndex > 0]) ifTrue: - [ctxt failPrimitiveWith: val]. + primFailCode ifNotNil: + [ctxt failPrimitiveWith: primFailCode]. ^ctxt Current senders of #primitiveFailTokenFor: could then evaluate the failBlock if the primitive fails. Do you think this approach would be worth a try? :-) Definitely. It might eliminate multiple tests. I think you should definitely try it. It looks nice to me. Thank you! Best, Christoph ________________________________ Von: Squeak-dev > im Auftrag von Eliot Miranda > Gesendet: Freitag, 1. Januar 2021 22:34:28 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Two new curious Context/primitive questions :-) errata: On Fri, Jan 1, 2021 at 1:22 PM Eliot Miranda > wrote: Hi Christoph, happy new year!! On Fri, Jan 1, 2021 at 11:28 AM Thiede, Christoph > wrote: Hi all, hi Eliot, new year, new simulation fun, and I have collected two new questions about the Context implementation which I'd love to get answered here: First, I was confused by the following: (BlockClosure >> #numArgs) primitive. "266" (Context >> #pc) primitive. "0" What makes Context so special that it cannot be compiled with quick accessor methods? The gory details are here: http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ But that's full of implementation detail. Let me try and explain at a higher level. Contexts are wonderful but very expensive. Any VM that actually creates contexts for every method or block activation will inevitably run slowly. There are two overheads here. One is the basic overhead of allocating and reclaiming the contexts that are created. The other is the cost of moving the outgoing receiver and arguments from the sending context to the new context. A fast VM must avoid these overheads, and the key solution is to use a stack frame organization as is used in conventional language implementations. The key here is that with stack frames the receiver and incoming arguments do not have to be moved; they stay where they are and a new frame is built underneath them which includes them as the incoming receiver and arguments; stack frames overlap outgoing and incoming arguments. But crucially, in addition the VM must still create contexts if and when they are needed. If not, this would no longer be a Smalltalk-80 implementation. Now one could imagine a VM which converted stack frames to contexts whenever a method or block activation was accessed using thisContext (or thisContext sender etc which access contexts by following the sender field). But that would be very slow. Instead, the fastest approach is to try and keep stack frames as stack frames for as long as possible. For this to work contexts have to be able to function as "proxy objects" for stack frames. The VM does indeed create contexts when one uses thisContext, or even when one creates a block, but internally the context is in a very special state, a state in which it points at a stack frame. Some terminology is useful. Peter Deutsch used "volatile", "hybrid" and "stable". I like "single", "married", "widowed" and "divorced" (Peter's scheme didn't have "widowed" which is the key to why my scheme is faster, and why the closure implementation is as it is). When a stack frame is created it is "single". It has a slot within it to refer to a context object if it is needed, but the slot is nil. When a stack frame needs a context object one is created and the two are "married". When a method or block returns its stack frame is discarded; the stack frame has died and if it was married its context becomes "widowed". (*) When space is needed for new stack frames all reclaimed stack frames are "divorced" from their contexts. The stack frame state is written to the context object and the context object no longer acts as a proxy; it is a fully fledged normal stack object. (*) (*) Stack frames exist in a small memory zone organized as stack pages, the stack zone. The size of the stack zone is set at startup, and its size is either the VM's default or set by a value that persists in the image header (see vmParameterAt: 43). Since the system may run out of stack pages (a deep call stack, many active processes), the VM makes new pages available by purging the least recently used pages to the heap in the form of context objects. All the frames in the least recently used stack page are divorced at the same time. A context must be created for each frame that is not yet married. A page is big enough to hold on average about 40 method activations; since activations are of different sizes and change size as execution proceeds, the number of activations per full page varies. (*) The reason why Peter's original scheme is slower is that in HPS at return time the VM has to check for a frame being hybrid and copy state to the hybrid context, making it stable. This has to be done because a closure's outer temporary variables are stored in the lexically enclosing stack frame, and so have to be made to persist in the stable context or their values will be stale. In my (lisp-derived) closure implementation there are no such references to outer temporary variables; values are either copied if they do not change, or stored in an Array (the "indirection vector"), which can then be copied. Note that divorce is a process. Once divorced a context is single and free to function as a context does. Indeed when the system starts up it loads an image which only contains single contexts. All contexts are divorced on snapshot. Divorced contexts are amnesiacs. So now, finally, we can answer your question. Why is (Context>>#pc), a method that simply answers an instance variable, not compiled as a quick method with a primitive that answers that variable? "married" and "widowed" contexts are proxies for stack frames. Only the instance variables they contain which do not change can be fetched from the context object itself; these are the receiver, arguments, closureOrNil, and method. sender, pc, stackp and other stack contents may change as execution proceeds. These mutable values must be fetched from the stack frame itself, if it still exists. All accesses to sender, pc, stackp, and stack contents (Context>>at:[put:]) must be mediated. A married or widowed context has its sender field set to the frame pointer of its stack frame, encoded as a SmallInteger. You can never see this from the image (except via a special xRay primitive). By following the frame pointer encoded in the sender field the VM can detect if the frame is still live. If so, the relevant values are synthesized or fetched from the stack frame itself. If not, the context is widowed and "mourns"; it is changed into a context with a nil sender field, a nil pc, and a stackp that points at the last argument. How is this mediation done? One design could be to require that all image level accesses to Context inst vars are through primitives. This feels contrived to me. Instead, inst var access is via inst var access bytcodes. But if we do this naively we would have to check in all inst var access bytecodes whose index is the same as sender (0), pc (1) & stackp (2). This would slow down inst var access enormously. Instead we observe that inst var access bytecodes pushReceiverVariable:, popIntoReceiverVariable: have short forms for the most frequently used (indexes 0 to 15 for push, indexes 0 to 7 for popInto). By arranging that we only use the long forms for accessing inst vars in Context, and superclasses and subclasses, we only have to check in the long forms and the check is cheap. We check that the index is <= 2, because all other inst var accesses with these indices will use the short-form bytecodes. By arranging that Context's inst vars are *not* accessed by quick primitives we do not have to duplicate this machinery in quick primitive dispatch, which would also slow things down. Hence Context>>pc is compiled as a vanilla method and its inst var access bytecode is the long form: 25 pushRcvr: 1 27 <5C> returnTop 'Nuff said Second, Context >> #isPrimFailToken: attracted my attention multiple times when looking at different #timeProfile results of simulation sessions. In the expression [100000 factorial] it takes up more than 44% of the whole execution time! I have no idea why it could be so slow, but this message is sent really often, which is at least 2 times per simulation of a special message send. Would there be an easy change to resolve this bottleneck and speed up the simulation by 40% or more? Would it be possible to provide a primitive for this method? Or do you see any other way to optimize it? It's not slow so much as that it has to be used all the time to check whether a send has invoked a primitive which has failed. Its function is to support primitive error codes. Before primitive error codes (IIRC) we simply checked for nil. But with primitive error codes we need a container that both reliably distinguishes a primitive failure result from all other objects in the system, and holds onto the primitive failure code. It may indeed be able to reduce the overhead by only testing when absolutely necessary. It may be that reimplementing the scheme is faster. For example, one could imagine a class whose instances are the only objects to answer #isPrimFailToken, which would be faster than a one argument message send. But beware, because if one was debugging the debugger one mustn't confuse a PrimFailToken created in the simulation for a PrimFailToken created by the simulation. Remember to distinguish between price and value. Implementing the context-to-stack mapping scheme outlined above was very costly, but its value is very high. It allows us to have contexts, with all their utility, while reducing their costs significantly. Similarly, and closely related, being able to simulate execution is costly but hugely valuable. If the price is 40% of simulated execution then it is a price worth paying. Best, Christoph Happy New Year! _,,,^..^,,,_ best, Eliot -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.thiede at student.hpi.uni-potsdam.de Wed Jan 6 00:16:41 2021 From: christoph.thiede at student.hpi.uni-potsdam.de (Christoph Thiede) Date: Tue, 5 Jan 2021 18:16:41 -0600 (CST) Subject: [squeak-dev] The Trunk: Files-eem.184.mcz In-Reply-To: References: Message-ID: <1609892201726-0.post@n4.nabble.com> That's interesting. The VM generates a drag'n'drop event when a new (USB?) device is plugged in? Why??? :-) Best, Christoph ----- Carpe Squeak! -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From Christoph.Thiede at student.hpi.uni-potsdam.de Wed Jan 6 00:22:46 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Wed, 6 Jan 2021 00:22:46 +0000 Subject: [squeak-dev] Bug in primitivePerform (was: The Inbox: KernelTests-ct.382.mcz) In-Reply-To: References: <2fc7d04d1fea4cbfb1aa7f0663a3f2de@student.hpi.uni-potsdam.de> , Message-ID: Agreed. Put this back onto my to-do list. Please don't merge until then. :-) Still, could we at least make primitive 118 a bit more robust against missing arguments? Its name implies trial and error, so it's a little disappointing to be kicked out of the VM in case of "error". Or is #tryPrimitive:withArgs: simply not meant to be a public selector but rather a private one that you should wrap with LBYL? Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 5. Januar 2021 12:00:39 An: squeak-dev Betreff: Re: [squeak-dev] Bug in primitivePerform (was: The Inbox: KernelTests-ct.382.mcz) > IMO the VM isn't obligated to implement checking for nonsensical definitions. That would slow the VM down unnecessarily. Instead one should *never* use primitive 83 in a method that takes no arguments. +1 Best, Marcel Am 02.01.2021 02:39:55 schrieb Eliot Miranda : Hi Christoph, On Fri, Jan 1, 2021 at 11:07 AM Thiede, Christoph > wrote: Hi all, please note that primitive 83 is currently crashing the VM (tested with VMMaker.oscog-eem.2850) when called without any arguments, so #testPrimitive83 in the patch below will break the test execution at the moment. However, primitive 84 works well, so to me this looks like a trivial mistake only. Hang on. When would one include primitive 83 in a method that takes no arguments? Implementing e.g. Object>>perform "Invoke the perform primitive with no arguments cuz there's nothing to perform" self error: 'you don''t say' makes no sense. IMO the VM isn't obligated to implement checking for nonsensical definitions. That would slow the VM down unnecessarily. Instead one should *never* use primitive 843 in a method that takes no arguments. Hence in your simulation tests you can exclude the case where someone tries tryPrimitive: 83 withArguments: #() because it constitutes undefined behaviour and the VM crashing is IMO to be expected. I have (still!) not yet made myself the gift of exploring VMMaker, so I won't be able to fix a patch at the moment. But if someone can solve this, it would be great if you could give me a short pointer to the corresponding VMMaker patch because studying small interesting patches appear as a very nice way to explore an unknown framework to me. :-) Best, Christoph ________________________________ Von: Squeak-dev > im Auftrag von commits at source.squeak.org > Gesendet: Freitag, 1. Januar 2021 19:59 Uhr An: squeak-dev at lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: KernelTests-ct.382.mcz Christoph Thiede uploaded a new version of KernelTests to project The Inbox: http://source.squeak.org/inbox/KernelTests-ct.382.mcz ==================== Summary ==================== Name: KernelTests-ct.382 Author: ct Time: 1 January 2021, 7:59:13.17819 pm UUID: 812293dd-db7d-4c03-a33d-8b6f4354d1fa Ancestors: KernelTests-ct.375, KernelTests-tonyg.381 Tests simulation of #perform:... primitives 83, 84, and 100. Complements Kernel-ct.1367. Depends indeed not only on KernelTests-tonyg.381 but also on KernelTests-ct.375, it would be nice if we could get the latter merged soon, this has already been causing too many merge conflicts in the past. :-) =============== Diff against KernelTests-ct.375 =============== Item was added: + ----- Method: ContextTest>>testPrimitive100 (in category 'tests') ----- + testPrimitive100 + + { + {#isNil. {}. Object}. "valid 0-arg message" + {#=. {true}. UndefinedObject}. "valid unary message" + {#ifNil:ifNotNil:. {[2]. [:x | x]}. Object}. "valid binary message" + {}. "missing selector" + {#isNil}. "missing arguments" + {#isNil. 'not an array'}. "invalid arguments" + {#isNil. {}}. "missing lookupClass" + {#isNil. {'excess arg'}. Object}. "too many arguments" + {#=. {}. UndefinedObject}. "missing argument" + {#isNil. {}. Boolean}. "lookupClass not in inheritance chain" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 100 withArgs: args]) + equals: (nil tryPrimitive: 100 withArgs: args)].! Item was added: + ----- Method: ContextTest>>testPrimitive83 (in category 'tests') ----- + testPrimitive83 + + { + {#isNil}. "valid 0-arg message" + {#=. true}. "valid unary message" + {#ifNil:ifNotNil:. [2]. [:x | x]}. "valid binary message" + {}. "missing selector" + {#isNil. 'excess arg'}. "too many arguments" + {#=}. "missing argument" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 83 withArgs: args]) + equals: (nil tryPrimitive: 83 withArgs: args)].! Item was added: + ----- Method: ContextTest>>testPrimitive84 (in category 'tests') ----- + testPrimitive84 + + { + {#isNil. {}}. "valid 0-arg message" + {#=. {true}}. "valid unary message" + {#ifNil:ifNotNil:. {[2]. [:x | x]}}. "valid binary message" + {}. "missing selector" + {#isNil}. "missing arguments" + {#isNil. 'not an array'}. "invalid arguments" + {#isNil. {'excess arg'}}. "too many arguments" + {#=. {}}. "missing argument" + } do: [:args | + self + assert: (Context runSimulated: [nil tryPrimitive: 84 withArgs: args]) + equals: (nil tryPrimitive: 84 withArgs: args)].! -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Wed Jan 6 00:30:05 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Wed, 6 Jan 2021 00:30:05 +0000 Subject: [squeak-dev] A discrepancy between bytecode execution and simulation In-Reply-To: References: , Message-ID: <988ce7a9038f45aca5cf17177933e6a9@student.hpi.uni-potsdam.de> > Maybe it makes sense to think in terms of "simulation depth"? In a non-debugging scenario, that "simulation depth" is 0 because no simulation code is executed. When you debug/simulate your application code, depth is 1. When you debug/simulate the simulation code, depth is 2. If one would construct deeper "simulate the simulating simulator" processes, depth can be greater than 2. :-) Yahoo, a Meta-Object Facility adoption for Smalltalk systems. :-) And depth -1 would correspond to the Slang-generated VM implementation, right? ;-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 8. Dezember 2020 13:44:09 An: squeak-dev Betreff: Re: [squeak-dev] A discrepancy between bytecode execution and simulation Hi Christoph > [...] between simulation and production (btw did I choose the right terms for them? :) Since code simulation needs code execution, I think that "simulation" is a part of "execution". Maybe it makes sense to think in terms of "simulation depth"? In a non-debugging scenario, that "simulation depth" is 0 because no simulation code is executed. When you debug/simulate your application code, depth is 1. When you debug/simulate the simulation code, depth is 2. If one would construct deeper "simulate the simulating simulator" processes, depth can be greater than 2. :-) "Production" is then simulation depth 0. :-D Best, Marcel Am 07.12.2020 18:55:31 schrieb Thiede, Christoph : Hi all, hi Eliot, I constructed the following code snippet which evaluates to true when running it using the production execution machinery: nil == thisContext pop I guess this is fine, because what alternatives would the execution machinery have? It could terminate the whole VM or we could introduce something like #cannotReturn: for invalid stack frame objects. Probably the current implementation is the best despite an invalid position in the context stack has been addressed. However, the simulation machinery treats the same snippet differently, and it throws: Error: subscript is out of bounds: 0 I wonder whether it is acceptable to have diverging behaviors for such an ill-defined edge case between simulation and production (btw did I choose the right terms for them? :)). Might it a better alternative to raise a Warning (#notify:) only and then return nil such as the VM appears to do? Best, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa at codefrau.net Wed Jan 6 02:05:20 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Tue, 5 Jan 2021 18:05:20 -0800 Subject: [squeak-dev] Two new curious Context/primitive questions :-) In-Reply-To: References: Message-ID: This was a very interesting read - thank you Eliot! That should go in some book :) Another overview is in the class comment for MaybeContextInstanceVariableNode. Which I found by trying to figure out how the heck the compiler knows to use the long form for inst var refs in Context. Vanessa On Fri, Jan 1, 2021 at 1:23 PM Eliot Miranda wrote: > Hi Christoph, > > happy new year!! > > On Fri, Jan 1, 2021 at 11:28 AM Thiede, Christoph < > Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > >> Hi all, hi Eliot, >> >> >> new year, new simulation fun, and I have collected two new questions >> about the Context implementation which I'd love to get answered here: >> >> >> First, I was confused by the following: >> >> (BlockClosure >> #numArgs) primitive. "266" >> (Context >> #pc) primitive. "0" >> What makes Context so special that it cannot be compiled with quick >> accessor methods? >> > > The gory details are here: > http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ > > But that's full of implementation detail. Let me try and explain at a > higher level. > > Contexts are wonderful but very expensive. Any VM that actually creates > contexts for every method or block activation will inevitably run slowly. > There are two overheads here. One is the basic overhead of allocating and > reclaiming the contexts that are created. The other is the cost of moving > the outgoing receiver and arguments from the sending context to the new > context. A fast VM must avoid these overheads, and the key solution is to > use a stack frame organization as is used in conventional language > implementations. The key here is that with stack frames the receiver and > incoming arguments do not have to be moved; they stay where they are and a > new frame is built underneath them which includes them as the incoming > receiver and arguments; stack frames overlap outgoing and incoming > arguments. > > But crucially, in addition the VM must still create contexts if and when > they are needed. If not, this would no longer be a Smalltalk-80 > implementation. Now one could imagine a VM which converted stack frames to > contexts whenever a method or block activation was accessed using > thisContext (or thisContext sender etc which access contexts by following > the sdender field). But that would be very slow. Instead, the fastest > approach is to try and keep stack frames as stack frames for as long as > possible. For this to work contexts have to be able to function as "proxy > objects" for stack frames. The VM does indeed create contexts when one > uses thisContext, or even when one creates a block, but internally the > context is in a very special state, a state in which it points at a stack > frame. > > Some terminology is useful. Peter Deutsch used "volatile", "hybrid" and > "stable". I like "single", "married", "widowed" and "divorced" (Peter's > scheme didn't have "widowed" which is the key to why my scheme is faster, > and why the closure implementation is as it is). > > When a stack frame is created it is "single". It has a slot within it to > refer to a context object if it is needed, but the slot is nil. > When a stack frame needs a context object one is created and the two are > "married". > When a method or block returns its stack frame is discarded; the stack > frame has died and if it was married its context becomes "widowed". (*) > When space is needed for new stack frames all reclaimed stack frames are > "divorced" from their contexts. The stack frame state is written to the > context object and the context object no longer acts as a proxy; it is a > fully fledged normal stack object. (*) > > (*) Stack frames exist in a small memory zone organized as stack pages, > the stack zone. The size of the stack zone is set at startup, and its size > is either the VM's defaut oir set by a value that persists in the image > header (see vmParameterAt: 43). Since the system may run out of stack > pages (a deep call stack, many active processes), the VM makes new pages > available by purging the least recently used pages to the heap in the form > of context objects. All the frames in the least recently used stack page > are divorced at the same time. A context must be created for each frame > that is not yet married. > > (*) The reason why Peter's original scheme is slower is that at return > time the VM has to check for being married and copy state to the hybrid > context, making it stable. This has to be done because a closure's outer > temporary variables are stored in the lexically enclosing stack frame, and > so have to be made to persist in the stable context or their values will be > stale. In my (lisp-derived) closure implementation there are no such > references to outer temporary variables; values are either copied if they > do not change, or stored in an Array (the "indirection vector"), which can > then be copied. > > Note that divorce is a process. Once divorced a context is single and > free to function as a context does. Indeed when the system starts up it > loads an image which only contains single contexts. All contexts are > divorced on snapshot. > > > So now, finally, we can answer your question. Why is (Context>>#pc), a > method that simply answers an instance variable, not compiled as a quick > method with a primitive that answers that variable? "married" and > "widowed" contexts are proxies for stack frames. Only the instance > variables they contain which do not change can be fetched from the > context object itself; these are the receiver, arguments, closureOrNil, and > method. sender, pc, stackp and other stack contents may change as execution > proceeds. These mutable values must be fetched from the stack frame itself, > if it still exists. > > All accesses to sender, pc, stackp, and stack contents > (Context>>at:[put:]) must be mediated. A married or widowed context has > its sender field set to the frame pointer of its stack frame, encoded as a > SmallInteger. You can never see this from the image (except via a special > xRay primitive). By following the frame pointer encoded in the sender field > the VM can detect if the frame is still live. If so, the relevant > values are synthesized or fetched from the stack frame itself. If not, the > context is widowed and "mourns"; it is changed into a context with a nil > sender field, a nil pc, and a stackp that points at the last argument. > > How is this mediation done? One design could be to require that all image > level accesses to Context inst vars are through primitives. This feels > contrived to me. Instead, inst var access is via inst var access > bytcodes. But if we do this naively we would have to check in all inst var > access bytecodes whose index is the same as sender (0), pc (1) & stackp > (2). This would slow down inst var access enormously. Instead we observe > that inst var access bytecodes pushReceiverVariable:, > popIntoReceiverVariable: have short forms for the most frequently used > (indexes 0 to 15 for push, indexes 0 to 7 for popInto). By arranging that > we only use the long forms for accessing inst vars in Context, and > superclasses and subclasses, we only have to check in the long forms and > the check is cheap. We check that the index is <= 2, because all other > inst var accesses with these indices will use the short-form bytecodes. > > By arranging that Context's inst vars are *not* accessed by quick > primitives we do not have to duplicate this machinery in quick primitive > dispatch, which would also slow things down. Hence Context>>pc is compiled > as a vanilla method and its inst var access bytecode is the long form: > > 25 pushRcvr: 1 > 27 <5C> returnTop > > 'Nuff said > >> Second, Context >> #isPrimFailToken: attracted my attention multiple >> times when looking at different #timeProfile results of simulation >> sessions. In the expression [100000 factorial] it takes up more than 44% of >> the whole execution time! >> I have no idea why it could be so slow, but this message is sent really >> often, which is at least 2 times per simulation of a special message send. >> Would there be an easy change to resolve this bottleneck and speed >> up the simulation by 40% or more? >> Would it be possible to provide a primitive for this method? Or do you >> see any other way to optimize it? >> > > It's not slow, so much as it has to be used all the time to check whether > a send has invoked a primitive which has failed. Its function is to > support primitive error codes. Without it we can simply check for nil. > But with it we need a container that both reliably distinguishes a > primitive failure result from all other objects in the system, and holds > onto the primitive failure code. It may indeed be able to reduce the > overhead by only testing when absolutely necessary. It may be that > reimplementing the scheme is faster. > > For example, one could imagine a class whose instances are the only > objects to answer #isPrimFailToken, which would be faster than a one > argument message send. But beware, because if one was debugging the > debugger one mustn't confuse a PrimFailToken created in the simulation for > a PrimFailToken created by the simulation. > Remember to distinguish between price and value. Implementing the > context-to-stack mapping scheme outlined above was very costly, but its > value is very high. It allows us to have contexts, with all their utility, > while reducing their costs significantly. Similarly, and closely related, > being able to simulate execution is costly but hugely valuable. If the > price is 40% of simulated execution then it is a price worth paying. > > Best, >> Christoph >> > > Happy New Year! > > _,,,^..^,,,_ > best, Eliot > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa at codefrau.net Wed Jan 6 02:07:01 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Tue, 5 Jan 2021 18:07:01 -0800 Subject: [squeak-dev] V3 Message-ID: Reading the code I again noticed "Squeak V3" as name for the old bytecode set. Always wanted to know: Where does the "V3" nomenclature come from? What's V1 and V2? And should we consider Sista to be V4, or treat it as completely unrelated? Vanessa -------------- next part -------------- An HTML attachment was scrubbed... URL: From squeaklist at gmail.com Wed Jan 6 02:53:42 2021 From: squeaklist at gmail.com (Kjell Godo) Date: Tue, 5 Jan 2021 18:53:42 -0800 Subject: [squeak-dev] A discrepancy between bytecode execution and simulation In-Reply-To: <988ce7a9038f45aca5cf17177933e6a9@student.hpi.uni-potsdam.de> References: <988ce7a9038f45aca5cf17177933e6a9@student.hpi.uni-potsdam.de> Message-ID: +1 On Tue, Jan 5, 2021 at 16:30 Thiede, Christoph < Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > > Maybe it makes sense to think in terms of "simulation depth"? In a > non-debugging scenario, that "simulation depth" is 0 because no simulation > code is executed. When you debug/simulate your application code, depth is > 1. When you debug/simulate the simulation code, depth is 2. If one would > construct deeper "simulate the simulating simulator" processes, depth can > be greater than 2. :-) > > Yahoo, a Meta-Object Facility adoption for Smalltalk systems. :-) And > depth -1 would correspond to the Slang-generated VM implementation, right? > ;-) > > Best, > Christoph > ------------------------------ > *Von:* Squeak-dev im > Auftrag von Taeumel, Marcel > *Gesendet:* Dienstag, 8. Dezember 2020 13:44:09 > *An:* squeak-dev > *Betreff:* Re: [squeak-dev] A discrepancy between bytecode execution and > simulation > > Hi Christoph > > > [...] between simulation and production (btw did I choose the right > terms for them? :) > > Since code simulation needs code execution, I think that "simulation" is a > part of "execution". > > Maybe it makes sense to think in terms of "simulation depth"? In a > non-debugging scenario, that "simulation depth" is 0 because no simulation > code is executed. When you debug/simulate your application code, depth is > 1. When you debug/simulate the simulation code, depth is 2. If one would > construct deeper "simulate the simulating simulator" processes, depth can > be greater than 2. :-) > > "Production" is then simulation depth 0. :-D > > Best, > Marcel > > Am 07.12.2020 18:55:31 schrieb Thiede, Christoph < > christoph.thiede at student.hpi.uni-potsdam.de>: > > Hi all, hi Eliot, > > > I constructed the following code snippet which evaluates to true when > running it using the production execution machinery: > > > nil == thisContext pop > > > I guess this is fine, because what alternatives would the execution > machinery have? It could terminate the whole VM or we could introduce > something like #cannotReturn: for invalid stack frame objects. Probably the > current implementation is the best despite an invalid position in > the context stack has been addressed. > > > However, the simulation machinery treats the same snippet differently, and > it throws: > > > Error: subscript is out of bounds: 0 > > > I wonder whether it is acceptable to have diverging behaviors for such an > ill-defined edge case between simulation and production (btw did I choose > the right terms for them? :)). Might it a better alternative to raise > a Warning (#notify:) only and then return nil such as the VM appears to do? > > > Best, > > Christoph > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jecel at merlintec.com Wed Jan 6 03:02:51 2021 From: jecel at merlintec.com (Jecel Assumpcao Jr) Date: Wed, 6 Jan 2021 00:02:51 -0300 Subject: [squeak-dev] V3 In-Reply-To: References: Message-ID: <20210106030254.CB28D8C07FC@proxy.email-ssl.com.br> Vanessa, > Reading the code I again noticed "Squeak V3" as name for the old bytecode > set. Always wanted to know: Where does the "V3" nomenclature come from? It was the format for the planned Squeak 3.0: https://wiki.squeak.org/squeak/750 > What's V1 and V2? They were never named, but you could consider the original Squeak to be V1 and the one with Morphic in it to be V2, but I don't think there are any significant changes between them. But please note that the V3 effort was abandoned, so in practice VI3 is essentially the original Squeak image format. > And should we consider Sista to be V4, or treat it as completely unrelated? There was a VI4 effort, also abandoned, that is linked from that page: https://wiki.squeak.org/squeak/2119 But Eliot's efforts to add closures did get adopted (third time's the charm!) and yet it only got new image version numbers and not a new name. So it is a VI3 format that doesn't match the previous meaning of the term. Since none of those matter any more it is just odd but doesn't actually cause any confusion. What is confusing is the use of the term both for the image format (VI3 x Spur) and the bytecode set (VI3 x Sista). In any case, the 3 in VI3 was originally associated with the transition from Squeak 2 to Squeak 3 and makes no sense in this Squeak 5 (soon 6) era. -- Jecel From vanessa at codefrau.net Wed Jan 6 03:09:37 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Tue, 5 Jan 2021 19:09:37 -0800 Subject: [squeak-dev] A discrepancy between bytecode execution and simulation In-Reply-To: <3D3F224F-CD7E-4939-9A99-0377ED8AE0F5@gmail.com> References: <3D3F224F-CD7E-4939-9A99-0377ED8AE0F5@gmail.com> Message-ID: On Mon, Dec 7, 2020 at 9:12 PM Eliot Miranda wrote: > nil == thisContext pop > > I guess this is fine, because what alternatives would the execution > machinery have? It could terminate the whole VM or we could introduce > something like #cannotReturn: for invalid stack frame objects. Probably the > current implementation is the best despite an invalid position in > the context stack has been addressed. > > Well, one pop is almost "fine" because there still is an object on the stack (the receiver). But if you were to do 2 pops then we would fetch from the void. [image: image.png] after stepping over #pop it looks like this [image: image.png] ... when there really should be 2 nils on the stack (in slots 6 and 7). After stepping once more: [image: image.png] ... it actually replaced the receiver slot, going "below" the stack. > However, the simulation machinery treats the same snippet differently, and > it throws: > > Error: subscript is out of bounds: 0 > > If we did bounds checking for stack access in SqueakJS (which I used for the above screenshots) then yes we could produce an error. But that would be really expensive. > I wonder whether it is acceptable to have diverging behaviors for such an > ill-defined edge case between simulation and production (btw did I choose > the right terms for them? :)). Might it a better alternative to raise > a Warning (#notify:) only and then return nil such as the VM appears to do? > > It’s a very good question. I’m going to provide a very lazy and pragmatic > answer, forced by lack of resources to address the issue properly. It’s > clear that the behaviour is at best undefined. It is good that the > simulation produces an error. The only regrettable thing is that what is > reported is a low-level error rather than a high-level one that says, fir > example, “undefined behaviour encountered”. Achieving a specification > which states that this is undefined behaviour allows the JIT to get away > with not dealing with the issue, and that’s important because dealing with > the issue such that the JIT could detect this as an error would likely > destroy lots of performance gains it is able to make by assuming it is > given valid defined execution sequences. > > That’s a long winded way of saying that, given limited resources, I’m > giving the same response as a doctor that when told by a patient that it > hurts when the patient does X says “then stop doing X”. > Exactly. Dr. Vanessa -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 35776 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 32071 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 29750 bytes Desc: not available URL: From frank-lesser at lesser-software.com Wed Jan 6 06:28:29 2021 From: frank-lesser at lesser-software.com (Frank Lesser) Date: Wed, 6 Jan 2021 07:28:29 +0100 Subject: [squeak-dev] Two new curious Context/primitive questions :-) In-Reply-To: References: <9ea2e9b8c16341ceaa49089d4631a229@student.hpi.uni-potsdam.de> Message-ID: <11a95d98-1b74-2f0e-31d9-cf3c57b40b99@lesser-software.com> Hi Christoph, yes this optimization is possible - IMO Pharo/Squeal has a CleanBlockClosure - I used the term red & green BlockClosure ( demonstrated at a customer in 2010  ) - implemented in LSWGVM since more than a decade. Frank On 1/6/2021 01:16, Thiede, Christoph wrote: > > Hi Eliot, > > > thanks for the feedback! This is an exciting task and I'll put it onto > my list, I'm looking forward to tackling it ... :-) > > > > We can, but remember that passing a block is in fact hiding an > allocation, maybe two. Mentioning a block in code causes it to be > allocated and if not already done so, causes allocation of the > lexically enclosing context. > > > > That's correct, but I believe that it could be possible to waive any > closure variables but only use block arguments, block returns, and > method returns. This should be relatively fast, shouldn't it? > > Best, > Christoph > ------------------------------------------------------------------------ > *Von:* Squeak-dev im > Auftrag von Eliot Miranda > *Gesendet:* Samstag, 2. Januar 2021 02:45:53 > *An:* The general-purpose Squeak developers list > *Betreff:* Re: [squeak-dev] Two new curious Context/primitive > questions :-) > Hi Christoph, > > On Fri, Jan 1, 2021 at 4:18 PM Thiede, Christoph > > wrote: > > Hi Eliot, > > > once again I am very pleasantly surprised by your professional and > detailed answer which was a joy to read! > > > > > 'Nuff said > > No further questions. This was very interesting! > It also gives me a possible explanation for why one cannot > execute a context subinstance without any problems. That's because > the marriage between stack frame and context objects is hard-coded > based on the Context class (specialObjects at: 11), isn't it? > > > Indeed. One may be able to go the other way, create a stack of > contexts whose class is different.  These should retain their class > because the associated stack frames will be married to them.  But > going the other way is not supported. > > > But beware, because if one was debugging the debugger one mustn't > confuse a PrimFailToken created in the simulation for a > PrimFailToken created by the simulation. > > Hm, aren't we already in a very similar situation? I had planned > to write a separate message for this issue, but here is my case: > > {Context primitiveFailTokenFor: nil} at: 1. "{an Object . nil}" > Context runSimulated: [{Context primitiveFailTokenFor: nil} at: > 1]. "⚡ Error: subscript is out of bounds: 1" > > Now one could argue that this is not a very likely situation to > occur ever in "production", but the same could be said for a > hypothetical #isPrimFailToken selector, and above all, it > precludes an ideal, i.e. completely transparent simulation > machinery ... > So I would like to suggest to find a different solution for this > problem anyway, provided that you support this idea in general. > > An alternative I could imagine would be the SetElement pattern > from Collections which is completely transparent. But this would > probably be too expensive for simulation purposes (because we > would need to instantiate one object per > simulated primitive call), right? > > > Not sure.  If instantiation can be deferred until failure then things > should be OK. > > Why not encode a failing primitive via a changed control > flow? Couldn't we pass an additional failBlock argument to > #doPrimitive:method:receiver:args:, #tryPrimitive:withArgs:/#tryNamedPrimitiveIn:for:withArgs:, > and #simulateValueWithArguments:caller: (and analogously to > ExternalFunction >> #tryInvokeWithArguments: and the critsect > primitive methods on Mutex)? > > > We can, but remember that passing a block is in fact hiding an > allocation, maybe two.  Mentioning a block in code causes it to be > allocated and if not already done so, causes allocation of the > lexically enclosing context. > > Then we could rewrite #send:to:with:lookupIn: like this (pseudo): > > send: selector to: rcvr with: arguments lookupIn: lookupClass >     "Simulate the action of sending a message with selector > and arguments to rcvr. The argument, lookupClass, is the class > in which to lookup the message. This is the receiver's class > for normal messages, but for super messages it will be some > specific class related to the source method." > >     | meth primFailCodeval ctxt | >     (meth := lookupClass lookupSelector: selector) ifNil: >         [selector == #doesNotUnderstand: ifTrue: >             [self error: 'Recursive message not understood!' > translated]. >         ^self send: #doesNotUnderstand: >                 to: rcvr >                 with: {(Message selector: selector arguments: > arguments) lookupClass: lookupClass} >                 lookupIn: lookupClass]. > >     meth isCompiledMethod ifFalse: >         ["Object as Methods (OaM) protocol: 'The contract is > that, when the VM encounters an ordinary object (rather than a > compiled method) in the method dictionary during lookup, it > sends it the special selector #run:with:in: providing the > original selector, arguments, and receiver.'. DOI: > 10.1145/2991041.2991062." >         ^self send: #run:with:in: >             to: meth >             with: {selector. arguments. rcvr}]. > >     meth numArgs = arguments size ifFalse: >         [^ self error: ('Wrong number of arguments in > simulated message {1}' translated format: {selector})]. >     (primIndex := meth primitive) > 0 ifTrue: > -         [val := self doPrimitive: primIndex method: meth > receiver: rcvr args: arguments. > -         (self isPrimFailToken: val) ifFalse: > -             [^val]]. > +         [val := self doPrimitive: primIndex method: meth > receiver: rcvr args: arguments ifFail: > +             [:code | primFailCode := code]. > +  primFailCode ifNil: [^ val]]. > >     (selector == #doesNotUnderstand: and: [lookupClass == > ProtoObject]) ifTrue: >         [^self error: ('Simulated message {1} not understood' > translated format: {arguments first selector})]. > >     ctxt := Context sender: self receiver: rcvr method: meth > arguments: arguments. > -     (primIndex isInteger and: [primIndex > 0]) ifTrue: > -         [ctxt failPrimitiveWith: val]. > +  primFailCode ifNotNil: > +       [ctxt failPrimitiveWith: primFailCode]. > >     ^ctxt > > > Current senders of #primitiveFailTokenFor: could then evaluate the > failBlock if the primitive fails. > Do you think this approach would be worth a try? :-) > > > Definitely.  It might eliminate multiple tests.  I think you should > definitely try it.  It looks nice to me.  Thank you! > > > Best, > Christoph > ------------------------------------------------------------------------ > *Von:* Squeak-dev > im Auftrag > von Eliot Miranda > > *Gesendet:* Freitag, 1. Januar 2021 22:34:28 > *An:* The general-purpose Squeak developers list > *Betreff:* Re: [squeak-dev] Two new curious Context/primitive > questions :-) > errata: > > On Fri, Jan 1, 2021 at 1:22 PM Eliot Miranda > > wrote: > Hi Christoph, > >     happy new year!! > > On Fri, Jan 1, 2021 at 11:28 AM Thiede, Christoph > > wrote: > > Hi all, hi Eliot, > > new year, new simulation fun, and I have collected two new > questions about the Context implementation which I'd love to > get answered here: > > First, I was confused by the following: > (BlockClosure >> #numArgs) primitive. "266" > (Context >> #pc) primitive. "0" > What makes Context so special that it cannot be compiled with > quick accessor methods? > > > The gory details are here: > http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ > > > But that's full of implementation detail.  Let me try and explain > at a higher level. > > Contexts are wonderful but very expensive.  Any VM that actually > creates contexts for every method or block activation will > inevitably run slowly.  There are two overheads here. One is the > basic overhead of allocating and reclaiming the contexts that are > created. The other is the cost of moving the outgoing receiver and > arguments from the sending context to the new context.  A fast VM > must avoid these overheads, and the key solution is to use a stack > frame organization as is used in conventional language > implementations.  The key here is that with stack frames the > receiver and incoming arguments do not have to be moved; they stay > where they are and a new frame is built underneath them which > includes them as the incoming receiver and arguments; stack frames > overlap outgoing and incoming arguments. > > But crucially, in addition the VM must still create contexts if > and when they are needed.  If not, this would no longer be a > Smalltalk-80 implementation.  Now one could imagine a VM which > converted stack frames to contexts whenever a method or block > activation was accessed using thisContext (or thisContext sender > etc which access contexts by following the sender field). But that > would be very slow.  Instead, the fastest approach is to try and > keep stack frames as stack frames for as long as possible.  For > this to work contexts have to be able to function as "proxy > objects" for stack frames.  The VM does indeed create contexts > when one uses thisContext, or even when one creates a block, but > internally the context is in a very special state, a state in > which it points at a stack frame. > > Some terminology is useful.  Peter Deutsch used "volatile", > "hybrid" and "stable".  I like "single", "married", "widowed" and > "divorced" (Peter's scheme didn't have "widowed" which is the key > to why my scheme is faster, and why the closure implementation is > as it is). > > When a stack frame is created it is "single".  It has a slot > within it to refer to a context object if it is needed, but the > slot is nil. > When a stack frame needs a context object one is created and the > two are "married". > When a method or block returns its stack frame is discarded; the > stack frame has died and if it was married its context becomes > "widowed". (*) > When space is needed for new stack frames all reclaimed stack > frames are "divorced" from their contexts.  The stack frame state > is written to the context object and the context object no longer > acts as a proxy; it is a fully fledged normal stack object. (*) > > (*) Stack frames exist in a small memory zone organized as stack > pages, the stack zone. The size of the stack zone is set at > startup, and its size is either the VM's default or set by a value > that persists in the image header (see vmParameterAt: 43).  Since > the system may run out of stack pages (a deep call stack, many > active processes), the VM makes new pages available by purging the > least recently used pages to the heap in the form of context > objects.  All the frames in the least recently used stack page are > divorced at the same time. A context must be created for each > frame that is not yet married.A page is big enough to hold on > average about 40 method activations; since activations are of > different sizes and change size as execution proceeds, the number > of activations per full page varies. > > (*) The reason why Peter's original scheme is slower is that in > HPS at return time the VM has to check for a frame being > hybrid and copy state to the hybrid context, making it stable.  > This has to be done because a closure's outer temporary variables > are stored in the lexically enclosing stack frame, and so have to > be made to persist in the stable context or their values will be > stale.  In my (lisp-derived) closure implementation there are no > such references to outer temporary variables; values are either > copied if they do not change, or stored in an Array (the > "indirection vector"), which can then be copied. > > Note that divorce is a process.  Once divorced a context is single > and free to function as a context does.  Indeed when the system > starts up it loads an image which only contains single contexts.  > All contexts are divorced on snapshot. Divorced contexts are > amnesiacs. > > > So now, finally, we can answer your question.  Why is > (Context>>#pc), a method that simply answers an instance variable, > not compiled as a quick method with a primitive that answers that > variable?  "married" and "widowed" contexts are proxies for stack > frames.  Only the instance variables they contain which do not > change can be fetched from the context object itself; these are > the receiver, arguments, closureOrNil, and method. sender, pc, > stackp and other stack contents may change as execution proceeds. > These mutable values must be fetched from the stack frame itself, > if it still exists. > > All accesses to sender, pc, stackp, and stack contents > (Context>>at:[put:]) must be mediated.  A married or widowed > context has its sender field set to the frame pointer of its stack > frame, encoded as a SmallInteger. You can never see this from the > image (except via a special xRay primitive). By following the > frame pointer encoded in the sender field the VM can detect if the > frame is still live.  If so, the relevant values are synthesized > or fetched from the stack frame itself.  If not, the context is > widowed and "mourns"; it is changed into a context with a nil > sender field, a nil pc, and a stackp that points at the last argument. > > How is this mediation done?  One design could be to require that > all image level accesses to Context inst vars are through > primitives. This feels contrived to me.  Instead, inst var access > is via inst var access bytcodes. But if we do this naively we > would have to check in all inst var access bytecodes whose index > is the same as sender (0), pc (1) & stackp (2).  This would slow > down inst var access enormously.  Instead we observe that inst var > access bytecodes pushReceiverVariable:, popIntoReceiverVariable: > have short forms for the most frequently used (indexes 0 to 15 for > push, indexes 0 to 7 for popInto). By arranging that we only use > the long forms for accessing inst vars in Context, and > superclasses and subclasses, we only have to check in the long > forms and the check is cheap.  We check that the index is <= 2, > because all other inst var accesses with these indices will use > the short-form bytecodes. > > By arranging that Context's inst vars are *not* accessed by quick > primitives we do not have to duplicate this machinery in quick > primitive dispatch, which would also slow things down.  Hence > Context>>pc is compiled as a vanilla method and its inst var > access bytecode is the long form: > > 25 pushRcvr: 1 > 27 <5C> returnTop > > 'Nuff said > > Second, Context >> #isPrimFailToken: attracted my attention > multiple times when looking at different #timeProfile results > of simulation sessions. In the expression [100000 factorial] > it takes up more than 44% of the whole execution time! > I have no idea why it could be so slow, but this message is > sent really often, which is at least 2 times per simulation of > a special message send. > Would there be an easy change to resolve this bottleneck and > speed up the simulation by 40% or more? > Would it be possible to provide a primitive for this method? > Or do you see any other way to optimize it? > > > It's not slow so much as that it has to be used all the time to > check whether a send has invoked a primitive which has failed.  > Its function is to support primitive error codes. Before primitive > error codes (IIRC) we simply checked for nil. But with primitive > error codes we need a container that both reliably distinguishes a > primitive failure result from all other objects in the system, and > holds onto the primitive failure code.  It may indeed be able to > reduce the overhead by only testing when absolutely necessary.  It > may be that reimplementing the scheme is faster. > > For example, one could imagine a class whose instances are the > only objects to answer #isPrimFailToken, which would be faster > than a one argument message send.  But beware, because if one was > debugging the debugger one mustn't confuse a PrimFailToken created > in the simulation for a PrimFailToken created by the simulation. > Remember to distinguish between price and value. Implementing the > context-to-stack mapping scheme outlined above was very costly, > but its value is very high.  It allows us to have contexts, with > all their utility, while reducing their costs significantly. > Similarly, and closely related, being able to simulate execution > is costly but hugely valuable.  If the price is 40% of simulated > execution then it is a price worth paying. > > Best, > Christoph > > > Happy New Year! > > _,,,^..^,,,_ > best, Eliot > > > > -- > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Wed Jan 6 07:22:26 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Wed, 6 Jan 2021 08:22:26 +0100 Subject: [squeak-dev] Two new curious Context/primitive questions :-) In-Reply-To: References: Message-ID: <3F45191D-F58A-45DD-AE6E-3C33357EBFC4@gmx.de> > On 6. Jan 2021, at 03:05, Vanessa Freudenberg wrote: > > This was a very interesting read - thank you Eliot! That should go in some book :) Fast Smalltalk by Example… A collection of VM essays let's do it. -t > > Another overview is in the class comment for MaybeContextInstanceVariableNode. Which I found by trying to figure out how the heck the compiler knows to use the long form for inst var refs in Context. > > Vanessa > > On Fri, Jan 1, 2021 at 1:23 PM Eliot Miranda wrote: > Hi Christoph, > > happy new year!! > > On Fri, Jan 1, 2021 at 11:28 AM Thiede, Christoph wrote: > Hi all, hi Eliot, > > > new year, new simulation fun, and I have collected two new questions about the Context implementation which I'd love to get answered here: > > > First, I was confused by the following: > > > (BlockClosure >> #numArgs) primitive. "266" > (Context >> #pc) primitive. "0" > What makes Context so special that it cannot be compiled with quick accessor methods? > > The gory details are here: http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ > > But that's full of implementation detail. Let me try and explain at a higher level. > > Contexts are wonderful but very expensive. Any VM that actually creates contexts for every method or block activation will inevitably run slowly. There are two overheads here. One is the basic overhead of allocating and reclaiming the contexts that are created. The other is the cost of moving the outgoing receiver and arguments from the sending context to the new context. A fast VM must avoid these overheads, and the key solution is to use a stack frame organization as is used in conventional language implementations. The key here is that with stack frames the receiver and incoming arguments do not have to be moved; they stay where they are and a new frame is built underneath them which includes them as the incoming receiver and arguments; stack frames overlap outgoing and incoming arguments. > > But crucially, in addition the VM must still create contexts if and when they are needed. If not, this would no longer be a Smalltalk-80 implementation. Now one could imagine a VM which converted stack frames to contexts whenever a method or block activation was accessed using thisContext (or thisContext sender etc which access contexts by following the sdender field). But that would be very slow. Instead, the fastest approach is to try and keep stack frames as stack frames for as long as possible. For this to work contexts have to be able to function as "proxy objects" for stack frames. The VM does indeed create contexts when one uses thisContext, or even when one creates a block, but internally the context is in a very special state, a state in which it points at a stack frame. > > Some terminology is useful. Peter Deutsch used "volatile", "hybrid" and "stable". I like "single", "married", "widowed" and "divorced" (Peter's scheme didn't have "widowed" which is the key to why my scheme is faster, and why the closure implementation is as it is). > > When a stack frame is created it is "single". It has a slot within it to refer to a context object if it is needed, but the slot is nil. > When a stack frame needs a context object one is created and the two are "married". > When a method or block returns its stack frame is discarded; the stack frame has died and if it was married its context becomes "widowed". (*) > When space is needed for new stack frames all reclaimed stack frames are "divorced" from their contexts. The stack frame state is written to the context object and the context object no longer acts as a proxy; it is a fully fledged normal stack object. (*) > > (*) Stack frames exist in a small memory zone organized as stack pages, the stack zone. The size of the stack zone is set at startup, and its size is either the VM's defaut oir set by a value that persists in the image header (see vmParameterAt: 43). Since the system may run out of stack pages (a deep call stack, many active processes), the VM makes new pages available by purging the least recently used pages to the heap in the form of context objects. All the frames in the least recently used stack page are divorced at the same time. A context must be created for each frame that is not yet married. > > (*) The reason why Peter's original scheme is slower is that at return time the VM has to check for being married and copy state to the hybrid context, making it stable. This has to be done because a closure's outer temporary variables are stored in the lexically enclosing stack frame, and so have to be made to persist in the stable context or their values will be stale. In my (lisp-derived) closure implementation there are no such references to outer temporary variables; values are either copied if they do not change, or stored in an Array (the "indirection vector"), which can then be copied. > > Note that divorce is a process. Once divorced a context is single and free to function as a context does. Indeed when the system starts up it loads an image which only contains single contexts. All contexts are divorced on snapshot. > > > So now, finally, we can answer your question. Why is (Context>>#pc), a method that simply answers an instance variable, not compiled as a quick method with a primitive that answers that variable? "married" and "widowed" contexts are proxies for stack frames. Only the instance variables they contain which do not change can be fetched from the context object itself; these are the receiver, arguments, closureOrNil, and method. sender, pc, stackp and other stack contents may change as execution proceeds. These mutable values must be fetched from the stack frame itself, if it still exists. > > All accesses to sender, pc, stackp, and stack contents (Context>>at:[put:]) must be mediated. A married or widowed context has its sender field set to the frame pointer of its stack frame, encoded as a SmallInteger. You can never see this from the image (except via a special xRay primitive). By following the frame pointer encoded in the sender field the VM can detect if the frame is still live. If so, the relevant values are synthesized or fetched from the stack frame itself. If not, the context is widowed and "mourns"; it is changed into a context with a nil sender field, a nil pc, and a stackp that points at the last argument. > > How is this mediation done? One design could be to require that all image level accesses to Context inst vars are through primitives. This feels contrived to me. Instead, inst var access is via inst var access bytcodes. But if we do this naively we would have to check in all inst var access bytecodes whose index is the same as sender (0), pc (1) & stackp (2). This would slow down inst var access enormously. Instead we observe that inst var access bytecodes pushReceiverVariable:, popIntoReceiverVariable: have short forms for the most frequently used (indexes 0 to 15 for push, indexes 0 to 7 for popInto). By arranging that we only use the long forms for accessing inst vars in Context, and superclasses and subclasses, we only have to check in the long forms and the check is cheap. We check that the index is <= 2, because all other inst var accesses with these indices will use the short-form bytecodes. > > By arranging that Context's inst vars are *not* accessed by quick primitives we do not have to duplicate this machinery in quick primitive dispatch, which would also slow things down. Hence Context>>pc is compiled as a vanilla method and its inst var access bytecode is the long form: > > 25 pushRcvr: 1 > 27 <5C> returnTop > > 'Nuff said > Second, Context >> #isPrimFailToken: attracted my attention multiple times when looking at different #timeProfile results of simulation sessions. In the expression [100000 factorial] it takes up more than 44% of the whole execution time! > I have no idea why it could be so slow, but this message is sent really often, which is at least 2 times per simulation of a special message send. > Would there be an easy change to resolve this bottleneck and speed up the simulation by 40% or more? > Would it be possible to provide a primitive for this method? Or do you see any other way to optimize it? > > It's not slow, so much as it has to be used all the time to check whether a send has invoked a primitive which has failed. Its function is to support primitive error codes. Without it we can simply check for nil. But with it we need a container that both reliably distinguishes a primitive failure result from all other objects in the system, and holds onto the primitive failure code. It may indeed be able to reduce the overhead by only testing when absolutely necessary. It may be that reimplementing the scheme is faster. > > For example, one could imagine a class whose instances are the only objects to answer #isPrimFailToken, which would be faster than a one argument message send. But beware, because if one was debugging the debugger one mustn't confuse a PrimFailToken created in the simulation for a PrimFailToken created by the simulation. > Remember to distinguish between price and value. Implementing the context-to-stack mapping scheme outlined above was very costly, but its value is very high. It allows us to have contexts, with all their utility, while reducing their costs significantly. Similarly, and closely related, being able to simulate execution is costly but hugely valuable. If the price is 40% of simulated execution then it is a price worth paying. > > Best, > Christoph > > Happy New Year! > > _,,,^..^,,,_ > best, Eliot > > From commits at source.squeak.org Wed Jan 6 09:33:36 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 6 Jan 2021 09:33:36 0000 Subject: [squeak-dev] The Trunk: ST80-mt.263.mcz Message-ID: Marcel Taeumel uploaded a new version of ST80 to project The Trunk: http://source.squeak.org/trunk/ST80-mt.263.mcz ==================== Summary ==================== Name: ST80-mt.263 Author: mt Time: 6 January 2021, 10:33:34.521417 am UUID: 06e12acc-4e20-0c4c-9e25-ca0838ccf765 Ancestors: ST80-mt.262 Fixes auto-indent bug in MVC text editors by supporting type-aheads with size > 1 outside the context of copy-paste (and similar) in #zapSelectionWithCompositionWith:. Note that dynamic character composition is not supported in Morphic's TextEditor, I suppose. We might want to add that, too. Yoshiki added this feature in 2007 only to ST80/MVC. =============== Diff against ST80-mt.262 =============== Item was changed: ----- Method: ParagraphEditor>>zapSelectionWithCompositionWith: (in category 'accessing-selection') ----- zapSelectionWithCompositionWith: aString "Deselect, and replace the selection text by aString. Remember the resulting selectionInterval in UndoInterval and otherInterval. Do not set up for undo." | stream newString aText beforeChar | wasComposition := false. ((aString isEmpty or: [(beforeChar := self charBefore) isNil]) or: [ + aString size >= 1 and: [(Unicode isComposition: aString first) not]]) ifTrue: [ - aString size = 1 and: [(Unicode isComposition: aString first) not]]) ifTrue: [ ^ self zapSelectionWith: (Text string: aString emphasis: emphasisHere)]. stream := UnicodeCompositionStream on: (String new: 16). stream nextPut: beforeChar. stream nextPutAll: aString. newString := stream contents. aText := Text string: newString emphasis: emphasisHere. self markBlock < self pointBlock ifTrue: [self setMark: self markBlock stringIndex - 1] ifFalse: [self setPoint: self pointBlock stringIndex - 1]. wasComposition := true. self zapSelectionWith: aText. ! From commits at source.squeak.org Wed Jan 6 09:54:52 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 6 Jan 2021 09:54:52 0000 Subject: [squeak-dev] The Trunk: ToolBuilder-MVC-mt.63.mcz Message-ID: Marcel Taeumel uploaded a new version of ToolBuilder-MVC to project The Trunk: http://source.squeak.org/trunk/ToolBuilder-MVC-mt.63.mcz ==================== Summary ==================== Name: ToolBuilder-MVC-mt.63 Author: mt Time: 6 January 2021, 10:54:51.611417 am UUID: 3d989178-1d1f-9343-b240-39472ac722dd Ancestors: ToolBuilder-MVC-mt.62, ToolBuilder-MVC-ct.60 Merges ToolBuilder-MVC-ct.60, which got shadowed by ToolBuilder-MVC-TheresaHMartenK.60 last June. =============== Diff against ToolBuilder-MVC-mt.62 =============== Item was changed: ----- Method: MVCToolBuilder>>open: (in category 'opening') ----- open: anObject "Build and open the object. Answer the widget opened." | window | + window := (anObject isKindOf: View orOf: PopUpMenu) - window := (anObject isKindOf: View) ifTrue: [anObject] ifFalse: [self build: anObject]. (window isKindOf: PopUpMenu) ifTrue: [window invokeOn: nil]. (window isKindOf: View) ifTrue: [window controller open]. ^window! From commits at source.squeak.org Wed Jan 6 10:12:17 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 6 Jan 2021 10:12:17 0000 Subject: [squeak-dev] The Trunk: Tools-mt.1023.mcz Message-ID: Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-mt.1023.mcz ==================== Summary ==================== Name: Tools-mt.1023 Author: mt Time: 6 January 2021, 11:12:15.085417 am UUID: cc33f893-f9b4-2047-a2f9-b085897e017f Ancestors: Tools-eem.1022 Improve robustness against erroneous menu builders. =============== Diff against Tools-eem.1022 =============== Item was changed: ----- Method: Model>>buildMenu:withBuilders:shifted: (in category '*Tools-pluggable menus') ----- buildMenu: aMenu withBuilders: builders shifted: aBoolean + " We let every builder modify the menu. Skip erroneous builders silently. - " We let every builder modify the menu. The builder should indicate whether to abort by returning nil." | menu | menu := aMenu. builders do: [:builder | + menu := [self perform: builder method selector withEnoughArguments: { menu . aBoolean }] + ifError: [:msg | Transcript showln: 'Menu builder failed: ', msg. menu]. - menu := self perform: builder method selector withEnoughArguments: { menu . aBoolean }. menu ifNil: [^ aMenu]]. ^ menu ! From commits at source.squeak.org Wed Jan 6 21:59:33 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 6 Jan 2021 21:59:33 0000 Subject: [squeak-dev] The Trunk: System-dtl.1210.mcz Message-ID: David T. Lewis uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-dtl.1210.mcz ==================== Summary ==================== Name: System-dtl.1210 Author: dtl Time: 6 January 2021, 4:59:31.092128 pm UUID: a704d749-4986-46f9-aa2f-faa8bb4ea5e1 Ancestors: System-eem.1207 Provide vmParameterAt:ifAbsent: to handle primitive failure on reading VM parameters. Supply default parameter values to mock possibly missing elements in the parameters array. =============== Diff against System-eem.1207 =============== Item was changed: ----- Method: SmalltalkImage>>isRunningCog (in category 'system attributes') ----- isRunningCog "Answers if we're running on a Cog VM (JIT or StackInterpreter)" + ^(self vmParameterAt: 42 ifAbsent: nil) - ^(self vmParameterAt: 42) ifNil: [false] ifNotNil: [:numStackPages| numStackPages > 0]! Item was changed: ----- Method: SmalltalkImage>>isRunningCogit (in category 'system attributes') ----- isRunningCogit "Answers if we're running on the Cog JIT" + ^(self vmParameterAt: 46 ifAbsent: nil) - ^(self vmParameterAt: 46) ifNil: [false] ifNotNil: [:machineCodeZoneSize| machineCodeZoneSize > 0]! Item was changed: ----- Method: SmalltalkImage>>lowSpaceThreshold (in category 'memory space') ----- lowSpaceThreshold "Answer the low space threshold. When the amount of free memory (after garbage collection) falls below this limit, the system is in serious danger of completely exhausting memory and crashing. This limit should be made high enough to allow the user open a debugger to diagnose a problem or to save the image. In a stack-based VM such as Cog contexts for activations in the stack zone will have to be created as the debugger opens, requiring additional headroom." | slotsForDebugger slotsForContextsOnStackPages | slotsForDebugger := 65536. "Arbitrary guess" slotsForContextsOnStackPages := + (self vmParameterAt: 42 ifAbsent: nil) - (self vmParameterAt: 42) ifNil: [0] ifNotNil: [:numStackPages| | headerSize numActivationsPerPage maxContextSize | numActivationsPerPage := 40. "Design goal of the Cog & Stack VMs" headerSize := 8 / self wordSize. "64-bits for Spur" maxContextSize := thisContext class instSize + CompiledMethod fullFrameSize + headerSize. numStackPages * numActivationsPerPage * maxContextSize]. ^slotsForDebugger + slotsForContextsOnStackPages * self wordSize! Item was changed: ----- Method: SmalltalkImage>>maxExternalSemaphores (in category 'vm parameters') ----- maxExternalSemaphores + "The size of table where external semaphores are registered. Only in Cog, + other VMs are expected to answer nil if present in the parameters array." + ^self vmParameterAt: 49 ifAbsent: nil! - "The size of table where external semaphores are registered. Only in Cog" - self isRunningCog ifFalse: [^nil]. - ^self vmParameterAt: 49! Item was changed: ----- Method: SmalltalkImage>>maxExternalSemaphores: (in category 'vm parameters') ----- maxExternalSemaphores: aSize "Changes the size of table where external semaphores are registered. The size can only grow, and will always be the next power of two larger than the parameter. Setting this at any time other than start-up can potentially lose requests. i.e. during the realloc new storage is allocated, the old contents are copied and then pointers are switched. Requests occurring during copying won't be seen if they occur to indices already copied. The intended use is to set the table to some adequate maximum at start-up" - self isRunningCog ifFalse: [^0]. "The vm-header field is a short, maximum 64k entries. Well, on most platforms anyways " (aSize < 0 or: [aSize > 16rFFFF]) ifTrue: [^self error: 'maxExternalSemaphores: is limited to 16rFFFF']. + ^[self vmParameterAt: 49 put: aSize] on: Error do: [0].! - ^self vmParameterAt: 49 put: aSize! Item was changed: ----- Method: SmalltalkImage>>processPreemptionYields (in category 'system attributes') ----- processPreemptionYields "Answer whether the VM causes a process to yield on process preemption, i.e. to put a preempted process at the back of its run queue. If the parameter is unavailable (non-Cog VMs) or bit 2 (4) is 0 then preemption yields." + ^((self vmParameterAt: 48 ifAbsent: [^true]) allMask: 4) not + ! - ^(([self vmParameterAt: 48] - on: Error - do: [:ex| ^true]) allMask: 4) not! Item was changed: ----- Method: SmalltalkImage>>sendMouseWheelEvents (in category 'system attributes') ----- sendMouseWheelEvents "The Cog VM can be instructed to deliver mouse wheel events as mouse wheel events. By default mouse wheel events are mapped to arrow events. This flag persists across snapshots, stored in the image header." + ^(self vmParameterAt: 48 ifAbsent: 0) anyMask: 32! - ^(self vmParameterAt: 48) anyMask: 32! Item was changed: ----- Method: SmalltalkImage>>supportsMultipleBytecodeSets (in category 'system attributes') ----- supportsMultipleBytecodeSets "Answer whether the VM supports multiple bytecodeSets." "SmalltalkImage current supportsMultipleBytecodeSets" + ^(self vmParameterAt: 65 ifAbsent: nil) - ^(self vmParameterAt: 65) ifNil: [false] ifNotNil: [:param| "In older VMs this is a boolean answering the vm-internal MULTIPLE_BYTECODE_SETS define" param isInteger "In newer VMs it is a set of integer flags, bit 0 of which is the vm-internal MULTIPLE_BYTECODE_SETS define" ifTrue: [param anyMask: 1] ifFalse: [param]]! Item was changed: ----- Method: SmalltalkImage>>supportsQueueingFinalization (in category 'system attributes') ----- supportsQueueingFinalization "Answer whether the VM queues individual weak arrays for finalization, instead of signalling the finalization semaphore once for all arrays and having the WeakRegistry mechanism finalize all weak arrays, whether they need to or not." "SmalltalkImage current supportsQueueingFinalization" + ^(self vmParameterAt: 48 ifAbsent: 0) anyMask: 16! - ^(self vmParameterAt: 48) anyMask: 16! Item was changed: ----- Method: SmalltalkImage>>supportsQueueingFinalization: (in category 'system attributes') ----- supportsQueueingFinalization: aBoolean "Determine whether the VM queues individual weak arrays for finalization, instead of signalling the finalization semaphore once for all arrays and having the WeakRegistry mechanism finalize all weak arrays, whether they need to or not. This flag persists across snapshots, stored in the image header." "SmalltalkImage current supportsQueueingFinalization: true" + self vmParameterAt: 48 put: ((self vmParameterAt: 48 ifAbsent: [^false]) bitClear: 16) + (aBoolean ifTrue: [16] ifFalse: [0])! - self vmParameterAt: 48 put: ((self vmParameterAt: 48) bitClear: 16) + (aBoolean ifTrue: [16] ifFalse: [0])! Item was changed: ----- Method: SmalltalkImage>>supportsReadOnlyObjects (in category 'system attributes') ----- supportsReadOnlyObjects "Answer whether the VM observes the per-object read-only flag and consequently aborts writes to inst vars of, and fails primitives that attempt to modify, read-only objects." "SmalltalkImage current supportsReadOnlyObjects" + ^(self vmParameterAt: 65 ifAbsent: nil) - ^(self vmParameterAt: 65) ifNil: [false] ifNotNil: [:param| "In older VMs this is a boolean answering the vm-internal MULTIPLE_BYTECODE_SETS define" param isInteger "In newer VMs it is a set of integer flags, bit 1 of which is the vm-internal IMMUTABILITY define" ifTrue: [param anyMask: 2] ifFalse: [false]]! Item was added: + ----- Method: SmalltalkImage>>vmParameterAt:ifAbsent: (in category 'vm parameters') ----- + vmParameterAt: parameterIndex ifAbsent: defaultValueOrBlock + "Answer a VM parameter or defaultValueOrBlock value if out of range." + ^ [self vmParameterAt: parameterIndex] + on: Error + do: [defaultValueOrBlock value]! Item was changed: ----- Method: SmalltalkImage>>wordSize (in category 'image') ----- wordSize "Answer the size in bytes of an object pointer or word in the object memory. The value does not change for a given image, but may be modified by a SystemTracer when converting the image to another format. The value is cached in WordSize to avoid the performance overhead of repeatedly consulting the VM." "Smalltalk wordSize" + ^ WordSize ifNil: [WordSize := self vmParameterAt: 40 ifAbsent: 4]! - ^ WordSize ifNil: [WordSize := [self vmParameterAt: 40] on: Error do: [4]]! From marcel.taeumel at hpi.de Thu Jan 7 11:27:35 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 7 Jan 2021 12:27:35 +0100 Subject: [squeak-dev] A discrepancy between bytecode execution and simulation In-Reply-To: <988ce7a9038f45aca5cf17177933e6a9@student.hpi.uni-potsdam.de> References: <,> <988ce7a9038f45aca5cf17177933e6a9@student.hpi.uni-potsdam.de> Message-ID: > Yahoo, a Meta-Object Facility adoption for Smalltalk systems. There is already a powerful MOP (meta-object protocol) in Squeak/Smalltalk. Take #class etc. Yet, Newspeak's mirrors feel more clean and explicit. Best, Marcel Am 06.01.2021 01:30:13 schrieb Thiede, Christoph : > Maybe it makes sense to think in terms of "simulation depth"? In a non-debugging scenario, that "simulation depth" is 0 because no simulation code is executed. When you debug/simulate your application code, depth is 1. When you debug/simulate the simulation code, depth is 2. If one would construct deeper "simulate the simulating simulator" processes, depth can be greater than 2. :-) Yahoo, a Meta-Object Facility adoption for Smalltalk systems. :-) And depth -1 would correspond to the Slang-generated VM implementation, right? ;-) Best, Christoph Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 8. Dezember 2020 13:44:09 An: squeak-dev Betreff: Re: [squeak-dev] A discrepancy between bytecode execution and simulation   Hi Christoph > [...] between simulation and production (btw did I choose the right terms for them? :) Since code simulation needs code execution, I think that "simulation" is a part of "execution". Maybe it makes sense to think in terms of "simulation depth"? In a non-debugging scenario, that "simulation depth" is 0 because no simulation code is executed. When you debug/simulate your application code, depth is 1. When you debug/simulate the simulation code, depth is 2. If one would construct deeper "simulate the simulating simulator" processes, depth can be greater than 2. :-) "Production" is then simulation depth 0. :-D Best, Marcel Am 07.12.2020 18:55:31 schrieb Thiede, Christoph : Hi all, hi Eliot, I constructed the following code snippet which evaluates to true when running it using the production execution machinery: nil == thisContext pop I guess this is fine, because what alternatives would the execution machinery have? It could terminate the whole VM or we could introduce something like #cannotReturn: for invalid stack frame objects. Probably the current implementation is the best despite an invalid position in the context stack has been addressed. However, the simulation machinery treats the same snippet differently, and it throws: Error: subscript is out of bounds: 0 I wonder whether it is acceptable to have diverging behaviors for such an ill-defined edge case between simulation and production (btw did I choose the right terms for them? :)). Might it a better alternative to raise a Warning (#notify:) only and then return nil such as the VM appears to do? Best, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Thu Jan 7 11:37:42 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 7 Jan 2021 12:37:42 +0100 Subject: [squeak-dev] [ANN] Update on my current work In-Reply-To: References: Message-ID: Hi Stef, nice! Thank you. Note that your project is listed on https://squeak.org/projects/ under "Rogue Game Engine". Best, Marcel Am 05.01.2021 20:58:23 schrieb Stéphane Rollandin : Hello all, I have just released an updated image of my current work, including the development snapshot of a 2.5D adventure game engine: http://www.zogotounga.net/comp/squeak/rogue.htm See details and demos in the image. -- New stuff (that I can think of right now): improved controls tactical navigation a different representation for dark areas incremental floor textures nicer baobabs! many more monsters, better animated spiders and rock golems a recursive dungeon floor spawner terrains (water, lava) doors utility methods for color tweaking, better gradient fills dice-rolling improvements again, this is all described or demo-ed in the image itself -- Best, Stef -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank-lesser at lesser-software.com Thu Jan 7 14:27:41 2021 From: frank-lesser at lesser-software.com (Frank Lesser) Date: Thu, 7 Jan 2021 15:27:41 +0100 Subject: [squeak-dev] [ANN] Update on my current work In-Reply-To: References: Message-ID: <2130ec2b-a3a1-1a16-20ba-3b39d4a6753c@lesser-software.com> I have started my first survey on twitter about Smalltalk future development https://twitter.com/LesserFrank/status/1347186405085163523?s=20 Frank On 1/7/2021 12:37, Marcel Taeumel wrote: > Hi Stef, > > nice! Thank you. Note that your project is listed on > https://squeak.org/projects/ under "Rogue Game Engine". > > Best, > Marcel >> >> Am 05.01.2021 20:58:23 schrieb Stéphane Rollandin >> : >> >> Hello all, >> >> I have just released an updated image of my current work, including the >> development snapshot of a 2.5D adventure game engine: >> >> http://www.zogotounga.net/comp/squeak/rogue.htm >> >> See details and demos in the image. >> >> -- >> >> New stuff (that I can think of right now): >> >> improved controls >> tactical navigation >> a different representation for dark areas >> incremental floor textures >> nicer baobabs! >> many more monsters, better animated spiders and rock golems >> a recursive dungeon floor spawner >> terrains (water, lava) >> doors >> utility methods for color tweaking, better gradient fills >> dice-rolling improvements >> >> again, this is all described or demo-ed in the image itself >> >> -- >> >> Best, >> >> Stef >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank-lesser at lesser-software.com Thu Jan 7 14:30:23 2021 From: frank-lesser at lesser-software.com (Frank Lesser) Date: Thu, 7 Jan 2021 15:30:23 +0100 Subject: [squeak-dev] [ANN] Update on my current work In-Reply-To: <2130ec2b-a3a1-1a16-20ba-3b39d4a6753c@lesser-software.com> References: <2130ec2b-a3a1-1a16-20ba-3b39d4a6753c@lesser-software.com> Message-ID: ups sorry wrong topic From lecteur at zogotounga.net Thu Jan 7 20:59:38 2021 From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=) Date: Thu, 7 Jan 2021 21:59:38 +0100 Subject: [squeak-dev] [ANN] Update on my current work In-Reply-To: References: Message-ID: <11cff6c9-4dd3-0ae5-df4c-d85123a53c5e@zogotounga.net> > nice! Thank you. Note that your project is listed on > https://squeak.org/projects/ under "Rogue Game Engine". Ah! The baobabs are nicer now :) Stef From eliot.miranda at gmail.com Fri Jan 8 00:15:03 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu, 7 Jan 2021 16:15:03 -0800 Subject: [squeak-dev] The Trunk: Files-eem.184.mcz In-Reply-To: <1609892201726-0.post@n4.nabble.com> References: <1609892201726-0.post@n4.nabble.com> Message-ID: On Tue, Jan 5, 2021 at 4:16 PM Christoph Thiede < christoph.thiede at student.hpi.uni-potsdam.de> wrote: > That's interesting. The VM generates a drag'n'drop event when a new (USB?) > device is plugged in? Why??? :-) > Because the Mac delivers notifications of insertion of USB devices via Drag & Drop events. Since this notification is potentially useful it's better to have primDropRequestFileName: filter out the misunderstood event than have the VM not deliver the event in the first place. I'm extending the DropPlugin with support for primDropRequestURI: and then different kinds of notifications come in as having different URL schemes. This means that EventSensor can do the filtering, which should be nicer. Give us a few days to deliver this. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Fri Jan 8 13:56:21 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 8 Jan 2021 13:56:21 0000 Subject: [squeak-dev] The Inbox: Graphics-mt.445.mcz Message-ID: A new version of Graphics was added to project The Inbox: http://source.squeak.org/inbox/Graphics-mt.445.mcz ==================== Summary ==================== Name: Graphics-mt.445 Author: mt Time: 8 January 2021, 2:56:15.018507 pm UUID: 66fc9fef-60ca-9e4f-b6f1-743c92f25e0f Ancestors: Graphics-nice.444 Proposal. Adds #larger and #smaller to font objects. Just like color objects understand #ligher and #darker. Examples: TextStyle defaultFont smaller. Preferences standardButtonFont larger. =============== Diff against Graphics-nice.444 =============== Item was added: + ----- Method: AbstractFont>>adjustPointSize: (in category 'transformations') ----- + adjustPointSize: delta + "Implementation based on Preferences class >> #setDefaultFonts:" + + ^ (((TextStyle named: self familyName) ifNil: [TextStyle default]) + fontOfPointSize: self pointSize + delta) + emphasized: self emphasis! Item was added: + ----- Method: AbstractFont>>larger (in category 'transformations') ----- + larger + + ^ self adjustPointSize: 3! Item was added: + ----- Method: AbstractFont>>smaller (in category 'transformations') ----- + smaller + + ^ self adjustPointSize: -3! From vanessa at codefrau.net Fri Jan 8 17:17:20 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Fri, 8 Jan 2021 09:17:20 -0800 Subject: [squeak-dev] V3 In-Reply-To: <20210106030254.CB28D8C07FC@proxy.email-ssl.com.br> References: <20210106030254.CB28D8C07FC@proxy.email-ssl.com.br> Message-ID: So with regard to the VM and in particular the byte code set, “V3” is completely wrong? Should we rename the Encoder subclass and related methods to something reasonable then? I believe Eliot introduced these names, what do you think? Vanessa On Tue, Jan 5, 2021 at 7:03 PM Jecel Assumpcao Jr wrote: > Vanessa, > > > Reading the code I again noticed "Squeak V3" as name for the old bytecode > > set. Always wanted to know: Where does the "V3" nomenclature come from? > > It was the format for the planned Squeak 3.0: > > https://wiki.squeak.org/squeak/750 > > > What's V1 and V2? > > They were never named, but you could consider the original Squeak to be > V1 and the one with Morphic in it to be V2, but I don't think there are > any significant changes between them. > > But please note that the V3 effort was abandoned, so in practice VI3 is > essentially the original Squeak image format. > > > And should we consider Sista to be V4, or treat it as completely > unrelated? > > There was a VI4 effort, also abandoned, that is linked from that page: > > https://wiki.squeak.org/squeak/2119 > > But Eliot's efforts to add closures did get adopted (third time's the > charm!) and yet it only got new image version numbers and not a new > name. So it is a VI3 format that doesn't match the previous meaning of > the term. Since none of those matter any more it is just odd but doesn't > actually cause any confusion. > > What is confusing is the use of the term both for the image format (VI3 > x Spur) and the bytecode set (VI3 x Sista). > > In any case, the 3 in VI3 was originally associated with the transition > from Squeak 2 to Squeak 3 and makes no sense in this Squeak 5 (soon 6) > era. > > -- Jecel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Fri Jan 8 19:27:49 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 8 Jan 2021 19:27:49 0000 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.270.mcz Message-ID: A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.270 Author: cbc Time: 8 January 2021, 11:27:47.8204 am UUID: abbbeb8a-9a8b-ef4a-b6a9-051b55cc2d5b Ancestors: ToolBuilder-Morphic-mt.269 Set the initial extent of the ListChooser to not require resizing the dialog for reasonable sized lists (i.e., expand it so you can see all of the list). At the small end, still object MT's suggested size; at the large end, will not take up more the 3/4ths of the world size. =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont width height | - - | listFont | listFont := Preferences standardListFont. + width := (items collect: [:item| listFont widthOfString: item]) max + 20 "Acutal size of items plus dialog buffer left/right" + max: (20 * (listFont widthOf: $m)). "but we want a not-too-small box as well" + height := ((items size max: 15) * listFont height) + 40. "for various other stuff in dialog above/below list" + "But, don't use the whole world." + width := width min: (self currentWorld extent x * 0.75) asInteger. + height := height min: (self currentWorld extent y * 0.75) asInteger. + ^ width at height! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! From eliot.miranda at gmail.com Sat Jan 9 04:08:33 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 8 Jan 2021 20:08:33 -0800 Subject: [squeak-dev] V3 In-Reply-To: References: Message-ID: Hi V, On Tue, Jan 5, 2021 at 6:07 PM Vanessa Freudenberg wrote: > Reading the code I again noticed "Squeak V3" as name for the old bytecode > set. Always wanted to know: Where does the "V3" nomenclature come from? > What's V1 and V2? And should we consider Sista to be V4, or treat it as > completely unrelated? > In my diseased and uninformed mind V3 came from my noticing that the double extended do anything bytecode didn't exist in Smalltalk-80, so I presumed it wasn't in Squeak V1. I don't know if it's in V2, and I was too lazy to go look, but I did know it was in V3, so I called it, and the object representation "V3". Presumptuous but concise of me. For me it really is a label for no more than the state of play of Squeak when I came to start changing its core execution engine. I hope this is harmless enough. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Sat Jan 9 15:09:21 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 9 Jan 2021 10:09:21 -0500 Subject: [squeak-dev] V3 In-Reply-To: References: Message-ID: <20210109150921.GA331@shell.msen.com> On Fri, Jan 08, 2021 at 08:08:33PM -0800, Eliot Miranda wrote: > Hi V, > > On Tue, Jan 5, 2021 at 6:07 PM Vanessa Freudenberg > wrote: > > > Reading the code I again noticed "Squeak V3" as name for the old bytecode > > set. Always wanted to know: Where does the "V3" nomenclature come from? > > What's V1 and V2? And should we consider Sista to be V4, or treat it as > > completely unrelated? > > > > In my diseased and uninformed mind V3 came from my noticing that the double > extended do anything bytecode didn't exist in Smalltalk-80, so I presumed > it wasn't in Squeak V1. I don't know if it's in V2, and I was too lazy to > go look, but I did know it was in V3, so I called it, and the object > representation "V3". Presumptuous but concise of me. For me it really is > a label for no more than the state of play of Squeak when I came to start > changing its core execution engine. I hope this is harmless enough. > I have become quite comfortable with the "V3" notation by now, regardless of its origins. I would prefer not to change it because I have used it extensively in some of my own personal projects (e.g. all of the package names in my http://www.squeaksource.com/TrunkUpdateStreamV3 hobby project). I also just like the name. "V3" is short and easily recognized, and it works nicely as a prefix or suffix in other names. To me, it also carries a vague connotation of "stable but not necessarily the latest thing". That's probably based on my recollection of early PC applications and operating systems where everyone knew not to trust any product until it reached at least version 3 ;-) Dave From gettimothy at zoho.com Sun Jan 10 13:17:07 2021 From: gettimothy at zoho.com (gettimothy) Date: Sun, 10 Jan 2021 08:17:07 -0500 Subject: [squeak-dev] =?utf-8?q?specifiying_the_character_class_range_for_?= =?utf-8?q?some_funky_characters_from_=C4=B0stanbul?= Message-ID: <176ec7176d9.cd538d0f1133.2722976116117842067@zoho.com> Hi Folks, My parser rules are not being invoked for certain character classes. For example, look at the İstanbul at this link:  https://en.wikipedia.org/w/index.php?title=Template:%C4%B0stanbul_B%C3%BCy%C3%BCk%C5%9Fehir_Belediyesi_sections&action=edit The PEG specifieds its own grammar and in that there is a "regex" character classes defined thusly. Escape <- BACKSLASH [x] [0-9A-F]{6} which specifies an '\' followed by an 'x' followed by 6 characters in the 0-9 and A-F ranges.  i.e. \x000FOO   I am guessing, but do not know, that I need a character class similar to the above that will handle the funky twirly above the "I" in İstanbul I have been using a code smell rule I call DotNot i.e. not the dot that has clearly outlived its usefullness.... DotNot <- [a-zA-Z0-9_\s\t\-\+\.\;\:\"\&\#\?\%\!\<\>\/\,\=\''\`\(\)\w]   That rule is used by other rules, to say "accept these characters" and for the links in the linked example that rule looks like: LinkFreeCaptioned <- OPEN_BRACKET{2} DotNot*  PipeCaption which does a great job on English, but barfs on Instanbul [[İstanbul Büyükşehir Belediyespor (basketball)|Basketball]] As you can see, the funky "I" is not in DotNot. I have flailed around aimlessly here: https://regexr.com/ to no avail. Pointers appreciated. cordially, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Sun Jan 10 15:13:26 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Sun, 10 Jan 2021 16:13:26 +0100 Subject: [squeak-dev] =?utf-8?q?specifiying_the_character_class_range_for_?= =?utf-8?q?some_funky_characters_from_=C4=B0stanbul?= In-Reply-To: <176ec7176d9.cd538d0f1133.2722976116117842067@zoho.com> References: <176ec7176d9.cd538d0f1133.2722976116117842067@zoho.com> Message-ID: <51452494-CBC1-4381-AD7F-C4E5686F4E74@gmx.de> > On 10. Jan 2021, at 14:17, gettimothy via Squeak-dev wrote: > > Hi Folks, > > My parser rules are not being invoked for certain character classes. > > For example, look at the İstanbul at this link: https://en.wikipedia.org/w/index.php?title=Template:%C4%B0stanbul_B%C3%BCy%C3%BCk%C5%9Fehir_Belediyesi_sections&action=edit > > > The PEG specifieds its own grammar and in that there is a "regex" character classes defined thusly. > > Escape <- BACKSLASH [x] [0-9A-F]{6} > > > which specifies an '\' followed by an 'x' followed by 6 characters in the 0-9 and A-F ranges. i.e. \x000FOO > > > I am guessing, but do not know, that I need a character class similar to the above that will handle the funky twirly above the "I" in İstanbul > > I have been using a code smell rule I call DotNot i.e. not the dot that has clearly outlived its usefullness.... > > DotNot <- [a-zA-Z0-9_\s\t\-\+\.\;\:\"\&\#\?\%\!\<\>\/\,\=\''\`\(\)\w] I think the \w does not do here what you think. What happens is that the upper case I with dot above is encoded as UTF-8-Sequences-Percent-Encoded. So you need a parser that is (a) aware of URL percent-escaping and (b) unicode/utf-8. That is not what you DotNot does. It can only ascii, I presume… What kind of Regex-lib do you use? Best regards -Tobias > > That rule is used by other rules, to say "accept these characters" and for the links in the linked example that rule looks like: > > LinkFreeCaptioned <- OPEN_BRACKET{2} DotNot* PipeCaption > > which does a great job on English, but barfs on Instanbul > > [[İstanbul Büyükşehir Belediyespor (basketball)|Basketball]] > As you can see, the funky "I" is not in DotNot. > > > I have flailed around aimlessly here: https://regexr.com/ to no avail. > > Pointers appreciated. > > cordially, > > > > From gettimothy at zoho.com Sun Jan 10 16:10:02 2021 From: gettimothy at zoho.com (gettimothy) Date: Sun, 10 Jan 2021 11:10:02 -0500 Subject: [squeak-dev] =?utf-8?q?specifiying_the_character_class_range_for_?= =?utf-8?q?some_funky_characters_from_=C4=B0stanbul?= In-Reply-To: <51452494-CBC1-4381-AD7F-C4E5686F4E74@gmx.de> References: <176ec7176d9.cd538d0f1133.2722976116117842067@zoho.com> <51452494-CBC1-4381-AD7F-C4E5686F4E74@gmx.de> Message-ID: <176ed0fc4f8.dff025262172.3931976022692755219@zoho.com> Hi Tobias. Thanks for the reply. I think the \w does not do here what you think. What happens is that the upper case I with dot above is encoded as UTF-8-Sequences-Percent-Encoded. So you need a parser that is (a) aware of URL percent-escaping and (b) unicode/utf-8. That is not what you DotNot does. It can only ascii, I presume… What kind of Regex-lib do you use? I have no idea.  I have basically inferred the functionality of the Grammar as I go with valuable insight from Levente. There are a couple of PEG Grammar rules in Xtreams-Parsing that uses the character class to define some rules, example: whitespace <- [\s\t\n\r] Identifier <- [a-zA-Z_] [a-zA-Z0-9_]* NumLiteral <- "Infinity" / "0" / [1-9] [0-9]* Escape <- BACKSLASH [x] [0-9A-F]{6} / BACKSLASH [nrts\-\\\[\]\''\"] / EscapeError So, whatever Xtreams or Squeak use for character classes? I have no idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Sun Jan 10 16:18:53 2021 From: gettimothy at zoho.com (gettimothy) Date: Sun, 10 Jan 2021 11:18:53 -0500 Subject: [squeak-dev] =?utf-8?q?specifiying_the_character_class_range_for_?= =?utf-8?q?some_funky_characters_from_=C4=B0stanbul?= In-Reply-To: <51452494-CBC1-4381-AD7F-C4E5686F4E74@gmx.de> References: <176ec7176d9.cd538d0f1133.2722976116117842067@zoho.com> <51452494-CBC1-4381-AD7F-C4E5686F4E74@gmx.de> Message-ID: <176ed17e0ea.f10704ec2235.1330670453720914981@zoho.com> poking around in the grammar some more, it defines RangeSet with a rule Range <- OPEN_BRACKET s "^"? RangeSet{1,CLOSE_BRACKET} That is tied to a callback via a pragma... Range: excluding sets: sets sets isEmpty ifTrue: [ ^excluding ifNil: [self DOT] ifNotNil: [ [parser not: [parser anything]] ]]. ^excluding ifNil: [ [parser including: sets] ] ifNotNil: [ [parser excluding: sets] ] Which is too deep in the weeds to grok at the moment, but appears to be a filter excluding is part of PEGParser excluding: intervals | position integer | position := stream position. [stream read: 1 into: cache at: 1] on: Incomplete do: [stream position: position. ^Failure]. integer := (cache at: 1) asInteger. intervals do: [:interval | (interval includes: integer) ifTrue: [stream position: position. ^Failure]]. ^cache at: 1 cordially, t -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank-lesser at lesser-software.com Sun Jan 10 16:40:55 2021 From: frank-lesser at lesser-software.com (Frank Lesser) Date: Sun, 10 Jan 2021 17:40:55 +0100 Subject: [squeak-dev] SmalltalkPuzzle In-Reply-To: <2130ec2b-a3a1-1a16-20ba-3b39d4a6753c@lesser-software.com> References: <2130ec2b-a3a1-1a16-20ba-3b39d4a6753c@lesser-software.com> Message-ID: <2d630992-2ab9-7f53-dbdd-fb8b16206778@lesser-software.com> Hi, I have published a new #SmalltalkPuzzle ( https://twitter.com/LesserFrank/status/1348303972671614979?s=20 ) Pleave vote on my Smalltalk survey https://twitter.com/LesserFrank/status/1347186405085163523?s=20 Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 11 09:11:12 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 11 Jan 2021 10:11:12 +0100 Subject: [squeak-dev] SmalltalkPuzzle In-Reply-To: <2d630992-2ab9-7f53-dbdd-fb8b16206778@lesser-software.com> References: <2130ec2b-a3a1-1a16-20ba-3b39d4a6753c@lesser-software.com> <2d630992-2ab9-7f53-dbdd-fb8b16206778@lesser-software.com> Message-ID: Hi Frank! :-) > Pleave vote on my Smalltalk survey There is a "none of the above" missing, regarding Christoph's "I would say tooling" comment. :-) Best, Marcel Am 10.01.2021 17:41:11 schrieb Frank Lesser : Hi, I have published a new #SmalltalkPuzzle ( https://twitter.com/LesserFrank/status/1348303972671614979?s=20 [https://twitter.com/LesserFrank/status/1348303972671614979?s=20] ) Pleave vote on my Smalltalk survey https://twitter.com/LesserFrank/status/1347186405085163523?s=20 [https://twitter.com/LesserFrank/status/1347186405085163523?s=20] Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 11 10:27:13 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 11 Jan 2021 11:27:13 +0100 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.270.mcz In-Reply-To: References: Message-ID: Hi -- >From my experience with the codebase in Squeak 3 and 4, any magic buffers such as "20" and "40" should be avoided for the sake of HI-DPI and hard-to-debug UI glitches. Deriving such buffers from the current font metrics seems to be more robust. Note that, in general, I am not opposed to giving content "more space to breathe" :-) Having to iterate over all items in a list is too costly for larger lists. The LazyListMorph attempt to only consider a sample proved to entail annoying UI glitches such as shaky UI elements while scrolling. Here are some numbers: font := TextStyle defaultFont. items := SystemNavigation default allClasses collect: [:class | class name]. [items do: [:item | font widthOfString: item]] bench. '718 per second. 1.39 milliseconds per run. 0 % GC time.' [(20 * (font widthOf: $m))@(15 * font height)] bench. '22,000,000 per second. 45.4 nanoseconds per run. 2.47901 % GC time.' Having milliseconds for a simple thing such as #initialExtent is really an issue for snappy GUIs because, for example, there are only 25 milliseconds for a frame in 40 FPS. *** All in all, you are oppsed to always make room for 15 items and (roughly) 20 characters per item. So, I suggest that we could make the 15 derived from the actual number of items ... plus 1-2 if you want to leave more whitespace. For the 20, I would suggest to only count the number of characters and multiply with that width-of-$m. For performance reasons: [items inject: 0 into: [:max :item | max max: item size]] bench. '30,200 per second. 33.1 microseconds per run. 0.05999 % GC time.' Yes, we could watch out for the size of #currentWorld, as you suggested. But this already happens via RealEstateAgent class >> maximumUsableAreaInWorld: as well as sends of #translatedToBeWithin: to a world's bounds. No need to duplicate and scatter those constraints all over the code base. :-) ... That said ... I think there is a bug in DialogWindow >> #moveToPreferredPosition and also in its initial extent. DialogWindow does not talk to RealEstateAgent at all ... Best, Marcel P.S.: How can you know that "item" is something that works with #widthOfString:? :-) Could be an instance of Text, for example. Am 08.01.2021 20:27:56 schrieb commits at source.squeak.org : A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.270 Author: cbc Time: 8 January 2021, 11:27:47.8204 am UUID: abbbeb8a-9a8b-ef4a-b6a9-051b55cc2d5b Ancestors: ToolBuilder-Morphic-mt.269 Set the initial extent of the ListChooser to not require resizing the dialog for reasonable sized lists (i.e., expand it so you can see all of the list). At the small end, still object MT's suggested size; at the large end, will not take up more the 3/4ths of the world size. =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont width height | - - | listFont | listFont := Preferences standardListFont. + width := (items collect: [:item| listFont widthOfString: item]) max + 20 "Acutal size of items plus dialog buffer left/right" + max: (20 * (listFont widthOf: $m)). "but we want a not-too-small box as well" + height := ((items size max: 15) * listFont height) + 40. "for various other stuff in dialog above/below list" + "But, don't use the whole world." + width := width min: (self currentWorld extent x * 0.75) asInteger. + height := height min: (self currentWorld extent y * 0.75) asInteger. + ^ width at height! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 11 10:30:29 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 11 Jan 2021 11:30:29 +0100 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.270.mcz In-Reply-To: References: Message-ID: Still, it makes me wonder if you ever you "list filtering" in such dialogs? You seem to want to optimize the users browsing experience, not the searching experience. Best, Marcel Am 11.01.2021 11:27:13 schrieb Marcel Taeumel : Hi -- >From my experience with the codebase in Squeak 3 and 4, any magic buffers such as "20" and "40" should be avoided for the sake of HI-DPI and hard-to-debug UI glitches. Deriving such buffers from the current font metrics seems to be more robust. Note that, in general, I am not opposed to giving content "more space to breathe" :-) Having to iterate over all items in a list is too costly for larger lists. The LazyListMorph attempt to only consider a sample proved to entail annoying UI glitches such as shaky UI elements while scrolling. Here are some numbers: font := TextStyle defaultFont. items := SystemNavigation default allClasses collect: [:class | class name]. [items do: [:item | font widthOfString: item]] bench. '718 per second. 1.39 milliseconds per run. 0 % GC time.' [(20 * (font widthOf: $m))@(15 * font height)] bench. '22,000,000 per second. 45.4 nanoseconds per run. 2.47901 % GC time.' Having milliseconds for a simple thing such as #initialExtent is really an issue for snappy GUIs because, for example, there are only 25 milliseconds for a frame in 40 FPS. *** All in all, you are oppsed to always make room for 15 items and (roughly) 20 characters per item. So, I suggest that we could make the 15 derived from the actual number of items ... plus 1-2 if you want to leave more whitespace. For the 20, I would suggest to only count the number of characters and multiply with that width-of-$m. For performance reasons: [items inject: 0 into: [:max :item | max max: item size]] bench. '30,200 per second. 33.1 microseconds per run. 0.05999 % GC time.' Yes, we could watch out for the size of #currentWorld, as you suggested. But this already happens via RealEstateAgent class >> maximumUsableAreaInWorld: as well as sends of #translatedToBeWithin: to a world's bounds. No need to duplicate and scatter those constraints all over the code base. :-) ... That said ... I think there is a bug in DialogWindow >> #moveToPreferredPosition and also in its initial extent. DialogWindow does not talk to RealEstateAgent at all ... Best, Marcel P.S.: How can you know that "item" is something that works with #widthOfString:? :-) Could be an instance of Text, for example. Am 08.01.2021 20:27:56 schrieb commits at source.squeak.org : A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.270 Author: cbc Time: 8 January 2021, 11:27:47.8204 am UUID: abbbeb8a-9a8b-ef4a-b6a9-051b55cc2d5b Ancestors: ToolBuilder-Morphic-mt.269 Set the initial extent of the ListChooser to not require resizing the dialog for reasonable sized lists (i.e., expand it so you can see all of the list). At the small end, still object MT's suggested size; at the large end, will not take up more the 3/4ths of the world size. =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont width height | - - | listFont | listFont := Preferences standardListFont. + width := (items collect: [:item| listFont widthOfString: item]) max + 20 "Acutal size of items plus dialog buffer left/right" + max: (20 * (listFont widthOf: $m)). "but we want a not-too-small box as well" + height := ((items size max: 15) * listFont height) + 40. "for various other stuff in dialog above/below list" + "But, don't use the whole world." + width := width min: (self currentWorld extent x * 0.75) asInteger. + height := height min: (self currentWorld extent y * 0.75) asInteger. + ^ width at height! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.oneel at pckswarms.ch Mon Jan 11 11:03:48 2021 From: bruce.oneel at pckswarms.ch (Bruce O'Neel) Date: Mon, 11 Jan 2021 12:03:48 +0100 Subject: [squeak-dev] Squeak and Sound Message-ID: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> Hi, I just installed Mint 20.1, which is based on the most recent Ubuntu, on a x86-64 system ran apt install libpulse-dev and then built the VM at the git HEAD, and unlike before sound works perfectly.  This is with a 5.3 image. Off to try this on my PI 400... cheers bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.oneel at pckswarms.ch Mon Jan 11 16:00:47 2021 From: bruce.oneel at pckswarms.ch (Bruce O'Neel) Date: Mon, 11 Jan 2021 17:00:47 +0100 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> Message-ID: <1610380847-5784e7d16d84742f660041b9c9633992@pckswarms.ch> > Hi, > > I just installed Mint 20.1, which is based on the most recent Ubuntu, on a x86-64 system ran > > apt install libpulse-dev > > and then built the VM at the git HEAD, and unlike before sound works perfectly.  This is with a 5.3 image. > > Off to try this on my PI 400... which, duh, does not have a headphone jack so that was unsuccessful.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Mon Jan 11 16:36:44 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 11 Jan 2021 16:36:44 0000 Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.270.mcz Message-ID: Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk: http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.270.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-mt.270 Author: mt Time: 11 January 2021, 5:36:43.295446 pm UUID: 5171b75b-ee89-b14f-8ec9-a27cdfaa52bb Ancestors: ToolBuilder-Morphic-mt.269 To pluggable dialogs, add an expand button if the model supports #preferredExtent. Also tweaks a list-chooser's initial extent show 5 to 15 items which each about 10 to 20 characters, depending on the list's content. This commit addresses the concerns raised in ToolBuilder-Morphic-cbc.270 (inbox). See http://forum.world.st/The-Inbox-ToolBuilder-Morphic-cbc-270-mcz-tp5126045.html =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>buildWith: (in category 'building') ----- buildWith: builder | dialogSpec searchBarHeight listSpec fieldSpec | + searchBarHeight := self searchBarHeight. - searchBarHeight := Preferences standardDefaultTextFont height * 1.75. dialogSpec := builder pluggableDialogSpec new model: self; title: #title; closeAction: #closed; extent: self initialExtent; autoCancel: true; "Behave like a pop-up menu. Historical reasons." children: OrderedCollection new; buttons: OrderedCollection new; yourself. listSpec := builder pluggableListSpec new. listSpec model: self; list: #items; getIndex: #selectedIndex; setIndex: #selectedIndex:; doubleClick: #accept; "keystrokePreview: #keyStrokeFromList:;" autoDeselect: false; filterableList: true; clearFilterAutomatically: false; name: #list; frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: (0 at searchBarHeight corner: 0 at 0)). dialogSpec children add: listSpec. fieldSpec := builder pluggableInputFieldSpec new. fieldSpec model: self; name: #searchText ; getText: #searchText; editText: #searchText:; setText: #acceptText:; selection: #textSelection; menu: nil; indicateUnacceptedChanges: false; askBeforeDiscardingEdits: false; help: (self addAllowed ifTrue: ['Type new or filter existing...' translated] ifFalse: ['Type to filter existing...' translated]); frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: 0 at searchBarHeight)). dialogSpec children add: fieldSpec. "Buttons" dialogSpec buttons add: ( builder pluggableButtonSpec new model: self; label: #acceptLabel; action: #accept; enabled: #canAcceptOrAdd; color: #acceptColor). dialogSpec buttons add: ( builder pluggableButtonSpec new model: self; label: 'Cancel'; action: #cancel; color: #cancelColor). dialogMorph := builder build: dialogSpec. dialogMorph addKeyboardCaptureFilter: self ; positionOverWidgetNamed: #searchText. listMorph := builder widgetAt: #list. listMorph allowEmptyFilterResult: true. ^ dialogMorph! Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont itemCount maxItemSize cellSize | - | listFont | listFont := Preferences standardListFont. + itemCount := items size. + maxItemSize := items inject: 0 into: [:max :item | max max: item size]. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) + @ (itemCount + 1 "breathing space" min: 15 max: 5) + * cellSize) + (0@ self searchBarHeight)! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! Item was added: + ----- Method: ListChooser>>preferredExtent (in category 'building') ----- + preferredExtent + + | listFont cellSize | + listFont := Preferences standardListFont. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((items inject: 0 into: [:max :item | max max: (listFont widthOfString: item)]) + @ (items size * listFont height)) + + ((1 at 1) * cellSize) "breathing space" + + (0@ self searchBarHeight)! Item was added: + ----- Method: ListChooser>>searchBarHeight (in category 'building') ----- + searchBarHeight + + ^ Preferences standardDefaultTextFont height * 1.75! Item was changed: ----- Method: ListMultipleChooser>>initialExtent (in category 'toolbuilder') ----- initialExtent + | listFont itemCount maxItemSize cellSize | - | listFont | listFont := Preferences standardListFont. + itemCount := labels size. + maxItemSize := labels inject: 0 into: [:max :item | max max: item size]. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) + @ (itemCount + 1 "breathing space" min: 15 max: 5) + * cellSize)! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! Item was added: + ----- Method: ListMultipleChooser>>preferredExtent (in category 'toolbuilder') ----- + preferredExtent + + | listFont cellSize | + listFont := Preferences standardListFont. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((labels inject: 0 into: [:max :item | max max: (listFont widthOfString: item)]) + @ (labels size * listFont height)) + + ((1 at 1) * cellSize) "breathing space"! Item was changed: ----- Method: MorphicToolBuilder>>buildPluggableDialog: (in category 'widgets optional') ----- buildPluggableDialog: aSpec | widget | widget := self dialogClass new. self register: widget id: aSpec name. widget model: aSpec model. "Set child dependent layout properties. The pane morph holds the special contents." widget paneMorph wantsPaneSplitters: (aSpec wantsResizeHandles ifNil: [true]). self setLayoutHintsFor: widget paneMorph spec: aSpec. widget paneMorph layoutInset: (aSpec padding ifNil: [ProportionalSplitterMorph gripThickness]). widget paneMorph cellGap: (aSpec spacing ifNil: [ProportionalSplitterMorph gripThickness]). widget paneMorph wantsPaneSplitters ifTrue: [ widget paneMorph addCornerGrips"addEdgeGrips". widget paneMorph grips do: [:ea | ea showHandle: true]]. "Now create the children." panes := OrderedCollection new. aSpec children isSymbol ifTrue: [ widget getChildrenSelector: aSpec children. widget update: aSpec children] ifFalse: [ self buildAll: aSpec children in: widget paneMorph]. "Now create the buttons." aSpec buttons isSymbol ifTrue: [ widget getButtonsSelector: aSpec buttons. widget update: aSpec buttons] ifFalse: [ self buildAll: aSpec buttons in: widget buttonRowMorph. widget updateButtonProperties]. aSpec title ifNotNil: [:label | label isSymbol ifTrue:[widget getTitleSelector: label; update: label] ifFalse:[widget title: label]]. aSpec message ifNotNil: [:label | label isSymbol ifTrue:[widget getMessageSelector: label; update: label] ifFalse:[widget message: label]]. "Interaction behavior." aSpec autoCancel ifNotNil: [:b | widget autoCancel: b]. aSpec exclusive ifNotNil: [:b | widget exclusive: b]. widget closeDialogSelector: aSpec closeAction. self buildHelpFor: widget spec: aSpec. "Everything is shrink-wrapped around the pane morph." + widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]) + + (widget paneMorph layoutInset * 2) asPoint. - widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]). ^ widget! Item was added: + ----- Method: PluggableDialogWindow>>createTitle: (in category 'initialization') ----- + createTitle: aString + "Overridden to add an extra expand button. Yet, it depends on the model's interface whether that button will be visible. See #model:." + + | box expandButton| + super createTitle: aString. + + expandButton := SystemWindowButton new + name: #expandButton; + color: Color transparent; + target: self; + actionSelector: #expandDialogPane; + balloonText: 'Expand this dialog' translated; + borderWidth: 0; + yourself. + SystemWindow expandBoxImage scaleIconToDisplay in: [:icon | + expandButton labelGraphic: icon; extent: icon extent]. + + box := self submorphNamed: #title. + box addMorphBack: expandButton.! Item was added: + ----- Method: PluggableDialogWindow>>expandDialogPane (in category 'running') ----- + expandDialogPane + "Expand the dialog pane to its preferred extent. Honor the visible area in the world." + + | visibleArea decorationOffset expandedExtent | + visibleArea := self currentWorld visibleClearArea. + decorationOffset := self extent - self paneMorph extent. + expandedExtent := self model preferredExtent + (self paneMorph layoutInset * 2) asPoint. + + self paneMorph extent: (expandedExtent min: visibleArea extent - decorationOffset). + + self fullBounds. + self moveToPreferredPosition.! Item was changed: ----- Method: PluggableDialogWindow>>model: (in category 'accessing') ----- + model: newModel - model: anObject model ifNotNil: [model removeDependent: self]. + newModel ifNotNil: [ + newModel addDependent: self. + (newModel respondsTo: #preferredExtent) + ifFalse: [((self submorphNamed: #title) submorphNamed: #expandButton) delete]]. + model := newModel.! - anObject ifNotNil: [anObject addDependent: self]. - model := anObject.! From marcel.taeumel at hpi.de Mon Jan 11 16:38:03 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 11 Jan 2021 17:38:03 +0100 Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.270.mcz In-Reply-To: References: Message-ID: Am 11.01.2021 17:36:52 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk: http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.270.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-mt.270 Author: mt Time: 11 January 2021, 5:36:43.295446 pm UUID: 5171b75b-ee89-b14f-8ec9-a27cdfaa52bb Ancestors: ToolBuilder-Morphic-mt.269 To pluggable dialogs, add an expand button if the model supports #preferredExtent. Also tweaks a list-chooser's initial extent show 5 to 15 items which each about 10 to 20 characters, depending on the list's content. This commit addresses the concerns raised in ToolBuilder-Morphic-cbc.270 (inbox). See http://forum.world.st/The-Inbox-ToolBuilder-Morphic-cbc-270-mcz-tp5126045.html =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>buildWith: (in category 'building') ----- buildWith: builder | dialogSpec searchBarHeight listSpec fieldSpec | + searchBarHeight := self searchBarHeight. - searchBarHeight := Preferences standardDefaultTextFont height * 1.75. dialogSpec := builder pluggableDialogSpec new model: self; title: #title; closeAction: #closed; extent: self initialExtent; autoCancel: true; "Behave like a pop-up menu. Historical reasons." children: OrderedCollection new; buttons: OrderedCollection new; yourself. listSpec := builder pluggableListSpec new. listSpec model: self; list: #items; getIndex: #selectedIndex; setIndex: #selectedIndex:; doubleClick: #accept; "keystrokePreview: #keyStrokeFromList:;" autoDeselect: false; filterableList: true; clearFilterAutomatically: false; name: #list; frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: (0 at searchBarHeight corner: 0 at 0)). dialogSpec children add: listSpec. fieldSpec := builder pluggableInputFieldSpec new. fieldSpec model: self; name: #searchText ; getText: #searchText; editText: #searchText:; setText: #acceptText:; selection: #textSelection; menu: nil; indicateUnacceptedChanges: false; askBeforeDiscardingEdits: false; help: (self addAllowed ifTrue: ['Type new or filter existing...' translated] ifFalse: ['Type to filter existing...' translated]); frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: 0 at searchBarHeight)). dialogSpec children add: fieldSpec. "Buttons" dialogSpec buttons add: ( builder pluggableButtonSpec new model: self; label: #acceptLabel; action: #accept; enabled: #canAcceptOrAdd; color: #acceptColor). dialogSpec buttons add: ( builder pluggableButtonSpec new model: self; label: 'Cancel'; action: #cancel; color: #cancelColor). dialogMorph := builder build: dialogSpec. dialogMorph addKeyboardCaptureFilter: self ; positionOverWidgetNamed: #searchText. listMorph := builder widgetAt: #list. listMorph allowEmptyFilterResult: true. ^ dialogMorph! Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont itemCount maxItemSize cellSize | - | listFont | listFont := Preferences standardListFont. + itemCount := items size. + maxItemSize := items inject: 0 into: [:max :item | max max: item size]. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) + @ (itemCount + 1 "breathing space" min: 15 max: 5) + * cellSize) + (0@ self searchBarHeight)! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! Item was added: + ----- Method: ListChooser>>preferredExtent (in category 'building') ----- + preferredExtent + + | listFont cellSize | + listFont := Preferences standardListFont. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((items inject: 0 into: [:max :item | max max: (listFont widthOfString: item)]) + @ (items size * listFont height)) + + ((1 at 1) * cellSize) "breathing space" + + (0@ self searchBarHeight)! Item was added: + ----- Method: ListChooser>>searchBarHeight (in category 'building') ----- + searchBarHeight + + ^ Preferences standardDefaultTextFont height * 1.75! Item was changed: ----- Method: ListMultipleChooser>>initialExtent (in category 'toolbuilder') ----- initialExtent + | listFont itemCount maxItemSize cellSize | - | listFont | listFont := Preferences standardListFont. + itemCount := labels size. + maxItemSize := labels inject: 0 into: [:max :item | max max: item size]. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) + @ (itemCount + 1 "breathing space" min: 15 max: 5) + * cellSize)! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! Item was added: + ----- Method: ListMultipleChooser>>preferredExtent (in category 'toolbuilder') ----- + preferredExtent + + | listFont cellSize | + listFont := Preferences standardListFont. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((labels inject: 0 into: [:max :item | max max: (listFont widthOfString: item)]) + @ (labels size * listFont height)) + + ((1 at 1) * cellSize) "breathing space"! Item was changed: ----- Method: MorphicToolBuilder>>buildPluggableDialog: (in category 'widgets optional') ----- buildPluggableDialog: aSpec | widget | widget := self dialogClass new. self register: widget id: aSpec name. widget model: aSpec model. "Set child dependent layout properties. The pane morph holds the special contents." widget paneMorph wantsPaneSplitters: (aSpec wantsResizeHandles ifNil: [true]). self setLayoutHintsFor: widget paneMorph spec: aSpec. widget paneMorph layoutInset: (aSpec padding ifNil: [ProportionalSplitterMorph gripThickness]). widget paneMorph cellGap: (aSpec spacing ifNil: [ProportionalSplitterMorph gripThickness]). widget paneMorph wantsPaneSplitters ifTrue: [ widget paneMorph addCornerGrips"addEdgeGrips". widget paneMorph grips do: [:ea | ea showHandle: true]]. "Now create the children." panes := OrderedCollection new. aSpec children isSymbol ifTrue: [ widget getChildrenSelector: aSpec children. widget update: aSpec children] ifFalse: [ self buildAll: aSpec children in: widget paneMorph]. "Now create the buttons." aSpec buttons isSymbol ifTrue: [ widget getButtonsSelector: aSpec buttons. widget update: aSpec buttons] ifFalse: [ self buildAll: aSpec buttons in: widget buttonRowMorph. widget updateButtonProperties]. aSpec title ifNotNil: [:label | label isSymbol ifTrue:[widget getTitleSelector: label; update: label] ifFalse:[widget title: label]]. aSpec message ifNotNil: [:label | label isSymbol ifTrue:[widget getMessageSelector: label; update: label] ifFalse:[widget message: label]]. "Interaction behavior." aSpec autoCancel ifNotNil: [:b | widget autoCancel: b]. aSpec exclusive ifNotNil: [:b | widget exclusive: b]. widget closeDialogSelector: aSpec closeAction. self buildHelpFor: widget spec: aSpec. "Everything is shrink-wrapped around the pane morph." + widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]) + + (widget paneMorph layoutInset * 2) asPoint. - widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]). ^ widget! Item was added: + ----- Method: PluggableDialogWindow>>createTitle: (in category 'initialization') ----- + createTitle: aString + "Overridden to add an extra expand button. Yet, it depends on the model's interface whether that button will be visible. See #model:." + + | box expandButton| + super createTitle: aString. + + expandButton := SystemWindowButton new + name: #expandButton; + color: Color transparent; + target: self; + actionSelector: #expandDialogPane; + balloonText: 'Expand this dialog' translated; + borderWidth: 0; + yourself. + SystemWindow expandBoxImage scaleIconToDisplay in: [:icon | + expandButton labelGraphic: icon; extent: icon extent]. + + box := self submorphNamed: #title. + box addMorphBack: expandButton.! Item was added: + ----- Method: PluggableDialogWindow>>expandDialogPane (in category 'running') ----- + expandDialogPane + "Expand the dialog pane to its preferred extent. Honor the visible area in the world." + + | visibleArea decorationOffset expandedExtent | + visibleArea := self currentWorld visibleClearArea. + decorationOffset := self extent - self paneMorph extent. + expandedExtent := self model preferredExtent + (self paneMorph layoutInset * 2) asPoint. + + self paneMorph extent: (expandedExtent min: visibleArea extent - decorationOffset). + + self fullBounds. + self moveToPreferredPosition.! Item was changed: ----- Method: PluggableDialogWindow>>model: (in category 'accessing') ----- + model: newModel - model: anObject model ifNotNil: [model removeDependent: self]. + newModel ifNotNil: [ + newModel addDependent: self. + (newModel respondsTo: #preferredExtent) + ifFalse: [((self submorphNamed: #title) submorphNamed: #expandButton) delete]]. + model := newModel.! - anObject ifNotNil: [anObject addDependent: self]. - model := anObject.! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 111558 bytes Desc: not available URL: From commits at source.squeak.org Mon Jan 11 16:39:15 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 11 Jan 2021 16:39:15 0000 Subject: [squeak-dev] The Trunk: Morphic-mt.1714.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1714.mcz ==================== Summary ==================== Name: Morphic-mt.1714 Author: mt Time: 11 January 2021, 5:39:09.729446 pm UUID: e843c65c-8522-4544-84e8-4d21a8ca197e Ancestors: Morphic-mt.1713 Minor fix in dialog to not hide the world's docking bar. =============== Diff against Morphic-mt.1713 =============== Item was changed: ----- Method: DialogWindow>>moveToPreferredPosition (in category 'initialization') ----- moveToPreferredPosition self center: (preferredPosition isPoint ifTrue: [ preferredPosition ] ifFalse: [ self center + self currentHand position - preferredPosition center ]). + self bounds: (self bounds translatedToBeWithin: self currentWorld visibleClearArea)! - self bounds: (self bounds translatedToBeWithin: self currentWorld bounds)! From marcel.taeumel at hpi.de Mon Jan 11 16:45:38 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 11 Jan 2021 17:45:38 +0100 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.270.mcz In-Reply-To: References: Message-ID: Hi Chris -- In "ToolBuilder-Morphic-mt.270", I tweaked a dialog's minimal size for smaller lists and added an expand button so that you can see more at once. I am aware that this is just a compromise to your proposed changes. Can you work with that? :-) http://forum.world.st/The-Trunk-ToolBuilder-Morphic-mt-270-mcz-td5126091.html [http://forum.world.st/The-Trunk-ToolBuilder-Morphic-mt-270-mcz-td5126091.html] And I just realized that you did not propose a "breathing space" but just estimated the dialogs decorations around the central pane.  My bad. Well, there is now extra space to breathe. We might remove that as well. Best, Marcel Am 11.01.2021 11:30:29 schrieb Marcel Taeumel : Still, it makes me wonder if you ever you "list filtering" in such dialogs? You seem to want to optimize the users browsing experience, not the searching experience. Best, Marcel Am 11.01.2021 11:27:13 schrieb Marcel Taeumel : Hi -- >From my experience with the codebase in Squeak 3 and 4, any magic buffers such as "20" and "40" should be avoided for the sake of HI-DPI and hard-to-debug UI glitches. Deriving such buffers from the current font metrics seems to be more robust. Note that, in general, I am not opposed to giving content "more space to breathe" :-) Having to iterate over all items in a list is too costly for larger lists. The LazyListMorph attempt to only consider a sample proved to entail annoying UI glitches such as shaky UI elements while scrolling. Here are some numbers: font := TextStyle defaultFont. items := SystemNavigation default allClasses collect: [:class | class name]. [items do: [:item | font widthOfString: item]] bench. '718 per second. 1.39 milliseconds per run. 0 % GC time.' [(20 * (font widthOf: $m))@(15 * font height)] bench. '22,000,000 per second. 45.4 nanoseconds per run. 2.47901 % GC time.' Having milliseconds for a simple thing such as #initialExtent is really an issue for snappy GUIs because, for example, there are only 25 milliseconds for a frame in 40 FPS. *** All in all, you are oppsed to always make room for 15 items and (roughly) 20 characters per item. So, I suggest that we could make the 15 derived from the actual number of items ... plus 1-2 if you want to leave more whitespace. For the 20, I would suggest to only count the number of characters and multiply with that width-of-$m. For performance reasons: [items inject: 0 into: [:max :item | max max: item size]] bench. '30,200 per second. 33.1 microseconds per run. 0.05999 % GC time.' Yes, we could watch out for the size of #currentWorld, as you suggested. But this already happens via RealEstateAgent class >> maximumUsableAreaInWorld: as well as sends of #translatedToBeWithin: to a world's bounds. No need to duplicate and scatter those constraints all over the code base. :-) ... That said ... I think there is a bug in DialogWindow >> #moveToPreferredPosition and also in its initial extent. DialogWindow does not talk to RealEstateAgent at all ... Best, Marcel P.S.: How can you know that "item" is something that works with #widthOfString:? :-) Could be an instance of Text, for example. Am 08.01.2021 20:27:56 schrieb commits at source.squeak.org : A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.270 Author: cbc Time: 8 January 2021, 11:27:47.8204 am UUID: abbbeb8a-9a8b-ef4a-b6a9-051b55cc2d5b Ancestors: ToolBuilder-Morphic-mt.269 Set the initial extent of the ListChooser to not require resizing the dialog for reasonable sized lists (i.e., expand it so you can see all of the list). At the small end, still object MT's suggested size; at the large end, will not take up more the 3/4ths of the world size. =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont width height | - - | listFont | listFont := Preferences standardListFont. + width := (items collect: [:item| listFont widthOfString: item]) max + 20 "Acutal size of items plus dialog buffer left/right" + max: (20 * (listFont widthOf: $m)). "but we want a not-too-small box as well" + height := ((items size max: 15) * listFont height) + 40. "for various other stuff in dialog above/below list" + "But, don't use the whole world." + width := width min: (self currentWorld extent x * 0.75) asInteger. + height := height min: (self currentWorld extent y * 0.75) asInteger. + ^ width at height! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! -------------- next part -------------- An HTML attachment was scrubbed... URL: From cunningham.cb at gmail.com Mon Jan 11 17:12:46 2021 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Mon, 11 Jan 2021 09:12:46 -0800 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.270.mcz In-Reply-To: References: Message-ID: inline... On Mon, Jan 11, 2021 at 2:30 AM Marcel Taeumel wrote: > Still, it makes me wonder if you ever you "list filtering" in such > dialogs? You seem to want to optimize the users browsing experience, not > the searching experience. > Actually, this even helps with filtering. If I have large items (which I often do), and I don't know the exact combination of characters for what I want to choose, it can be frustrating with the default size. Try: ListChooser chooseFrom: #( 'A Really Big Option With Useful Stuff after: here, option Alpha' 'A Really Big Option With Useful Stuff after: here, option Beta' 'A Really Big Option With Useful Stuff after: here, option Gamma' 'Not what we want' ) and filter by, say 'Stuff'. Which one do you pick? Further, the grippies on this dialog are frustrating. If the dialog is near the bottom right of the screen, just dragging the top left (or bottom left) to make the dialog bigger to be able to see the rest of the text doesn't work. The dialog only expands down and to the right - no matter which grippy you try to expand (or shrink) the dialog with. So, I have to make it bigger, then move the dialog. If you need to do this often enough, I at least get frustrated. >From my experience with the codebase in Squeak 3 and 4, any magic buffers > such as "20" and "40" should be avoided for the sake of HI-DPI and > hard-to-debug UI glitches. Deriving such buffers from the current font > metrics seems to be more robust. Note that, in general, I am not opposed to > giving content "more space to breathe" :-) > > The buffer size I am talking about here isn't for more white space around the list, but for the size of the dialog that is outside of the list. InitialExtent is for the complete dialog size, not just the list box. So, you will never be able to see 15 lines in the previous version because of the other space taken up by buttons and filter box. (Which is ok if the lists choices are small in few in number, of course.) That said, you are right about HI-DPI and possible other font choices and/or future changes to ListChooser - I should derive the value and not hard code it. > > > Having to iterate over all items in a list is too costly for larger lists. > The LazyListMorph attempt to only consider a sample proved to entail > annoying UI glitches such as shaky UI elements while scrolling. > > > All in all, you are oppsed to always make room for 15 items and (roughly) > 20 characters per item. So, I suggest that we could make the 15 derived > from the actual number of items ... plus 1-2 if you want to leave more > whitespace. For the 20, I would suggest to only count the number of > characters and multiply with that width-of-$m. For performance reasons: > > Yes, agreed (and much better). Except extra space should not be based on the list items/count, but on the other Dialog stuff. > [items inject: 0 into: [:max :item | max max: item size]] bench. > '30,200 per second. 33.1 microseconds per run. 0.05999 % GC time.' > > Yes, we could watch out for the size of #currentWorld, as you suggested. > But this already happens via RealEstateAgent class > >> maximumUsableAreaInWorld: as well as sends of #translatedToBeWithin: to > a world's bounds. No need to duplicate and scatter those constraints all > over the code base. :-) ... That said ... I think there is a bug in > DialogWindow >> #moveToPreferredPosition and also in its initial extent. > DialogWindow does not talk to RealEstateAgent at all ... > > I'll try removing my #currentWorld and see what happens with a really REALLY large list. I did notice that it will not open the dialog with any of it off the screen by default - but didn't try with an extent larger than the world. So, at least that part is somehow handled. (But not the growth of the dialog by grippies, unfortunately). > Best, > Marcel > > P.S.: How can you know that "item" is something that works with > #widthOfString:? :-) Could be an instance of Text, for example. > > err, yeah. I always use stuff that knows #widthOfString, but that's just me. Will go with using size and width of $m. Thank you! > Am 08.01.2021 20:27:56 schrieb commits at source.squeak.org < > commits at source.squeak.org>: > A new version of ToolBuilder-Morphic was added to project The Inbox: > http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz > > ==================== Summary ==================== > > Name: ToolBuilder-Morphic-cbc.270 > Author: cbc > Time: 8 January 2021, 11:27:47.8204 am > UUID: abbbeb8a-9a8b-ef4a-b6a9-051b55cc2d5b > Ancestors: ToolBuilder-Morphic-mt.269 > > Set the initial extent of the ListChooser to not require resizing the > dialog for reasonable sized lists (i.e., expand it so you can see all of > the list). > At the small end, still object MT's suggested size; at the large end, will > not take up more the 3/4ths of the world size. > > =============== Diff against ToolBuilder-Morphic-mt.269 =============== > > Item was changed: > ----- Method: ListChooser>>initialExtent (in category 'building') ----- > initialExtent > + | listFont width height | > - > - | listFont | > listFont := Preferences standardListFont. > + width := (items collect: [:item| listFont widthOfString: item]) max + 20 > "Acutal size of items plus dialog buffer left/right" > + max: (20 * (listFont widthOf: $m)). "but we want a not-too-small box as > well" > + height := ((items size max: 15) * listFont height) + 40. "for various > other stuff in dialog above/below list" > + "But, don't use the whole world." > + width := width min: (self currentWorld extent x * 0.75) asInteger. > + height := height min: (self currentWorld extent y * 0.75) asInteger. > + ^ width at height! > - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cunningham.cb at gmail.com Mon Jan 11 17:48:11 2021 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Mon, 11 Jan 2021 09:48:11 -0800 Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.270.mcz In-Reply-To: References: Message-ID: Close. I'd still like to try and make it wide for the strings provided. Note that : width := ((items take: 15) collect: [:item| listFont widthOfString: item]) max. "A good estimate of what is needed in the list box width" works for both string and Text. That said, we should still have 2 bounds - one for width of world (dialog will build bigger than the world - not good) and lower bound for the size of the buttons - it would be nice not to stack the Choose/Cancel button. For the height - what you have is better than what I had - that part I like. On Mon, Jan 11, 2021 at 8:38 AM Marcel Taeumel wrote: > > Am 11.01.2021 17:36:52 schrieb commits at source.squeak.org < > commits at source.squeak.org>: > Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project > The Trunk: > http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.270.mcz > > ==================== Summary ==================== > > Name: ToolBuilder-Morphic-mt.270 > Author: mt > Time: 11 January 2021, 5:36:43.295446 pm > UUID: 5171b75b-ee89-b14f-8ec9-a27cdfaa52bb > Ancestors: ToolBuilder-Morphic-mt.269 > > To pluggable dialogs, add an expand button if the model supports > #preferredExtent. Also tweaks a list-chooser's initial extent show 5 to 15 > items which each about 10 to 20 characters, depending on the list's content. > > This commit addresses the concerns raised in ToolBuilder-Morphic-cbc.270 > (inbox). > See > http://forum.world.st/The-Inbox-ToolBuilder-Morphic-cbc-270-mcz-tp5126045.html > > =============== Diff against ToolBuilder-Morphic-mt.269 =============== > > Item was changed: > ----- Method: ListChooser>>buildWith: (in category 'building') ----- > buildWith: builder > > | dialogSpec searchBarHeight listSpec fieldSpec | > > + searchBarHeight := self searchBarHeight. > - searchBarHeight := Preferences standardDefaultTextFont height * 1.75. > > dialogSpec := builder pluggableDialogSpec new > model: self; > title: #title; > closeAction: #closed; > extent: self initialExtent; > autoCancel: true; "Behave like a pop-up menu. Historical reasons." > children: OrderedCollection new; > buttons: OrderedCollection new; > yourself. > > listSpec := builder pluggableListSpec new. > listSpec > model: self; > list: #items; > getIndex: #selectedIndex; > setIndex: #selectedIndex:; > doubleClick: #accept; > "keystrokePreview: #keyStrokeFromList:;" > autoDeselect: false; > filterableList: true; > clearFilterAutomatically: false; > name: #list; > frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: > (0 at searchBarHeight corner: 0 at 0)). > dialogSpec children add: listSpec. > > fieldSpec := builder pluggableInputFieldSpec new. > fieldSpec > model: self; > name: #searchText ; > getText: #searchText; > editText: #searchText:; > setText: #acceptText:; > selection: #textSelection; > menu: nil; > indicateUnacceptedChanges: false; > askBeforeDiscardingEdits: false; > help: (self addAllowed ifTrue: ['Type new or filter existing...' > translated] ifFalse: ['Type to filter existing...' translated]); > frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: > 0 at searchBarHeight)). > dialogSpec children add: fieldSpec. > > "Buttons" > dialogSpec buttons add: ( > builder pluggableButtonSpec new > model: self; > label: #acceptLabel; > action: #accept; > enabled: #canAcceptOrAdd; > color: #acceptColor). > > dialogSpec buttons add: ( > builder pluggableButtonSpec new > model: self; > label: 'Cancel'; > action: #cancel; > color: #cancelColor). > > dialogMorph := builder build: dialogSpec. > dialogMorph addKeyboardCaptureFilter: self ; positionOverWidgetNamed: > #searchText. > listMorph := builder widgetAt: #list. > listMorph allowEmptyFilterResult: true. > > ^ dialogMorph! > > Item was changed: > ----- Method: ListChooser>>initialExtent (in category 'building') ----- > initialExtent > > + | listFont itemCount maxItemSize cellSize | > - | listFont | > listFont := Preferences standardListFont. > + itemCount := items size. > + maxItemSize := items inject: 0 into: [:max :item | max max: item size]. > + cellSize := (listFont widthOf: $m) @ listFont height. > + > + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) > + @ (itemCount + 1 "breathing space" min: 15 max: 5) > + * cellSize) + (0@ self searchBarHeight)! > - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! > > Item was added: > + ----- Method: ListChooser>>preferredExtent (in category 'building') ----- > + preferredExtent > + > + | listFont cellSize | > + listFont := Preferences standardListFont. > + cellSize := (listFont widthOf: $m) @ listFont height. > + > + ^ ((items inject: 0 into: [:max :item | max max: (listFont > widthOfString: item)]) > + @ (items size * listFont height)) > + + ((1 at 1) * cellSize) "breathing space" > + + (0@ self searchBarHeight)! > > Item was added: > + ----- Method: ListChooser>>searchBarHeight (in category 'building') ----- > + searchBarHeight > + > + ^ Preferences standardDefaultTextFont height * 1.75! > > Item was changed: > ----- Method: ListMultipleChooser>>initialExtent (in category > 'toolbuilder') ----- > initialExtent > > + | listFont itemCount maxItemSize cellSize | > - | listFont | > listFont := Preferences standardListFont. > + itemCount := labels size. > + maxItemSize := labels inject: 0 into: [:max :item | max max: item size]. > + cellSize := (listFont widthOf: $m) @ listFont height. > + > + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) > + @ (itemCount + 1 "breathing space" min: 15 max: 5) > + * cellSize)! > - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! > > Item was added: > + ----- Method: ListMultipleChooser>>preferredExtent (in category > 'toolbuilder') ----- > + preferredExtent > + > + | listFont cellSize | > + listFont := Preferences standardListFont. > + cellSize := (listFont widthOf: $m) @ listFont height. > + > + ^ ((labels inject: 0 into: [:max :item | max max: (listFont > widthOfString: item)]) > + @ (labels size * listFont height)) > + + ((1 at 1) * cellSize) "breathing space"! > > Item was changed: > ----- Method: MorphicToolBuilder>>buildPluggableDialog: (in category > 'widgets optional') ----- > buildPluggableDialog: aSpec > > | widget | > > widget := self dialogClass new. > self register: widget id: aSpec name. > > widget model: aSpec model. > > "Set child dependent layout properties. The pane morph holds the special > contents." > widget paneMorph wantsPaneSplitters: (aSpec wantsResizeHandles ifNil: > [true]). > self setLayoutHintsFor: widget paneMorph spec: aSpec. > widget paneMorph layoutInset: (aSpec padding ifNil: > [ProportionalSplitterMorph gripThickness]). > widget paneMorph cellGap: (aSpec spacing ifNil: [ProportionalSplitterMorph > gripThickness]). > widget paneMorph wantsPaneSplitters ifTrue: [ > widget paneMorph addCornerGrips"addEdgeGrips". > widget paneMorph grips do: [:ea | ea showHandle: true]]. > > "Now create the children." > panes := OrderedCollection new. > aSpec children isSymbol > ifTrue: [ > widget getChildrenSelector: aSpec children. > widget update: aSpec children] > ifFalse: [ > self buildAll: aSpec children in: widget paneMorph]. > > "Now create the buttons." > aSpec buttons isSymbol > ifTrue: [ > widget getButtonsSelector: aSpec buttons. > widget update: aSpec buttons] > ifFalse: [ > self buildAll: aSpec buttons in: widget buttonRowMorph. > widget updateButtonProperties]. > > aSpec title ifNotNil: [:label | > label isSymbol > ifTrue:[widget getTitleSelector: label; update: label] > ifFalse:[widget title: label]]. > aSpec message ifNotNil: [:label | > label isSymbol > ifTrue:[widget getMessageSelector: label; update: label] > ifFalse:[widget message: label]]. > > "Interaction behavior." > aSpec autoCancel ifNotNil: [:b | widget autoCancel: b]. > aSpec exclusive ifNotNil: [:b | widget exclusive: b]. > > widget closeDialogSelector: aSpec closeAction. > self buildHelpFor: widget spec: aSpec. > > "Everything is shrink-wrapped around the pane morph." > + widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]) > + + (widget paneMorph layoutInset * 2) asPoint. > - widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]). > > ^ widget! > > Item was added: > + ----- Method: PluggableDialogWindow>>createTitle: (in category > 'initialization') ----- > + createTitle: aString > + "Overridden to add an extra expand button. Yet, it depends on the > model's interface whether that button will be visible. See #model:." > + > + | box expandButton| > + super createTitle: aString. > + > + expandButton := SystemWindowButton new > + name: #expandButton; > + color: Color transparent; > + target: self; > + actionSelector: #expandDialogPane; > + balloonText: 'Expand this dialog' translated; > + borderWidth: 0; > + yourself. > + SystemWindow expandBoxImage scaleIconToDisplay in: [:icon | > + expandButton labelGraphic: icon; extent: icon extent]. > + > + box := self submorphNamed: #title. > + box addMorphBack: expandButton.! > > Item was added: > + ----- Method: PluggableDialogWindow>>expandDialogPane (in category > 'running') ----- > + expandDialogPane > + "Expand the dialog pane to its preferred extent. Honor the visible area > in the world." > + > + | visibleArea decorationOffset expandedExtent | > + visibleArea := self currentWorld visibleClearArea. > + decorationOffset := self extent - self paneMorph extent. > + expandedExtent := self model preferredExtent + (self paneMorph > layoutInset * 2) asPoint. > + > + self paneMorph extent: (expandedExtent min: visibleArea extent - > decorationOffset). > + > + self fullBounds. > + self moveToPreferredPosition.! > > Item was changed: > ----- Method: PluggableDialogWindow>>model: (in category 'accessing') ----- > + model: newModel > - model: anObject > > model ifNotNil: [model removeDependent: self]. > + newModel ifNotNil: [ > + newModel addDependent: self. > + (newModel respondsTo: #preferredExtent) > + ifFalse: [((self submorphNamed: #title) submorphNamed: #expandButton) > delete]]. > + model := newModel.! > - anObject ifNotNil: [anObject addDependent: self]. > - model := anObject.! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 111558 bytes Desc: not available URL: From eliot.miranda at gmail.com Mon Jan 11 18:11:13 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon, 11 Jan 2021 10:11:13 -0800 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> Message-ID: Hi Bruce, Hi squeak.org maintainers, this kind of information is incredibly important for new users who grab squeak and want to get things done. We should make sure there is on squeak.org a "tips and tricks" page, or series of items on the download page that help new users solve these kinds of issues. The last thing we want is for a new user to find themselves blocked and have to go to the mailing list to get help. In that arc from being blocked to asking for help many people may simply give up and we will, I believe, lose users that way. So Bruce, this inf should be in HowToBuild, but all, it should also be on squeak.org, and prominently. On Mon, Jan 11, 2021 at 3:04 AM Bruce O'Neel wrote: > Hi, > > I just installed Mint 20.1, which is based on the most recent Ubuntu, on a > x86-64 system ran > > apt install libpulse-dev > > and then built the VM at the git HEAD, and unlike before sound works > perfectly. This is with a 5.3 image. > > Off to try this on my PI 400... > > cheers > > bruce > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Mon Jan 11 18:15:52 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 11 Jan 2021 18:15:52 0000 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.271.mcz Message-ID: A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.271.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.271 Author: cbc Time: 11 January 2021, 10:15:51.0644 am UUID: 76f9fb95-5700-1b43-a9af-9ab88aaa890f Ancestors: ToolBuilder-Morphic-mt.270 Let the width of List Chooser try to accomodate better to the actual size of the string. =============== Diff against ToolBuilder-Morphic-mt.270 =============== Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont itemCount width | - - | listFont itemCount maxItemSize cellSize | listFont := Preferences standardListFont. itemCount := items size. + width := ((items take: 15) collect: [:item| listFont widthOfString: item]) max. + ^ (width min: (self currentWorld extent x * 0.75) asInteger max: ((listFont widthOf: $m) * 12)) + @ ((itemCount min: 15 max: 5) * listFont height + self searchBarHeight) + ! - maxItemSize := items inject: 0 into: [:max :item | max max: item size]. - cellSize := (listFont widthOf: $m) @ listFont height. - - ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) - @ (itemCount + 1 "breathing space" min: 15 max: 5) - * cellSize) + (0@ self searchBarHeight)! From cunningham.cb at gmail.com Mon Jan 11 18:17:37 2021 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Mon, 11 Jan 2021 10:17:37 -0800 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.271.mcz In-Reply-To: References: Message-ID: [image: image.png] and [image: image.png] close enough. On Mon, Jan 11, 2021 at 10:16 AM wrote: > A new version of ToolBuilder-Morphic was added to project The Inbox: > http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.271.mcz > > ==================== Summary ==================== > > Name: ToolBuilder-Morphic-cbc.271 > Author: cbc > Time: 11 January 2021, 10:15:51.0644 am > UUID: 76f9fb95-5700-1b43-a9af-9ab88aaa890f > Ancestors: ToolBuilder-Morphic-mt.270 > > Let the width of List Chooser try to accomodate better to the actual size > of the string. > > =============== Diff against ToolBuilder-Morphic-mt.270 =============== > > Item was changed: > ----- Method: ListChooser>>initialExtent (in category 'building') ----- > initialExtent > + | listFont itemCount width | > - > - | listFont itemCount maxItemSize cellSize | > listFont := Preferences standardListFont. > itemCount := items size. > + width := ((items take: 15) collect: [:item| listFont > widthOfString: item]) max. > + ^ (width min: (self currentWorld extent x * 0.75) asInteger max: > ((listFont widthOf: $m) * 12)) > + @ ((itemCount min: 15 max: 5) * listFont height + self > searchBarHeight) > + ! > - maxItemSize := items inject: 0 into: [:max :item | max max: item > size]. > - cellSize := (listFont widthOf: $m) @ listFont height. > - > - ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) > - @ (itemCount + 1 "breathing space" min: 15 max: 5) > - * cellSize) + (0@ self searchBarHeight)! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18053 bytes Desc: not available URL: From cunningham.cb at gmail.com Mon Jan 11 19:20:07 2021 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Mon, 11 Jan 2021 11:20:07 -0800 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.271.mcz In-Reply-To: References: Message-ID: It looks like it is 2 pixels short for height. If the size list size is between 5 and 15, it will include the vertical scroll bar to scroll for those 2 pixels (or, I am guessing, however big the list box boundary line is). It looks like the width is short by the padding size before and after the text - maybe adding an $m width to the horizontal size would make it better (or figure out what the right padding + list box boundary line width is and add it in). On Mon, Jan 11, 2021 at 10:17 AM Chris Cunningham wrote: > [image: image.png] > and > [image: image.png] > close enough. > > On Mon, Jan 11, 2021 at 10:16 AM wrote: > >> A new version of ToolBuilder-Morphic was added to project The Inbox: >> http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.271.mcz >> >> ==================== Summary ==================== >> >> Name: ToolBuilder-Morphic-cbc.271 >> Author: cbc >> Time: 11 January 2021, 10:15:51.0644 am >> UUID: 76f9fb95-5700-1b43-a9af-9ab88aaa890f >> Ancestors: ToolBuilder-Morphic-mt.270 >> >> Let the width of List Chooser try to accomodate better to the actual size >> of the string. >> >> =============== Diff against ToolBuilder-Morphic-mt.270 =============== >> >> Item was changed: >> ----- Method: ListChooser>>initialExtent (in category 'building') ----- >> initialExtent >> + | listFont itemCount width | >> - >> - | listFont itemCount maxItemSize cellSize | >> listFont := Preferences standardListFont. >> itemCount := items size. >> + width := ((items take: 15) collect: [:item| listFont >> widthOfString: item]) max. >> + ^ (width min: (self currentWorld extent x * 0.75) asInteger max: >> ((listFont widthOf: $m) * 12)) >> + @ ((itemCount min: 15 max: 5) * listFont height + self >> searchBarHeight) >> + ! >> - maxItemSize := items inject: 0 into: [:max :item | max max: item >> size]. >> - cellSize := (listFont widthOf: $m) @ listFont height. >> - >> - ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) >> - @ (itemCount + 1 "breathing space" min: 15 max: 5) >> - * cellSize) + (0@ self searchBarHeight)! >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18053 bytes Desc: not available URL: From commits at source.squeak.org Mon Jan 11 19:45:18 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 11 Jan 2021 19:45:18 0000 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.271.mcz Message-ID: A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.271.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.271 Author: cbc Time: 11 January 2021, 11:45:17.6054 am UUID: e3ae199a-f7cd-504e-9905-2afcf36dbdb1 Ancestors: ToolBuilder-Morphic-mt.270 Better estimated size: - includes default cellInsert for listMorph - includes boundary line size Also tries to size for width of strings - at least, the first 15 samples. =============== Diff against ToolBuilder-Morphic-mt.270 =============== Item was changed: ----- Method: ListChooser>>buildWith: (in category 'building') ----- buildWith: builder | dialogSpec searchBarHeight listSpec fieldSpec | searchBarHeight := self searchBarHeight. dialogSpec := builder pluggableDialogSpec new model: self; title: #title; closeAction: #closed; extent: self initialExtent; autoCancel: true; "Behave like a pop-up menu. Historical reasons." children: OrderedCollection new; buttons: OrderedCollection new; yourself. listSpec := builder pluggableListSpec new. listSpec model: self; list: #items; getIndex: #selectedIndex; setIndex: #selectedIndex:; doubleClick: #accept; "keystrokePreview: #keyStrokeFromList:;" autoDeselect: false; filterableList: true; clearFilterAutomatically: false; name: #list; + frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: (0 at searchBarHeight corner: 0 at 0)); + hScrollBarPolicy: #whenNeeded. - frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: (0 at searchBarHeight corner: 0 at 0)). dialogSpec children add: listSpec. fieldSpec := builder pluggableInputFieldSpec new. fieldSpec model: self; name: #searchText ; getText: #searchText; editText: #searchText:; setText: #acceptText:; selection: #textSelection; menu: nil; indicateUnacceptedChanges: false; askBeforeDiscardingEdits: false; help: (self addAllowed ifTrue: ['Type new or filter existing...' translated] ifFalse: ['Type to filter existing...' translated]); frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: 0 at searchBarHeight)). dialogSpec children add: fieldSpec. "Buttons" dialogSpec buttons add: ( builder pluggableButtonSpec new model: self; label: #acceptLabel; action: #accept; enabled: #canAcceptOrAdd; color: #acceptColor). dialogSpec buttons add: ( builder pluggableButtonSpec new model: self; label: 'Cancel'; action: #cancel; color: #cancelColor). dialogMorph := builder build: dialogSpec. dialogMorph addKeyboardCaptureFilter: self ; positionOverWidgetNamed: #searchText. listMorph := builder widgetAt: #list. listMorph allowEmptyFilterResult: true. ^ dialogMorph! Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont itemCount width listBoxBoundaryLineSize defaultCellWidthIndex | - - | listFont itemCount maxItemSize cellSize | listFont := Preferences standardListFont. itemCount := items size. + listBoxBoundaryLineSize := 2. + defaultCellWidthIndex := 6. "3 before, 3 after, no height insert - taken from LazyListMorph, the underlying list morph" + width := ((items take: 15) collect: [:item| listFont widthOfString: item]) max. + width := width + listBoxBoundaryLineSize + defaultCellWidthIndex. + ^ (width min: (self currentWorld extent x * 0.75) asInteger max: ((listFont widthOf: $m) * 12)) + @ ((itemCount min: 15 max: 5) * listFont height + self searchBarHeight + listBoxBoundaryLineSize) + ! - maxItemSize := items inject: 0 into: [:max :item | max max: item size]. - cellSize := (listFont widthOf: $m) @ listFont height. - - ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) - @ (itemCount + 1 "breathing space" min: 15 max: 5) - * cellSize) + (0@ self searchBarHeight)! From cunningham.cb at gmail.com Mon Jan 11 19:47:49 2021 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Mon, 11 Jan 2021 11:47:49 -0800 Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.270.mcz In-Reply-To: References: Message-ID: Would my current version 271 in the inbox be acceptable? -cbc On Mon, Jan 11, 2021 at 9:48 AM Chris Cunningham wrote: > Close. I'd still like to try and make it wide for the strings > provided. Note that : > width := ((items take: 15) collect: [:item| listFont widthOfString: > item]) max. "A good estimate of what is needed in the list box width" > works for both string and Text. That said, we should still have 2 bounds > - one for width of world (dialog will build bigger than the world - not > good) and lower bound for the size of the buttons - it would be nice not to > stack the Choose/Cancel button. > > For the height - what you have is better than what I had - that part I > like. > > On Mon, Jan 11, 2021 at 8:38 AM Marcel Taeumel > wrote: > >> >> Am 11.01.2021 17:36:52 schrieb commits at source.squeak.org < >> commits at source.squeak.org>: >> Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project >> The Trunk: >> http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.270.mcz >> >> ==================== Summary ==================== >> >> Name: ToolBuilder-Morphic-mt.270 >> Author: mt >> Time: 11 January 2021, 5:36:43.295446 pm >> UUID: 5171b75b-ee89-b14f-8ec9-a27cdfaa52bb >> Ancestors: ToolBuilder-Morphic-mt.269 >> >> To pluggable dialogs, add an expand button if the model supports >> #preferredExtent. Also tweaks a list-chooser's initial extent show 5 to 15 >> items which each about 10 to 20 characters, depending on the list's content. >> >> This commit addresses the concerns raised in ToolBuilder-Morphic-cbc.270 >> (inbox). >> See >> http://forum.world.st/The-Inbox-ToolBuilder-Morphic-cbc-270-mcz-tp5126045.html >> >> =============== Diff against ToolBuilder-Morphic-mt.269 =============== >> >> Item was changed: >> ----- Method: ListChooser>>buildWith: (in category 'building') ----- >> buildWith: builder >> >> | dialogSpec searchBarHeight listSpec fieldSpec | >> >> + searchBarHeight := self searchBarHeight. >> - searchBarHeight := Preferences standardDefaultTextFont height * 1.75. >> >> dialogSpec := builder pluggableDialogSpec new >> model: self; >> title: #title; >> closeAction: #closed; >> extent: self initialExtent; >> autoCancel: true; "Behave like a pop-up menu. Historical reasons." >> children: OrderedCollection new; >> buttons: OrderedCollection new; >> yourself. >> >> listSpec := builder pluggableListSpec new. >> listSpec >> model: self; >> list: #items; >> getIndex: #selectedIndex; >> setIndex: #selectedIndex:; >> doubleClick: #accept; >> "keystrokePreview: #keyStrokeFromList:;" >> autoDeselect: false; >> filterableList: true; >> clearFilterAutomatically: false; >> name: #list; >> frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: >> (0 at searchBarHeight corner: 0 at 0)). >> dialogSpec children add: listSpec. >> >> fieldSpec := builder pluggableInputFieldSpec new. >> fieldSpec >> model: self; >> name: #searchText ; >> getText: #searchText; >> editText: #searchText:; >> setText: #acceptText:; >> selection: #textSelection; >> menu: nil; >> indicateUnacceptedChanges: false; >> askBeforeDiscardingEdits: false; >> help: (self addAllowed ifTrue: ['Type new or filter existing...' >> translated] ifFalse: ['Type to filter existing...' translated]); >> frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: >> 0 at searchBarHeight)). >> dialogSpec children add: fieldSpec. >> >> "Buttons" >> dialogSpec buttons add: ( >> builder pluggableButtonSpec new >> model: self; >> label: #acceptLabel; >> action: #accept; >> enabled: #canAcceptOrAdd; >> color: #acceptColor). >> >> dialogSpec buttons add: ( >> builder pluggableButtonSpec new >> model: self; >> label: 'Cancel'; >> action: #cancel; >> color: #cancelColor). >> >> dialogMorph := builder build: dialogSpec. >> dialogMorph addKeyboardCaptureFilter: self ; positionOverWidgetNamed: >> #searchText. >> listMorph := builder widgetAt: #list. >> listMorph allowEmptyFilterResult: true. >> >> ^ dialogMorph! >> >> Item was changed: >> ----- Method: ListChooser>>initialExtent (in category 'building') ----- >> initialExtent >> >> + | listFont itemCount maxItemSize cellSize | >> - | listFont | >> listFont := Preferences standardListFont. >> + itemCount := items size. >> + maxItemSize := items inject: 0 into: [:max :item | max max: item size]. >> + cellSize := (listFont widthOf: $m) @ listFont height. >> + >> + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) >> + @ (itemCount + 1 "breathing space" min: 15 max: 5) >> + * cellSize) + (0@ self searchBarHeight)! >> - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! >> >> Item was added: >> + ----- Method: ListChooser>>preferredExtent (in category 'building') >> ----- >> + preferredExtent >> + >> + | listFont cellSize | >> + listFont := Preferences standardListFont. >> + cellSize := (listFont widthOf: $m) @ listFont height. >> + >> + ^ ((items inject: 0 into: [:max :item | max max: (listFont >> widthOfString: item)]) >> + @ (items size * listFont height)) >> + + ((1 at 1) * cellSize) "breathing space" >> + + (0@ self searchBarHeight)! >> >> Item was added: >> + ----- Method: ListChooser>>searchBarHeight (in category 'building') >> ----- >> + searchBarHeight >> + >> + ^ Preferences standardDefaultTextFont height * 1.75! >> >> Item was changed: >> ----- Method: ListMultipleChooser>>initialExtent (in category >> 'toolbuilder') ----- >> initialExtent >> >> + | listFont itemCount maxItemSize cellSize | >> - | listFont | >> listFont := Preferences standardListFont. >> + itemCount := labels size. >> + maxItemSize := labels inject: 0 into: [:max :item | max max: item size]. >> + cellSize := (listFont widthOf: $m) @ listFont height. >> + >> + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) >> + @ (itemCount + 1 "breathing space" min: 15 max: 5) >> + * cellSize)! >> - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! >> >> Item was added: >> + ----- Method: ListMultipleChooser>>preferredExtent (in category >> 'toolbuilder') ----- >> + preferredExtent >> + >> + | listFont cellSize | >> + listFont := Preferences standardListFont. >> + cellSize := (listFont widthOf: $m) @ listFont height. >> + >> + ^ ((labels inject: 0 into: [:max :item | max max: (listFont >> widthOfString: item)]) >> + @ (labels size * listFont height)) >> + + ((1 at 1) * cellSize) "breathing space"! >> >> Item was changed: >> ----- Method: MorphicToolBuilder>>buildPluggableDialog: (in category >> 'widgets optional') ----- >> buildPluggableDialog: aSpec >> >> | widget | >> >> widget := self dialogClass new. >> self register: widget id: aSpec name. >> >> widget model: aSpec model. >> >> "Set child dependent layout properties. The pane morph holds the special >> contents." >> widget paneMorph wantsPaneSplitters: (aSpec wantsResizeHandles ifNil: >> [true]). >> self setLayoutHintsFor: widget paneMorph spec: aSpec. >> widget paneMorph layoutInset: (aSpec padding ifNil: >> [ProportionalSplitterMorph gripThickness]). >> widget paneMorph cellGap: (aSpec spacing ifNil: >> [ProportionalSplitterMorph gripThickness]). >> widget paneMorph wantsPaneSplitters ifTrue: [ >> widget paneMorph addCornerGrips"addEdgeGrips". >> widget paneMorph grips do: [:ea | ea showHandle: true]]. >> >> "Now create the children." >> panes := OrderedCollection new. >> aSpec children isSymbol >> ifTrue: [ >> widget getChildrenSelector: aSpec children. >> widget update: aSpec children] >> ifFalse: [ >> self buildAll: aSpec children in: widget paneMorph]. >> >> "Now create the buttons." >> aSpec buttons isSymbol >> ifTrue: [ >> widget getButtonsSelector: aSpec buttons. >> widget update: aSpec buttons] >> ifFalse: [ >> self buildAll: aSpec buttons in: widget buttonRowMorph. >> widget updateButtonProperties]. >> >> aSpec title ifNotNil: [:label | >> label isSymbol >> ifTrue:[widget getTitleSelector: label; update: label] >> ifFalse:[widget title: label]]. >> aSpec message ifNotNil: [:label | >> label isSymbol >> ifTrue:[widget getMessageSelector: label; update: label] >> ifFalse:[widget message: label]]. >> >> "Interaction behavior." >> aSpec autoCancel ifNotNil: [:b | widget autoCancel: b]. >> aSpec exclusive ifNotNil: [:b | widget exclusive: b]. >> >> widget closeDialogSelector: aSpec closeAction. >> self buildHelpFor: widget spec: aSpec. >> >> "Everything is shrink-wrapped around the pane morph." >> + widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]) >> + + (widget paneMorph layoutInset * 2) asPoint. >> - widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]). >> >> ^ widget! >> >> Item was added: >> + ----- Method: PluggableDialogWindow>>createTitle: (in category >> 'initialization') ----- >> + createTitle: aString >> + "Overridden to add an extra expand button. Yet, it depends on the >> model's interface whether that button will be visible. See #model:." >> + >> + | box expandButton| >> + super createTitle: aString. >> + >> + expandButton := SystemWindowButton new >> + name: #expandButton; >> + color: Color transparent; >> + target: self; >> + actionSelector: #expandDialogPane; >> + balloonText: 'Expand this dialog' translated; >> + borderWidth: 0; >> + yourself. >> + SystemWindow expandBoxImage scaleIconToDisplay in: [:icon | >> + expandButton labelGraphic: icon; extent: icon extent]. >> + >> + box := self submorphNamed: #title. >> + box addMorphBack: expandButton.! >> >> Item was added: >> + ----- Method: PluggableDialogWindow>>expandDialogPane (in category >> 'running') ----- >> + expandDialogPane >> + "Expand the dialog pane to its preferred extent. Honor the visible area >> in the world." >> + >> + | visibleArea decorationOffset expandedExtent | >> + visibleArea := self currentWorld visibleClearArea. >> + decorationOffset := self extent - self paneMorph extent. >> + expandedExtent := self model preferredExtent + (self paneMorph >> layoutInset * 2) asPoint. >> + >> + self paneMorph extent: (expandedExtent min: visibleArea extent - >> decorationOffset). >> + >> + self fullBounds. >> + self moveToPreferredPosition.! >> >> Item was changed: >> ----- Method: PluggableDialogWindow>>model: (in category 'accessing') >> ----- >> + model: newModel >> - model: anObject >> >> model ifNotNil: [model removeDependent: self]. >> + newModel ifNotNil: [ >> + newModel addDependent: self. >> + (newModel respondsTo: #preferredExtent) >> + ifFalse: [((self submorphNamed: #title) submorphNamed: #expandButton) >> delete]]. >> + model := newModel.! >> - anObject ifNotNil: [anObject addDependent: self]. >> - model := anObject.! >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 111558 bytes Desc: not available URL: From bruce.oneel at pckswarms.ch Mon Jan 11 20:36:02 2021 From: bruce.oneel at pckswarms.ch (Bruce O'Neel) Date: Mon, 11 Jan 2021 21:36:02 +0100 Subject: [squeak-dev] Squeak and Sound In-Reply-To: References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> Message-ID: <1610397362-e6a8a67e130b246c1df9b9d6d5aeb5b0@pckswarms.ch> Hi, It seems that libpulse-dev only needs to be installed on the build machine.  That is quite logical, it is a dev package.  It also looks that pulse audio is picked by default, at least on new? linux versions. I am unable to test on the PI.  I can't convince it to work with a bluetooth speaker so I guess I need a USB speaker. I also notice that on the newest version of Raspberry PI OS seems not to get all the way through the build though there are no obvious errors.  it stops right after the ar of vm.a, and does not do the libtool parts.  Both the older PI 3 and the new PI 4 have the same packages installed after the installation but maybe a different base set. I'll look more tomorrow. cheers bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Mon Jan 11 21:19:24 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon, 11 Jan 2021 22:19:24 +0100 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <1610397362-e6a8a67e130b246c1df9b9d6d5aeb5b0@pckswarms.ch> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610397362-e6a8a67e130b246c1df9b9d6d5aeb5b0@pckswarms.ch> Message-ID: hi > On 11. Jan 2021, at 21:36, Bruce O'Neel wrote: > > > Hi, > > It seems that libpulse-dev only needs to be installed on the build machine. yes > That is quite logical, it is a dev package. It also looks that pulse audio is picked by default, at least on new? linux versions. yes > > I am unable to test on the PI. I can't convince it to work with a bluetooth speaker so I guess I need a USB speaker. > > I also notice that on the newest version of Raspberry PI OS seems not to get all the way through the build though there are no obvious errors. it stops right after the ar of vm.a, and does not do the libtool parts. can you open an issue on github with the error? Best regards -Tobias > Both the older PI 3 and the new PI 4 have the same packages installed after the installation but maybe a different base set. > > I'll look more tomorrow. > > cheers > > bruce > > > 11 January 2021 19:11 Eliot Miranda wrote: > Hi Bruce, Hi squeak.org maintainers, > > this kind of information is incredibly important for new users who grab squeak and want to get things done. We should make sure there is on squeak.org a "tips and tricks" page, or series of items on the download page that help new users solve these kinds of issues. The last thing we want is for a new user to find themselves blocked and have to go to the mailing list to get help. In that arc from being blocked to asking for help many people may simply give up and we will, I believe, lose users that way. > > So Bruce, this inf should be in HowToBuild, but all, it should also be on squeak.org, and prominently. > > On Mon, Jan 11, 2021 at 3:04 AM Bruce O'Neel wrote: > Hi, > > I just installed Mint 20.1, which is based on the most recent Ubuntu, on a x86-64 system ran > > apt install libpulse-dev > > and then built the VM at the git HEAD, and unlike before sound works perfectly. This is with a 5.3 image. > > Off to try this on my PI 400... > > cheers > > bruce From tim at rowledge.org Mon Jan 11 21:28:31 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 11 Jan 2021 13:28:31 -0800 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> Message-ID: > On 2021-01-11, at 3:03 AM, Bruce O'Neel wrote: > > Hi, > > I just installed Mint 20.1, which is based on the most recent Ubuntu, on a x86-64 system ran > > apt install libpulse-dev > > and then built the VM at the git HEAD, and unlike before sound works perfectly. This is with a 5.3 image. > > Off to try this on my PI 400... I'll be very interested in your report. Sound on the latest PI OS with pulse works just fine for almost all cases BUT do try the pianokeyboardmorph and zip up and down the keyboard. The short notes with negligible time gap between each and the next seems to really mess things up. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: WDS: Warp Drive, Scotty! From tim at rowledge.org Mon Jan 11 21:30:31 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 11 Jan 2021 13:30:31 -0800 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <1610380847-5784e7d16d84742f660041b9c9633992@pckswarms.ch> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610380847-5784e7d16d84742f660041b9c9633992@pckswarms.ch> Message-ID: > On 2021-01-11, at 8:00 AM, Bruce O'Neel wrote: > > > Off to try this on my PI 400... > > > > > which, duh, does not have a headphone jack so that was unsuccessful. Can you do a) bluetooth audio (one of the reasons for Pi moving to pulse is apparently better BT audio) b) usb audio c) HDMI audio tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Ignoranus (n): A person who's both stupid and an asshole. From tim at rowledge.org Mon Jan 11 21:43:29 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 11 Jan 2021 13:43:29 -0800 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <1610397362-e6a8a67e130b246c1df9b9d6d5aeb5b0@pckswarms.ch> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610397362-e6a8a67e130b246c1df9b9d6d5aeb5b0@pckswarms.ch> Message-ID: <61A78EEC-EE1A-4AE2-8B6C-AB293B802F77@rowledge.org> > On 2021-01-11, at 12:36 PM, Bruce O'Neel wrote: > > > Hi, > > It seems that libpulse-dev only needs to be installed on the build machine. That is quite logical, it is a dev package. It also looks that pulse audio is picked by default, at least on new? linux versions. > > I am unable to test on the PI. I can't convince it to work with a bluetooth speaker so I guess I need a USB speaker. > > I also notice that on the newest version of Raspberry PI OS seems not to get all the way through the build though there are no obvious errors. it stops right after the ar of vm.a, and does not do the libtool parts. Both the older PI 3 and the new PI 4 have the same packages installed after the installation but maybe a different base set. I've had to do 'sudo ./mvm' recently in order to get a completed build. No idea why. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim A conscience is what hurts when all your other parts feel so good. From vanessa at codefrau.net Mon Jan 11 22:56:51 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Mon, 11 Jan 2021 14:56:51 -0800 Subject: [squeak-dev] V3 In-Reply-To: <20210109150921.GA331@shell.msen.com> References: <20210109150921.GA331@shell.msen.com> Message-ID: On Sat, Jan 9, 2021 at 7:09 AM David T. Lewis wrote: > On Fri, Jan 08, 2021 at 08:08:33PM -0800, Eliot Miranda wrote: > > Hi V, > > > > On Tue, Jan 5, 2021 at 6:07 PM Vanessa Freudenberg > > > wrote: > > > > > Reading the code I again noticed "Squeak V3" as name for the old > bytecode > > > set. Always wanted to know: Where does the "V3" nomenclature come from? > > > What's V1 and V2? And should we consider Sista to be V4, or treat it as > > > completely unrelated? > > > > > > > In my diseased and uninformed mind V3 came from my noticing that the > double > > extended do anything bytecode didn't exist in Smalltalk-80, so I presumed > > it wasn't in Squeak V1. I don't know if it's in V2, and I was too lazy > to > > go look, but I did know it was in V3, so I called it, and the object > > representation "V3". Presumptuous but concise of me. For me it really > is > > a label for no more than the state of play of Squeak when I came to start > > changing its core execution engine. I hope this is harmless enough. > > > > I have become quite comfortable with the "V3" notation by now, regardless > of its origins. I would prefer not to change it because I have used it > extensively in some of my own personal projects (e.g. all of the package > names in my http://www.squeaksource.com/TrunkUpdateStreamV3 hobby > project). > > I also just like the name. "V3" is short and easily recognized, and it > works nicely as a prefix or suffix in other names. To me, it also carries > a vague connotation of "stable but not necessarily the latest thing". > That's probably based on my recollection of early PC applications and > operating systems where everyone knew not to trust any product until > it reached at least version 3 ;-) > > Dave > Can we come up with some major VM milestones to retroactively label as V1 / V2 / V3? Off the top of my head these could be * the original extension from ST80 to Squeak (as documented in Dan's "Back to the future": 32 bit direct pointers, no refcounting, variable-length object headers, etc) * named primitives * 64 bit support * closures V1 would be the 1996 one then V3 might be the closure-supporting one (which year was that?) V2 - ? Vanessa -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Mon Jan 11 23:00:13 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon, 11 Jan 2021 15:00:13 -0800 Subject: [squeak-dev] V3 In-Reply-To: References: <20210109150921.GA331@shell.msen.com> Message-ID: On Mon, Jan 11, 2021 at 2:57 PM Vanessa Freudenberg wrote: > On Sat, Jan 9, 2021 at 7:09 AM David T. Lewis wrote: > >> On Fri, Jan 08, 2021 at 08:08:33PM -0800, Eliot Miranda wrote: >> > Hi V, >> > >> > On Tue, Jan 5, 2021 at 6:07 PM Vanessa Freudenberg < >> vanessa at codefrau.net> >> > wrote: >> > >> > > Reading the code I again noticed "Squeak V3" as name for the old >> bytecode >> > > set. Always wanted to know: Where does the "V3" nomenclature come >> from? >> > > What's V1 and V2? And should we consider Sista to be V4, or treat it >> as >> > > completely unrelated? >> > > >> > >> > In my diseased and uninformed mind V3 came from my noticing that the >> double >> > extended do anything bytecode didn't exist in Smalltalk-80, so I >> presumed >> > it wasn't in Squeak V1. I don't know if it's in V2, and I was too lazy >> to >> > go look, but I did know it was in V3, so I called it, and the object >> > representation "V3". Presumptuous but concise of me. For me it really >> is >> > a label for no more than the state of play of Squeak when I came to >> start >> > changing its core execution engine. I hope this is harmless enough. >> > >> >> I have become quite comfortable with the "V3" notation by now, regardless >> of its origins. I would prefer not to change it because I have used it >> extensively in some of my own personal projects (e.g. all of the package >> names in my http://www.squeaksource.com/TrunkUpdateStreamV3 hobby >> project). >> >> I also just like the name. "V3" is short and easily recognized, and it >> works nicely as a prefix or suffix in other names. To me, it also carries >> a vague connotation of "stable but not necessarily the latest thing". >> That's probably based on my recollection of early PC applications and >> operating systems where everyone knew not to trust any product until >> it reached at least version 3 ;-) >> >> Dave >> > > Can we come up with some major VM milestones to retroactively label as V1 > / V2 / V3? > > Off the top of my head these could be > > * the original extension from ST80 to Squeak (as documented in Dan's "Back > to the future": 32 bit direct pointers, no refcounting, variable-length > object headers, etc) > * named primitives > * 64 bit support > * closures > > V1 would be the 1996 one then > +1 > V3 might be the closure-supporting one (which year was that?) > 2009 (internally @ Qwaq) / 2010 (released to the community) V2 - ? > Named primitives seems like a major change to me. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa at codefrau.net Mon Jan 11 23:14:35 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Mon, 11 Jan 2021 15:14:35 -0800 Subject: [squeak-dev] V3 In-Reply-To: References: <20210109150921.GA331@shell.msen.com> Message-ID: On Mon, Jan 11, 2021 at 3:00 PM Eliot Miranda wrote: > > > On Mon, Jan 11, 2021 at 2:57 PM Vanessa Freudenberg > wrote: > >> On Sat, Jan 9, 2021 at 7:09 AM David T. Lewis >> wrote: >> >>> On Fri, Jan 08, 2021 at 08:08:33PM -0800, Eliot Miranda wrote: >>> > Hi V, >>> > >>> > On Tue, Jan 5, 2021 at 6:07 PM Vanessa Freudenberg < >>> vanessa at codefrau.net> >>> > wrote: >>> > >>> > > Reading the code I again noticed "Squeak V3" as name for the old >>> bytecode >>> > > set. Always wanted to know: Where does the "V3" nomenclature come >>> from? >>> > > What's V1 and V2? And should we consider Sista to be V4, or treat it >>> as >>> > > completely unrelated? >>> > > >>> > >>> > In my diseased and uninformed mind V3 came from my noticing that the >>> double >>> > extended do anything bytecode didn't exist in Smalltalk-80, so I >>> presumed >>> > it wasn't in Squeak V1. I don't know if it's in V2, and I was too >>> lazy to >>> > go look, but I did know it was in V3, so I called it, and the object >>> > representation "V3". Presumptuous but concise of me. For me it >>> really is >>> > a label for no more than the state of play of Squeak when I came to >>> start >>> > changing its core execution engine. I hope this is harmless enough. >>> > >>> >>> I have become quite comfortable with the "V3" notation by now, regardless >>> of its origins. I would prefer not to change it because I have used it >>> extensively in some of my own personal projects (e.g. all of the package >>> names in my http://www.squeaksource.com/TrunkUpdateStreamV3 hobby >>> project). >>> >>> I also just like the name. "V3" is short and easily recognized, and it >>> works nicely as a prefix or suffix in other names. To me, it also carries >>> a vague connotation of "stable but not necessarily the latest thing". >>> That's probably based on my recollection of early PC applications and >>> operating systems where everyone knew not to trust any product until >>> it reached at least version 3 ;-) >>> >>> Dave >>> >> >> Can we come up with some major VM milestones to retroactively label as V1 >> / V2 / V3? >> >> Off the top of my head these could be >> >> * the original extension from ST80 to Squeak (as documented in Dan's >> "Back to the future": 32 bit direct pointers, no refcounting, >> variable-length object headers, etc) >> * named primitives >> * 64 bit support >> * closures >> >> V1 would be the 1996 one then >> > > +1 > >> V3 might be the closure-supporting one (which year was that?) >> > > 2009 (internally @ Qwaq) / 2010 (released to the community) > > V2 - ? >> > > Named primitives seems like a major change to me > This message appears to indicate that named primitives and weak collections arrived at the same time in 1998: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-November/023502.html Seems like a good candidate. Unless someone remembers a history of changes to bytecodes specifically? - Vanessa - -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Mon Jan 11 23:15:35 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 11 Jan 2021 15:15:35 -0800 Subject: [squeak-dev] V3 In-Reply-To: References: <20210109150921.GA331@shell.msen.com> Message-ID: <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> > On 2021-01-11, at 3:00 PM, Eliot Miranda wrote: > > V1 would be the 1996 one then > > +1 > V3 might be the closure-supporting one (which year was that?) Except Dan was talking V3 back in '99 and the intent was to include Ian's never-quite-done jit, and from a Dan-mail of Oct 19th - > My revised goal would be... > > Increase max context size to 80, and go back to two sizes like 16 and 80 > Merge format bits in behaviors > Merge prim index bits in methods > Your compiled method changes (to which Ian might wish to add an extra field) > > 2009 (internally @ Qwaq) / 2010 (released to the community) > > V2 - ? > > Named primitives seems like a major change to me. The named/external prims was early '99-ish tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Oyster (n.), a person who sprinkles his conversation with Yiddishisms. From vanessa at codefrau.net Mon Jan 11 23:37:07 2021 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Mon, 11 Jan 2021 15:37:07 -0800 Subject: [squeak-dev] V3 In-Reply-To: <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> Message-ID: On Mon, Jan 11, 2021 at 3:15 PM tim Rowledge wrote: > > > > On 2021-01-11, at 3:00 PM, Eliot Miranda > wrote: > > > > > V1 would be the 1996 one then > > > > +1 > > V3 might be the closure-supporting one (which year was that?) > > Except Dan was talking V3 back in '99 Do you mean "3.x"? That was in the Squeak 2.x era and I think he was talking about Squeak versions. We're trying to find a justification for calling the "old" VMs "V3", independent of the Squeak releases (or SqueakV3.sources which unfortunately uses V3 in a completely different sense) I'd personally prefer to get rid of the V3 naming for bytecode/VM-related entities but as Dave pointed out, it has proliferated due to being unquestioned for too long. Giving some sensible meaning to "V3" seems like a good way forward. and the intent was to include Ian's never-quite-done jit, and from a > Dan-mail of Oct 19th - > > > My revised goal would be... > > > > Increase max context size to 80, and go back to two sizes like 16 > and 80 > > Merge format bits in behaviors > > Merge prim index bits in methods > > Your compiled method changes (to which Ian might wish to add an > extra field) > Right, but that version never got adopted. > The named/external prims was early '99-ish > Sounds about right. Does someone have an actual history of the VM, maybe from SVN? Or were we still using changesets for VM code back then? - Vanessa - -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Mon Jan 11 23:55:44 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 11 Jan 2021 15:55:44 -0800 Subject: [squeak-dev] V3 In-Reply-To: References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> Message-ID: > On 2021-01-11, at 3:37 PM, Vanessa Freudenberg wrote: > > On Mon, Jan 11, 2021 at 3:15 PM tim Rowledge wrote: > > > > On 2021-01-11, at 3:00 PM, Eliot Miranda wrote: > > > > > V1 would be the 1996 one then > > > > +1 > > V3 might be the closure-supporting one (which year was that?) > > Except Dan was talking V3 back in '99 > > Do you mean "3.x"? That was in the Squeak 2.x era and I think he was talking about Squeak versions. Maaaaaybe. The emails are headed 'Version 3 image'. I think retconning history may be futile. It's quite clear the reality lines have been thoroughly messed up since at least 2000. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim "How many Motie Mediators does it take to chage a lightbulb?” "Are you insane? Only Crazy Eddie would want to change *anything*!" From lewis at mail.msen.com Tue Jan 12 00:52:56 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 11 Jan 2021 19:52:56 -0500 Subject: [squeak-dev] [Test][Squeak5.2rc1][SqueakMap] FFI entry in SqueakMap catalog for 5.2? In-Reply-To: References: Message-ID: <20210112005256.GA70731@shell.msen.com> On Fri, Oct 12, 2018 at 10:05:40PM +0200, H. Hirzel wrote: > Hi Chris > > On 10/12/18, Chris Muller wrote: > > Hi Hannes, > > > > I think you did not understand. Just because you "tested it and it > > worked" TODAY does not mean that script will continue working forever. > > There is no such claim. The claim is just that it still works for 5.2. +1 > > > That's why we MUST NOT put a "Squeak 5.2" tag on it unless we make a > > separate Release with a script that uses explicitly-specified > > versions. > > > That's what we have now, I see no versions of "FFI" for 4.5, only > > (head), 3.10, and 3.9. The last two were published by Andreas. > > And that contains > > Installer new merge: #ffiTests' > > That means this script has been working since 3.9, i.e. for 10 years. +1 Chris, this is important. We have to have some way to handle the use case that Hannes is trying to handle here. As a package maintainer, I do /not/ want to declare a new release of my package unless unless I have actually released something new in my package, because that forces me to declare a new release of my package when no such thing has actually happened. When someone in the Squeak or Cuis or Pharo community decides to announce a new release of their image distribution, I /do/ want to announce my claim that some version of my package works with that release, because I want to let that community know that my package still works with their new release. We need some way to deal with this use case. "Make another bogus release of your package every time somebody in Sqeak/Cuis/Pharo decides to announce a new release of their image" is not really a very good answer. it kind of works but ... yuk. Dave > > > --Hannes > > > HTH, > > Chris > > On Fri, Oct 12, 2018 at 2:36 PM H. Hirzel wrote: > >> > >> Hi Chris > >> > >> I think that just > >> > >> Installer new merge: #ffiTests > >> > >> is good enough. Like it was for earlier version. I tested it and it > >> worked. > >> > >> I just wonder what I need to do that it shows up in the list of > >> available packages for 5.2? > >> > >> --Hannes > >> > >> On 10/12/18, Chris Muller wrote: > >> > Hi Hannes, > >> > > >> > It depends on what all we want do the work to catalog. "Installer new > >> > merge: #ffiTests" just loads the latest versions of all the packages, > >> > not a fixed configuration, so that script is not suitable to tag with > >> > any Squeak-specific versions, only the (head) version. If you want to > >> > make one for 5.2, we must use a totally different script which > >> > specifies the exact version #'s of all the packages, so we know it > >> > will always work in 5.2. You could copy & paste one of the scripts > >> > for one of my packages (Magma, etc.) which I just updated yesterday, > >> > BTW... > >> > > >> > Best, > >> > Chris > >> > > >> >> The relevant FFI entry has as load script is just > >> >> > >> >> Installer new merge: #ffiTests > >> >> > >> >> This still applies for 5.2. > >> >> > >> >> However the last time FFI shows up in the SqueakMap client list for a > >> >> particular release is version 4.5. > >> >> > >> >> Not in 4.6, 5.0 and 5.1 > >> >> > >> >> What do I need to do to make it appear in the list for 5.2. > >> >> > >> >> Creating a release for 5.2 would be an option but that seems > >> >> unnecessary as it had not been done for 4.5 either. > >> >> > >> >> Suggestions how to proceed? > >> >> > >> >> Regards > >> >> Hannes > >> >> > >> > > >> > > > > From lewis at mail.msen.com Tue Jan 12 01:04:32 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 11 Jan 2021 20:04:32 -0500 Subject: [squeak-dev] V3 In-Reply-To: References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> Message-ID: <20210112010432.GB70731@shell.msen.com> On Mon, Jan 11, 2021 at 03:37:07PM -0800, Vanessa Freudenberg wrote: > On Mon, Jan 11, 2021 at 3:15 PM tim Rowledge wrote: > > > The named/external prims was early '99-ish > > > > Sounds about right. Does someone have an actual history of the VM, maybe > from SVN? Or were we still using changesets for VM code back then? > The SVN repository history is on line, and begins October 2001: http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/Cross/vm/sqVirtualMachine.h?revision=2&view=markup Prior to that the support code was hosted on sourceforge.com. I don't know if any copy of that repository still exists, and I don't know when it first became publicly available. Some of that history may be lost. The Smalltalk sources were first put on squeaksource.org in 2004 (MMMaker-tpr.2). As far as I know, the main gap in this historical record would probably be the sourceforge history. Dave From lewis at mail.msen.com Tue Jan 12 01:44:42 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 11 Jan 2021 20:44:42 -0500 Subject: [squeak-dev] [Test][Squeak5.2rc1][SqueakMap] FFI entry in SqueakMap catalog for 5.2? In-Reply-To: <20210112005256.GA70731@shell.msen.com> References: <20210112005256.GA70731@shell.msen.com> Message-ID: <20210112014442.GA78477@shell.msen.com> My apologies, please disregard this post. I was cleaning out some old junk from my local files and sent this to the list by accident. It belongs in the waste basket. Sorry, Dave From jecel at merlintec.com Tue Jan 12 02:35:01 2021 From: jecel at merlintec.com (Jecel Assumpcao Jr) Date: Mon, 11 Jan 2021 23:35:01 -0300 Subject: [squeak-dev] V3 In-Reply-To: <20210112010432.GB70731@shell.msen.com> References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> <20210112010432.GB70731@shell.msen.com> Message-ID: <20210112023506.27F681480B56@proxy.email-ssl.com.br> David T. Lewis wrote on Mon, 11 Jan 2021 20:04:32 -0500 > The SVN repository history is on line, and begins October 2001: > > http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/Cross/vm/sqVirtualMachine.h?revision=2&view=markup The VM was originally found in the .sources and .changes files, so looking at the #initializeBytecodeTable method I can see that the only change was that Squeak 1.1, 1.16 and 1.18 had (138 143 unknownBytecode) and that got replaced in Squeak 1.22 by (138 143 experimentalBytecode) There were no more changes until at least Squeak 3.8. Eventually the code was moved to VMMaker. For the history of named primitives and similar things I would first look into the code in the compiler that parses the methods. -- Jecel From eliot.miranda at gmail.com Tue Jan 12 05:15:23 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon, 11 Jan 2021 21:15:23 -0800 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <1610397362-e6a8a67e130b246c1df9b9d6d5aeb5b0@pckswarms.ch> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610397362-e6a8a67e130b246c1df9b9d6d5aeb5b0@pckswarms.ch> Message-ID: On Mon, Jan 11, 2021 at 12:36 PM Bruce O'Neel wrote: > > Hi, > > It seems that libpulse-dev only needs to be installed on the build > machine. That is quite logical, it is a dev package. It also looks that > pulse audio is picked by default, at least on new? linux versions. > OK, then let's make sure that this info gets in all the linux.buildXXX/HowToBuild files. > > I am unable to test on the PI. I can't convince it to work with a > bluetooth speaker so I guess I need a USB speaker. > > I also notice that on the newest version of Raspberry PI OS seems not to > get all the way through the build though there are no obvious errors. it > stops right after the ar of vm.a, and does not do the libtool parts. Both > the older PI 3 and the new PI 4 have the same packages installed after the > installation but maybe a different base set. > > I'll look more tomorrow. > > cheers > > bruce > > > > *11 January 2021 19:11 Eliot Miranda > wrote:* > > Hi Bruce, Hi squeak.org maintainers, > > this kind of information is incredibly important for new users who > grab squeak and want to get things done. We should make sure there is on > squeak.org a "tips and tricks" page, or series of items on the download > page that help new users solve these kinds of issues. The last thing we > want is for a new user to find themselves blocked and have to go to the > mailing list to get help. In that arc from being blocked to asking for > help many people may simply give up and we will, I believe, lose users that > way. > > So Bruce, this inf should be in HowToBuild, but all, it should also be on > squeak.org, and prominently. > > On Mon, Jan 11, 2021 at 3:04 AM Bruce O'Neel > wrote: > >> Hi, >> >> I just installed Mint 20.1, which is based on the most recent Ubuntu, on >> a x86-64 system ran >> >> apt install libpulse-dev >> >> and then built the VM at the git HEAD, and unlike before sound works >> perfectly. This is with a 5.3 image. >> >> Off to try this on my PI 400... >> >> cheers >> >> bruce >> >> >> > > -- > > _,,,^..^,,,_ > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.oneel at pckswarms.ch Tue Jan 12 09:29:58 2021 From: bruce.oneel at pckswarms.ch (Bruce O'Neel) Date: Tue, 12 Jan 2021 10:29:58 +0100 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <61A78EEC-EE1A-4AE2-8B6C-AB293B802F77@rowledge.org> References: <61A78EEC-EE1A-4AE2-8B6C-AB293B802F77@rowledge.org> <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610397362-e6a8a67e130b246c1df9b9d6d5aeb5b0@pckswarms.ch> Message-ID: <1610443798-31fe6a91a0885dbc658bc297c37a601c@pckswarms.ch> Hi, Nope, this was my error.  Somehow I skpped the install steps for the GL Development libraries.  Once that is done it works fine and I do not need sudo. In my case sudo ./mvm changed things enough that that error shows up. It would be best if we do not have to build using sudo.  I get bad clenchy feelings in my stomach with that. cheers bruce > > On 2021-01-11, at 12:36 PM, Bruce O'Neel wrote: > > > > > > Hi, > > > > It seems that libpulse-dev only needs to be installed on the build machine. That is quite logical, it is a dev package. It also looks that pulse audio is picked by default, at least on new? linux versions. > > > > I am unable to test on the PI. I can't convince it to work with a bluetooth speaker so I guess I need a USB speaker. > > > > I also notice that on the newest version of Raspberry PI OS seems not to get all the way through the build though there are no obvious errors. it stops right after the ar of vm.a, and does not do the libtool parts. Both the older PI 3 and the new PI 4 have the same packages installed after the installation but maybe a different base set. > > I've had to do 'sudo ./mvm' recently in order to get a completed build. No idea why. > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > A conscience is what hurts when all your other parts feel so good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 12 09:40:37 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 12 Jan 2021 10:40:37 +0100 Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.270.mcz In-Reply-To: References: Message-ID: Hi Chris. > Would my current version 271 in the inbox be acceptable? Not quite: - If you want to make use of horizontal scroll bars in such lists, please disable the preference "Always hise h scroll bar" - An initial world bounds check should be added to DialogWindow, not the dialog's model. I will do that. It is missing. - That "defaultCellWidthIndex" and "listBoxBoundaryLineSize" do not belong into the model. Not sure what you want to achieve here. The use of "searchBarHeight" is a compromise due to #buildWidth:. > it would be nice not to stack the Choose/Cancel button. Yeah, that's tricky. Buttons should not be stacked if there is enough width. There is an issue with HI-DPI usabge, though. But also we need a stacking logic for some ancient uses of list choose for yes/no/cancel. > That said, we should still have 2 bounds - one for width of world (dialog will build bigger than the world - not good) and lower bound for the size of the buttons. Agreed for the world bounds, disagreed for the buttons. Sorry about that button wrapping. It's due to some ancient but expected uses of list-choosers for yes/no/cancel. Maybe I can find a better solution in the future to avoid unnecessary button wraps. :-/ Best, Marcel Am 11.01.2021 20:48:15 schrieb Chris Cunningham : Would my current version 271 in the inbox be acceptable? -cbc On Mon, Jan 11, 2021 at 9:48 AM Chris Cunningham wrote:   Close.  I'd still like to try and make it wide for the strings provided.  Note that :  width := ((items take: 15) collect: [:item| listFont widthOfString: item]) max. "A good estimate of what is needed in the list box width" works for both string and Text.  That said, we should still have 2 bounds - one for width of world (dialog will build bigger than the world - not good) and lower bound for the size of the buttons - it would be nice not to stack the Choose/Cancel button. For the height - what you have is better than what I had - that part I like. On Mon, Jan 11, 2021 at 8:38 AM Marcel Taeumel wrote: Am 11.01.2021 17:36:52 schrieb commits at source.squeak.org [mailto:commits at source.squeak.org] : Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk: http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.270.mcz [http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.270.mcz] ==================== Summary ==================== Name: ToolBuilder-Morphic-mt.270 Author: mt Time: 11 January 2021, 5:36:43.295446 pm UUID: 5171b75b-ee89-b14f-8ec9-a27cdfaa52bb Ancestors: ToolBuilder-Morphic-mt.269 To pluggable dialogs, add an expand button if the model supports #preferredExtent. Also tweaks a list-chooser's initial extent show 5 to 15 items which each about 10 to 20 characters, depending on the list's content. This commit addresses the concerns raised in ToolBuilder-Morphic-cbc.270 (inbox). See http://forum.world.st/The-Inbox-ToolBuilder-Morphic-cbc-270-mcz-tp5126045.html [http://forum.world.st/The-Inbox-ToolBuilder-Morphic-cbc-270-mcz-tp5126045.html] =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>buildWith: (in category 'building') ----- buildWith: builder | dialogSpec searchBarHeight listSpec fieldSpec | + searchBarHeight := self searchBarHeight. - searchBarHeight := Preferences standardDefaultTextFont height * 1.75. dialogSpec := builder pluggableDialogSpec new model: self; title: #title; closeAction: #closed; extent: self initialExtent; autoCancel: true; "Behave like a pop-up menu. Historical reasons." children: OrderedCollection new; buttons: OrderedCollection new; yourself. listSpec := builder pluggableListSpec new. listSpec model: self; list: #items; getIndex: #selectedIndex; setIndex: #selectedIndex:; doubleClick: #accept; "keystrokePreview: #keyStrokeFromList:;" autoDeselect: false; filterableList: true; clearFilterAutomatically: false; name: #list; frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 1) offsets: (0 at searchBarHeight corner: 0 at 0)). dialogSpec children add: listSpec. fieldSpec := builder pluggableInputFieldSpec new. fieldSpec model: self; name: #searchText ; getText: #searchText; editText: #searchText:; setText: #acceptText:; selection: #textSelection; menu: nil; indicateUnacceptedChanges: false; askBeforeDiscardingEdits: false; help: (self addAllowed ifTrue: ['Type new or filter existing...' translated] ifFalse: ['Type to filter existing...' translated]); frame: (LayoutFrame fractions: (0 at 0 corner: 1 at 0) offsets: (0 at 0 corner: 0 at searchBarHeight)). dialogSpec children add: fieldSpec. "Buttons" dialogSpec buttons add: ( builder pluggableButtonSpec new model: self; label: #acceptLabel; action: #accept; enabled: #canAcceptOrAdd; color: #acceptColor). dialogSpec buttons add: ( builder pluggableButtonSpec new model: self; label: 'Cancel'; action: #cancel; color: #cancelColor). dialogMorph := builder build: dialogSpec. dialogMorph addKeyboardCaptureFilter: self ; positionOverWidgetNamed: #searchText. listMorph := builder widgetAt: #list. listMorph allowEmptyFilterResult: true. ^ dialogMorph! Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont itemCount maxItemSize cellSize | - | listFont | listFont := Preferences standardListFont. + itemCount := items size. + maxItemSize := items inject: 0 into: [:max :item | max max: item size]. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) + @ (itemCount + 1 "breathing space" min: 15 max: 5) + * cellSize) + (0@ self searchBarHeight)! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! Item was added: + ----- Method: ListChooser>>preferredExtent (in category 'building') ----- + preferredExtent + + | listFont cellSize | + listFont := Preferences standardListFont. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((items inject: 0 into: [:max :item | max max: (listFont widthOfString: item)]) + @ (items size * listFont height)) + + ((1 at 1) * cellSize) "breathing space" + + (0@ self searchBarHeight)! Item was added: + ----- Method: ListChooser>>searchBarHeight (in category 'building') ----- + searchBarHeight + + ^ Preferences standardDefaultTextFont height * 1.75! Item was changed: ----- Method: ListMultipleChooser>>initialExtent (in category 'toolbuilder') ----- initialExtent + | listFont itemCount maxItemSize cellSize | - | listFont | listFont := Preferences standardListFont. + itemCount := labels size. + maxItemSize := labels inject: 0 into: [:max :item | max max: item size]. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) + @ (itemCount + 1 "breathing space" min: 15 max: 5) + * cellSize)! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! Item was added: + ----- Method: ListMultipleChooser>>preferredExtent (in category 'toolbuilder') ----- + preferredExtent + + | listFont cellSize | + listFont := Preferences standardListFont. + cellSize := (listFont widthOf: $m) @ listFont height. + + ^ ((labels inject: 0 into: [:max :item | max max: (listFont widthOfString: item)]) + @ (labels size * listFont height)) + + ((1 at 1) * cellSize) "breathing space"! Item was changed: ----- Method: MorphicToolBuilder>>buildPluggableDialog: (in category 'widgets optional') ----- buildPluggableDialog: aSpec | widget | widget := self dialogClass new. self register: widget id: aSpec name. widget model: aSpec model. "Set child dependent layout properties. The pane morph holds the special contents." widget paneMorph wantsPaneSplitters: (aSpec wantsResizeHandles ifNil: [true]). self setLayoutHintsFor: widget paneMorph spec: aSpec. widget paneMorph layoutInset: (aSpec padding ifNil: [ProportionalSplitterMorph gripThickness]). widget paneMorph cellGap: (aSpec spacing ifNil: [ProportionalSplitterMorph gripThickness]). widget paneMorph wantsPaneSplitters ifTrue: [ widget paneMorph addCornerGrips"addEdgeGrips". widget paneMorph grips do: [:ea | ea showHandle: true]]. "Now create the children." panes := OrderedCollection new. aSpec children isSymbol ifTrue: [ widget getChildrenSelector: aSpec children. widget update: aSpec children] ifFalse: [ self buildAll: aSpec children in: widget paneMorph]. "Now create the buttons." aSpec buttons isSymbol ifTrue: [ widget getButtonsSelector: aSpec buttons. widget update: aSpec buttons] ifFalse: [ self buildAll: aSpec buttons in: widget buttonRowMorph. widget updateButtonProperties]. aSpec title ifNotNil: [:label | label isSymbol ifTrue:[widget getTitleSelector: label; update: label] ifFalse:[widget title: label]]. aSpec message ifNotNil: [:label | label isSymbol ifTrue:[widget getMessageSelector: label; update: label] ifFalse:[widget message: label]]. "Interaction behavior." aSpec autoCancel ifNotNil: [:b | widget autoCancel: b]. aSpec exclusive ifNotNil: [:b | widget exclusive: b]. widget closeDialogSelector: aSpec closeAction. self buildHelpFor: widget spec: aSpec. "Everything is shrink-wrapped around the pane morph." + widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]) + + (widget paneMorph layoutInset * 2) asPoint. - widget paneMorph extent: (aSpec extent ifNil:[widget initialExtent]). ^ widget! Item was added: + ----- Method: PluggableDialogWindow>>createTitle: (in category 'initialization') ----- + createTitle: aString + "Overridden to add an extra expand button. Yet, it depends on the model's interface whether that button will be visible. See #model:." + + | box expandButton| + super createTitle: aString. + + expandButton := SystemWindowButton new + name: #expandButton; + color: Color transparent; + target: self; + actionSelector: #expandDialogPane; + balloonText: 'Expand this dialog' translated; + borderWidth: 0; + yourself. + SystemWindow expandBoxImage scaleIconToDisplay in: [:icon | + expandButton labelGraphic: icon; extent: icon extent]. + + box := self submorphNamed: #title. + box addMorphBack: expandButton.! Item was added: + ----- Method: PluggableDialogWindow>>expandDialogPane (in category 'running') ----- + expandDialogPane + "Expand the dialog pane to its preferred extent. Honor the visible area in the world." + + | visibleArea decorationOffset expandedExtent | + visibleArea := self currentWorld visibleClearArea. + decorationOffset := self extent - self paneMorph extent. + expandedExtent := self model preferredExtent + (self paneMorph layoutInset * 2) asPoint. + + self paneMorph extent: (expandedExtent min: visibleArea extent - decorationOffset). + + self fullBounds. + self moveToPreferredPosition.! Item was changed: ----- Method: PluggableDialogWindow>>model: (in category 'accessing') ----- + model: newModel - model: anObject model ifNotNil: [model removeDependent: self]. + newModel ifNotNil: [ + newModel addDependent: self. + (newModel respondsTo: #preferredExtent) + ifFalse: [((self submorphNamed: #title) submorphNamed: #expandButton) delete]]. + model := newModel.! - anObject ifNotNil: [anObject addDependent: self]. - model := anObject.! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 111558 bytes Desc: not available URL: From bruce.oneel at pckswarms.ch Tue Jan 12 09:42:17 2021 From: bruce.oneel at pckswarms.ch (Bruce O'Neel) Date: Tue, 12 Jan 2021 10:42:17 +0100 Subject: [squeak-dev] Squeak and Sound In-Reply-To: References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> Message-ID: <1610444537-e44cc4a295e27fde6d2848a9b26eddb0@pckswarms.ch> Ok so I ran this on Linux Mint 20.1, VM source as of 2021/01/09.  Works but little pops. I get the same exact sound behavior on my Mac running Catalina, VM from 2020/11/09 that was prebuilt. In both cases this image is Squeak 5.3 as shipped. I'm not a piano player, but, what I vaguly remember as middle C does not seem to be middle C and the lower third of the keyboard seems silent though probably because the frequency is too low. Starting from the left the third octave C is the first C I can hear.  The D next to it I can hear, the E next I randomly hear or not.  Hitting it quickly gives clicks.  Hitting it and waiting is more sucessful but not 100%.   If this an analog system or an organ it would feel that some capacitor was not charging right or the air pressure was low.   > > On 2021-01-11, at 3:03 AM, Bruce O'Neel wrote: > > > > Hi, > > > > I just installed Mint 20.1, which is based on the most recent Ubuntu, on a x86-64 system ran > > > > apt install libpulse-dev > > > > and then built the VM at the git HEAD, and unlike before sound works perfectly. This is with a 5.3 image. > > > > Off to try this on my PI 400... > > I'll be very interested in your report. Sound on the latest PI OS with pulse works just fine for almost all cases BUT do try the pianokeyboardmorph and zip up and down the keyboard. The short notes with negligible time gap between each and the next seems to really mess things up. > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: WDS: Warp Drive, Scotty! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 12 09:44:18 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 12 Jan 2021 10:44:18 +0100 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.270.mcz In-Reply-To: References: Message-ID: Hi Chris. Thanks for the explanations. I will address your concerns. Also see my response to cbc.271 :-) Best, Marcel Am 11.01.2021 18:13:08 schrieb Chris Cunningham : inline... On Mon, Jan 11, 2021 at 2:30 AM Marcel Taeumel wrote: Still, it makes me wonder if you ever you "list filtering" in such dialogs? You seem to want to optimize the users browsing experience, not the searching experience. Actually, this even helps with filtering.  If I have large items (which I often do), and I don't know the exact combination of characters for what I want to choose, it can be frustrating with the default size.  Try:   ListChooser chooseFrom: #(     'A Really Big Option With Useful Stuff after: here, option Alpha'     'A Really Big Option With Useful Stuff after: here, option Beta'     'A Really Big Option With Useful Stuff after: here, option Gamma'     'Not what we want'   ) and filter by, say 'Stuff'.  Which one do you pick? Further, the grippies on this dialog are frustrating. If the dialog is near the bottom right of the screen, just dragging the top left (or bottom left) to make the dialog bigger to be able to see the rest of the text doesn't work. The dialog only expands down and to the right - no matter which grippy you try to expand (or shrink) the dialog with.  So, I have to make it bigger, then move the dialog.  If you need to do this often enough, I at least get frustrated. >From my experience with the codebase in Squeak 3 and 4, any magic buffers such as "20" and "40" should be avoided for the sake of HI-DPI and hard-to-debug UI glitches. Deriving such buffers from the current font metrics seems to be more robust. Note that, in general, I am not opposed to giving content "more space to breathe" :-) The buffer size I am talking about here isn't for more white space around the list, but for the size of the dialog that is outside of the list.  InitialExtent is for the complete dialog size, not just the list box.  So, you will never be able to see 15 lines in the previous version because of the other space taken up by buttons and filter box.  (Which is ok if the lists choices are small in few in number, of course.) That said, you are right about HI-DPI and possible other font choices and/or future changes to ListChooser - I should derive the value and not hard code it. Having to iterate over all items in a list is too costly for larger lists. The LazyListMorph attempt to only consider a sample proved to entail annoying UI glitches such as shaky UI elements while scrolling.   All in all, you are oppsed to always make room for 15 items and (roughly) 20 characters per item. So, I suggest that we could make the 15 derived from the actual number of items ... plus 1-2 if you want to leave more whitespace. For the 20, I would suggest to only count the number of characters and multiply with that width-of-$m. For performance reasons: Yes, agreed (and much better). Except extra space should not be based on the list items/count, but on the other Dialog stuff. [items inject: 0 into: [:max :item | max max: item size]] bench. '30,200 per second. 33.1 microseconds per run. 0.05999 % GC time.' Yes, we could watch out for the size of #currentWorld, as you suggested. But this already happens via RealEstateAgent class >> maximumUsableAreaInWorld: as well as sends of #translatedToBeWithin: to a world's bounds. No need to duplicate and scatter those constraints all over the code base. :-) ... That said ... I think there is a bug in DialogWindow >> #moveToPreferredPosition and also in its initial extent. DialogWindow does not talk to RealEstateAgent at all ... I'll try removing my #currentWorld and see what happens with a really REALLY large list. I did notice that it will not open the dialog with any of it off the screen by default - but didn't try with an extent larger than the world.  So, at least that part is somehow handled.  (But not the growth of the dialog by grippies, unfortunately). Best, Marcel P.S.: How can you know that "item" is something that works with #widthOfString:? :-) Could be an instance of Text, for example. err, yeah.  I always use stuff that knows #widthOfString, but that's just me.  Will go with using size and width of $m. Thank you! Am 08.01.2021 20:27:56 schrieb commits at source.squeak.org [mailto:commits at source.squeak.org] : A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz [http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz] ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.270 Author: cbc Time: 8 January 2021, 11:27:47.8204 am UUID: abbbeb8a-9a8b-ef4a-b6a9-051b55cc2d5b Ancestors: ToolBuilder-Morphic-mt.269 Set the initial extent of the ListChooser to not require resizing the dialog for reasonable sized lists (i.e., expand it so you can see all of the list). At the small end, still object MT's suggested size; at the large end, will not take up more the 3/4ths of the world size. =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont width height | - - | listFont | listFont := Preferences standardListFont. + width := (items collect: [:item| listFont widthOfString: item]) max + 20 "Acutal size of items plus dialog buffer left/right" + max: (20 * (listFont widthOf: $m)). "but we want a not-too-small box as well" + height := ((items size max: 15) * listFont height) + 40. "for various other stuff in dialog above/below list" + "But, don't use the whole world." + width := width min: (self currentWorld extent x * 0.75) asInteger. + height := height min: (self currentWorld extent y * 0.75) asInteger. + ^ width at height! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 12 09:51:01 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 12 Jan 2021 10:51:01 +0100 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.270.mcz In-Reply-To: References: Message-ID: Hi Chris. > InitialExtent is for the complete dialog size, not just the list box. For clarification: #initialExtent is for the dialog's contents only. The model should not have to deal with dialog decorations such as title bar or button bar or other borders. See ListChooser >> #buildWith: for more information. DialogWindow is the attempt to bring all the many scenarios around dialogs from the past 25 years together to make them somewhat manageable: The button wrapping in the last example is still buggy in HiDPI/Demo mode. :-/ Best, Marcel Am 11.01.2021 18:13:08 schrieb Chris Cunningham : inline... On Mon, Jan 11, 2021 at 2:30 AM Marcel Taeumel wrote: Still, it makes me wonder if you ever you "list filtering" in such dialogs? You seem to want to optimize the users browsing experience, not the searching experience. Actually, this even helps with filtering.  If I have large items (which I often do), and I don't know the exact combination of characters for what I want to choose, it can be frustrating with the default size.  Try:   ListChooser chooseFrom: #(     'A Really Big Option With Useful Stuff after: here, option Alpha'     'A Really Big Option With Useful Stuff after: here, option Beta'     'A Really Big Option With Useful Stuff after: here, option Gamma'     'Not what we want'   ) and filter by, say 'Stuff'.  Which one do you pick? Further, the grippies on this dialog are frustrating. If the dialog is near the bottom right of the screen, just dragging the top left (or bottom left) to make the dialog bigger to be able to see the rest of the text doesn't work. The dialog only expands down and to the right - no matter which grippy you try to expand (or shrink) the dialog with.  So, I have to make it bigger, then move the dialog.  If you need to do this often enough, I at least get frustrated. >From my experience with the codebase in Squeak 3 and 4, any magic buffers such as "20" and "40" should be avoided for the sake of HI-DPI and hard-to-debug UI glitches. Deriving such buffers from the current font metrics seems to be more robust. Note that, in general, I am not opposed to giving content "more space to breathe" :-) The buffer size I am talking about here isn't for more white space around the list, but for the size of the dialog that is outside of the list.  InitialExtent is for the complete dialog size, not just the list box.  So, you will never be able to see 15 lines in the previous version because of the other space taken up by buttons and filter box.  (Which is ok if the lists choices are small in few in number, of course.) That said, you are right about HI-DPI and possible other font choices and/or future changes to ListChooser - I should derive the value and not hard code it. Having to iterate over all items in a list is too costly for larger lists. The LazyListMorph attempt to only consider a sample proved to entail annoying UI glitches such as shaky UI elements while scrolling.   All in all, you are oppsed to always make room for 15 items and (roughly) 20 characters per item. So, I suggest that we could make the 15 derived from the actual number of items ... plus 1-2 if you want to leave more whitespace. For the 20, I would suggest to only count the number of characters and multiply with that width-of-$m. For performance reasons: Yes, agreed (and much better). Except extra space should not be based on the list items/count, but on the other Dialog stuff. [items inject: 0 into: [:max :item | max max: item size]] bench. '30,200 per second. 33.1 microseconds per run. 0.05999 % GC time.' Yes, we could watch out for the size of #currentWorld, as you suggested. But this already happens via RealEstateAgent class >> maximumUsableAreaInWorld: as well as sends of #translatedToBeWithin: to a world's bounds. No need to duplicate and scatter those constraints all over the code base. :-) ... That said ... I think there is a bug in DialogWindow >> #moveToPreferredPosition and also in its initial extent. DialogWindow does not talk to RealEstateAgent at all ... I'll try removing my #currentWorld and see what happens with a really REALLY large list. I did notice that it will not open the dialog with any of it off the screen by default - but didn't try with an extent larger than the world.  So, at least that part is somehow handled.  (But not the growth of the dialog by grippies, unfortunately). Best, Marcel P.S.: How can you know that "item" is something that works with #widthOfString:? :-) Could be an instance of Text, for example. err, yeah.  I always use stuff that knows #widthOfString, but that's just me.  Will go with using size and width of $m. Thank you! Am 08.01.2021 20:27:56 schrieb commits at source.squeak.org [mailto:commits at source.squeak.org] : A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz [http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.270.mcz] ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.270 Author: cbc Time: 8 January 2021, 11:27:47.8204 am UUID: abbbeb8a-9a8b-ef4a-b6a9-051b55cc2d5b Ancestors: ToolBuilder-Morphic-mt.269 Set the initial extent of the ListChooser to not require resizing the dialog for reasonable sized lists (i.e., expand it so you can see all of the list). At the small end, still object MT's suggested size; at the large end, will not take up more the 3/4ths of the world size. =============== Diff against ToolBuilder-Morphic-mt.269 =============== Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent + | listFont width height | - - | listFont | listFont := Preferences standardListFont. + width := (items collect: [:item| listFont widthOfString: item]) max + 20 "Acutal size of items plus dialog buffer left/right" + max: (20 * (listFont widthOf: $m)). "but we want a not-too-small box as well" + height := ((items size max: 15) * listFont height) + 40. "for various other stuff in dialog above/below list" + "But, don't use the whole world." + width := width min: (self currentWorld extent x * 0.75) asInteger. + height := height min: (self currentWorld extent y * 0.75) asInteger. + ^ width at height! - ^ (20 * (listFont widthOf: $m))@(15 * listFont height)! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12337 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 37719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 32901 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 74193 bytes Desc: not available URL: From marcel.taeumel at hpi.de Tue Jan 12 09:59:06 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 12 Jan 2021 10:59:06 +0100 Subject: [squeak-dev] The Inbox: ToolBuilder-Morphic-cbc.271.mcz In-Reply-To: References: Message-ID: > It looks like it is 2 pixels short for height. Yes. That's a bug that occurs when resolving the layout frame in the proportional layout. The 2 pixels are the border widths not considered correctly for fixed-height/width frames. I will investigate. :-) If you want to even avoid clicking the expand button in a dialog, what are good average widths for an item? Even for more than 20 characters? Best, Marcel Am 11.01.2021 20:20:32 schrieb Chris Cunningham : It looks like it is 2 pixels short for height.  If the size list size is between 5 and 15, it will include the vertical scroll bar to scroll for those 2 pixels (or, I am guessing, however big the list box boundary line is). It looks like the width is short by the padding size before and after the text - maybe adding an $m width to the horizontal size would make it better (or figure out what the right padding + list box boundary line width is and add it in). On Mon, Jan 11, 2021 at 10:17 AM Chris Cunningham wrote: [image.png] and [image.png] close enough. On Mon, Jan 11, 2021 at 10:16 AM wrote: A new version of ToolBuilder-Morphic was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.271.mcz [http://source.squeak.org/inbox/ToolBuilder-Morphic-cbc.271.mcz] ==================== Summary ==================== Name: ToolBuilder-Morphic-cbc.271 Author: cbc Time: 11 January 2021, 10:15:51.0644 am UUID: 76f9fb95-5700-1b43-a9af-9ab88aaa890f Ancestors: ToolBuilder-Morphic-mt.270 Let the width of List Chooser try to accomodate better to the actual size of the string. =============== Diff against ToolBuilder-Morphic-mt.270 =============== Item was changed:   ----- Method: ListChooser>>initialExtent (in category 'building') -----   initialExtent +       | listFont itemCount width | - -       | listFont itemCount maxItemSize cellSize |         listFont := Preferences standardListFont.         itemCount := items size. +       width := ((items take: 15) collect: [:item| listFont widthOfString: item]) max. +       ^ (width min: (self currentWorld extent x * 0.75) asInteger max:  ((listFont widthOf: $m) * 12)) +               @ ((itemCount min: 15 max: 5) * listFont height + self searchBarHeight) + ! -       maxItemSize := items inject: 0 into: [:max :item | max max: item size]. -       cellSize := (listFont widthOf: $m) @ listFont height. -        -       ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) -               @ (itemCount + 1 "breathing space" min: 15 max: 5) -               * cellSize) + (0@ self searchBarHeight)! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18053 bytes Desc: not available URL: From vaidasd at gmail.com Tue Jan 12 11:08:35 2021 From: vaidasd at gmail.com (=?UTF-8?Q?Vaidotas_Did=C5=BEbalis?=) Date: Tue, 12 Jan 2021 13:08:35 +0200 Subject: [squeak-dev] Tiles error Message-ID: 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 From marcel.taeumel at hpi.de Tue Jan 12 11:42:36 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 12 Jan 2021 12:42:36 +0100 Subject: [squeak-dev] Tiles error In-Reply-To: References: Message-ID: Hi, there. In 5.2 and later, we ported Etoys changes back to Squeak, which includes TileMorph >> #morphToDropInPasteUp:. That wraps the tile into a ScriptingTileHolder, which disappears on a click later on. See ScriptingTileHolder >> #mouseDown:. What would be the expected behavior? Best, Marcel Am 12.01.2021 12:09:21 schrieb Vaidotas Didžbalis : 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Jan 12 13:04:13 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 12 Jan 2021 13:04:13 0000 Subject: [squeak-dev] The Trunk: Morphic-mt.1715.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1715.mcz ==================== Summary ==================== Name: Morphic-mt.1715 Author: mt Time: 12 January 2021, 2:04:07.252356 pm UUID: 2641645d-9048-f44f-b6ea-2cd85e2c7ff0 Ancestors: Morphic-mt.1714 Fixes the issue where a dialog with flexible contents was not fully visible in small worlds. Thanks to Chris (cbc) for pointing this out! (Note that I think that we need a better way for this combination of #fullBounds, #extent:, and #translatedToBeWithin: to make sure that a morph is visible in the world. May be also useful for other windows. Not sure about this variation with #center: though.) =============== Diff against Morphic-mt.1714 =============== Item was changed: ----- Method: DialogWindow>>moveToHand (in category 'position') ----- moveToHand + self moveToHand: self currentHand.! - self moveToHand: self activeHand.! Item was changed: ----- Method: DialogWindow>>moveToPreferredPosition (in category 'initialization') ----- moveToPreferredPosition + "Moves the dialog window to its preferred position, which can be a point on the screen or a named widget in the dialog's central pane. Ensure that the dialog is fully visible in the world. Also see #positionOverWidgetNamed:." + + | visibleArea decorationOffset | + self fullBounds. "Compute new layout to have updated bounds." + visibleArea := self currentWorld visibleClearArea. + decorationOffset := self extent - self paneMorph extent. + self paneMorph extent: + (self paneMorph extent min: visibleArea extent - decorationOffset). + self fullBounds. "Compute new layout to have updated bounds." self center: (preferredPosition isPoint ifTrue: [ preferredPosition ] ifFalse: [ self center + self currentHand position - preferredPosition center ]). + self bounds: + (self bounds translatedToBeWithin: visibleArea).! - self bounds: (self bounds translatedToBeWithin: self currentWorld visibleClearArea)! From commits at source.squeak.org Tue Jan 12 13:09:58 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 12 Jan 2021 13:09:58 0000 Subject: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.271.mcz Message-ID: Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk: http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.271.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-mt.271 Author: mt Time: 12 January 2021, 2:09:57.073356 pm UUID: b77f7e90-6347-f242-8b9b-921013f06122 Ancestors: ToolBuilder-Morphic-mt.270 Removes the "breathing space" in a list-chooser's preferred extent. Thanks to Chris (cbc) for clarifying the issue with the cellInset in LazyListMorph. Note that I do have a better solution for min/max/preferredExtent in combination with ProportionalLayout and LayoutFrame. Maybe now is the time to invest more time into that. Also note that I will now investigate that 2-pixel-bug that causes the vertical scroll bar to remain after hitting the expand button in a dialog. It is related to the list's and input-field's borderWidth. =============== Diff against ToolBuilder-Morphic-mt.270 =============== Item was changed: ----- Method: ListChooser>>initialExtent (in category 'building') ----- initialExtent | listFont itemCount maxItemSize cellSize | listFont := Preferences standardListFont. itemCount := items size. maxItemSize := items inject: 0 into: [:max :item | max max: item size]. cellSize := (listFont widthOf: $m) @ listFont height. + ^ ((maxItemSize min: 20 max: 10) + @ (itemCount min: 15 max: 5) - ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) - @ (itemCount + 1 "breathing space" min: 15 max: 5) * cellSize) + (0@ self searchBarHeight)! Item was changed: ----- Method: ListChooser>>preferredExtent (in category 'building') ----- preferredExtent | listFont cellSize | listFont := Preferences standardListFont. cellSize := (listFont widthOf: $m) @ listFont height. ^ ((items inject: 0 into: [:max :item | max max: (listFont widthOfString: item)]) @ (items size * listFont height)) - + ((1 at 1) * cellSize) "breathing space" + (0@ self searchBarHeight)! Item was changed: ----- Method: ListMultipleChooser>>initialExtent (in category 'toolbuilder') ----- initialExtent | listFont itemCount maxItemSize cellSize | listFont := Preferences standardListFont. itemCount := labels size. maxItemSize := labels inject: 0 into: [:max :item | max max: item size]. cellSize := (listFont widthOf: $m) @ listFont height. + ^ ((maxItemSize min: 20 max: 10) + @ (itemCount min: 15 max: 5) - ^ ((maxItemSize + 1 "breathing space" min: 20 max: 10) - @ (itemCount + 1 "breathing space" min: 15 max: 5) * cellSize)! Item was changed: ----- Method: ListMultipleChooser>>preferredExtent (in category 'toolbuilder') ----- preferredExtent | listFont cellSize | listFont := Preferences standardListFont. cellSize := (listFont widthOf: $m) @ listFont height. ^ ((labels inject: 0 into: [:max :item | max max: (listFont widthOfString: item)]) + @ (labels size * listFont height))! - @ (labels size * listFont height)) - + ((1 at 1) * cellSize) "breathing space"! Item was changed: ----- Method: PluggableDialogWindow>>expandDialogPane (in category 'running') ----- expandDialogPane + "Expand the dialog pane to its preferred extent, including the pane's extra layout inset used for grips. Then try again to move to the dialog's preferred position." - "Expand the dialog pane to its preferred extent. Honor the visible area in the world." + | extra | + self flag: #preferredExtentWorkaround. "mt: Working with a widget's min, max, and preferred extent is still very awkward using proportional layouts and layout frames. For now, approximate extra spacing to accommodate ListChooser and ListMultipleChooser only." + extra := LazyListMorph new cellInset. extra := extra topLeft + extra bottomRight. - | visibleArea decorationOffset expandedExtent | - visibleArea := self currentWorld visibleClearArea. - decorationOffset := self extent - self paneMorph extent. - expandedExtent := self model preferredExtent + (self paneMorph layoutInset * 2) asPoint. - - self paneMorph extent: (expandedExtent min: visibleArea extent - decorationOffset). + self paneMorph extent: + (self model preferredExtent + + (self paneMorph layoutInset * 2) asPoint + + extra). - self fullBounds. self moveToPreferredPosition.! From vaidasd at gmail.com Tue Jan 12 13:25:25 2021 From: vaidasd at gmail.com (=?UTF-8?Q?Vaidotas_Did=C5=BEbalis?=) Date: Tue, 12 Jan 2021 15:25:25 +0200 Subject: [squeak-dev] Tiles error In-Reply-To: References: Message-ID: Hello, IMHO let's remove TileMorph>>#morphToDropInPasteUp: . thank you On Tue, Jan 12, 2021 at 1:42 PM Marcel Taeumel wrote: > > Hi, there. > > In 5.2 and later, we ported Etoys changes back to Squeak, which includes TileMorph >> #morphToDropInPasteUp:. That wraps the tile into a ScriptingTileHolder, which disappears on a click later on. See ScriptingTileHolder >> #mouseDown:. > > What would be the expected behavior? > > Best, > Marcel > > Am 12.01.2021 12:09:21 schrieb Vaidotas Didžbalis : > > 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 > > From commits at source.squeak.org Tue Jan 12 13:52:53 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 12 Jan 2021 13:52:53 0000 Subject: [squeak-dev] The Trunk: Morphic-mt.1716.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1716.mcz ==================== Summary ==================== Name: Morphic-mt.1716 Author: mt Time: 12 January 2021, 2:52:47.977356 pm UUID: 93f95f53-4457-5e4c-a157-5cbf89aa7328 Ancestors: Morphic-mt.1715 Fixes a bug in resize grips (having #rigid targets) that are placed within layouted (usually #shrinkWrap) owners. This makes all grips in resizable dialogs finally work as expected. I still consider this a #workaround to be improved. =============== Diff against Morphic-mt.1715 =============== Item was changed: ----- Method: BorderedMorph>>doFastWindowReframe: (in category 'resize handling') ----- doFastWindowReframe: ptName + | newBounds delta | - | newBounds | "For fast display, only higlight the rectangle during loop" newBounds := self bounds newRectButtonPressedDo: [:f | f withSideOrCorner: ptName setToPoint: (self pointFromWorld: Sensor cursorPoint) minExtent: self minimumExtent]. + delta := newBounds origin - self bounds origin. self bounds: newBounds. + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner topLeft: owner topLeft + delta]]. ^newBounds.! Item was changed: ----- Method: BottomLeftGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner + (0 @ delta y)). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner left: owner left + delta x]].! - bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner + (0 @ delta y))! Item was changed: ----- Method: LeftGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner left: owner left + delta x]].! - bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner)! Item was changed: ----- Method: TopGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + (0 @ delta y) corner: oldBounds corner). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner top: owner top + delta y]].! - bounds: (oldBounds origin + (0 @ delta y) corner: oldBounds corner)! Item was changed: ----- Method: TopLeftGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + delta corner: oldBounds corner). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner topLeft: owner topLeft + delta]].! - bounds: (oldBounds origin + delta corner: oldBounds corner)! Item was changed: ----- Method: TopRightGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + (0 at delta y) corner: oldBounds corner + (delta x @ 0)). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner top: owner top + delta y]].! - bounds: (oldBounds origin + (0 at delta y) corner: oldBounds corner + (delta x @ 0))! From tim at rowledge.org Tue Jan 12 19:08:19 2021 From: tim at rowledge.org (tim Rowledge) Date: Tue, 12 Jan 2021 11:08:19 -0800 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <1610444537-e44cc4a295e27fde6d2848a9b26eddb0@pckswarms.ch> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610444537-e44cc4a295e27fde6d2848a9b26eddb0@pckswarms.ch> Message-ID: > On 2021-01-12, at 1:42 AM, Bruce O'Neel wrote: > > Ok so I ran this on Linux Mint 20.1, VM source as of 2021/01/09. Works but little pops. This - https://mega.nz/file/7dd3BSJI#WC7LG4oi1WUjnZUGvQB1py3kXk8J-OBm9ASXY7iNnkA - is a wav file created by zooming up and down the scratch keyboard morph (which is essentially the same as the vanilla one) and the samples *created by Squeak* saved before being passed to pulse audio. This one - https://mega.nz/file/LVFxmCAA#Fy8oigSzm3MjJn4BRpxANaSwjid1l757HP7bKSEx7U0 - is the 'same' (but different because I can't replicate the exact same zooming around) from an ALSA setup pi. Notice how similar they sound; no nasty crackling etc. Yet the actual sound I hear on the pulse-pi when the squeak samples are sent to pulse audio is pretty nasty. Clearly something is wrong; it got a bit less wrong with a recent update to the PI OS pulse libraries but nowhere near perfect. > > I get the same exact sound behavior on my Mac running Catalina, VM from 2020/11/09 that was prebuilt. On my Mojave OS iMac the sounds are just fine. > > In both cases this image is Squeak 5.3 as shipped. > > I'm not a piano player, but, what I vaguly remember as middle C does not seem to be middle C and the lower third of the keyboard seems silent though probably because the frequency is too low. The claimed middle C is set to 440Hz, which I'm fairly sure is correct. It sound about right to me when played but I am not a musician. > > Starting from the left the third octave C is the first C I can hear. The D next to it I can hear, the E next I randomly hear or not. Hitting it quickly gives clicks. Hitting it and waiting is more sucessful but not 100%. Seriously weird. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim I'm so skeptical that I'm not sure I'm really a skeptic From vaidasd at gmail.com Tue Jan 12 20:26:51 2021 From: vaidasd at gmail.com (=?UTF-8?Q?Vaidotas_Did=C5=BEbalis?=) Date: Tue, 12 Jan 2021 22:26:51 +0200 Subject: [squeak-dev] Tiles error In-Reply-To: References: Message-ID: On Tuesday, January 12, 2021, Marcel Taeumel wrote: > Hi, there. > > In 5.2 and later, we ported Etoys changes back to Squeak, which includes > TileMorph >> #morphToDropInPasteUp:. That wraps the tile into a > ScriptingTileHolder, which disappears on a click later on. See > ScriptingTileHolder >> #mouseDown:. > > What would be the expected behavior > Hand shall grab the clicked tile -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Jan 12 23:42:24 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 12 Jan 2021 23:42:24 0000 Subject: [squeak-dev] The Trunk: SystemReporter-eem.47.mcz Message-ID: Eliot Miranda uploaded a new version of SystemReporter to project The Trunk: http://source.squeak.org/trunk/SystemReporter-eem.47.mcz ==================== Summary ==================== Name: SystemReporter-eem.47 Author: eem Time: 12 January 2021, 3:42:22.819678 pm UUID: 440e979a-59dd-4593-8ada-75bc330a6583 Ancestors: SystemReporter-eem.46 Add event tracing mask, VM ticker stats, mixed arithmetic flag, and separate marking time. =============== Diff against SystemReporter-eem.46 =============== Item was changed: ----- Method: SystemReporter>>reportVMParameters: (in category 'reporting') ----- reportVMParameters: aStream | vmParameters isStack isCog isSpur | self header: 'Virtual Machine Parameters' on: aStream. vmParameters := Smalltalk vm getVMParameters. isStack := (vmParameters at: 42 ifAbsent: [0]) ~= 0. "42 = number of stack pages available" isCog := isStack and: [(vmParameters at: 46) ~= 0]. "46 is machine code zone size" isSpur := isStack and: [(vmParameters at: 41) anyMask: 2r10000]. "41 is imageFormatVersion for the VM; bit 16 is the Spur bit" (isSpur ifFalse: [#( 1 'size of old space' 2 'size of young+old space' 3 'size of memory' 4 'allocationCount' 5 'allocations between GCs' 6 'survivor count tenuring threshold')] ifTrue: [#( 1 'size of old space' 2 'used bytes in new space (used eden + used past space)' 3 'size of heap')]), #( 7 'full GCs since startup' 8 'total milliseconds in full GCs since startup'), (isSpur ifFalse: [#( 9 'incremental GCs since startup' 10 'total milliseconds in incremental GCs since startup' 11 'tenures of surving objects since startup'), {12 to: 19. 'specific to the translating VM'}] ifTrue: [#( 9 'scavenging GCs since startup' 10 'total milliseconds in scavenging GCs since startup' + 11 'tenures of surving objects since startup' + 12 'event trace mask (for debugging input events)' + 13 'VM ticker start microseconds (Croquet/QwaqVM)' + 14 'VM ticker count (Croquet/QwaqVM)' + 15 'VM ticker call count (Croquet/QwaqVM)' + 16 'total microseconds in idle since startup' - 11 'tenures of surving objects since startup'), - {12 to: 15. 'reserved for future use'}, - #( 16 'total microseconds in idle since startup' 17 'proportion of code zone available for use (Sista VMs only; read-write)' 18 'total milliseconds in full GC compaction since startup (a portion of parameter 8)' 19 'scavenge threshold; the effective size of eden')]), #( 20 'utc microseconds at startup (if non-zero)' 21 'root/remembered table size (occupancy)' 22 'root/remembered table overflows since startup' 23 'bytes of extra memory to reserve for VM buffers, plugins, etc.' 24 'free memory threshold above which object memory will be shrunk' 25 'memory headroom when growing object memory'), (isStack ifFalse: [#( 26 'interruptChecksEveryNms - force an ioProcessEvents every N milliseconds, in case the image is not calling getNextEvent often')] ifTrue: [#( 26 'heartbeat period (ms; see #58)')]), (isSpur ifFalse: [#( 27 'number of times mark loop iterated for current IGC/FGC includes ALL marking' 28 'number of times sweep loop iterated for current IGC/FGC' 29 'number of times make forward loop iterated for current IGC/FGC' 30 'number of times compact move loop iterated for current IGC/FGC')] ifTrue: [#()]), #( 31 'number of grow memory requests' 32 'number of shrink memory requests'), (isSpur ifFalse: [#( 33 'number of root table entries used for current IGC/FGC' 34 'number of allocations done before current IGC/FGC' 35 'number of survivor objects after current IGC/FGC' 36 'millisecond clock when current IGC/FGC completed' 37 'number of marked objects for Roots of the world, not including Root Table entries for current IGC/FGC' 38 'milliseconds taken by current IGC' 39 'Number of finalization signals for Weak Objects pending when current IGC/FGC completed')] ifTrue: [#( 33 'number of root table entries at last scavenge' 35 'number of survivor objects at last scavenge (if non-zero)' 36 'millisecond clock when current scavenge completed' 38 'milliseconds taken by current scavenge' 39 'Number of finalization signals for Weak Objects pending when current SGC/FGC completed')]), #( 40 'VM word size - 4 or 8'), (isStack ifTrue: [#( 41 'imageFormatVersion for the VM' 42 'number of stack pages available' 43 'desired number of stack pages (stored in image file header, max 65535)' 44 'size of eden, in bytes' 45 'desired size of eden, in bytes (stored in image file header)' 46 'machine code zone size, in bytes (0 in Stack VM)' 47 'desired machine code zone size (0 => default 1Mb to 2Mb depending on processor)'), { 48. 'Persistent image header flags\ bit 0: implies Process has threadId as its 4th inst var\ bit 1: if set, methods that are interpreted will have the flag bit set in their header\ bit 2: if set, implies preempting a process does not put it to the back of its run queue\ bit 3: if set, implies the GUI should run on the first thread and event queues should not be accessed from other threads\ bit 4: if set, implies the new finalization scheme where WeakArrays are queued\ bit 5: if set, implies wheel events will be delivered as such and not mapped to arrow key events\ bit 6: if set, implies arithmetic primitives will fail if given arguments of different types (float vs int)\ bit 7: if set, causes times delivered from file primitives to be in UTC rather than local time.' withCRs }, #( 49 'max size the image promises to grow the external semaphore table to'), (isSpur ifFalse: [{ 50 to: 51. 'reserved for VM parameters that persist in the image (such as size of eden above)'. 52 to: 56. 'specific to Spur' }] ifTrue: [{ 50 to: 51. 'reserved for VM parameters that persist in the image (such as size of eden above)' }, #( 52 'root/remembered table capacity' 53 'number of old space segments' 54 'total free old space' 55 'ratio of growth and image size at or above which a GC will be performed post scavenge')]), #( 56 'number of process switches since startup' 57 'number of ioProcessEvents calls since startup' 58 'number of forceInterruptCheck calls since startup' 59 'number of check event calls since startup' 60 'number of stack page overflows since startup' 61 'number of stack page divorces since startup' 62 'compiled code compactions since startup'), (isCog ifFalse: [#()] ifTrue: [#( 63 'total milliseconds in compiled code compactions since startup' 64 'the number of methods that currently have jitted machine-code')]), { 65. 'Cog feature flags\ bit 0: set if the VM supports MULTIPLE_BYTECODE_SETS.\ bit 1: set if the VM supports read-only objects (IMMUTABILITY).\ bit 2: set if the VM has an ITIMER_HEARTBEAT\ bit 3: set if the VM supports cross-platform BIT_IDENTICAL_FLOATING_POINT arithmetic' withCRs. 66. 'the byte size of a stack page'.}, (isSpur ifFalse: [{ 67 to: 69. 'reserved for more Cog-related info' }] ifTrue: [#( 67 'the maximum allowed size of old space (if zero there is no limit)' 68 'the average number of live stack pages when scanned by scavenge/gc/become' 69 'the maximum number of live stack pages when scanned by scavenge/gc/become')]), #( 70 'the vmProxyMajorVersion (the interpreterProxy VM_MAJOR_VERSION)' + 71 'the vmProxyMinorVersion (the interpreterProxy VM_MINOR_VERSION)'), + (isSpur + ifFalse: [#()] + ifTrue: + [#( 72 'milliseconds spent marking since startup' + 73 'reserved for more Spur-related info' + 74 'reserved for more Spur-related info' + 75 'do mixed arithmetic; if false binary arithmetic primitives will fail unless receiver and argument are of the same type')])] - 71 'the vmProxyMinorVersion (the interpreterProxy VM_MINOR_VERSION)')] ifFalse: [#()]) pairsDo: [:idx :desc | | value values | aStream nextPut: $#. idx isInteger ifTrue: [value := vmParameters at: idx. aStream print: idx; tab: (idx < 10 ifTrue: [2] ifFalse: [1]); nextPutAll: ((value isInteger and: [idx ~= 41]) ifTrue: [(desc includesSubstring: 'bit 0:') ifTrue: [value printStringBase: 2 nDigits: value highBit] ifFalse: [value asStringWithCommas]] ifFalse: [value printString])] ifFalse: [value := vmParameters at: idx first. aStream print: idx first; next: 2 put: $.; print: idx last; tab. values := idx collect: [:i| vmParameters at: i]. values asSet size = 1 ifTrue: [aStream print: value] ifFalse: [values do: [:v| aStream print: v] separatedBy: [aStream nextPutAll: ', ']]]. aStream tab; nextPutAll: desc; cr]! From tim at rowledge.org Wed Jan 13 05:43:45 2021 From: tim at rowledge.org (tim Rowledge) Date: Tue, 12 Jan 2021 21:43:45 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down Message-ID: One of the things I had to make for NuScratch was a keyboardlistener that keeps a bitmap of the keys currently pressed - quite a few Scratch things are state dependent rather than even responsive. It originally worked pretty well as far as anybody could ever see; I had no reports of problems for years. Whilst trying to make a 5.3 version it seems that something is making it much less reliable. It is clear from some tracking code that if one holds down a key, presses and releases another key and then finally releases the initial key, that we are losing the final expected key-up of the held-down key. Which in turn leaves my keyboard listener thinking the key is still pressed. This is a Bad Thing. It causes me to lose games of Asteroid Blaster. I don't like to lose at Asteroid Blaster. Looking at the unix VM keystroke handling code causes migraines. Has anybody got any idea what on earth is going on down there? I'll build a VM with the relevant debug code turned on soon but really... if anyone that knows this part could save some pain it would be very pleasant. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hmm. That’s the second time today I’ve seen a Word doc eat a man’s soul. Time for a bug report... From commits at source.squeak.org Wed Jan 13 13:32:57 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 13 Jan 2021 13:32:57 0000 Subject: [squeak-dev] The Trunk: HelpSystem-Core-mt.134.mcz Message-ID: Marcel Taeumel uploaded a new version of HelpSystem-Core to project The Trunk: http://source.squeak.org/trunk/HelpSystem-Core-mt.134.mcz ==================== Summary ==================== Name: HelpSystem-Core-mt.134 Author: mt Time: 13 January 2021, 2:32:57.075665 pm UUID: 3680a1e7-e6e0-4144-a673-66b470bd5235 Ancestors: HelpSystem-Core-mt.133 In a help browser's search results, fixes the issue with title-only matches not showing up. Also show the path to the matched topic. =============== Diff against HelpSystem-Core-mt.133 =============== Item was changed: ----- Method: SearchTopic>>find:in:results: (in category 'searching') ----- find: term in: path results: results + | resultTemplate topic contents index | - | resultTemplate c topic | topic := path last. + resultTemplate := Array new: 6. + resultTemplate at: 1 put: path. + + contents := topic title asString. + (index := contents findString: term startingAt: 1 caseSensitive: false) > 0 ifTrue: [ + resultTemplate at: 2 put: (index to: index + term size) ]. + + contents := topic contents asString withSqueakLineEndings. + (index := contents findString: term startingAt: 1 caseSensitive: false) > 0 ifTrue: [ + | leadingContext trailingContext i | + leadingContext := 0. + trailingContext := 0. + i := index. + [i notNil] whileTrue: [ + (leadingContext = 2 or: [i = 1]) + ifTrue: [ + leadingContext := i = 1 ifTrue: [i] ifFalse: [i+1]. + i := nil] + ifFalse: [ + ((contents at: i) = Character cr) ifTrue: [ + leadingContext := leadingContext + 1]. + i := i - 1] ]. + i := index + term size. + [i notNil] whileTrue: [ + (trailingContext = 2 or: [i >= contents size]) + ifTrue: [ + trailingContext := i = contents size ifTrue: [i] ifFalse: [i-1]. + i := nil] + ifFalse: [ + ((contents at: i) = Character cr) ifTrue: [ + trailingContext := trailingContext + 1]. + i := i + 1] ]. - resultTemplate := Array new: 6. - (topic title asString findString: term startingAt: 1 caseSensitive: false) in: [:index | - index > 0 ifTrue: [resultTemplate at: 2 put: (index to: index + term size)]]. + resultTemplate + at: 3 put: (index - leadingContext + 1 to: index - leadingContext + term size); + at: 4 put: (contents copyFrom: leadingContext to: trailingContext); + at: 5 put: leadingContext; + at: 6 put: (index to: index + term size - 1) ]. - ((c := topic contents asString withSqueakLineEndings) findString: term startingAt: 1 caseSensitive: false) in: [:index | - index > 0 ifTrue: [ - | leadingContext trailingContext i | - leadingContext := 0. - trailingContext := 0. - i := index. - [i notNil] whileTrue: [ - (leadingContext = 2 or: [i = 1]) - ifTrue: [ - leadingContext := i = 1 ifTrue: [i] ifFalse: [i+1]. - i := nil] - ifFalse: [ - ((c at: i) = Character cr) ifTrue: [ - leadingContext := leadingContext + 1]. - i := i - 1] ]. - i := index + term size. - [i notNil] whileTrue: [ - (trailingContext = 2 or: [i >= c size]) - ifTrue: [ - trailingContext := i = c size ifTrue: [i] ifFalse: [i-1]. - i := nil] - ifFalse: [ - ((c at: i) = Character cr) ifTrue: [ - trailingContext := trailingContext + 1]. - i := i + 1] ]. - - resultTemplate - at: 1 put: path; - at: 3 put: (index - leadingContext + 1 to: index - leadingContext + term size); - at: 4 put: (c copyFrom: leadingContext to: trailingContext); - at: 5 put: leadingContext; - at: 6 put: (index to: index + term size - 1). - - self mutex critical: [ results add: resultTemplate ]. - self triggerUpdateContents. - - ] ]. + (resultTemplate second notNil "match in title" or: [resultTemplate third notNil "match in contents"]) ifTrue: [ + self mutex critical: [ results add: resultTemplate ]. + self triggerUpdateContents]. + topic isSearchable ifTrue: [ topic subtopics do: [:t | self find: term in: path, {t} results: results]].! Item was changed: ----- Method: SearchTopic>>printResultEntry: (in category 'private') ----- printResultEntry: entry | resultEntry topic | resultEntry := '' asText. topic := entry first last. entry second notNil ifFalse: [resultEntry append: ( (topic title) asText addAttribute: TextEmphasis bold)] ifTrue: [resultEntry append: ( (topic title) asText addAttribute: TextEmphasis bold; addAttribute: (TextColor color: Color green muchDarker) from: entry second first to: entry second last)]. resultEntry append: (' (open topic)' asText addAttribute: (PluggableTextAttribute evalBlock: [ self changed: #searchResultSelected with: entry first. self changed: #searchResultContentsSelected with: entry sixth])). resultEntry append: String cr. + resultEntry append: ( + ('> ', ((entry first allButLast collect: [:t | t title]) joinSeparatedBy: ' > ')) asText + addAttribute: (TextColor color: (Color gray: 0.7))). + + resultEntry append: String cr. + + entry fourth ifNil: [resultEntry append: '\\' withCRs] ifNotNil: [:contents | - entry fourth in: [:contents | | text | text := contents asText. text addAttribute: (TextColor color: Color green muchDarker) from: entry third first to: entry third last; addAttribute: TextEmphasis bold from: entry third first to: entry third last. resultEntry append: text withBlanksTrimmed; append: '\\' withCRs. ]. ^ resultEntry! From marcel.taeumel at hpi.de Wed Jan 13 13:35:12 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Wed, 13 Jan 2021 14:35:12 +0100 Subject: [squeak-dev] The Trunk: HelpSystem-Core-mt.134.mcz In-Reply-To: References: Message-ID: Here is an example: Best, Marcel Am 13.01.2021 14:33:04 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of HelpSystem-Core to project The Trunk: http://source.squeak.org/trunk/HelpSystem-Core-mt.134.mcz ==================== Summary ==================== Name: HelpSystem-Core-mt.134 Author: mt Time: 13 January 2021, 2:32:57.075665 pm UUID: 3680a1e7-e6e0-4144-a673-66b470bd5235 Ancestors: HelpSystem-Core-mt.133 In a help browser's search results, fixes the issue with title-only matches not showing up. Also show the path to the matched topic. =============== Diff against HelpSystem-Core-mt.133 =============== Item was changed: ----- Method: SearchTopic>>find:in:results: (in category 'searching') ----- find: term in: path results: results + | resultTemplate topic contents index | - | resultTemplate c topic | topic := path last. + resultTemplate := Array new: 6. + resultTemplate at: 1 put: path. + + contents := topic title asString. + (index := contents findString: term startingAt: 1 caseSensitive: false) > 0 ifTrue: [ + resultTemplate at: 2 put: (index to: index + term size) ]. + + contents := topic contents asString withSqueakLineEndings. + (index := contents findString: term startingAt: 1 caseSensitive: false) > 0 ifTrue: [ + | leadingContext trailingContext i | + leadingContext := 0. + trailingContext := 0. + i := index. + [i notNil] whileTrue: [ + (leadingContext = 2 or: [i = 1]) + ifTrue: [ + leadingContext := i = 1 ifTrue: [i] ifFalse: [i+1]. + i := nil] + ifFalse: [ + ((contents at: i) = Character cr) ifTrue: [ + leadingContext := leadingContext + 1]. + i := i - 1] ]. + i := index + term size. + [i notNil] whileTrue: [ + (trailingContext = 2 or: [i >= contents size]) + ifTrue: [ + trailingContext := i = contents size ifTrue: [i] ifFalse: [i-1]. + i := nil] + ifFalse: [ + ((contents at: i) = Character cr) ifTrue: [ + trailingContext := trailingContext + 1]. + i := i + 1] ]. - resultTemplate := Array new: 6. - (topic title asString findString: term startingAt: 1 caseSensitive: false) in: [:index | - index > 0 ifTrue: [resultTemplate at: 2 put: (index to: index + term size)]]. + resultTemplate + at: 3 put: (index - leadingContext + 1 to: index - leadingContext + term size); + at: 4 put: (contents copyFrom: leadingContext to: trailingContext); + at: 5 put: leadingContext; + at: 6 put: (index to: index + term size - 1) ]. - ((c := topic contents asString withSqueakLineEndings) findString: term startingAt: 1 caseSensitive: false) in: [:index | - index > 0 ifTrue: [ - | leadingContext trailingContext i | - leadingContext := 0. - trailingContext := 0. - i := index. - [i notNil] whileTrue: [ - (leadingContext = 2 or: [i = 1]) - ifTrue: [ - leadingContext := i = 1 ifTrue: [i] ifFalse: [i+1]. - i := nil] - ifFalse: [ - ((c at: i) = Character cr) ifTrue: [ - leadingContext := leadingContext + 1]. - i := i - 1] ]. - i := index + term size. - [i notNil] whileTrue: [ - (trailingContext = 2 or: [i >= c size]) - ifTrue: [ - trailingContext := i = c size ifTrue: [i] ifFalse: [i-1]. - i := nil] - ifFalse: [ - ((c at: i) = Character cr) ifTrue: [ - trailingContext := trailingContext + 1]. - i := i + 1] ]. - - resultTemplate - at: 1 put: path; - at: 3 put: (index - leadingContext + 1 to: index - leadingContext + term size); - at: 4 put: (c copyFrom: leadingContext to: trailingContext); - at: 5 put: leadingContext; - at: 6 put: (index to: index + term size - 1). - - self mutex critical: [ results add: resultTemplate ]. - self triggerUpdateContents. - - ] ]. + (resultTemplate second notNil "match in title" or: [resultTemplate third notNil "match in contents"]) ifTrue: [ + self mutex critical: [ results add: resultTemplate ]. + self triggerUpdateContents]. + topic isSearchable ifTrue: [ topic subtopics do: [:t | self find: term in: path, {t} results: results]].! Item was changed: ----- Method: SearchTopic>>printResultEntry: (in category 'private') ----- printResultEntry: entry | resultEntry topic | resultEntry := '' asText. topic := entry first last. entry second notNil ifFalse: [resultEntry append: ( (topic title) asText addAttribute: TextEmphasis bold)] ifTrue: [resultEntry append: ( (topic title) asText addAttribute: TextEmphasis bold; addAttribute: (TextColor color: Color green muchDarker) from: entry second first to: entry second last)]. resultEntry append: (' (open topic)' asText addAttribute: (PluggableTextAttribute evalBlock: [ self changed: #searchResultSelected with: entry first. self changed: #searchResultContentsSelected with: entry sixth])). resultEntry append: String cr. + resultEntry append: ( + ('> ', ((entry first allButLast collect: [:t | t title]) joinSeparatedBy: ' > ')) asText + addAttribute: (TextColor color: (Color gray: 0.7))). + + resultEntry append: String cr. + + entry fourth ifNil: [resultEntry append: '\\' withCRs] ifNotNil: [:contents | - entry fourth in: [:contents | | text | text := contents asText. text addAttribute: (TextColor color: Color green muchDarker) from: entry third first to: entry third last; addAttribute: TextEmphasis bold from: entry third first to: entry third last. resultEntry append: text withBlanksTrimmed; append: '\\' withCRs. ]. ^ resultEntry! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 114458 bytes Desc: not available URL: From commits at source.squeak.org Wed Jan 13 15:38:18 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 13 Jan 2021 15:38:18 0000 Subject: [squeak-dev] The Trunk: EToys-mt.416.mcz Message-ID: Marcel Taeumel uploaded a new version of EToys to project The Trunk: http://source.squeak.org/trunk/EToys-mt.416.mcz ==================== Summary ==================== Name: EToys-mt.416 Author: mt Time: 13 January 2021, 4:38:11.621847 pm UUID: 27def810-ffb2-7b47-8af1-c264f29c9bd3 Ancestors: EToys-pre.415 Fixes minor layout issue. =============== Diff against EToys-pre.415 =============== Item was added: + ----- Method: NumericReadoutTile>>minWidth (in category 'misc') ----- + minWidth + ^ 40! Item was removed: - ----- Method: NumericReadoutTile>>minimumWidth (in category 'misc') ----- - minimumWidth - ^ 40! Item was added: + ----- Method: TileMorph>>minWidth (in category 'misc') ----- + minWidth + | aWidth | + aWidth := self basicWidth. + upArrow ifNotNil: [aWidth := aWidth + UpArrowAllowance]. + suffixArrow ifNotNil: [aWidth := aWidth + SuffixArrowAllowance]. + ^ aWidth + ! Item was removed: - ----- Method: TileMorph>>minimumWidth (in category 'misc') ----- - minimumWidth - | aWidth | - aWidth := self basicWidth. - upArrow ifNotNil: [aWidth := aWidth + UpArrowAllowance]. - suffixArrow ifNotNil: [aWidth := aWidth + SuffixArrowAllowance]. - ^ aWidth - ! From commits at source.squeak.org Wed Jan 13 15:39:30 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 13 Jan 2021 15:39:30 0000 Subject: [squeak-dev] The Trunk: MorphicExtras-mt.282.mcz Message-ID: Marcel Taeumel uploaded a new version of MorphicExtras to project The Trunk: http://source.squeak.org/trunk/MorphicExtras-mt.282.mcz ==================== Summary ==================== Name: MorphicExtras-mt.282 Author: mt Time: 13 January 2021, 4:39:27.045847 pm UUID: 95c69503-32a5-6348-89d5-201549e7b662 Ancestors: MorphicExtras-mt.281 Fixes minor layout issue. =============== Diff against MorphicExtras-mt.281 =============== Item was added: + ----- Method: ObjectsTool>>minHeight (in category 'layout') ----- + minHeight + ^(self minimumBottom - self top) max: 280! Item was added: + ----- Method: ObjectsTool>>minWidth (in category 'layout') ----- + minWidth + "Answer a width that assures that the alphabet fits in two rows. For olpc, this is increased in order to make the Connectors category not too absurdly tall." + + ^ 400! Item was removed: - ----- Method: ObjectsTool>>minimumHeight (in category 'layout') ----- - minimumHeight - ^(self minimumBottom - self top) max: 280! Item was removed: - ----- Method: ObjectsTool>>minimumWidth (in category 'layout') ----- - minimumWidth - "Answer a width that assures that the alphabet fits in two rows. For olpc, this is increased in order to make the Connectors category not too absurdly tall." - - ^ 400! From commits at source.squeak.org Wed Jan 13 15:41:23 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 13 Jan 2021 15:41:23 0000 Subject: [squeak-dev] The Trunk: Morphic-mt.1717.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1717.mcz ==================== Summary ==================== Name: Morphic-mt.1717 Author: mt Time: 13 January 2021, 4:41:17.950847 pm UUID: 7b18d879-1009-e04b-b0b2-fe5ad7fe4376 Ancestors: Morphic-mt.1716 Improves documentation to maybe avoid issues such as the ones fixes in EToys-mt.416 and MorphicExtras-mt.282. =============== Diff against Morphic-mt.1716 =============== Item was changed: ----- Method: Morph>>minimumHeight (in category 'geometry - layout') ----- minimumHeight + "Wrapper for layout-specific function to avoid confusion. Please configure through #minimumHeight: or #minHeight: or by overriding #minHeight. Please do not override #minimumHeight since the layout mechanism will not call it." - "Wrapper for layout-specific function to avoid confusion." ^ self minHeight! Item was changed: ----- Method: Morph>>minimumWidth (in category 'geometry - layout') ----- minimumWidth + "Wrapper for layout-specific function to avoid confusion. Please configure through #minimumWidth: or #minWidth: or by overriding #minWidth. Please do not override #minimumWidth since the layout mechanism will not call it." - "Wrapper for layout-specific function to avoid confusion." ^ self minWidth! From peter at ozzard.org Wed Jan 13 18:10:56 2021 From: peter at ozzard.org (Peter Crowther) Date: Wed, 13 Jan 2021 18:10:56 +0000 Subject: [squeak-dev] Squeak and Sound In-Reply-To: References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610444537-e44cc4a295e27fde6d2848a9b26eddb0@pckswarms.ch> Message-ID: On Tue, 12 Jan 2021 at 19:08, tim Rowledge wrote: > > I'm not a piano player, but, what I vaguly remember as middle C does not > seem to be middle C and the lower third of the keyboard seems silent though > probably because the frequency is too low. > > The claimed middle C is set to 440Hz, which I'm fairly sure is correct. It > sound about right to me when played but I am not a musician. > If true, you're a sixth high. You want A440 to be the A above middle C. C isn't far off 256Hz (though don't use that as a reference!) Cheers, - Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Wed Jan 13 18:48:30 2021 From: tim at rowledge.org (tim Rowledge) Date: Wed, 13 Jan 2021 10:48:30 -0800 Subject: [squeak-dev] Squeak and Sound In-Reply-To: References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610444537-e44cc4a295e27fde6d2848a9b26eddb0@pckswarms.ch> Message-ID: <9518F8CF-7434-4EF9-841F-A667452710D0@rowledge.org> > On 2021-01-13, at 10:10 AM, Peter Crowther wrote: > > On Tue, 12 Jan 2021 at 19:08, tim Rowledge wrote: > > I'm not a piano player, but, what I vaguly remember as middle C does not seem to be middle C and the lower third of the keyboard seems silent though probably because the frequency is too low. > > The claimed middle C is set to 440Hz, which I'm fairly sure is correct. It sound about right to me when played but I am not a musician. > > If true, you're a sixth high. You want A440 to be the A above middle C. C isn't far off 256Hz (though don't use that as a reference!) You're right. I did point out I'm not a player... AbstractSound sets middle C to 261.6265Hz, which agrees with https://en.wikipedia.org/wiki/Piano_key_frequencies I guess an interesting question is whether anyone has both an oscilloscope and a Squeak system to compare and validate? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Law of Logical Argument: Anything is possible if you don't know what you are talking about. From lewis at mail.msen.com Wed Jan 13 22:24:58 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Wed, 13 Jan 2021 17:24:58 -0500 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <9518F8CF-7434-4EF9-841F-A667452710D0@rowledge.org> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610444537-e44cc4a295e27fde6d2848a9b26eddb0@pckswarms.ch> <9518F8CF-7434-4EF9-841F-A667452710D0@rowledge.org> Message-ID: <20210113222458.GA32875@shell.msen.com> On Wed, Jan 13, 2021 at 10:48:30AM -0800, tim Rowledge wrote: > > > > On 2021-01-13, at 10:10 AM, Peter Crowther wrote: > > > > On Tue, 12 Jan 2021 at 19:08, tim Rowledge wrote: > > > I'm not a piano player, but, what I vaguly remember as middle C does not seem to be middle C and the lower third of the keyboard seems silent though probably because the frequency is too low. > > > > The claimed middle C is set to 440Hz, which I'm fairly sure is correct. It sound about right to me when played but I am not a musician. > > > > If true, you're a sixth high. You want A440 to be the A above middle C. C isn't far off 256Hz (though don't use that as a reference!) > > You're right. I did point out I'm not a player... > > AbstractSound sets middle C to 261.6265Hz, which agrees with https://en.wikipedia.org/wiki/Piano_key_frequencies I guess an interesting question is whether anyone has both an oscilloscope and a Squeak system to compare and validate? > Here is another handy reference: http://newt.phys.unsw.edu.au/jw/notes.html Dave From lewis at mail.msen.com Thu Jan 14 01:51:03 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Wed, 13 Jan 2021 20:51:03 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: Message-ID: <20210114015103.GA57336@shell.msen.com> On Tue, Jan 12, 2021 at 09:43:45PM -0800, tim Rowledge wrote: > One of the things I had to make for NuScratch was a keyboardlistener that keeps a bitmap of the keys currently pressed - quite a few Scratch things are state dependent rather than even responsive. It originally worked pretty well as far as anybody could ever see; I had no reports of problems for years. > > Whilst trying to make a 5.3 version it seems that something is making it much less reliable. It is clear from some tracking code that if one holds down a key, presses and releases another key and then finally releases the initial key, that we are losing the final expected key-up of the held-down key. Which in turn leaves my keyboard listener thinking the key is still pressed. This is a Bad Thing. It causes me to lose games of Asteroid Blaster. I don't like to lose at Asteroid Blaster. > > Looking at the unix VM keystroke handling code causes migraines. Has anybody got any idea what on earth is going on down there? I'll build a VM with the relevant debug code turned on soon but really... if anyone that knows this part could save some pain it would be very pleasant. > Your question reminded me of something from a previous round of debugging a similar (same?) issue circa 2011 (see Mantis 0007597). There is a standard X11 utility program called xev that displays X events as they are being generated, and another program called xwininfo that lets you identify X11 windows and their parent and children and such. I'm going to predict that the man pages are likely to drive you crazy, but if you read them patiently a few dozen times, it's all in there. The output of xev is overwhelming, but you can redirect it to a file and look through that if you're patient. Another thing that is not too obvious is that the X11 window for the Squeak display is actually one window directly embedded in another of the same dimensions, so it can be a bit tricky to figure out which window is the "real" one. Your Squeak VM is an X11 client program that opens X11 windows under the control of the X window server. The events that you see are looking at with the xev program are the raw events, some of which are delivered to your client program (the VM) when the Squeak window is active and you are typing on your keyboard. The client VM program recieves the events and converts them into into Squeak events, and those events get delivered to the image. You can think of the X11 events from the X server as analogous to the Windows events on MS-Windows, in both cases the system (X server or Windows OS) has a source of events, some of which are delivered to your VM, and in both cases the raw events get converted in the VM into the Squeak event format for delivery to the image. In order to debug this mess, the first order of business would be to confirm that the ncessary keyup events actually are happening over in X11. So if you were using xev to write all of the events to a file, and if you carefully and quickly press the exact sequence of keystrokes of interest, then you would be looking for evidence of the "missing" keyup event appearing somewhere in the xev output. On the image side, you would want to confirm that the keyup event is actually missing (as opposed to being somehow misused in the image code). I think there are some morphs to help with this, and Matthew Fulmer's change set attached to the Mantis issue might help if you can get it to work in modern Squeak (the change set is an attachment on http://bugs.squeak.org/view.php?id=7597. If the events are present in X11 but missing by the time they get delivered to the image, then it's got to be a problem in the VM, most likely in the vm-display-X11 module. Dave From commits at source.squeak.org Thu Jan 14 12:21:18 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 14 Jan 2021 12:21:18 0000 Subject: [squeak-dev] The Trunk: Tools-mt.1024.mcz Message-ID: Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-mt.1024.mcz ==================== Summary ==================== Name: Tools-mt.1024 Author: mt Time: 14 January 2021, 1:21:15.354081 pm UUID: 0ef67378-0ca6-4743-be9c-5a60621c07cd Ancestors: Tools-mt.1023 Improves the description of several confirmation dialogs for removing batches of source code. =============== Diff against Tools-mt.1023 =============== Item was changed: ----- Method: Browser>>removeMessageCategory (in category 'message category functions') ----- removeMessageCategory "If a message category is selected, create a Confirmer so the user can verify that the currently selected message category should be removed from the system. If so, remove it." | messageCategoryName | self hasMessageCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. messageCategoryName := self selectedMessageCategoryName. (self messageList size = 0 + or: [Project uiManager confirm: ('Are you sure you want to remove\the message category\\ {1}\ in {2}\\and all its {3} methods? Maybe save\your image before doing this.' translated withCRs asText format: { + messageCategoryName asText allBold. + self selectedClassOrMetaClass name. + (self selectedClassOrMetaClass organization listAtCategoryNamed: messageCategoryName) size asString asText allBold + + }) title: 'Remove Message Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this method category - and all its methods?']) ifTrue: [self selectedClassOrMetaClass removeCategory: messageCategoryName. self selectMessageCategoryNamed: nil. self changed: #classSelectionChanged]. self changed: #messageCategoryList. ! Item was changed: ----- Method: Browser>>removeSystemCategory (in category 'system category functions') ----- removeSystemCategory "If a class category is selected, create a Confirmer so the user can verify that the currently selected class category and all of its classes should be removed from the system. If so, remove it." self hasSystemCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. (self classList size = 0 + or: [Project uiManager + confirm: ('Are you sure you want to remove\the system category\\ {1}\\and all its {2} classes? Maybe save\your image before doing this.' translated withCRs asText + format: { + self selectedSystemCategory asText allBold. + (systemOrganizer listAtCategoryNamed: self selectedSystemCategory) size asString asText allBold}) + title: 'Remove System Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this system category - and all its classes?']) ifTrue: [| nextSelectedCat | nextSelectedCat := self systemCategoryList before: self selectedSystemCategory ifAbsent: [nil]. systemOrganizer removeSystemCategory: self selectedSystemCategory. self selectSystemCategory: nextSelectedCat. self changed: #systemCategoryList]! Item was changed: ----- Method: CodeHolder>>removeClass (in category 'commands') ----- removeClass "Remove the selected class from the system, at interactive user request. Make certain the user really wants to do this, since it is not reversible. Answer true if removal actually happened." | message className classToRemove result | self okToChange ifFalse: [^ false]. classToRemove := self selectedClassOrMetaClass ifNil: [Beeper beep. ^ false]. classToRemove := classToRemove theNonMetaClass. className := classToRemove name. + message := 'Are you sure that you want to remove\the class\\ {1}\\and all its {2} methods? Maybe save\your image before doing this.{3}' translated withCRs asText format: { + className asText allBold. + (classToRemove methodDict size + classToRemove class methodDict size) asString asText allBold. + classToRemove subclasses size > 0 ifFalse: [''] ifTrue: [ + '\\(There are {1} subclasses, whose superclass\must be updated manually after this.)' translated withCRs asText format: { classToRemove subclasses size asString asText allBold }]}. + (result := Project uiManager confirm: message title: 'Remove Class' translated) - message := 'Are you certain that you - want to REMOVE the class ', className, ' - from the system?'. - (result := self confirm: message) ifTrue: [classToRemove subclasses size > 0 ifTrue: [(self confirm: 'class has subclasses: ' , message) ifFalse: [^ false]]. classToRemove removeFromSystem. self changed: #classList. true]. ^ result! From marcel.taeumel at hpi.de Thu Jan 14 12:24:13 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 14 Jan 2021 13:24:13 +0100 Subject: [squeak-dev] The Trunk: Tools-mt.1024.mcz In-Reply-To: References: Message-ID: Best, Marcel Am 14.01.2021 13:21:28 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-mt.1024.mcz ==================== Summary ==================== Name: Tools-mt.1024 Author: mt Time: 14 January 2021, 1:21:15.354081 pm UUID: 0ef67378-0ca6-4743-be9c-5a60621c07cd Ancestors: Tools-mt.1023 Improves the description of several confirmation dialogs for removing batches of source code. =============== Diff against Tools-mt.1023 =============== Item was changed: ----- Method: Browser>>removeMessageCategory (in category 'message category functions') ----- removeMessageCategory "If a message category is selected, create a Confirmer so the user can verify that the currently selected message category should be removed from the system. If so, remove it." | messageCategoryName | self hasMessageCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. messageCategoryName := self selectedMessageCategoryName. (self messageList size = 0 + or: [Project uiManager confirm: ('Are you sure you want to remove\the message category\\ {1}\ in {2}\\and all its {3} methods? Maybe save\your image before doing this.' translated withCRs asText format: { + messageCategoryName asText allBold. + self selectedClassOrMetaClass name. + (self selectedClassOrMetaClass organization listAtCategoryNamed: messageCategoryName) size asString asText allBold + + }) title: 'Remove Message Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this method category - and all its methods?']) ifTrue: [self selectedClassOrMetaClass removeCategory: messageCategoryName. self selectMessageCategoryNamed: nil. self changed: #classSelectionChanged]. self changed: #messageCategoryList. ! Item was changed: ----- Method: Browser>>removeSystemCategory (in category 'system category functions') ----- removeSystemCategory "If a class category is selected, create a Confirmer so the user can verify that the currently selected class category and all of its classes should be removed from the system. If so, remove it." self hasSystemCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. (self classList size = 0 + or: [Project uiManager + confirm: ('Are you sure you want to remove\the system category\\ {1}\\and all its {2} classes? Maybe save\your image before doing this.' translated withCRs asText + format: { + self selectedSystemCategory asText allBold. + (systemOrganizer listAtCategoryNamed: self selectedSystemCategory) size asString asText allBold}) + title: 'Remove System Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this system category - and all its classes?']) ifTrue: [| nextSelectedCat | nextSelectedCat := self systemCategoryList before: self selectedSystemCategory ifAbsent: [nil]. systemOrganizer removeSystemCategory: self selectedSystemCategory. self selectSystemCategory: nextSelectedCat. self changed: #systemCategoryList]! Item was changed: ----- Method: CodeHolder>>removeClass (in category 'commands') ----- removeClass "Remove the selected class from the system, at interactive user request. Make certain the user really wants to do this, since it is not reversible. Answer true if removal actually happened." | message className classToRemove result | self okToChange ifFalse: [^ false]. classToRemove := self selectedClassOrMetaClass ifNil: [Beeper beep. ^ false]. classToRemove := classToRemove theNonMetaClass. className := classToRemove name. + message := 'Are you sure that you want to remove\the class\\ {1}\\and all its {2} methods? Maybe save\your image before doing this.{3}' translated withCRs asText format: { + className asText allBold. + (classToRemove methodDict size + classToRemove class methodDict size) asString asText allBold. + classToRemove subclasses size > 0 ifFalse: [''] ifTrue: [ + '\\(There are {1} subclasses, whose superclass\must be updated manually after this.)' translated withCRs asText format: { classToRemove subclasses size asString asText allBold }]}. + (result := Project uiManager confirm: message title: 'Remove Class' translated) - message := 'Are you certain that you - want to REMOVE the class ', className, ' - from the system?'. - (result := self confirm: message) ifTrue: [classToRemove subclasses size > 0 ifTrue: [(self confirm: 'class has subclasses: ' , message) ifFalse: [^ false]]. classToRemove removeFromSystem. self changed: #classList. true]. ^ result! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 29075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 22215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24309 bytes Desc: not available URL: From frank-lesser at lesser-software.com Thu Jan 14 16:56:20 2021 From: frank-lesser at lesser-software.com (Frank Lesser) Date: Thu, 14 Jan 2021 17:56:20 +0100 Subject: [squeak-dev] [offtopic] Survey In-Reply-To: References: <2130ec2b-a3a1-1a16-20ba-3b39d4a6753c@lesser-software.com> <2d630992-2ab9-7f53-dbdd-fb8b16206778@lesser-software.com> Message-ID: <6a8b6c09-5ee7-1b4d-34b8-bb32b207cc80@lesser-software.com> hi, a new survey, https://twitter.com/LesserFrank/status/1349759950113951744?s=20 btw, a DolphinSmalltalk Discord server is online https://discord.gg/X5JMRP85nG Frank On 1/11/2021 10:11, Marcel Taeumel wrote: > Hi Frank! :-) > > > Pleave vote on my Smalltalk survey > > There is a "none of the above" missing, regarding Christoph's "I would > say tooling" comment. :-) > > Best, > Marcel >> >> Am 10.01.2021 17:41:11 schrieb Frank Lesser >> : >> >> Hi, >> >> I have published a new #SmalltalkPuzzle ( >> https://twitter.com/LesserFrank/status/1348303972671614979?s=20 ) >> >> Pleave vote on my Smalltalk survey >> >> https://twitter.com/LesserFrank/status/1347186405085163523?s=20 >> >> Frank >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Thu Jan 14 21:09:52 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Thu, 14 Jan 2021 16:09:52 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210114015103.GA57336@shell.msen.com> References: <20210114015103.GA57336@shell.msen.com> Message-ID: <20210114210952.GA59050@shell.msen.com> On Wed, Jan 13, 2021 at 08:51:03PM -0500, David T. Lewis wrote: > On Tue, Jan 12, 2021 at 09:43:45PM -0800, tim Rowledge wrote: > > One of the things I had to make for NuScratch was a keyboardlistener that keeps a bitmap of the keys currently pressed - quite a few Scratch things are state dependent rather than even responsive. It originally worked pretty well as far as anybody could ever see; I had no reports of problems for years. > > > > Whilst trying to make a 5.3 version it seems that something is making it much less reliable. It is clear from some tracking code that if one holds down a key, presses and releases another key and then finally releases the initial key, that we are losing the final expected key-up of the held-down key. Which in turn leaves my keyboard listener thinking the key is still pressed. This is a Bad Thing. It causes me to lose games of Asteroid Blaster. I don't like to lose at Asteroid Blaster. > > > > Looking at the unix VM keystroke handling code causes migraines. Has anybody got any idea what on earth is going on down there? I'll build a VM with the relevant debug code turned on soon but really... if anyone that knows this part could save some pain it would be very pleasant. > > > > Your question reminded me of something from a previous round of > debugging a similar (same?) issue circa 2011 (see Mantis 0007597). > > There is a standard X11 utility program called xev that displays > X events as they are being generated, and another program called > xwininfo that lets you identify X11 windows and their parent and > children and such. I'm going to predict that the man pages are > likely to drive you crazy, but if you read them patiently a few > dozen times, it's all in there. > > The output of xev is overwhelming, but you can redirect it to a > file and look through that if you're patient. > I used xev to check out the X11 events that get generated from the keyboard. My test was to do this (quickly)with xev running: - depress "x" key - depreas "y" key - release "y" key - release "x" key The X11 events as logged by xev were: KeyPress event, serial 37, synthetic NO, window 0x4a00001, root 0x157, subw 0x0, time 47948369, (-236,-191), root:(1506,711), state 0x0, keycode 53 (keysym 0x78, x), same_screen YES, XLookupString gives 1 bytes: (78) "x" XmbLookupString gives 1 bytes: (78) "x" XFilterEvent returns: False KeyPress event, serial 37, synthetic NO, window 0x4a00001, root 0x157, subw 0x0, time 47948766, (-236,-191), root:(1506,711), state 0x0, keycode 29 (keysym 0x79, y), same_screen YES, XLookupString gives 1 bytes: (79) "y" XmbLookupString gives 1 bytes: (79) "y" XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x4a00001, root 0x157, subw 0x0, time 47949114, (-236,-191), root:(1506,711), state 0x0, keycode 29 (keysym 0x79, y), same_screen YES, XLookupString gives 1 bytes: (79) "y" XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x4a00001, root 0x157, subw 0x0, time 47949541, (-236,-191), root:(1506,711), state 0x0, keycode 53 (keysym 0x78, x), same_screen YES, XLookupString gives 1 bytes: (78) "x" XFilterEvent returns: False Conclusion: All of the necessary keyboard events are generated by the X server and we can safely assume that they are being delivered to the VM. Next debugging step would be to confirm whether or not the "y" release event is being delivered to the image. Dave From craig at blackpagedigital.com Thu Jan 14 21:23:39 2021 From: craig at blackpagedigital.com (Craig Latta) Date: Thu, 14 Jan 2021 13:23:39 -0800 Subject: [squeak-dev] Squeak and Sound In-Reply-To: <9518F8CF-7434-4EF9-841F-A667452710D0@rowledge.org> References: <1610363028-4d793d76dcd8e2af2f2b50ea42e4c815@pckswarms.ch> <1610444537-e44cc4a295e27fde6d2848a9b26eddb0@pckswarms.ch> <9518F8CF-7434-4EF9-841F-A667452710D0@rowledge.org> Message-ID: <2663b74b-a842-61ee-5b30-7b228de47bd8@blackpagedigital.com> Hi Tim-- > I guess an interesting question is whether anyone has both an > oscilloscope and a Squeak system to compare and validate? Or just open up the waveform in Squeak or a no-cost editor like Audacity, and look at the time between the peaks. -C -- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE From craig at blackpagedigital.com Thu Jan 14 21:35:42 2021 From: craig at blackpagedigital.com (Craig Latta) Date: Thu, 14 Jan 2021 13:35:42 -0800 Subject: [squeak-dev] V3 In-Reply-To: <20210112010432.GB70731@shell.msen.com> References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> <20210112010432.GB70731@shell.msen.com> Message-ID: <2a5881e2-39ca-6973-2b6c-78072868016c@blackpagedigital.com> Hi Dave-- > ... > > Prior to that the support code was hosted on sourceforge.com. I don't > know if any copy of that repository still exists, and I don't know > when it first became publicly available. Some of that history may be > lost. Perhaps it's worth looking around the Wayback Machine snapshots at archive.org? -C -- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE From lewis at mail.msen.com Fri Jan 15 04:07:09 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Thu, 14 Jan 2021 23:07:09 -0500 Subject: [squeak-dev] V3 In-Reply-To: <2a5881e2-39ca-6973-2b6c-78072868016c@blackpagedigital.com> References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> <20210112010432.GB70731@shell.msen.com> <2a5881e2-39ca-6973-2b6c-78072868016c@blackpagedigital.com> Message-ID: <20210115040709.GA20797@shell.msen.com> Hi Craig, On Thu, Jan 14, 2021 at 01:35:42PM -0800, Craig Latta wrote: > > Hi Dave-- > > > ... > > > > Prior to that the support code was hosted on sourceforge.com. I don't > > know if any copy of that repository still exists, and I don't know > > when it first became publicly available. Some of that history may be > > lost. > > Perhaps it's worth looking around the Wayback Machine snapshots at > archive.org? > I don't know if there is anything of real interest in the original SourceForge repository, but if so I would guess that Ian Piumarta would be most likely to have a copy of it. The current Subversion repository that is still on line at squeakvm.org has version history going back to October 2001. Most likely there is some discussion of this on the squeak-dev list archives from that period. I don't recall any specifics, but I think that sourceforge was the github of that era - ie the latest and greatest cool hosting service - and for reasons I no longer recall it got to be uncool and we had to rescue the VM sources. "We" in this case being Ian, who has been providing and paying for the hosting service ever since. FWIW, Tim Rowledge appears to have the honor of having made the very first commit to the SVN repository circa 2001. I keep a private git mirror of the squeakvm.org repository, and a tail of the git log says this: > commit 6364e4a829c239562a1dbddbf77c57fe74c20a3c > Author: Tim Rowledge > Date: Wed Oct 24 23:11:49 2001 +0000 > > Initial revision > > commit eaae7a667f99ee68cc477d3167a6fe3b88e012bf > Author: (no author) <(no author)> > Date: Wed Oct 24 23:11:49 2001 +0000 > > New repository initialized by cvs2svn. Which may or may not be correct, since the actual SVN log says: > ------------------------------------------------------------------------ > r2 | rowledge | 2001-10-24 19:11:49 -0400 (Wed, 24 Oct 2001) | 2 lines > > Initial revision > > ------------------------------------------------------------------------ Either way I think that Tim gets first commit honors. And the git variant of the log tells me that the earlier repo was a CVS repository, for whatever that may be worth. Dave From tim at rowledge.org Fri Jan 15 04:22:01 2021 From: tim at rowledge.org (tim Rowledge) Date: Thu, 14 Jan 2021 20:22:01 -0800 Subject: [squeak-dev] V3 In-Reply-To: <20210115040709.GA20797@shell.msen.com> References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> <20210112010432.GB70731@shell.msen.com> <2a5881e2-39ca-6973-2b6c-78072868016c@blackpagedigital.com> <20210115040709.GA20797@shell.msen.com> Message-ID: > On 2021-01-14, at 8:07 PM, David T. Lewis wrote: > > I don't recall any specifics, but I think that sourceforge was the github > of that era - ie the latest and greatest cool hosting service - and for > reasons I no longer recall it got to be uncool and we had to rescue the > VM sources. "We" in this case being Ian, who has been providing and paying > for the hosting service ever since. I vaguely recall us getting uncomfortable with the ethos of sourceforge for some reason. Were they bought up by some nasty bunch? Started supporting the wrong feetball team? Got bossy about precise licensing terms? > > FWIW, Tim Rowledge appears to have the honor of having made the very first > commit to the SVN repository circa 2001. Uuuh, gosh. My emails imply we made the move around this time on '05. Ah - here is the announcement email -------------- next part -------------- An embedded message was scrubbed... From: goran.krampe at bluefish.se Subject: [ANN] Squeak VM sources have moved! Date: Tue, 1 Feb 2005 23:55:38 +0200 Size: 3394 URL: -------------- next part -------------- tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim The gains I make don't make me a hero; all the work I do is just to get back to Zero From tim at rowledge.org Fri Jan 15 04:36:34 2021 From: tim at rowledge.org (tim Rowledge) Date: Thu, 14 Jan 2021 20:36:34 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210114210952.GA59050@shell.msen.com> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> Message-ID: <102DE905-A968-429E-804A-7F08C0A03654@rowledge.org> > On 2021-01-14, at 1:09 PM, David T. Lewis wrote: > > I used xev to check out the X11 events that get generated from the > keyboard. My test was to do this (quickly)with xev running: > > - depress "x" key > - depreas "y" key > - release "y" key > - release "x" key > [snip] > Conclusion: All of the necessary keyboard events are generated by the > X server and we can safely assume that they are being delivered to > the VM. > > Next debugging step would be to confirm whether or not the "y" release > event is being delivered to the image. I see the same behaviour, which is good in the sense of the problem being real and not just my Mac->VNC setup. So it looks like a bug in the vm-display-x11 code somewhere. Well. That will be fun... tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Oxymorons: Exact estimate From tim at rowledge.org Fri Jan 15 05:46:57 2021 From: tim at rowledge.org (tim Rowledge) Date: Thu, 14 Jan 2021 21:46:57 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <102DE905-A968-429E-804A-7F08C0A03654@rowledge.org> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <102DE905-A968-429E-804A-7F08C0A03654@rowledge.org> Message-ID: Definitely some issue with sqUnixX11.c Press&hold 'a', see repeats of keypress event & keyrelease event for 'a', press&hold 'b' see repeats of keypress event & keyrelease event for 'b' - no more events for 'a' even though it is still pressed release 'b' see release of 'b' - no return to events for 'a' release 'a' see only lowest level VM event of releasing 'a', nothing goes to image To see this I compiled with OPT="-g -O2 -DNDEBUG -DDEBUGVM=0 -DDEBUG_EVENTS -DDEBUG_CONV" in the mvm file. Really weird. And I guess we should note that the xev listing shows the same behaviour wrt the repeats of 'a' stopping when 'b' is pressed; it's just that the final release of 'a' happens it records it. Is this some weird x keyboard extension we need to install to do things properly? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SNARF: System Normalize And Reset Flags From marcel.taeumel at hpi.de Fri Jan 15 08:40:06 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Fri, 15 Jan 2021 09:40:06 +0100 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210114210952.GA59050@shell.msen.com> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> Message-ID: Hi Dave. > Next debugging step would be to confirm whether or not the "y" release > event is being delivered to the image. 1) Add a "Transcript showln: anEvent" to the beginning of HandMorph >> #showEvent:. 2) Do it: "HandMorph showEvents: true" 3) Open a transcript window and observe. Best, Marcel Am 14.01.2021 22:10:01 schrieb David T. Lewis : On Wed, Jan 13, 2021 at 08:51:03PM -0500, David T. Lewis wrote: > On Tue, Jan 12, 2021 at 09:43:45PM -0800, tim Rowledge wrote: > > One of the things I had to make for NuScratch was a keyboardlistener that keeps a bitmap of the keys currently pressed - quite a few Scratch things are state dependent rather than even responsive. It originally worked pretty well as far as anybody could ever see; I had no reports of problems for years. > > > > Whilst trying to make a 5.3 version it seems that something is making it much less reliable. It is clear from some tracking code that if one holds down a key, presses and releases another key and then finally releases the initial key, that we are losing the final expected key-up of the held-down key. Which in turn leaves my keyboard listener thinking the key is still pressed. This is a Bad Thing. It causes me to lose games of Asteroid Blaster. I don't like to lose at Asteroid Blaster. > > > > Looking at the unix VM keystroke handling code causes migraines. Has anybody got any idea what on earth is going on down there? I'll build a VM with the relevant debug code turned on soon but really... if anyone that knows this part could save some pain it would be very pleasant. > > > > Your question reminded me of something from a previous round of > debugging a similar (same?) issue circa 2011 (see Mantis 0007597). > > There is a standard X11 utility program called xev that displays > X events as they are being generated, and another program called > xwininfo that lets you identify X11 windows and their parent and > children and such. I'm going to predict that the man pages are > likely to drive you crazy, but if you read them patiently a few > dozen times, it's all in there. > > The output of xev is overwhelming, but you can redirect it to a > file and look through that if you're patient. > I used xev to check out the X11 events that get generated from the keyboard. My test was to do this (quickly)with xev running: - depress "x" key - depreas "y" key - release "y" key - release "x" key The X11 events as logged by xev were: KeyPress event, serial 37, synthetic NO, window 0x4a00001, root 0x157, subw 0x0, time 47948369, (-236,-191), root:(1506,711), state 0x0, keycode 53 (keysym 0x78, x), same_screen YES, XLookupString gives 1 bytes: (78) "x" XmbLookupString gives 1 bytes: (78) "x" XFilterEvent returns: False KeyPress event, serial 37, synthetic NO, window 0x4a00001, root 0x157, subw 0x0, time 47948766, (-236,-191), root:(1506,711), state 0x0, keycode 29 (keysym 0x79, y), same_screen YES, XLookupString gives 1 bytes: (79) "y" XmbLookupString gives 1 bytes: (79) "y" XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x4a00001, root 0x157, subw 0x0, time 47949114, (-236,-191), root:(1506,711), state 0x0, keycode 29 (keysym 0x79, y), same_screen YES, XLookupString gives 1 bytes: (79) "y" XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x4a00001, root 0x157, subw 0x0, time 47949541, (-236,-191), root:(1506,711), state 0x0, keycode 53 (keysym 0x78, x), same_screen YES, XLookupString gives 1 bytes: (78) "x" XFilterEvent returns: False Conclusion: All of the necessary keyboard events are generated by the X server and we can safely assume that they are being delivered to the VM. Next debugging step would be to confirm whether or not the "y" release event is being delivered to the image. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Fri Jan 15 17:30:15 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 15 Jan 2021 12:30:15 -0500 Subject: [squeak-dev] V3 In-Reply-To: References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> <20210112010432.GB70731@shell.msen.com> <2a5881e2-39ca-6973-2b6c-78072868016c@blackpagedigital.com> <20210115040709.GA20797@shell.msen.com> Message-ID: <20210115173015.GA67437@shell.msen.com> On Thu, Jan 14, 2021 at 08:22:01PM -0800, tim Rowledge wrote: > > > > On 2021-01-14, at 8:07 PM, David T. Lewis wrote: > > > > I don't recall any specifics, but I think that sourceforge was the github > > of that era - ie the latest and greatest cool hosting service - and for > > reasons I no longer recall it got to be uncool and we had to rescue the > > VM sources. "We" in this case being Ian, who has been providing and paying > > for the hosting service ever since. > > > I vaguely recall us getting uncomfortable with the ethos of sourceforge for some reason. Were they bought up by some nasty bunch? Started supporting the wrong feetball team? Got bossy about precise licensing terms? > > > > > FWIW, Tim Rowledge appears to have the honor of having made the very first > > commit to the SVN repository circa 2001. > > Uuuh, gosh. My emails imply we made the move around this time on '05. Ah - here is the announcement email > Excellent, that's it then. The earlier SourceForge CVS repository was converted to Subversion in the 2005 time frame. The conversion was done with the cvs2svn tool, which would have preserved all available version history. All of the original source history from SourceForge is present in the SVN repository on squeakvm.org now, and nothing has been lost. Dave From nicolas.cellier.aka.nice at gmail.com Fri Jan 15 17:40:09 2021 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Fri, 15 Jan 2021 18:40:09 +0100 Subject: [squeak-dev] V3 In-Reply-To: <20210115173015.GA67437@shell.msen.com> References: <20210109150921.GA331@shell.msen.com> <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> <20210112010432.GB70731@shell.msen.com> <2a5881e2-39ca-6973-2b6c-78072868016c@blackpagedigital.com> <20210115040709.GA20797@shell.msen.com> <20210115173015.GA67437@shell.msen.com> Message-ID: Le ven. 15 janv. 2021 à 18:30, David T. Lewis a écrit : > > On Thu, Jan 14, 2021 at 08:22:01PM -0800, tim Rowledge wrote: > > > > > > > On 2021-01-14, at 8:07 PM, David T. Lewis wrote: > > > > > > I don't recall any specifics, but I think that sourceforge was the github > > > of that era - ie the latest and greatest cool hosting service - and for > > > reasons I no longer recall it got to be uncool and we had to rescue the > > > VM sources. "We" in this case being Ian, who has been providing and paying > > > for the hosting service ever since. > > > > > > I vaguely recall us getting uncomfortable with the ethos of sourceforge for some reason. Were they bought up by some nasty bunch? Started supporting the wrong feetball team? Got bossy about precise licensing terms? > > > > > > > > FWIW, Tim Rowledge appears to have the honor of having made the very first > > > commit to the SVN repository circa 2001. > > > > Uuuh, gosh. My emails imply we made the move around this time on '05. Ah - here is the announcement email > > > > Excellent, that's it then. The earlier SourceForge CVS repository > was converted to Subversion in the 2005 time frame. The conversion > was done with the cvs2svn tool, which would have preserved all > available version history. > > All of the original source history from SourceForge is present in > the SVN repository on squeakvm.org now, and nothing has been lost. > > Dave > > Given that we still have a script named ./scripts/updateSCCSVersions I would not be amazed that some earlier history could eventually be found before the CVS time frame ;) Nicolas From giovanni at corriga.net Fri Jan 15 19:35:00 2021 From: giovanni at corriga.net (Giovanni Corriga) Date: Fri, 15 Jan 2021 19:35:00 +0000 Subject: [squeak-dev] UK Smalltalk User Group meeting - Wednesday, January 27th Message-ID: The next meeting of the UK Smalltalk User Group will be on Wednesday, January 27th. For this presentation, guest speaker Michael Engel will bring us back to basics with a bare-metal Smalltalk-80 system for the Raspberry Pi. In 2020, the Xerox PARC research laboratory celebrated its 50th anniversary. One of the most important developments coming out of PARC is the Smalltalk system, which integrates a programming language, operating system and graphical user interface. Today, most of the Smalltalk systems run in hosted mode on a conventional operating system. This contradicts Dan Ingalls' idea that "an operating system is a collection of things that don't fit inside a language; there shouldn't be one". Accordingly, original Smalltalk systems, e.g. for the Alto workstation, ran on the bare metal of the computer. In this talk, we will discuss an approach to create a bare-metal Smalltalk-80 implementation for the Raspberry Pi ( https://www.raspberrypi.org/ ), a popular family of ARM-based systems. Interesting aspects that will be investigated are the overhead involved in bringing the system to life and debugging it, adapting the system to different Raspberry Pi models, and constraints due to properties of the hardware and the Smalltalk-80 VM. Michael Engel ( https://multicores.org/ ) is associate professor for compiler design at the Norwegian University of Science and Technology (NTNU) in Trondheim/Norway. His research interests lie on the intersection of compilers, operating systems and modern hardware. In previous positions, Michael worked at different German Universities as well as Oracle Labs Cambridge and Leeds Beckett University. He also was founder and CTO of kernel concepts, the first German company working with embedded Linux systems in 1999. Given the current COVID-19 restrictions, this will be an online meeting from home. If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/UKSTUG/events/cbklbrycccbkc/ ) to receive the meeting details. Don’t forget to bring your laptop and drinks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Fri Jan 15 21:54:45 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 15 Jan 2021 16:54:45 -0500 Subject: [squeak-dev] V3 In-Reply-To: References: <7F1D2412-ECA5-47E4-8686-F7EBA8E18C66@rowledge.org> <20210112010432.GB70731@shell.msen.com> <2a5881e2-39ca-6973-2b6c-78072868016c@blackpagedigital.com> <20210115040709.GA20797@shell.msen.com> <20210115173015.GA67437@shell.msen.com> Message-ID: <20210115215445.GA8548@shell.msen.com> On Fri, Jan 15, 2021 at 06:40:09PM +0100, Nicolas Cellier wrote: > Le ven. 15 janv. 2021 ?? 18:30, David T. Lewis a ??crit : > > > > On Thu, Jan 14, 2021 at 08:22:01PM -0800, tim Rowledge wrote: > > > > > > > > > > On 2021-01-14, at 8:07 PM, David T. Lewis wrote: > > > > > > > > I don't recall any specifics, but I think that sourceforge was the github > > > > of that era - ie the latest and greatest cool hosting service - and for > > > > reasons I no longer recall it got to be uncool and we had to rescue the > > > > VM sources. "We" in this case being Ian, who has been providing and paying > > > > for the hosting service ever since. > > > > > > > > > I vaguely recall us getting uncomfortable with the ethos of sourceforge for some reason. Were they bought up by some nasty bunch? Started supporting the wrong feetball team? Got bossy about precise licensing terms? > > > > > > > > > > > FWIW, Tim Rowledge appears to have the honor of having made the very first > > > > commit to the SVN repository circa 2001. > > > > > > Uuuh, gosh. My emails imply we made the move around this time on '05. Ah - here is the announcement email > > > > > > > Excellent, that's it then. The earlier SourceForge CVS repository > > was converted to Subversion in the 2005 time frame. The conversion > > was done with the cvs2svn tool, which would have preserved all > > available version history. > > > > All of the original source history from SourceForge is present in > > the SVN repository on squeakvm.org now, and nothing has been lost. > > > > Dave > > > > > > Given that we still have a script named > > ./scripts/updateSCCSVersions > > I would not be amazed that some earlier history could eventually be > found before the CVS time frame ;) > > Nicolas > LOL you are probably right! Dave From lewis at mail.msen.com Fri Jan 15 22:20:29 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 15 Jan 2021 17:20:29 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> Message-ID: <20210115222029.GA10532@shell.msen.com> On Fri, Jan 15, 2021 at 09:40:06AM +0100, Marcel Taeumel wrote: > Hi Dave. > > >??Next debugging step would be to confirm whether or not the "y" release > > event is being delivered to the image. > > 1) Add a "Transcript showln: anEvent" to the beginning of HandMorph >> #showEvent:. > 2) Do it: "HandMorph showEvents: true" > 3) Open a transcript window and observe. > Thanks Marcel, Thanks, that works really well. And the results are interesting. On a Spur VM, I cannot reproduce the problem. Here is what I saw: [452 at 596 keyDown (102) 85961993] [452 at 596 keystroke 'f' (102) 85961993]f [452 at 596 keyDown (106) 85962215] [452 at 596 keystroke 'j' (106) 85962215]j [452 at 596 keyUp (106) 85962285] [452 at 596 keyUp (102) 85962664] The test was press "f", press "j", release "j", release "f" Then I repeated the test on an interpreter VM, and it *does" have the problem. Presumably this is the issue that was reported on Mantis 0007597. According to the Mantis report, the issue was fixed in Cog (and presumably not in the interpreter VM). Tim, can you try this on your Raspberry Pi and see if you can reproduce? Here is the Spur VM that I used: Virtual Machine --------------- /usr/local/lib/squeak/5.0-202007252116/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2780] Unix built on Jul 25 2020 21:21:30 Compiler: 4.2.1 Compatible Clang 7.0.0 (tags/RELEASE_700/final) platform sources revision VM: 202007252116 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jul 25 14:16:21 2020 CommitHash: c53070d Plugins: 202007252116 https://github.com/OpenSmalltalk/opensmalltalk-vm.git CoInterpreter VMMaker.oscog-eem.2780 uuid: 5e381464-117c-4633-8fe7-a95973208436 Jul 25 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2780 uuid: 5e381464-117c-4633-8fe7-a95973208436 Jul 25 2020 Dave > Best, > Marcel > Am 14.01.2021 22:10:01 schrieb David T. Lewis : > On Wed, Jan 13, 2021 at 08:51:03PM -0500, David T. Lewis wrote: > > On Tue, Jan 12, 2021 at 09:43:45PM -0800, tim Rowledge wrote: > > > One of the things I had to make for NuScratch was a keyboardlistener that keeps a bitmap of the keys currently pressed - quite a few Scratch things are state dependent rather than even responsive. It originally worked pretty well as far as anybody could ever see; I had no reports of problems for years. > > > > > > Whilst trying to make a 5.3 version it seems that something is making it much less reliable. It is clear from some tracking code that if one holds down a key, presses and releases another key and then finally releases the initial key, that we are losing the final expected key-up of the held-down key. Which in turn leaves my keyboard listener thinking the key is still pressed. This is a Bad Thing. It causes me to lose games of Asteroid Blaster. I don't like to lose at Asteroid Blaster. > > > > > > Looking at the unix VM keystroke handling code causes migraines. Has anybody got any idea what on earth is going on down there? I'll build a VM with the relevant debug code turned on soon but really... if anyone that knows this part could save some pain it would be very pleasant. > > > > > > > Your question reminded me of something from a previous round of > > debugging a similar (same?) issue circa 2011 (see Mantis 0007597). > > > > There is a standard X11 utility program called xev that displays > > X events as they are being generated, and another program called > > xwininfo that lets you identify X11 windows and their parent and > > children and such. I'm going to predict that the man pages are > > likely to drive you crazy, but if you read them patiently a few > > dozen times, it's all in there. > > > > The output of xev is overwhelming, but you can redirect it to a > > file and look through that if you're patient. > > > > I used xev to check out the X11 events that get generated from the > keyboard. My test was to do this (quickly)with xev running: > > - depress "x" key > - depreas "y" key > - release "y" key > - release "x" key > > The X11 events as logged by xev were: > > > KeyPress event, serial 37, synthetic NO, window 0x4a00001, > root 0x157, subw 0x0, time 47948369, (-236,-191), root:(1506,711), > state 0x0, keycode 53 (keysym 0x78, x), same_screen YES, > XLookupString gives 1 bytes: (78) "x" > XmbLookupString gives 1 bytes: (78) "x" > XFilterEvent returns: False > > KeyPress event, serial 37, synthetic NO, window 0x4a00001, > root 0x157, subw 0x0, time 47948766, (-236,-191), root:(1506,711), > state 0x0, keycode 29 (keysym 0x79, y), same_screen YES, > XLookupString gives 1 bytes: (79) "y" > XmbLookupString gives 1 bytes: (79) "y" > XFilterEvent returns: False > > KeyRelease event, serial 37, synthetic NO, window 0x4a00001, > root 0x157, subw 0x0, time 47949114, (-236,-191), root:(1506,711), > state 0x0, keycode 29 (keysym 0x79, y), same_screen YES, > XLookupString gives 1 bytes: (79) "y" > XFilterEvent returns: False > > KeyRelease event, serial 37, synthetic NO, window 0x4a00001, > root 0x157, subw 0x0, time 47949541, (-236,-191), root:(1506,711), > state 0x0, keycode 53 (keysym 0x78, x), same_screen YES, > XLookupString gives 1 bytes: (78) "x" > XFilterEvent returns: False > > Conclusion: All of the necessary keyboard events are generated by the > X server and we can safely assume that they are being delivered to > the VM. > > Next debugging step would be to confirm whether or not the "y" release > event is being delivered to the image. > > Dave > > > From tim at rowledge.org Sat Jan 16 01:13:58 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 15 Jan 2021 17:13:58 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210115222029.GA10532@shell.msen.com> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> Message-ID: <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> > On 2021-01-15, at 2:20 PM, David T. Lewis wrote: > > > Tim, can you try this on your Raspberry Pi and see if you can reproduce? Yeah, I've done various test including what Marcel suggested and it Just Don't Work Here. Marcel's idea provides - [350.0 at 397.0 keyDown (97) 67898453] [350.0 at 397.0 keystroke 'a' (97) 67898453]a [350.0 at 397.0 keyDown (97) 67898523] [350.0 at 397.0 keystroke 'a' (97) 67898523]a [350.0 at 397.0 keyDown (97) 67898609] [350.0 at 397.0 keystroke 'a' (97) 67898609]a [350.0 at 397.0 keyDown (98) 67898697] [350.0 at 397.0 keystroke 'b' (98) 67898697]b [350.0 at 397.0 keyUp (98) 67898779] I also tried logging the KeyboardEvent>>#setType:buttons:position:keyValue:hand:stamp: to catch the rawest level in the image that I could get to, the KeyboardStateWatcher>>#handleListenEvent: to see if my keyboard listener was triggering (it is) and turned on DEBUG_EVENT& DEBUG_CONV in the VM to log what the VM sees. Oh, and I have the rather cute KeyboardEventMorphs deployed - they are nice little widgets that you can set to listen to specific key events and display the state. In my terminal I get this - (handleEvent)X KeyPress state 0x0 raw keycode 38 keycode 38 x2sqKey XLookupBoth count 1 x2sqKey == 97 symbolic, keyCode, ucs4: 61, 97, 61 pressed, buffer: 0, 0 multi_key reset keyCode, ucs4, multi_key_buffer: 97, 97, 0 signalInputEvent EVENT (recordKeyboardEvent): time: 68294181 key down `a' (97 = 0x61) ucs4 97 signalInputEvent EVENT (recordKeyboardEvent): time: 68294181 key char `a' (97 = 0x61) ucs4 97 (ioGetNextEvent) KEYBOARD evt: time: 68294181 char: 97 utf32: 0 (ioGetNextEvent) KEYBOARD evt: time: 68294181 char: 97 utf32: 97 (ioGetNextEvent) KEYBOARD evt: time: 68294181 char: 97 utf32: 97 rawkeyUp: 97 <<<<<---------the rawkey*: & key*: lines are from the image logging keyup: 65 rawkeyDown: 97 keydown: 65 rawkeystroke: 97 keystroke: 65 (handleEvent)X KeyRelease state 0x0 raw keycode 38 signalInputEvent EVENT (recordKeyboardEvent): time: 68294264 key up `a' (97 = 0x61) ucs4 0 (handleEvent)X KeyPress state 0x0 raw keycode 38 keycode 38 x2sqKey XLookupBoth count 1 x2sqKey == 97 symbolic, keyCode, ucs4: 61, 97, 61 pressed, buffer: 0, 0 multi_key reset keyCode, ucs4, multi_key_buffer: 97, 97, 0 signalInputEvent EVENT (recordKeyboardEvent): time: 68294264 key down `a' (97 = 0x61) ucs4 97 signalInputEvent EVENT (recordKeyboardEvent): time: 68294264 key char `a' (97 = 0x61) ucs4 97 (ioGetNextEvent) KEYBOARD evt: time: 68294264 char: 97 utf32: 0 (ioGetNextEvent) KEYBOARD evt: time: 68294264 char: 97 utf32: 97 (ioGetNextEvent) KEYBOARD evt: time: 68294264 char: 97 utf32: 97 rawkeyUp: 97 keyup: 65 rawkeyDown: 97 keydown: 65 rawkeystroke: 97 keystroke: 65 (handleEvent)X KeyPress state 0x0 raw keycode 56 keycode 56 x2sqKey XLookupBoth count 1 x2sqKey == 98 symbolic, keyCode, ucs4: 62, 98, 62 pressed, buffer: 0, 0 multi_key reset keyCode, ucs4, multi_key_buffer: 98, 98, 0 signalInputEvent EVENT (recordKeyboardEvent): time: 68294327 key down `b' (98 = 0x62) ucs4 98 signalInputEvent EVENT (recordKeyboardEvent): time: 68294327 key char `b' (98 = 0x62) ucs4 98 (ioGetNextEvent) KEYBOARD evt: time: 68294327 char: 98 utf32: 98 (ioGetNextEvent) KEYBOARD evt: time: 68294327 char: 98 utf32: 98 rawkeyDown: 98 keydown: 66 rawkeystroke: 98 keystroke: 66 (handleEvent)X KeyRelease state 0x0 raw keycode 56 signalInputEvent EVENT (recordKeyboardEvent): time: 68294767 key up `b' (98 = 0x62) ucs4 0 (ioGetNextEvent) KEYBOARD evt: time: 68294767 char: 98 utf32: 0 rawkeyUp: 98 keyup: 66 (handleEvent)X KeyRelease state 0x0 raw keycode 38 Note how there is no signalInputEvent triggered by that last KeyRelease? > > Here is the Spur VM that I used: Mine is built last night from sources of a few days ago. /home/pi/Documents/Squeak/sqcogspurlinuxhtRPi/lib/squeak/5.0-202012301853/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2908] Unix built on Jan 14 2021 21:19:52 Compiler: 8.3.0 platform sources revision VM: 202012301853 tim at Diziet.local:Documents/Squeak/opensmalltalk-vm Date: Wed Dec 30 10:53:48 2020 CommitHash: 85708ef49 Plugins: 202012301853 tim at Diziet.local:Documents/Squeak/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2908 uuid: fddf1a4f-c585-45ab-8a74-442230cd3dbd Jan 14 2021 StackToRegisterMappingCogit VMMaker.oscog-eem.2905 uuid: b2778a08-d45d-4f84-8467-21a8eccf46dc Jan 14 2021 So my VM is ~six months newer than yours. Wonder if something got broken since then... or maybe another one of those 'amusing' compiler errors. Looking at the sqUnixX11.c on github it appears that lines ~3746 are the place where we need to concentrate. case KeyRelease: noteEventState(evt->xkey); { KeySym symbolic; int keyCode, ucs4; if (XPending(stDisplay)) { XEvent evt2; XPeekEvent(stDisplay, &evt2); if ((evt2.type == KeyPress) && (evt2.xkey.keycode == evt->xkey.keycode) && ((evt2.xkey.time - evt->xkey.time < 2))) break; } keyCode= x2sqKey(&evt->xkey, &symbolic); ucs4= xkeysym2ucs4(symbolic); if ((keyCode >= 0) || (ucs4 > 0)) recordKeyboardEvent(keyCode, EventKeyUp, modifierState, ucs4); } break; If something makes that last clause skip then we wouldn't call recordKeyboardEvent() and so wouldn't... record... the keyboard event. That in turn would mean no signalInputEvent(). Similarly, that XPending(stDisplay) test can cause us to skip. Oh well, add more debugging clutter to the VM... tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Watch out for off-by-one errorss. From tim at rowledge.org Sat Jan 16 04:51:16 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 15 Jan 2021 20:51:16 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> Message-ID: <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> > On 2021-01-15, at 5:13 PM, tim Rowledge wrote: > > Oh well, add more debugging clutter to the VM... > Well. That tells us - (handleEvent)X KeyRelease state 0x0 raw keycode 38 symbolic, keyCode, ucs4: 4fd530, -1, 0 Skip KeyRelease at keyCode/ucs4 test line 3764 Where line 3764 is fairly obvious in - KeySym symbolic; int keyCode, ucs4; if (XPending(stDisplay)) { XEvent evt2; XPeekEvent(stDisplay, &evt2); if ((evt2.type == KeyPress) && (evt2.xkey.keycode == evt->xkey.keycode) && ((evt2.xkey.time - evt->xkey.time < 2))) { DCONV_PRINTERR("Skip KeyRelease at XPeekEvent check line 3757"); break; } } keyCode= x2sqKey(&evt->xkey, &symbolic); ucs4= xkeysym2ucs4(symbolic); DCONV_PRINTERR("symbolic, keyCode, ucs4: %x, %d, %x\n", symbolic, keyCode, ucs4); if ((keyCode >= 0) || (ucs4 > 0)) <<<<<<<-------- line 3764 recordKeyboardEvent(keyCode, EventKeyUp, modifierState, ucs4); else DCONV_PRINTERR("Skip KeyRelease at keyCode/ucs4 test line 3764"); } break; Ah; look at static int x2sqKeyInput() {line 1720} - it carefully does some stuff to track the *single* last key pressed and if the event is a release, tells you what the last press key was and then sets the record of last-press to -1. Thus if we press a second key it destroys any evidence of the prior press and we're screwed. There's the same stuff in static int x2sqKeyCompositionInput() but *not* in static int x2sqKeyPlain(), though it can still return -1. Might it be that you (Dave) had a VM using that? It looks like we can force use of x2sqKeyPlain() by the cmdline flag '-nointl' and that certainly skips the above problem but unfortunately completely misses the point. The log shows (handleEvent)X KeyRelease state 0x0 raw keycode 38 symbolic, keyCode, ucs4: 1785530, -1, 785530 signalInputEvent EVENT (recordKeyboardEvent): time: 126350 key up ` ' (0 = 0x0) ucs4 7886128 (ioGetNextEvent) KEYBOARD evt: time: 126350 char: 0 utf32: 7886128 - where the keyCode is still -1 but the ucs4 value is the left-over value from the prior read event, totally confusing the system and creating a nonsense event to pass to the image. Oh and the utf32 value is sometimes(?) nonsensical on a release but I suspect that is just a dumb side-effect. This really pretty ridiculous stuff. I really hope somebody around here actually understands X event stuff! tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Oyster (n.), a person who sprinkles his conversation with Yiddishisms. From tim at rowledge.org Sat Jan 16 23:17:06 2021 From: tim at rowledge.org (tim Rowledge) Date: Sat, 16 Jan 2021 15:17:06 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> Message-ID: <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> > On 2021-01-15, at 8:51 PM, tim Rowledge wrote: > > Ah; look at static int x2sqKeyInput() {line 1720} - it carefully does some stuff to track the *single* last key pressed and if the event is a release, tells you what the last press key was and then sets the record of last-press to -1. Thus if we press a second key it destroys any evidence of the prior press and we're screwed. So far as I can work out this insane collection of input X code is unable to convert a key release in the same way that it converts a key press; possibly sometihng to do with use of the extra compositor things and multiple keypresses ? We can't use XmbLookupString() since that is undefined for key release events. What it means is that in order to provide an event saying "oh, key $b was released" based on the information provided by X events we had to use some side-effect algorithm that maps the char code produced by the last press of the key. Currently that only copes with a single key being pressed at a time. It seems faintly plausible that making a somewhat bigger array with pairs of the event keycode and the value returned last time that was pressed *might* work. The potential problem would be any case where a multiple key action had been required to compose a character; I have no idea how one might handle that. I think this is one of those cases where simply passing the raw OS event data into the image and handling it there might have been less painful. Obviously more platform spread stuff in the image but... Surely this can't be a unique situation? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful random insult:- The wheel's spinning but the hamster's dead. From lewis at mail.msen.com Sat Jan 16 23:33:14 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 16 Jan 2021 18:33:14 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> Message-ID: <20210116233314.GA53746@shell.msen.com> Hi Tim, On Sat, Jan 16, 2021 at 03:17:06PM -0800, tim Rowledge wrote: > > > > On 2021-01-15, at 8:51 PM, tim Rowledge wrote: > > > > Ah; look at static int x2sqKeyInput() {line 1720} - it carefully does some stuff to track the *single* last key pressed and if the event is a release, tells you what the last press key was and then sets the record of last-press to -1. Thus if we press a second key it destroys any evidence of the prior press and we're screwed. > > So far as I can work out this insane collection of input X code is unable to convert a key release in the same way that it converts a key press; possibly sometihng to do with use of the extra compositor things and multiple keypresses ? We can't use XmbLookupString() since that is undefined for key release events. > > What it means is that in order to provide an event saying "oh, key $b was released" based on the information provided by X events we had to use some side-effect algorithm that maps the char code produced by the last press of the key. Currently that only copes with a single key being pressed at a time. It seems faintly plausible that making a somewhat bigger array with pairs of the event keycode and the value returned last time that was pressed *might* work. The potential problem would be any case where a multiple key action had been required to compose a character; I have no idea how one might handle that. > I have to admit I'm getting a bit lost in this, but I have been looking in the same area and I think you are on the right track. The part I can't figure out is how it could be working on any of the VMs. For the functions that you are looking at, the C code is almost (but not quite) identical in the oscog git code base and the squeakvm svn code base. The small differences that I so do not appear relevant to the missing KeyRelease event problem. But on my PC, one VM works and the other does not. So far I've run the interpreter VM under gdb and I can see where it is not working (exactly as you have explained). I have not yet tried making a debug version of the Spur VM but it's possible that it would show why that one *does* seem to work on my PC. I'll try to find time to check that tomorrow. > I think this is one of those cases where simply passing the raw OS event data into the image and handling it there might have been less painful. Obviously more platform spread stuff in the image but... > Quite possible so. I certainly would make the debugging simpler. Dave > Surely this can't be a unique situation? > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Useful random insult:- The wheel's spinning but the hamster's dead. > > > From tim at rowledge.org Sun Jan 17 00:03:45 2021 From: tim at rowledge.org (tim Rowledge) Date: Sat, 16 Jan 2021 16:03:45 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210116233314.GA53746@shell.msen.com> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> Message-ID: <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> > On 2021-01-16, at 3:33 PM, David T. Lewis wrote: > . The part I > can't figure out is how it could be working on any of the VMs. I can't see any case where it can work either but the code is so convoluted you need a native guide. The one thing I can see that might just possibly account for differences is the way that x2sqKey is a function pointer that can end up pointing to any of three routines depending upon assorted commandline options, environment variables and phase of a random selection of Jupiter's moons. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RSC: Rewind System Clock From tim at rowledge.org Sun Jan 17 00:21:44 2021 From: tim at rowledge.org (tim Rowledge) Date: Sat, 16 Jan 2021 16:21:44 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> Message-ID: Wow, this really is reminding horribly why I always hated writing C code. It's so.... clumsy. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Long computations that yield zero are probably all for naught. From lewis at mail.msen.com Sun Jan 17 05:17:39 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 17 Jan 2021 00:17:39 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> Message-ID: <20210117051739.GA16486@shell.msen.com> On Sat, Jan 16, 2021 at 04:03:45PM -0800, tim Rowledge wrote: > > > > On 2021-01-16, at 3:33 PM, David T. Lewis wrote: > > . The part I > > can't figure out is how it could be working on any of the VMs. > > I can't see any case where it can work either but the code is so convoluted you need a native guide. The one thing I can see that might just possibly account for differences is the way that x2sqKey is a function pointer that can end up pointing to any of three routines depending upon assorted commandline options, environment variables and phase of a random selection of Jupiter's moons. > Exactly right. Well it's not exactly a function of Jupiter's moons, but pretty darn close. I've narrowed the issue down some more, and can offer at least a workaround for Scratch. The reason that the key up events are being lost is that either the LC_ALL or the LC_CTYPE environment variable is set. If you unset both of these, the key up events will start working. The reason that my interpreter VM showed the problem and Spur did not is that the run script for the interpreter VM sets LC_ALL to the current value of $LANG. The run script for the Spur VM does not do this. The X11 VM display module provides three variations of x2sqKey() functions, only one of which will be active. The default is x2sqKeyPlain(), which works as expected for key up events. The x2sqKeyInput() variant is activated if LC_ALL or LC_CTYPE are defined in then environment, and this function has the missing key up event problem. The third variant, x2sqKeyCompositionInput(), is active when the VM is started with the -compositioninput command line option (or SQUEAK_COMPOSITIONINPUT environment variable is set). This also seems to have the missing key up event problem. Dave From tim at rowledge.org Sun Jan 17 06:15:22 2021 From: tim at rowledge.org (tim Rowledge) Date: Sat, 16 Jan 2021 22:15:22 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210117051739.GA16486@shell.msen.com> References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> Message-ID: > On 2021-01-16, at 9:17 PM, David T. Lewis wrote: > > On Sat, Jan 16, 2021 at 04:03:45PM -0800, tim Rowledge wrote: >> >> >>> On 2021-01-16, at 3:33 PM, David T. Lewis wrote: >>> . The part I >>> can't figure out is how it could be working on any of the VMs. >> >> I can't see any case where it can work either but the code is so convoluted you need a native guide. The one thing I can see that might just possibly account for differences is the way that x2sqKey is a function pointer that can end up pointing to any of three routines depending upon assorted commandline options, environment variables and phase of a random selection of Jupiter's moons. >> > > Exactly right. Well it's not exactly a function of Jupiter's moons, but > pretty darn close. > > I've narrowed the issue down some more, and can offer at least a > workaround for Scratch. > > The reason that the key up events are being lost is that either the > LC_ALL or the LC_CTYPE environment variable is set. If you unset both of > these, the key up events will start working. That's interesting. I had tried manually specifying the x2sqKeyPlain by using `-nointl` but it looks like it gets over-ridden pretty quickly. I see that on my Pi ` echo $LC_ALL en_US.UTF-8 ` So it looks like the big difference is use of XmbLookupString vs XLookupString. Since as mentioned "We can't use XmbLookupString() since that is undefined for key release events." I guess maybe we might try using XLookupString for handling key release events ? It will potentially be wrong for times when a composited character was used but it's really hard to imagine what *wouldn't* be wrong. Maybe one might take comfort in the thought that using a composited character within the sort of Scratch script that uses key states is pretty close to unimaginable. Actually... checking... yes, impossible since the usable keys are a-z,0-9,yp,down,left,right,space. Maybe there is something in that which can drive a useful heuristic? Thanks so much for digging into this Dave. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim A flash of light, a cloud of dust, and... What was the question? From nicolas.cellier.aka.nice at gmail.com Sun Jan 17 09:47:46 2021 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Sun, 17 Jan 2021 10:47:46 +0100 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> Message-ID: IMO it's a mistake: we should always pass the keypress/release events as is to the image, that's what raw events means to be. Composition shall alter the keychar events only - that is some 1st level interpretation of the raw events... Le dim. 17 janv. 2021 à 07:15, tim Rowledge a écrit : > > > > On 2021-01-16, at 9:17 PM, David T. Lewis wrote: > > > > On Sat, Jan 16, 2021 at 04:03:45PM -0800, tim Rowledge wrote: > >> > >> > >>> On 2021-01-16, at 3:33 PM, David T. Lewis wrote: > >>> . The part I > >>> can't figure out is how it could be working on any of the VMs. > >> > >> I can't see any case where it can work either but the code is so > convoluted you need a native guide. The one thing I can see that might just > possibly account for differences is the way that x2sqKey is a function > pointer that can end up pointing to any of three routines depending upon > assorted commandline options, environment variables and phase of a random > selection of Jupiter's moons. > >> > > > > Exactly right. Well it's not exactly a function of Jupiter's moons, but > > pretty darn close. > > > > I've narrowed the issue down some more, and can offer at least a > > workaround for Scratch. > > > > The reason that the key up events are being lost is that either the > > LC_ALL or the LC_CTYPE environment variable is set. If you unset both of > > these, the key up events will start working. > > That's interesting. I had tried manually specifying the x2sqKeyPlain by > using `-nointl` but it looks like it gets over-ridden pretty quickly. I see > that on my Pi > ` > echo $LC_ALL > en_US.UTF-8 > ` > > So it looks like the big difference is use of XmbLookupString vs > XLookupString. Since as mentioned "We can't use XmbLookupString() since > that is undefined for key release events." I guess maybe we might try using > XLookupString for handling key release events ? It will potentially be > wrong for times when a composited character was used but it's really hard > to imagine what *wouldn't* be wrong. Maybe one might take comfort in the > thought that using a composited character within the sort of Scratch script > that uses key states is pretty close to unimaginable. Actually... > checking... yes, impossible since the usable keys are > a-z,0-9,yp,down,left,right,space. Maybe there is something in that which > can drive a useful heuristic? > > Thanks so much for digging into this Dave. > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > A flash of light, a cloud of dust, and... What was the question? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Sun Jan 17 16:30:00 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 17 Jan 2021 11:30:00 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> Message-ID: <20210117163000.GA23156@shell.msen.com> On Sat, Jan 16, 2021 at 10:15:22PM -0800, tim Rowledge wrote: > > > > On 2021-01-16, at 9:17 PM, David T. Lewis wrote: > > > > On Sat, Jan 16, 2021 at 04:03:45PM -0800, tim Rowledge wrote: > >> > >> > >>> On 2021-01-16, at 3:33 PM, David T. Lewis wrote: > >>> . The part I > >>> can't figure out is how it could be working on any of the VMs. > >> > >> I can't see any case where it can work either but the code is so convoluted you need a native guide. The one thing I can see that might just possibly account for differences is the way that x2sqKey is a function pointer that can end up pointing to any of three routines depending upon assorted commandline options, environment variables and phase of a random selection of Jupiter's moons. > >> > > > > Exactly right. Well it's not exactly a function of Jupiter's moons, but > > pretty darn close. > > > > I've narrowed the issue down some more, and can offer at least a > > workaround for Scratch. > > > > The reason that the key up events are being lost is that either the > > LC_ALL or the LC_CTYPE environment variable is set. If you unset both of > > these, the key up events will start working. > > That's interesting. I had tried manually specifying the x2sqKeyPlain by using `-nointl` but it looks like it gets over-ridden pretty quickly. I see that on my Pi > ` > echo $LC_ALL > en_US.UTF-8 > ` So we know that there is a problem in the X11 key handling in the VM that is triggered if the environment variable LC_ALL is set. Scratch is now encoountering this problem, whereas previously it had no problem. Most likely the thing that has changed is that the Linux environment on Raspberry Pi (updated OS?) is now setting the LC_ALL variable to support locale handling. Apparently Scratch worked fine without this, so the workaround to avoid the problem would be to unset LC_ALL in whatever script is being used to run Scratch. I don't have a Pi to check, but most likely there is a unix shell script somewhere, such as /usr/bin/scratch, that runs the VM and brings up the Scratch image. If so, then you can add "unset LC_ALL" to the script, and I expect that Scratch will be happy again. Dave > > So it looks like the big difference is use of XmbLookupString vs XLookupString. Since as mentioned "We can't use XmbLookupString() since that is undefined for key release events." I guess maybe we might try using XLookupString for handling key release events ? It will potentially be wrong for times when a composited character was used but it's really hard to imagine what *wouldn't* be wrong. Maybe one might take comfort in the thought that using a composited character within the sort of Scratch script that uses key states is pretty close to unimaginable. Actually... checking... yes, impossible since the usable keys are a-z,0-9,yp,down,left,right,space. Maybe there is something in that which can drive a useful heuristic? > > Thanks so much for digging into this Dave. > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > A flash of light, a cloud of dust, and... What was the question? > > > From lewis at mail.msen.com Sun Jan 17 17:12:49 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 17 Jan 2021 12:12:49 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> Message-ID: <20210117171249.GA30336@shell.msen.com> On Sun, Jan 17, 2021 at 10:47:46AM +0100, Nicolas Cellier wrote: > IMO it's a mistake: we should always pass the keypress/release events as is > to the image, that's what raw events means to be. Composition shall alter > the keychar events only - that is some 1st level interpretation of the raw > events... > For my understanding - are you saying that it is better to pass the keypress and release events to the image in the same way as currently done in x2sqKeyPlain, while continuing to use the x2sqKeyInput logic for keychar interpretation? Dave From Yoshiki.Ohshima at acm.org Sun Jan 17 18:01:49 2021 From: Yoshiki.Ohshima at acm.org (Yoshiki Ohshima) Date: Sun, 17 Jan 2021 10:01:49 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210117163000.GA23156@shell.msen.com> References: <20210117163000.GA23156@shell.msen.com> Message-ID: Thanks everybody for looking into this and I admit that I added confusion. One thing, though, is that this round of digging in here was triggered by a report from a group of Japanese users who are making a custom hardware.... I’d like to make sure that the compositioninput case work. -- Yoshiki > On Jan 17, 2021, at 8:30 AM, David T. Lewis wrote: > > On Sat, Jan 16, 2021 at 10:15:22PM -0800, tim Rowledge wrote: >> >> >>>> On 2021-01-16, at 9:17 PM, David T. Lewis wrote: >>> >>> On Sat, Jan 16, 2021 at 04:03:45PM -0800, tim Rowledge wrote: >>>> >>>> >>>>> On 2021-01-16, at 3:33 PM, David T. Lewis wrote: >>>>> . The part I >>>>> can't figure out is how it could be working on any of the VMs. >>>> >>>> I can't see any case where it can work either but the code is so convoluted you need a native guide. The one thing I can see that might just possibly account for differences is the way that x2sqKey is a function pointer that can end up pointing to any of three routines depending upon assorted commandline options, environment variables and phase of a random selection of Jupiter's moons. >>>> >>> >>> Exactly right. Well it's not exactly a function of Jupiter's moons, but >>> pretty darn close. >>> >>> I've narrowed the issue down some more, and can offer at least a >>> workaround for Scratch. >>> >>> The reason that the key up events are being lost is that either the >>> LC_ALL or the LC_CTYPE environment variable is set. If you unset both of >>> these, the key up events will start working. >> >> That's interesting. I had tried manually specifying the x2sqKeyPlain by using `-nointl` but it looks like it gets over-ridden pretty quickly. I see that on my Pi >> ` >> echo $LC_ALL >> en_US.UTF-8 >> ` > > So we know that there is a problem in the X11 key handling in the VM > that is triggered if the environment variable LC_ALL is set. Scratch > is now encoountering this problem, whereas previously it had no problem. > > Most likely the thing that has changed is that the Linux environment > on Raspberry Pi (updated OS?) is now setting the LC_ALL variable to > support locale handling. Apparently Scratch worked fine without this, > so the workaround to avoid the problem would be to unset LC_ALL in > whatever script is being used to run Scratch. > > I don't have a Pi to check, but most likely there is a unix shell > script somewhere, such as /usr/bin/scratch, that runs the VM and brings > up the Scratch image. If so, then you can add "unset LC_ALL" to the > script, and I expect that Scratch will be happy again. > > Dave > > >> >> So it looks like the big difference is use of XmbLookupString vs XLookupString. Since as mentioned "We can't use XmbLookupString() since that is undefined for key release events." I guess maybe we might try using XLookupString for handling key release events ? It will potentially be wrong for times when a composited character was used but it's really hard to imagine what *wouldn't* be wrong. Maybe one might take comfort in the thought that using a composited character within the sort of Scratch script that uses key states is pretty close to unimaginable. Actually... checking... yes, impossible since the usable keys are a-z,0-9,yp,down,left,right,space. Maybe there is something in that which can drive a useful heuristic? >> >> Thanks so much for digging into this Dave. >> >> tim >> -- >> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim >> A flash of light, a cloud of dust, and... What was the question? >> >> >> > From lewis at mail.msen.com Sun Jan 17 18:36:36 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 17 Jan 2021 13:36:36 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210117163000.GA23156@shell.msen.com> Message-ID: <20210117183636.GA43696@shell.msen.com> On Sun, Jan 17, 2021 at 10:01:49AM -0800, Yoshiki Ohshima wrote: > Thanks everybody for looking into this and I admit that I added confusion. > > One thing, though, is that this round of digging in here was triggered by a report from a group of Japanese users who are making a custom hardware.... I???d like to make sure that the compositioninput case work. > Thanks Yoshiki, The suggestion that I made to Tim to unset LC_ALL and LC_CTYPE environment variables will not have any effect on composition input. However, when I run the VM with -compositioninput and test keystrokes using the 'f' and 'j' keys, this is what I see: [502 at 771 keyDown (102) 127659] [502 at 771 keystroke 'f' (102) 127659]f [502 at 771 keyDown (106) 127848] [502 at 771 keystroke 'j' (106) 127848]j [502 at 771 keyUp (106) 127969] [502 at 771 keyUp (0) 128233] It looks to me like key release event for the 'f' key is being delivered to the image, but it has keycode 0 instead of keycode 102. This does not look right to me, so I think that the issue with missing key release event would still be a problem for Japanese users. And it probably is an existing problem in any Scratch using composition input. In any case, if a fix for this can be found then we definitely need to make sure it works for Japanese users and the compositioninput case. Dave > > > -- Yoshiki > > > On Jan 17, 2021, at 8:30 AM, David T. Lewis wrote: > > > > ???On Sat, Jan 16, 2021 at 10:15:22PM -0800, tim Rowledge wrote: > >> > >> > >>>> On 2021-01-16, at 9:17 PM, David T. Lewis wrote: > >>> > >>> On Sat, Jan 16, 2021 at 04:03:45PM -0800, tim Rowledge wrote: > >>>> > >>>> > >>>>> On 2021-01-16, at 3:33 PM, David T. Lewis wrote: > >>>>> . The part I > >>>>> can't figure out is how it could be working on any of the VMs. > >>>> > >>>> I can't see any case where it can work either but the code is so convoluted you need a native guide. The one thing I can see that might just possibly account for differences is the way that x2sqKey is a function pointer that can end up pointing to any of three routines depending upon assorted commandline options, environment variables and phase of a random selection of Jupiter's moons. > >>>> > >>> > >>> Exactly right. Well it's not exactly a function of Jupiter's moons, but > >>> pretty darn close. > >>> > >>> I've narrowed the issue down some more, and can offer at least a > >>> workaround for Scratch. > >>> > >>> The reason that the key up events are being lost is that either the > >>> LC_ALL or the LC_CTYPE environment variable is set. If you unset both of > >>> these, the key up events will start working. > >> > >> That's interesting. I had tried manually specifying the x2sqKeyPlain by using `-nointl` but it looks like it gets over-ridden pretty quickly. I see that on my Pi > >> ` > >> echo $LC_ALL > >> en_US.UTF-8 > >> ` > > > > So we know that there is a problem in the X11 key handling in the VM > > that is triggered if the environment variable LC_ALL is set. Scratch > > is now encoountering this problem, whereas previously it had no problem. > > > > Most likely the thing that has changed is that the Linux environment > > on Raspberry Pi (updated OS?) is now setting the LC_ALL variable to > > support locale handling. Apparently Scratch worked fine without this, > > so the workaround to avoid the problem would be to unset LC_ALL in > > whatever script is being used to run Scratch. > > > > I don't have a Pi to check, but most likely there is a unix shell > > script somewhere, such as /usr/bin/scratch, that runs the VM and brings > > up the Scratch image. If so, then you can add "unset LC_ALL" to the > > script, and I expect that Scratch will be happy again. > > > > Dave > > > > > >> > >> So it looks like the big difference is use of XmbLookupString vs XLookupString. Since as mentioned "We can't use XmbLookupString() since that is undefined for key release events." I guess maybe we might try using XLookupString for handling key release events ? It will potentially be wrong for times when a composited character was used but it's really hard to imagine what *wouldn't* be wrong. Maybe one might take comfort in the thought that using a composited character within the sort of Scratch script that uses key states is pretty close to unimaginable. Actually... checking... yes, impossible since the usable keys are a-z,0-9,yp,down,left,right,space. Maybe there is something in that which can drive a useful heuristic? > >> > >> Thanks so much for digging into this Dave. > >> > >> tim > >> -- > >> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > >> A flash of light, a cloud of dust, and... What was the question? > >> > >> > >> > > > From tim at rowledge.org Sun Jan 17 19:02:32 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 17 Jan 2021 11:02:32 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210117183636.GA43696@shell.msen.com> References: <20210117163000.GA23156@shell.msen.com> <20210117183636.GA43696@shell.msen.com> Message-ID: <5EA0138A-B2B8-44F1-A31E-27557BD9734C@rowledge.org> > On 2021-01-17, at 10:36 AM, David T. Lewis wrote: > > However, when I run the VM with -compositioninput and test keystrokes using > the 'f' and 'j' keys, this is what I see: > > > [502 at 771 keyDown (102) 127659] > [502 at 771 keystroke 'f' (102) 127659]f > [502 at 771 keyDown (106) 127848] > [502 at 771 keystroke 'j' (106) 127848]j > [502 at 771 keyUp (106) 127969] > [502 at 771 keyUp (0) 128233] > > It looks to me like key release event for the 'f' key is being delivered > to the image, but it has keycode 0 instead of keycode 102. I'll guess for now that it is a side effect of the prior mentioned XmbLookupString vs XLookupString issue. A question we've not yet asked but that likely has some important bearing on this is just how do the composition input UI widgets and so on actually work? The only system I'm currently aware of is the relatively simple ctl-e-e to get an "é" on my iMac. I'm sure there are much more sophisticated options out there for languages using the huge range of glyphs for Chinese and Japanese etc. I suppose in some ways it's not very relevant to the Scratch usage issue because nobody is going to want to do a complex multi-gesture action instead of one of the cursor keys as part of a twitch game! Though a twitch training game to learn the actions as part of a language teaching system... tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful random insult:- A .22 caliber intellect in a .357 Magnum world. From tim at rowledge.org Sun Jan 17 19:07:52 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 17 Jan 2021 11:07:52 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210114015103.GA57336@shell.msen.com> <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> Message-ID: > On 2021-01-17, at 1:47 AM, Nicolas Cellier wrote: > > IMO it's a mistake: we should always pass the keypress/release events as is to the image, that's what raw events means to be. Composition shall alter the keychar events only - that is some 1st level interpretation of the raw events... I have much sympathy with this idea and some past experience with using it. The good part is that you get the raw input and can do whatever you want with it; the bad part is that you get the raw input and *have* to do something with it! That can cost so much effort that you just fail to provide the user with what is needed. In this case it would be converting the raw key code to characters with a map; but we'd have to work out how to build the map for each platform, for each variety of keyboard (Aaargh! Dvorak user approaching! Run away!) and each language. I don't think I'll live long enough to be able to implement that. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: JSP: Jump on Sexy Programmer From tim at rowledge.org Sun Jan 17 19:10:34 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 17 Jan 2021 11:10:34 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210117163000.GA23156@shell.msen.com> References: <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> Message-ID: <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> > On 2021-01-17, at 8:30 AM, David T. Lewis wrote: > > I don't have a Pi to check, but most likely there is a unix shell > script somewhere, such as /usr/bin/scratch, that runs the VM and brings > up the Scratch image. If so, then you can add "unset LC_ALL" to the > script, and I expect that Scratch will be happy again. I suspect that some of the 'enhanced initial setup' tools that have been added may well cause the setting of the local stuff. The problem I see with unsetting LC_ALL is that it would likely break the handling of any non-english systems. Which would definitely be an issue. Good experiment to try though. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful random insult:- If his IQ was two points higher he'd be a rock. From tim at rowledge.org Sun Jan 17 19:56:56 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 17 Jan 2021 11:56:56 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> References: <20210114210952.GA59050@shell.msen.com> <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> Message-ID: <939EE863-F536-4FE6-A490-0DC4E82BF526@rowledge.org> > On 2021-01-17, at 11:10 AM, tim Rowledge wrote: > > Good experiment to try though. It certainly allows the basic keystrokes to work and even ctl-e-e . That latter actually surprises me given the description of what XLookupString does, but life in X is always surprising - oh, wait, there's a bunch of code in case KeyPress: that handles some cases. The log for a ctl-e-e is (handleEvent)X KeyPress state 0x0 raw keycode 92 convert keycode 92(5c) -> 0(00) (keysym fe03 UNKNOWN CODE) symbolic, keyCode, ucs4: fe03, -1, 0 pressed, buffer: 0, 0 multi_key reset keyCode, ucs4, multi_key_buffer: -1, 0, 0 (handleEvent)X KeyRelease state 0x80 raw keycode 92 convert keycode 92(5c) -> 0(00) (keysym fe03 UNKNOWN CODE) symbolic, keyCode, ucs4: fe03, -1, 0 Skip KeyRelease at keyCode/ucs4 test line 3764 (handleEvent)X KeyPress state 0x0 raw keycode 252 convert keycode [195(c3),169(a9)] 252(fc) -> 195(c3) (keysym 00e9 XK_eacute) symbolic, keyCode, ucs4: e9, 195, e9 pressed, buffer: 0, 0 multi_key reset keyCode, ucs4, multi_key_buffer: 195, 233, 0 signalInputEvent EVENT (recordKeyboardEvent): time: 1565590 key down ` ' (195 = 0xc3) ucs4 233 signalInputEvent EVENT (recordKeyboardEvent): time: 1565590 key char ` ' (195 = 0xc3) ucs4 233 (ioGetNextEvent) KEYBOARD evt: time: 1565590 press: 1 char: 195 utf32: 233 (ioGetNextEvent) KEYBOARD evt: time: 1565590 press: 0 char: 195 utf32: 233 (handleEvent)X KeyRelease state 0x0 raw keycode 252 convert keycode [195(c3),169(a9)] 252(fc) -> 195(c3) (keysym 00e9 XK_eacute) symbolic, keyCode, ucs4: e9, 195, e9 signalInputEvent EVENT (recordKeyboardEvent): time: 1565687 key up ` ' (195 = 0xc3) ucs4 233 (ioGetNextEvent) KEYBOARD evt: time: 1565687 press: 2 char: 195 utf32: 233 Looks like the 'multi_key_buffer' stuff is what the 'lastKey' bit was modelled on? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim A computer scientist is someone who fixes things that aren't broken. From lewis at mail.msen.com Sun Jan 17 20:06:42 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 17 Jan 2021 15:06:42 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> References: <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> Message-ID: <20210117200642.GA55886@shell.msen.com> On Sun, Jan 17, 2021 at 11:10:34AM -0800, tim Rowledge wrote: > > > > On 2021-01-17, at 8:30 AM, David T. Lewis wrote: > > > > I don't have a Pi to check, but most likely there is a unix shell > > script somewhere, such as /usr/bin/scratch, that runs the VM and brings > > up the Scratch image. If so, then you can add "unset LC_ALL" to the > > script, and I expect that Scratch will be happy again. > > I suspect that some of the 'enhanced initial setup' tools that have been > added may well cause the setting of the local stuff. Yes that's probably what happened. On my somewhat old Ununtu system, LC_ALL is not set. But I can certainly see how people might decide that the locale information should always be set to *something* and that is probably what has been done on your newer Raspberry Pi system. > The problem I see with unsetting LC_ALL is that it would likely break the > handling of any non-english systems. Which would definitely be an issue. > If you can put it into a shell script that runs Scratch, then it will only affect Scratch itself. Within Scratch it might be an issue for keyboard input to Scratch. Maybe we can find a non-English Scratch users to check that out. For Japanese Scratch users, the LC_ALL setting should not have any effect because compositioninput is being used. Dave From herbertkoenig at gmx.net Sun Jan 17 21:40:36 2021 From: herbertkoenig at gmx.net (=?UTF-8?Q?Herbert_K=c3=b6nig?=) Date: Sun, 17 Jan 2021 22:40:36 +0100 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210117200642.GA55886@shell.msen.com> References: <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> Message-ID: <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> If it's Scratch on a Raspi I can do for German. -Where to find the script to add the LC_all? -What to do / load? Will be tomorrow around this time when I get to it. Cheers, Herbert Am 17.01.2021 um 21:06 schrieb David T. Lewis: > On Sun, Jan 17, 2021 at 11:10:34AM -0800, tim Rowledge wrote: >> >>> On 2021-01-17, at 8:30 AM, David T. Lewis wrote: >>> >>> I don't have a Pi to check, but most likely there is a unix shell >>> script somewhere, such as /usr/bin/scratch, that runs the VM and brings >>> up the Scratch image. If so, then you can add "unset LC_ALL" to the >>> script, and I expect that Scratch will be happy again. >> I suspect that some of the 'enhanced initial setup' tools that have been >> added may well cause the setting of the local stuff. > Yes that's probably what happened. On my somewhat old Ununtu system, > LC_ALL is not set. But I can certainly see how people might decide > that the locale information should always be set to *something* and > that is probably what has been done on your newer Raspberry Pi system. > >> The problem I see with unsetting LC_ALL is that it would likely break the >> handling of any non-english systems. Which would definitely be an issue. >> > If you can put it into a shell script that runs Scratch, then it > will only affect Scratch itself. Within Scratch it might be an > issue for keyboard input to Scratch. Maybe we can find a non-English > Scratch users to check that out. For Japanese Scratch users, the > LC_ALL setting should not have any effect because compositioninput > is being used. > > Dave > > From tim at rowledge.org Sun Jan 17 22:23:13 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 17 Jan 2021 14:23:13 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> References: <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> Message-ID: <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> > On 2021-01-17, at 1:40 PM, Herbert König wrote: > > If it's Scratch on a Raspi I can do for German. Ah, excellent. > -Where to find the script to add the LC_all? > -What to do / load? The easiest thing to do on a Pi is probably sudo nano /usr/bin/scratch just before the line "$WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS" add unset $LC_ALL ctl-o y ctl-x That should result in LC_ALL being undefined for the child process that actually runs scratch. I think. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Fac ut vivas. = Get a life. From lewis at mail.msen.com Sun Jan 17 23:12:05 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 17 Jan 2021 18:12:05 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> References: <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> Message-ID: <20210117231205.GA83431@shell.msen.com> On Sun, Jan 17, 2021 at 02:23:13PM -0800, tim Rowledge wrote: > > > > On 2021-01-17, at 1:40 PM, Herbert K??nig wrote: > > > > If it's Scratch on a Raspi I can do for German. > > Ah, excellent. > > > -Where to find the script to add the LC_all? > > -What to do / load? > > The easiest thing to do on a Pi is probably > > sudo nano /usr/bin/scratch > just before the line "$WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS" > add > unset $LC_ALL > ctl-o > y > ctl-x > > That should result in LC_ALL being undefined for the child process that actually runs scratch. I think. > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Useful Latin Phrases:- Fac ut vivas. = Get a life. > > > Take out the dollar sign before LC_AL, so instead of this: unset $LC_ALL Do this: unset LC_ALL Tim, can you post a copy of the /usr/bin/scratch script so I can have a look at it? Thanks, Dave From tim at rowledge.org Sun Jan 17 23:23:07 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 17 Jan 2021 15:23:07 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210117231205.GA83431@shell.msen.com> References: <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> Message-ID: <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> > On 2021-01-17, at 3:12 PM, David T. Lewis wrote: > > Take out the dollar sign before LC_AL, so instead of this: > > unset $LC_ALL > > Do this: > > unset LC_ALL Whoops. > > Tim, can you post a copy of the /usr/bin/scratch script so I can have a look at it? Sure - -------------- next part -------------- A non-text attachment was scrubbed... Name: scratch Type: application/octet-stream Size: 3083 bytes Desc: not available URL: -------------- next part -------------- tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SEOB: Set Every Other Bit From tim at rowledge.org Sun Jan 17 23:58:00 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 17 Jan 2021 15:58:00 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> References: <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> Message-ID: <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> I *might* have a sensible solution that will work with LC_ALL defined. The problem has been that in x2sqKeyInput we use XmbLookupString which cannot work with a key release. In x2sqKeyPlain we use XLookupString which *does* work with a key release. So my suggestion is to make use of x2sqKeyPlain within the x2sqKeyInput (and probably the x2sqKeyCompositionInput too?) key release. It seems to work ok in a shell where echo $LC_ALL en_US.UTF-8 and the logging shows me that we are going through that route. Attached the C file for comparison; note no change has been made to the x2sqKeyCompositionInput routine yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: sqUnixX11.c Type: application/octet-stream Size: 232418 bytes Desc: not available URL: -------------- next part -------------- Does this seem a reasonable thing to do? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Common sense – so rare it’s a goddam superpower From herbertkoenig at gmx.net Mon Jan 18 08:23:08 2021 From: herbertkoenig at gmx.net (Herbert) Date: Mon, 18 Jan 2021 09:23:08 +0100 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> References: <20210115222029.GA10532@shell.msen.com> <27842B16-0DDA-4DFD-B39E-BE9BE52C14DB@rowledge.org> <9873435A-7DDF-4EE5-BFA5-2FE65056A77E@rowledge.org> <78ED62C7-BCDA-4980-BEA6-53F047F69BBA@rowledge.org> <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> Message-ID: <8a28b429-82cc-4f71-eb12-13e52acf2e11@gmx.net> Early bird today. With the '$' the script doesn't start, without it starts. I'm not sure what to do but in both cases Say 'ÄÖÜßöäü' (<-- When typing those were German Umlauts) works and displys correctly. No sound though. The script still uses ALSA sound. Not sure what I shall try but can do that after work, maybe even read the whole thread ;-). Cheers, Herbert Am 17.01.21 um 23:23 schrieb tim Rowledge: > >> On 2021-01-17, at 1:40 PM, Herbert König wrote: >> >> If it's Scratch on a Raspi I can do for German. > Ah, excellent. > >> -Where to find the script to add the LC_all? >> -What to do / load? > The easiest thing to do on a Pi is probably > > sudo nano /usr/bin/scratch > just before the line "$WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS" > add > unset $LC_ALL > ctl-o > y > ctl-x > > That should result in LC_ALL being undefined for the child process that actually runs scratch. I think. > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Useful Latin Phrases:- Fac ut vivas. = Get a life. > > > From commits at source.squeak.org Mon Jan 18 11:55:42 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 18 Jan 2021 11:55:42 0000 Subject: [squeak-dev] The Inbox: Tests-ct.447.mcz Message-ID: Christoph Thiede uploaded a new version of Tests to project The Inbox: http://source.squeak.org/inbox/Tests-ct.447.mcz ==================== Summary ==================== Name: Tests-ct.447 Author: ct Time: 18 January 2021, 12:55:37.357232 pm UUID: 675252a4-a6d9-d442-b594-3c85592290a4 Ancestors: Tests-dtl.443 Fixes and supplements BecomeTest. - Updated #testBecomeForwardIdentityHash which has been broken since Collections-eem.885. Note that the referenced patch to #becomeForward: was a breaking change which we should make sure to document in the final release notes. - Added #testBecomeForwardIdentityAndHash to have a test for the classical primitiveArrayBecomeOneWay (primitive 72) again. - Added #testBecomeForwardCopyIdentityHash to test both bindings of the copyHash argument indeed. Please review! Fur further reference, see https://github.com/codefrau/SqueakJS/pull/117 where we were discussing the limitations/correctness of the current BecomeTest implementation. =============== Diff against Tests-dtl.443 =============== Item was added: + ----- Method: BecomeTest>>testBecomeForwardCopyIdentityHash (in category 'tests') ----- + testBecomeForwardCopyIdentityHash + "Check that + 1. the argument to becomeForward: is modified to have the receiver's identity hash. + 2. the receiver's identity hash is unchanged." + + | a b ha hb | + a := 'ab' copy. + b := 'cd' copy. + ha := a identityHash. + hb := b identityHash. + + a becomeForward: b copyHash: true. + + self + assert: ha equals: a identityHash; + assert: ha equals: b identityHash.! Item was added: + ----- Method: BecomeTest>>testBecomeForwardIdentityAndHash (in category 'tests') ----- + testBecomeForwardIdentityAndHash + "Check that + 1. the argument to becomeForward: is NOT modified to have the receiver's identity hash. + 2. the receiver's identity hash is unchanged." + + | a b ha | + a := 'ab' copy. + b := 'cd' copy. + ha := a identityHash. + + {a} elementsForwardIdentityAndHashTo: {b}. + + self + assert: ha equals: a identityHash; + assert: ha equals: b identityHash.! Item was changed: ----- Method: BecomeTest>>testBecomeForwardIdentityHash (in category 'tests') ----- testBecomeForwardIdentityHash "Check that + 1. the argument to becomeForward: is NOT modified to have the receiver's identity hash. - 1. the argument to becomeForward: is modified to have the receiver's identity hash. 2. the receiver's identity hash is unchanged." + | a b hb | - | a b ha | - a := 'ab' copy. b := 'cd' copy. + hb := b identityHash. + - ha := a identityHash. - a becomeForward: b. + - self + assert: a identityHash = hb; + assert: b identityHash = hb.! - assert: a identityHash = ha; - assert: b identityHash = ha. - - ! From jr at amanue.com Mon Jan 18 12:07:25 2021 From: jr at amanue.com (Jim Rosenberg) Date: Mon, 18 Jan 2021 07:07:25 -0500 Subject: [squeak-dev] Cannot read 4.3 image on Raspberry Pi Message-ID: <30761BA6E24B38D160E49291@chorder> Ouch! I have a lot of artistic work which is developed in Squeak on Linux -- currently only up to 4.3 (which is working fine for me, so I haven't upgraded). I'm trying to run one of my 4.3 images on a Raspberry Pi 3B+ which is at Raspbian 10 (buster), and with the current armv6 squeak VM, getting the message This interpreter (vers. 6521) cannot read image file (vers. 6504). Suggestions? -Thanks in advance, Jim From lewis at mail.msen.com Mon Jan 18 14:15:46 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 18 Jan 2021 09:15:46 -0500 Subject: [squeak-dev] Cannot read 4.3 image on Raspberry Pi In-Reply-To: <30761BA6E24B38D160E49291@chorder> References: <30761BA6E24B38D160E49291@chorder> Message-ID: <20210118141546.GA31888@shell.msen.com> On Mon, Jan 18, 2021 at 07:07:25AM -0500, Jim Rosenberg wrote: > Ouch! I have a lot of artistic work which is developed in Squeak on Linux > -- currently only up to 4.3 (which is working fine for me, so I haven't > upgraded). I'm trying to run one of my 4.3 images on a Raspberry Pi 3B+ > which is at Raspbian 10 (buster), and with the current armv6 squeak VM, > getting the message > > This interpreter (vers. 6521) cannot read image file (vers. 6504). > > Suggestions? > > -Thanks in advance, Jim > You will need to use a "classic" VM to run this image, because the newer VMs in use today are not able to run a Squeak 4.3 image. You can find a precompiled VM for ARM v61 at http://squeakvm.org/unix/ which may work, although it is out of date so I am not sure if it will run on your Pi. If you do not mind installing development tools on your Raspberry Pi, then the best thing to do is compile the VM yourself. Instructions for doing this are at http://wiki.squeak.org/squeak/6354 If you have any difficulty building your VM, please ask for help. And if it works without problems, please report back so we know. Thanks, Dave From lewis at mail.msen.com Mon Jan 18 14:29:24 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 18 Jan 2021 09:29:24 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> References: <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> Message-ID: <20210118142924.GA34853@shell.msen.com> On Sun, Jan 17, 2021 at 03:58:00PM -0800, tim Rowledge wrote: > I *might* have a sensible solution that will work with LC_ALL defined. > > The problem has been that in x2sqKeyInput we use XmbLookupString which cannot work with a key release. In x2sqKeyPlain we use XLookupString which *does* work with a key release. > > So my suggestion is to make use of x2sqKeyPlain within the x2sqKeyInput (and probably the x2sqKeyCompositionInput too?) key release. It seems to work ok in a shell where > > echo $LC_ALL > en_US.UTF-8 > > and the logging shows me that we are going through that route. > > Attached the C file for comparison; note no change has been made to the x2sqKeyCompositionInput routine yet. > > > Does this seem a reasonable thing to do? > I fear that it will not work for actual multibyte input though? Key press events would be using the multibyte XmbLookupString routine and key release events would use single byte XLookupString. I have no expertise in this area but it does not sound right. Dave From lewis at mail.msen.com Mon Jan 18 17:01:05 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 18 Jan 2021 12:01:05 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <8a28b429-82cc-4f71-eb12-13e52acf2e11@gmx.net> References: <20210116233314.GA53746@shell.msen.com> <93035A9F-F986-4B32-A3F7-04A508AC716D@rowledge.org> <20210117051739.GA16486@shell.msen.com> <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <8a28b429-82cc-4f71-eb12-13e52acf2e11@gmx.net> Message-ID: <20210118170105.GA57153@shell.msen.com> Hi Herbert, Thanks for testing this Tim can give a better idea of what to test for Scratch, but I think the basic idea is to just make sure that nothing seems broken for keyboard text entry after making the change. If you are able to enter German Umlouts that sounds like a good thing :-) Also the "missing key up" problem should be resolved. Earlier in this thread Marcel explained how to display the key events in Transcript, and I have been following his recommendation for that. Dave On Mon, Jan 18, 2021 at 09:23:08AM +0100, Herbert wrote: > Early bird today. > > With the '$' the script doesn't start, without it starts. > I'm not sure what to do but in both cases Say '??????????????' (<-- When > typing > those were German Umlauts) works and displys correctly. > No sound though. > The script still uses ALSA sound. > > Not sure what I shall try but can do that after work, maybe even read > the whole thread ;-). > > Cheers, > > Herbert > > Am 17.01.21 um 23:23 schrieb tim Rowledge: > > > >>On 2021-01-17, at 1:40 PM, Herbert K??nig wrote: > >> > >>If it's Scratch on a Raspi I can do for German. > >Ah, excellent. > > > >>-Where to find the script to add the LC_all? > >>-What to do / load? > >The easiest thing to do on a Pi is probably > > > >sudo nano /usr/bin/scratch > >just before the line "$WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" > >$IMOPTIONS" > >add > >unset $LC_ALL > >ctl-o > >y > >ctl-x > > > >That should result in LC_ALL being undefined for the child process that > >actually runs scratch. I think. > > > >tim > >-- > >tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > >Useful Latin Phrases:- Fac ut vivas. = Get a life. > > > > > > > From lewis at mail.msen.com Mon Jan 18 18:40:11 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 18 Jan 2021 13:40:11 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210118142924.GA34853@shell.msen.com> References: <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> <20210118142924.GA34853@shell.msen.com> Message-ID: <20210118184011.GA70239@shell.msen.com> Moving to vm-dev list for follow ups on the VM. Please keep the Scratch related part of the discussion going here on squeak-dev. On Mon, Jan 18, 2021 at 09:29:24AM -0500, David T. Lewis wrote: > On Sun, Jan 17, 2021 at 03:58:00PM -0800, tim Rowledge wrote: > > I *might* have a sensible solution that will work with LC_ALL defined. > > > > The problem has been that in x2sqKeyInput we use XmbLookupString which cannot work with a key release. In x2sqKeyPlain we use XLookupString which *does* work with a key release. > > > > So my suggestion is to make use of x2sqKeyPlain within the x2sqKeyInput (and probably the x2sqKeyCompositionInput too?) key release. It seems to work ok in a shell where > > > > echo $LC_ALL > > en_US.UTF-8 > > > > and the logging shows me that we are going through that route. > > > > Attached the C file for comparison; note no change has been made to the x2sqKeyCompositionInput routine yet. > > > > > > Does this seem a reasonable thing to do? > > > > I fear that it will not work for actual multibyte input though? > > Key press events would be using the multibyte XmbLookupString > routine and key release events would use single byte XLookupString. > I have no expertise in this area but it does not sound right. > I think I found a clean way to handle the missing key up event problem. I have it working in the interpreter VM now and I'll do a pull request for opensmalltalk-vm either today or tomorrow. The commit notice will look like this: Fix missing KeyRelease events when multiple keys are depressed. Reference Mantis 0007597 http://bugs.squeak.org/view.php?id=7597. Rather than keep a single lastKey to remember the last previously pressed pressed key value, maintain an array size 256 of last key pressed values indexed by X11 KeyCode. Works for any number of simultaneous keys. It will work for Japanese keyboard with composition input also. Dave From tim at rowledge.org Mon Jan 18 19:09:18 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 18 Jan 2021 11:09:18 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210118184011.GA70239@shell.msen.com> References: <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> <20210118142924.GA34853@shell.msen.com> <20210118184011.GA70239@shell.msen.com> Message-ID: <660E7773-057A-4304-A238-9C09A6B90263@rowledge.org> > On 2021-01-18, at 10:40 AM, David T. Lewis wrote: > > I think I found a clean way to handle the missing key up event problem. > I have it working in the interpreter VM now and I'll do a pull > request for opensmalltalk-vm either today or tomorrow. I was thinking of a similar approach at the end of last week too; if one records the ingoing charcode for a keycode then you can return it once again on a release. I got stuck trying to remember enough C to write what would be trivial in Smalltalk... I think one of the 'interesting' problems is having a good heuristic for what happens with multiple-key cases. Say you have some input that requires ctl-e-e-opt-s or some similarly convoluted gesture. That gets you a single character input event. When do you provide the release event for that single character? Is there even a real meaning to holding down that final 'opt-s' - and what if the opt is released before the s? Do the composited characters do repeats if the opt-s is held down? My brain will likely never fully recover from this assault. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Computer Science: solving today's problems tomorrow. From nicolas.cellier.aka.nice at gmail.com Mon Jan 18 20:08:34 2021 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Mon, 18 Jan 2021 21:08:34 +0100 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <660E7773-057A-4304-A238-9C09A6B90263@rowledge.org> References: <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> <20210118142924.GA34853@shell.msen.com> <20210118184011.GA70239@shell.msen.com> <660E7773-057A-4304-A238-9C09A6B90263@rowledge.org> Message-ID: Le lun. 18 janv. 2021 à 20:09, tim Rowledge a écrit : > > > > > On 2021-01-18, at 10:40 AM, David T. Lewis wrote: > > > > I think I found a clean way to handle the missing key up event problem. > > I have it working in the interpreter VM now and I'll do a pull > > request for opensmalltalk-vm either today or tomorrow. > > I was thinking of a similar approach at the end of last week too; if one records the ingoing charcode for a keycode then you can return it once again on a release. I got stuck trying to remember enough C to write what would be trivial in Smalltalk... > > I think one of the 'interesting' problems is having a good heuristic for what happens with multiple-key cases. Say you have some input that requires ctl-e-e-opt-s or some similarly convoluted gesture. That gets you a single character input event. When do you provide the release event for that single character? Is there even a real meaning to holding down that final 'opt-s' - and what if the opt is released before the s? Do the composited characters do repeats if the opt-s is held down? > > My brain will likely never fully recover from this assault. > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Computer Science: solving today's problems tomorrow. > > My understanding is that we want to achieve a perfect order, whenever buffered keys x & y do not compose: KeyPress x KeyChar x KeyPress y KeyChar y KeyRelease x KeyRelease y rather than: KeyPress x KeyPress y KeyChar x KeyChar y KeyRelease x KeyRelease y Is that it? If we would accept second form, code would be much simpler. From javier_diaz_r at mac.com Mon Jan 18 21:28:33 2021 From: javier_diaz_r at mac.com (Javier Diaz-Reinoso) Date: Mon, 18 Jan 2021 16:28:33 -0500 Subject: [squeak-dev] Problems with table layout in 5.x Message-ID: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> After finish all the features for version 1.0.0 in my port of Pronterface in squeak 4.5: > https://sourceforge.net/p/sqpronterface/mercurial/ I am trying to test in squeak 5.3 but I encounter problems with BobsUI who is the framework I am using. BobsUI use a lot of nested UIAlignmentMorphs and the layout of that is mostly OK, but the problem appears in a UIGroupBoxMorph, in this morph the top submorph are only two: a label (UIStringMorph) and a container (UIMorph) who have the submorphs of the widgets of the group, this image show the problem between squeak 4.5 and 5.3, this is using the basic example of BobsUi called ExampleRolodex: Tracing the execution of the creation of the morphs I find the problem in Morph>>adjustLayoutBounds reverting the version "mt 8/22/2019" to "ar 11/12/2000" restore the view (mostly) to the version 5.2. From the tracing I see changes in the order of the selectors who are used to evaluate the size of the tree of submorphs; appears to be that the old version (4.5) always wait to obtain the size of the "leaves" of the tree of submorphs before updating the top submorphs, I think the actual version fix some sizes prematurely. This is also apparent in other problem who is present in 5.2 and 5.3 but not in 4.5, 5.1, this image show the top of the UIWindowMorph (4.5 and 5.2): appears the title (UITitleBarMorph) size is fixed before the (last) UIGroupBoxMorph of the window is evaluated. Also in 5.3 (not in 5.2 and before) there is a lot of extra space around the widgets, the UIWindowMorph size are: 4.5 429 × 337 pixels 5,1 438 × 363 pixels, appears to be a change of fonts in the system 5.2 428 × 333 pixels 5.3 500 × 479 pixels this is worse in the title of 5.3 because the extra space move te title down the proper position: Finally I find the bounds and fullBound of the submorphs in 5.x are absolute where in 4.5 was relative to the window, in my probable naive opinion, I think is a lot of updates when a window move versus a single update to the top morph, for example ExampleRolodex have 77 submorphs, sqPronterface have 158. For reproducing the results, you can copy BobsUI/BobsUI-jdr.7.mcz (177KB) from the repository and create the window with: ExampleRolodex open beware that BobsUI, intentionally, suppress the halos, so you need to use Crtl-click or equivalent to inspect it, delete, .... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 16.33.58.png Type: image/png Size: 44548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 16.55.45.png Type: image/png Size: 57146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 17.59.38.png Type: image/png Size: 24971 bytes Desc: not available URL: From tim at rowledge.org Mon Jan 18 22:59:37 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 18 Jan 2021 14:59:37 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> <20210118142924.GA34853@shell.msen.com> <20210118184011.GA70239@shell.msen.com> <660E7773-057A-4304-A238-9C09A6B90263@rowledge.org> Message-ID: <965EEE9B-533B-45F7-96A3-ABAF559F4DD3@rowledge.org> > On 2021-01-18, at 12:08 PM, Nicolas Cellier wrote: > > My understanding is that we want to achieve a perfect order, whenever > buffered keys x & y do not compose: > KeyPress x > KeyChar x > KeyPress y > KeyChar y > KeyRelease x > KeyRelease y > > rather than: > KeyPress x > KeyPress y > KeyChar x > KeyChar y > KeyRelease x > KeyRelease y > > Is that it? > If we would accept second form, code would be much simpler. > > Honestly, I don't know how to even decide if one way is more meaningful than the other for this case. For the very narrow purposes of my work on updating/correcting NuScratch the key (hah!) is to make sure that tracking the state of the simple alphanumeric + cursor keys is accurate and timely. It will help with any sort of game/keyboard-music application too. As soon as we consider any of the multiple-gesture characters like é or composited ones like (I imagine this delightful 'man disco dancing' from the Mongolian alphabet is) ᡲ then what to do becomes... complicated. I'd say the important thing is to make sure that at least everything is balanced so that after all the keys are pressed, held, and released, anyone using a KeyboardListener will see no keys being still down. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SG: Show Garbage From lewis at mail.msen.com Mon Jan 18 23:00:49 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 18 Jan 2021 18:00:49 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210118184011.GA70239@shell.msen.com> References: <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> <20210118142924.GA34853@shell.msen.com> <20210118184011.GA70239@shell.msen.com> Message-ID: <20210118230049.GA8248@shell.msen.com> On Mon, Jan 18, 2021 at 01:40:11PM -0500, David T. Lewis wrote: > Moving to vm-dev list for follow ups on the VM. Please keep the > Scratch related part of the discussion going here on squeak-dev. > > On Mon, Jan 18, 2021 at 09:29:24AM -0500, David T. Lewis wrote: > > On Sun, Jan 17, 2021 at 03:58:00PM -0800, tim Rowledge wrote: > > > I *might* have a sensible solution that will work with LC_ALL defined. > > > > > > The problem has been that in x2sqKeyInput we use XmbLookupString which cannot work with a key release. In x2sqKeyPlain we use XLookupString which *does* work with a key release. > > > > > > So my suggestion is to make use of x2sqKeyPlain within the x2sqKeyInput (and probably the x2sqKeyCompositionInput too?) key release. It seems to work ok in a shell where > > > > > > echo $LC_ALL > > > en_US.UTF-8 > > > > > > and the logging shows me that we are going through that route. > > > > > > Attached the C file for comparison; note no change has been made to the x2sqKeyCompositionInput routine yet. > > > > > > > > > Does this seem a reasonable thing to do? > > > > > > > I fear that it will not work for actual multibyte input though? > > > > Key press events would be using the multibyte XmbLookupString > > routine and key release events would use single byte XLookupString. > > I have no expertise in this area but it does not sound right. > > > > I think I found a clean way to handle the missing key up event problem. > I have it working in the interpreter VM now and I'll do a pull > request for opensmalltalk-vm either today or tomorrow. The commit > notice will look like this: > > Fix missing KeyRelease events when multiple keys are depressed. > Reference Mantis 0007597 http://bugs.squeak.org/view.php?id=7597. > Rather than keep a single lastKey to remember the last previously pressed > pressed key value, maintain an array size 256 of last key pressed values > indexed by X11 KeyCode. Works for any number of simultaneous keys. > > It will work for Japanese keyboard with composition input also. > > Dave > Pull request for the fix is https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/547 I also pushed an update to SVN on squeakvm.org for interpreter VM. Dave From tim at rowledge.org Mon Jan 18 23:10:45 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 18 Jan 2021 15:10:45 -0800 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: <20210118230049.GA8248@shell.msen.com> References: <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> <20210118142924.GA34853@shell.msen.com> <20210118184011.GA70239@shell.msen.com> <20210118230049.GA8248@shell.msen.com> Message-ID: Looks sensible to me; the only question I have is whether it is actually guaranteed that no keycode can exceed 255? All I can find out right now is that the structure definition has it as an int. > > Pull request for the fix is https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/547 > > I also pushed an update to SVN on squeakvm.org for interpreter VM. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hipatitis (n): Terminal coolness From tim at rowledge.org Mon Jan 18 23:34:12 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 18 Jan 2021 15:34:12 -0800 Subject: [squeak-dev] Cannot read 4.3 image on Raspberry Pi In-Reply-To: <20210118141546.GA31888@shell.msen.com> References: <30761BA6E24B38D160E49291@chorder> <20210118141546.GA31888@shell.msen.com> Message-ID: <57906F77-670E-4947-B50F-AC1B3AF03D47@rowledge.org> Hmph. In the hope of being helpful here I fired off a quick compile of a stack/v3 VM on my Pi (that image is non-spur, and we never did a v3/cog VM because it requires a set of specific instructions to occupy a number of bytes that is a prime number and smells of purple locknuts) BUT it won't actually build. HOWEVER - you already have a decently suitable squeakvm installed on your Pi, left over from waaaay back when we weren't 100% sure of the newer Scratch system. So, in a terminal, try squeak.old my.image & and see if it works. On my Pi4 it starts up a vanilla 4.3 image straight away. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim "Bother" said Piglet, as Pooh smeared him in honey. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-18 at 3.33.16 PM.png Type: image/png Size: 89291 bytes Desc: not available URL: From nicolas.cellier.aka.nice at gmail.com Mon Jan 18 23:34:41 2021 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Tue, 19 Jan 2021 00:34:41 +0100 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210117163000.GA23156@shell.msen.com> <0525D3D7-5076-4983-8FD9-CDC1BF73AA4C@rowledge.org> <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> <20210118142924.GA34853@shell.msen.com> <20210118184011.GA70239@shell.msen.com> <20210118230049.GA8248@shell.msen.com> Message-ID: I would think we can do much simpler if we abandon the idea of ordering events. Deliver the raw event (Pess and release) ASAP. All we need is a translation of raw scan code to a platform independent keycode. For the cooked event (EventKeyChar), just do not change anything. What do you think? Le mar. 19 janv. 2021 à 00:10, tim Rowledge a écrit : > > Looks sensible to me; the only question I have is whether it is actually guaranteed that no keycode can exceed 255? All I can find out right now is that the structure definition has it as an int. > > > > > Pull request for the fix is https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/547 > > > > I also pushed an update to SVN on squeakvm.org for interpreter VM. > > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Hipatitis (n): Terminal coolness > > > From nicolas.cellier.aka.nice at gmail.com Mon Jan 18 23:51:54 2021 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Tue, 19 Jan 2021 00:51:54 +0100 Subject: [squeak-dev] Cannot read 4.3 image on Raspberry Pi In-Reply-To: <57906F77-670E-4947-B50F-AC1B3AF03D47@rowledge.org> References: <30761BA6E24B38D160E49291@chorder> <20210118141546.GA31888@shell.msen.com> <57906F77-670E-4947-B50F-AC1B3AF03D47@rowledge.org> Message-ID: Hi Tim, Looking at recent build https://travis-ci.com/github/OpenSmalltalk/opensmalltalk-vm/builds/213372081 the ARMV6 squeak.stack.v3 build passed https://travis-ci.com/github/OpenSmalltalk/opensmalltalk-vm/jobs/472299216 So it should be possible to build... Does the latest bintray work? https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.stack.v3_linux32ARMv6_202101160259.tar.gz Le mar. 19 janv. 2021 à 00:34, tim Rowledge a écrit : > Hmph. In the hope of being helpful here I fired off a quick compile of a > stack/v3 VM on my Pi (that image is non-spur, and we never did a v3/cog VM > because it requires a set of specific instructions to occupy a number of > bytes that is a prime number and smells of purple locknuts) BUT it won't > actually build. > > > HOWEVER - you already have a decently suitable squeakvm installed on your > Pi, left over from waaaay back when we weren't 100% sure of the newer > Scratch system. So, in a terminal, try > > squeak.old my.image & > > and see if it works. On my Pi4 it starts up a vanilla 4.3 image straight > away. > > > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > "Bother" said Piglet, as Pooh smeared him in honey. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-18 at 3.33.16 PM.png Type: image/png Size: 89291 bytes Desc: not available URL: From tim at rowledge.org Tue Jan 19 00:04:10 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 18 Jan 2021 16:04:10 -0800 Subject: [squeak-dev] Cannot read 4.3 image on Raspberry Pi In-Reply-To: References: <30761BA6E24B38D160E49291@chorder> <20210118141546.GA31888@shell.msen.com> <57906F77-670E-4947-B50F-AC1B3AF03D47@rowledge.org> Message-ID: <2E33B086-4434-4CD4-8917-A93F03DEEA08@rowledge.org> > On 2021-01-18, at 3:51 PM, Nicolas Cellier wrote: > > Hi Tim, > Looking at recent build > https://travis-ci.com/github/OpenSmalltalk/opensmalltalk-vm/builds/213372081 > the ARMV6 squeak.stack.v3 build passed > https://travis-ci.com/github/OpenSmalltalk/opensmalltalk-vm/jobs/472299216 > So it should be possible to build... > Does the latest bintray work? > https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.stack.v3_linux32ARMv6_202101160259.tar.gz It does! Wonder why it wouldn't build for me. It didn't even leave a LOG file as the cog/spur builds do. So Jim - grab https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.stack.v3_linux32ARMv6_202101160259.tar.gz - copy to your Pi - `tar xzvf squeak.stack.v3_linux32ARMv6_202101160259.tar.gz ` - `./sqstklinuxhtRPi/squeak my.image &` - Pro$it! tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim "Yummy" said Pooh, as he rotated Piglet slowly on the spit. From lewis at mail.msen.com Tue Jan 19 02:10:26 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 18 Jan 2021 21:10:26 -0500 Subject: [squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down In-Reply-To: References: <20210117200642.GA55886@shell.msen.com> <31658f2e-0451-58b6-8d9c-adb461129ebc@gmx.net> <45B0D7E5-B47A-4C26-B39C-8AFFD4EFBE4E@rowledge.org> <20210117231205.GA83431@shell.msen.com> <71A4BF3E-4C0D-4697-9EDF-DA24B823215F@rowledge.org> <1BE581BF-8FA1-42E5-8EFD-A2739596A261@rowledge.org> <20210118142924.GA34853@shell.msen.com> <20210118184011.GA70239@shell.msen.com> <20210118230049.GA8248@shell.msen.com> Message-ID: <20210119021026.GA33750@shell.msen.com> On Mon, Jan 18, 2021 at 03:10:45PM -0800, tim Rowledge wrote: > Looks sensible to me; the only question I have is whether it is actually > guaranteed that no keycode can exceed 255? All I can find out right now > is that the structure definition has it as an int. > I based this critical design decision on a random google query, which unearthed the following web page containing extremely plausible-sounding but otherwise unfounded facts: https://tronche.com/gui/x/xlib/input/keyboard-encoding.html I had considered masking off the lower 8 bits, but then I decided that if you can't trust random google queries then who are you going to trust anyhow? Dave From eliot.miranda at gmail.com Tue Jan 19 02:19:23 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon, 18 Jan 2021 18:19:23 -0800 Subject: [squeak-dev] Cannot read 4.3 image on Raspberry Pi In-Reply-To: <30761BA6E24B38D160E49291@chorder> References: <30761BA6E24B38D160E49291@chorder> Message-ID: Hi Jim, are you up to building your own VM? If so, I've just committed files that may succeed in building a JIT for that image format. If you clone https://github.com/OpenSmalltalk/opensmalltalk-vm.git and cd to build.linuxARMv6/squeak.cog.v3 and run ./makealldirty you may be in luck. Instructions on installing necessary support libraries are in build.linuxARMv6/HowToBuild. Report back to vm-dev if you succeed or you have problems. On Mon, Jan 18, 2021 at 4:08 AM Jim Rosenberg wrote: > Ouch! I have a lot of artistic work which is developed in Squeak on Linux > -- currently only up to 4.3 (which is working fine for me, so I haven't > upgraded). I'm trying to run one of my 4.3 images on a Raspberry Pi 3B+ > which is at Raspbian 10 (buster), and with the current armv6 squeak VM, > getting the message > > This interpreter (vers. 6521) cannot read image file (vers. 6504). > > Suggestions? > > -Thanks in advance, Jim > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Jan 19 10:11:23 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 19 Jan 2021 11:11:23 +0100 Subject: [squeak-dev] Problems with table layout in 5.x In-Reply-To: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> References: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> Message-ID: Hi Javier, this is most likely a configuration issue and thus easy to fix in your code. I will take a look at BobsUI/BobsUI-jdr.7.mcz and "ExampleRolodex open". In 5.3, we added tests for TableLayout and fixed several bugs. Yet, some "unexpected behavior" might have changed, which client code maybe relied on until now -- to be addressed in that client code. But maybe there are more bugs to fix and tests to write. :-) Best, Marcel Am 18.01.2021 22:29:00 schrieb Javier Diaz-Reinoso via Squeak-dev : After finish all the features for version 1.0.0  in my port of Pronterface in squeak 4.5: https://sourceforge.net/p/sqpronterface/mercurial/ [https://sourceforge.net/p/sqpronterface/mercurial/] I am trying to test in squeak 5.3 but I encounter problems with BobsUI who is the framework I am using. BobsUI use a lot of nested UIAlignmentMorphs and the layout of that is mostly OK, but the problem appears in a UIGroupBoxMorph, in this morph the top submorph are only two: a label (UIStringMorph) and a container (UIMorph) who have the submorphs of the widgets of the group, this image show the problem between squeak 4.5 and 5.3, this is using the basic example of BobsUi called ExampleRolodex: Tracing the execution of the creation of the morphs I find the problem in Morph>>adjustLayoutBounds reverting the version "mt 8/22/2019" to "ar 11/12/2000" restore the view (mostly) to the version 5.2. >From the tracing I see changes in the order of the selectors who are used to evaluate the size of the tree of submorphs; appears to be that the old version (4.5) always wait to obtain the size of the "leaves" of the tree of submorphs before updating the top submorphs, I think the actual version fix some sizes prematurely. This is also apparent in other problem who is present in 5.2 and 5.3 but not in 4.5, 5.1, this image show the top of the UIWindowMorph (4.5 and 5.2): appears the title (UITitleBarMorph) size is fixed before the (last) UIGroupBoxMorph of the window is evaluated. Also in 5.3 (not in 5.2 and before) there is a lot of extra space around the widgets, the UIWindowMorph size are: 4.5 429 × 337 pixels 5,1 438 × 363 pixels, appears to be a change of fonts in the system 5.2 428 × 333 pixels 5.3 500 × 479 pixels this is worse in the title of 5.3 because the extra space move te title down the proper position: Finally I find the bounds and fullBound of the submorphs in 5.x are absolute where in 4.5 was relative to the window, in my probable naive opinion, I think is a lot of updates when a window move versus a single update to the top morph, for example ExampleRolodex have 77 submorphs, sqPronterface have 158. For reproducing the results, you can copy BobsUI/BobsUI-jdr.7.mcz (177KB) from the repository and create the window with: ExampleRolodex open beware that BobsUI, intentionally, suppress the halos, so you need to use Crtl-click or equivalent to inspect it, delete, .... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 16.33.58.png Type: image/png Size: 44548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 16.55.45.png Type: image/png Size: 57146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 17.59.38.png Type: image/png Size: 24971 bytes Desc: not available URL: From marcel.taeumel at hpi.de Tue Jan 19 10:21:46 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 19 Jan 2021 11:21:46 +0100 Subject: [squeak-dev] Problems with table layout in 5.x In-Reply-To: References: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> Message-ID: Hi Javier, until then: Take a look at the 5.3 release notes under "compatibility notes". Best, Marcel Am 19.01.2021 11:11:23 schrieb Marcel Taeumel : Hi Javier, this is most likely a configuration issue and thus easy to fix in your code. I will take a look at BobsUI/BobsUI-jdr.7.mcz and "ExampleRolodex open". In 5.3, we added tests for TableLayout and fixed several bugs. Yet, some "unexpected behavior" might have changed, which client code maybe relied on until now -- to be addressed in that client code. But maybe there are more bugs to fix and tests to write. :-) Best, Marcel Am 18.01.2021 22:29:00 schrieb Javier Diaz-Reinoso via Squeak-dev : After finish all the features for version 1.0.0  in my port of Pronterface in squeak 4.5: https://sourceforge.net/p/sqpronterface/mercurial/ [https://sourceforge.net/p/sqpronterface/mercurial/] I am trying to test in squeak 5.3 but I encounter problems with BobsUI who is the framework I am using. BobsUI use a lot of nested UIAlignmentMorphs and the layout of that is mostly OK, but the problem appears in a UIGroupBoxMorph, in this morph the top submorph are only two: a label (UIStringMorph) and a container (UIMorph) who have the submorphs of the widgets of the group, this image show the problem between squeak 4.5 and 5.3, this is using the basic example of BobsUi called ExampleRolodex: Tracing the execution of the creation of the morphs I find the problem in Morph>>adjustLayoutBounds reverting the version "mt 8/22/2019" to "ar 11/12/2000" restore the view (mostly) to the version 5.2. >From the tracing I see changes in the order of the selectors who are used to evaluate the size of the tree of submorphs; appears to be that the old version (4.5) always wait to obtain the size of the "leaves" of the tree of submorphs before updating the top submorphs, I think the actual version fix some sizes prematurely. This is also apparent in other problem who is present in 5.2 and 5.3 but not in 4.5, 5.1, this image show the top of the UIWindowMorph (4.5 and 5.2): appears the title (UITitleBarMorph) size is fixed before the (last) UIGroupBoxMorph of the window is evaluated. Also in 5.3 (not in 5.2 and before) there is a lot of extra space around the widgets, the UIWindowMorph size are: 4.5 429 × 337 pixels 5,1 438 × 363 pixels, appears to be a change of fonts in the system 5.2 428 × 333 pixels 5.3 500 × 479 pixels this is worse in the title of 5.3 because the extra space move te title down the proper position: Finally I find the bounds and fullBound of the submorphs in 5.x are absolute where in 4.5 was relative to the window, in my probable naive opinion, I think is a lot of updates when a window move versus a single update to the top morph, for example ExampleRolodex have 77 submorphs, sqPronterface have 158. For reproducing the results, you can copy BobsUI/BobsUI-jdr.7.mcz (177KB) from the repository and create the window with: ExampleRolodex open beware that BobsUI, intentionally, suppress the halos, so you need to use Crtl-click or equivalent to inspect it, delete, .... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 16.33.58.png Type: image/png Size: 44548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 16.55.45.png Type: image/png Size: 57146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 17.59.38.png Type: image/png Size: 24971 bytes Desc: not available URL: From marcel.taeumel at hpi.de Tue Jan 19 11:50:19 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 19 Jan 2021 12:50:19 +0100 Subject: [squeak-dev] Problems with table layout in 5.x In-Reply-To: References: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> Message-ID: Hmm.... "BobsUI" uses a mix of layout policies and overrides through custom implementations of #extent: or #width: or #height:. Hmpf. Sometimes even in the same morph that actually uses such a policy. It also looks like that BobsUI fixes several layout bugs from 5.2 and before through subclassing. Unfortunately, one would have to go through all UI* classes and remove all those changes (or hacks). I do not have the resources to do that now. :-( What needs to be done is to replace all hacks in #width: and #height: (etc.) with proper configuration of layout properties (i.e., #hResizing, #vResizing, ...) The one thing you can easily fix is to replace all "#cellInset:" calls with "#cellGap:", which is explained in the Squeak 5.3 release notes. Best, Marcel Am 19.01.2021 11:21:46 schrieb Marcel Taeumel : Hi Javier, until then: Take a look at the 5.3 release notes under "compatibility notes". Best, Marcel Am 19.01.2021 11:11:23 schrieb Marcel Taeumel : Hi Javier, this is most likely a configuration issue and thus easy to fix in your code. I will take a look at BobsUI/BobsUI-jdr.7.mcz and "ExampleRolodex open". In 5.3, we added tests for TableLayout and fixed several bugs. Yet, some "unexpected behavior" might have changed, which client code maybe relied on until now -- to be addressed in that client code. But maybe there are more bugs to fix and tests to write. :-) Best, Marcel Am 18.01.2021 22:29:00 schrieb Javier Diaz-Reinoso via Squeak-dev : After finish all the features for version 1.0.0  in my port of Pronterface in squeak 4.5: https://sourceforge.net/p/sqpronterface/mercurial/ [https://sourceforge.net/p/sqpronterface/mercurial/] I am trying to test in squeak 5.3 but I encounter problems with BobsUI who is the framework I am using. BobsUI use a lot of nested UIAlignmentMorphs and the layout of that is mostly OK, but the problem appears in a UIGroupBoxMorph, in this morph the top submorph are only two: a label (UIStringMorph) and a container (UIMorph) who have the submorphs of the widgets of the group, this image show the problem between squeak 4.5 and 5.3, this is using the basic example of BobsUi called ExampleRolodex: Tracing the execution of the creation of the morphs I find the problem in Morph>>adjustLayoutBounds reverting the version "mt 8/22/2019" to "ar 11/12/2000" restore the view (mostly) to the version 5.2. >From the tracing I see changes in the order of the selectors who are used to evaluate the size of the tree of submorphs; appears to be that the old version (4.5) always wait to obtain the size of the "leaves" of the tree of submorphs before updating the top submorphs, I think the actual version fix some sizes prematurely. This is also apparent in other problem who is present in 5.2 and 5.3 but not in 4.5, 5.1, this image show the top of the UIWindowMorph (4.5 and 5.2): appears the title (UITitleBarMorph) size is fixed before the (last) UIGroupBoxMorph of the window is evaluated. Also in 5.3 (not in 5.2 and before) there is a lot of extra space around the widgets, the UIWindowMorph size are: 4.5 429 × 337 pixels 5,1 438 × 363 pixels, appears to be a change of fonts in the system 5.2 428 × 333 pixels 5.3 500 × 479 pixels this is worse in the title of 5.3 because the extra space move te title down the proper position: Finally I find the bounds and fullBound of the submorphs in 5.x are absolute where in 4.5 was relative to the window, in my probable naive opinion, I think is a lot of updates when a window move versus a single update to the top morph, for example ExampleRolodex have 77 submorphs, sqPronterface have 158. For reproducing the results, you can copy BobsUI/BobsUI-jdr.7.mcz (177KB) from the repository and create the window with: ExampleRolodex open beware that BobsUI, intentionally, suppress the halos, so you need to use Crtl-click or equivalent to inspect it, delete, .... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 16.33.58.png Type: image/png Size: 44548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 16.55.45.png Type: image/png Size: 57146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-12 at 17.59.38.png Type: image/png Size: 24971 bytes Desc: not available URL: From commits at source.squeak.org Tue Jan 19 12:31:31 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 19 Jan 2021 12:31:31 0000 Subject: [squeak-dev] The Trunk: CollectionsTests-ul.348.mcz Message-ID: Levente Uzonyi uploaded a new version of CollectionsTests to project The Trunk: http://source.squeak.org/trunk/CollectionsTests-ul.348.mcz ==================== Summary ==================== Name: CollectionsTests-ul.348 Author: ul Time: 19 January 2021, 1:29:30.901142 pm UUID: 7a478e2d-0752-43f2-ab4a-4f6aa9f3bbe6 Ancestors: CollectionsTests-nice.347 - improved tests for OrderedCollection's #removeFirst: and #removeLast:. =============== Diff against CollectionsTests-nice.347 =============== Item was changed: ----- Method: OrderedCollectionTest>>testRemoveFirst (in category 'tests - removing') ----- testRemoveFirst "Allows one to remove n element of a collection at the first" "self run:#testRemoveFirst" + | c1 c2 | - | c1 | c1 := #(2 3 4 6) asOrderedCollection. + c2 := c1 copy. + self assert: Array empty equals: (c1 removeFirst: 0). + self assert: c2 equals: c1. + self assert: #(2) equals: (c1 removeFirst: 1). + self assert: #(3 4 6) asOrderedCollection equals: c1. + self assert:#(3 4) equals: (c1 removeFirst: 2). + self assert: #(6) asOrderedCollection equals: c1. - c1 removeFirst: 1. - self assert: (c1 = #(3 4 6) asOrderedCollection). - c1 removeFirst: 2. - self assert: (c1 = #(6) asOrderedCollection). self should: [c1 removeFirst: 10] raise: Error. ! Item was changed: ----- Method: OrderedCollectionTest>>testRemoveLast (in category 'tests - removing') ----- testRemoveLast "Allows one to remove n element of a collection at the end" "self run:#testRemoveLast" + | c1 c2 | - | c1 | c1 := #(2 3 4 6) asOrderedCollection. + c2 := c1 copy. + self assert: Array empty equals: (c1 removeLast: 0). + self assert: c2 equals: c1. + self assert: #(6) equals: (c1 removeLast: 1). + self assert: #(2 3 4) asOrderedCollection equals: c1. + self assert: #(3 4) equals: (c1 removeLast: 2). + self assert: #(2) asOrderedCollection equals: c1. + self should: [c1 removeLast: 10] raise: Error! - c1 removeLast: 1. - self assert: (c1 = #(2 3 4) asOrderedCollection). - c1 removeLast: 2. - self assert: (c1 = #(2) asOrderedCollection). - self should: [c1 removeLast: 10] raise: Error.! From commits at source.squeak.org Tue Jan 19 12:31:53 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 19 Jan 2021 12:31:53 0000 Subject: [squeak-dev] The Trunk: Collections-ul.922.mcz Message-ID: Levente Uzonyi uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-ul.922.mcz ==================== Summary ==================== Name: Collections-ul.922 Author: ul Time: 19 January 2021, 1:28:51.784086 pm UUID: 7d688371-2966-43d3-9000-3985ae9f6afa Ancestors: Collections-nice.921 Fix off-by-one errors in OrderedCollection's #removeFirst: and #removeLast:. The argument of those methods can be zero. =============== Diff against Collections-nice.921 =============== Item was changed: ----- Method: OrderedCollection>>removeFirst: (in category 'removing') ----- removeFirst: n "Remove the first n objects into an array." | lastIndexToRemove result | + n < 0 ifTrue: [ self errorNoSuchElement ]. - n < 1 ifTrue: [ self errorNoSuchElement ]. lastIndex < (lastIndexToRemove := firstIndex + n - 1) ifTrue: [ self errorNotEnoughElements ]. result := array copyFrom: firstIndex to: lastIndexToRemove. array from: firstIndex to: lastIndexToRemove put: nil. firstIndex := lastIndexToRemove + 1. ^result! Item was changed: ----- Method: OrderedCollection>>removeLast: (in category 'removing') ----- removeLast: n "Remove the last n objects into an array with last in last position." | firstIndexToRemove result | + n < 0 ifTrue: [ self errorNoSuchElement ]. - n < 1 ifTrue: [ self errorNoSuchElement ]. (firstIndexToRemove := lastIndex - n + 1) < firstIndex ifTrue: [ self errorNotEnoughElements ]. result := array copyFrom: firstIndexToRemove to: lastIndex. array from: firstIndexToRemove to: lastIndex put: nil. lastIndex := firstIndexToRemove - 1. ^result! From eliot.miranda at gmail.com Tue Jan 19 21:35:57 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue, 19 Jan 2021 13:35:57 -0800 Subject: [squeak-dev] The Trunk: Collections-ul.922.mcz In-Reply-To: References: Message-ID: On Tue, Jan 19, 2021 at 4:31 AM wrote: > Levente Uzonyi uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-ul.922.mcz > > ==================== Summary ==================== > > Name: Collections-ul.922 > Author: ul > Time: 19 January 2021, 1:28:51.784086 pm > UUID: 7d688371-2966-43d3-9000-3985ae9f6afa > Ancestors: Collections-nice.921 > > Fix off-by-one errors in OrderedCollection's #removeFirst: and > #removeLast:. The argument of those methods can be zero. > Thanks!! Name: RoelTyper-eem.88 Author: eem Time: 19 January 2021, 1:33:32.686379 pm UUID: 7cba406e-2ec5-4798-8046-e41bf4bd0388 Ancestors: RoelTyper-eem.87 Revert the work-around in InstvarInterfaceExtractor>>nativeSend:numArgs: now that Collections-ul.922 fixes the issues with anOrderedColleciton removeLast: 0. > =============== Diff against Collections-nice.921 =============== > > Item was changed: > ----- Method: OrderedCollection>>removeFirst: (in category 'removing') > ----- > removeFirst: n > "Remove the first n objects into an array." > > | lastIndexToRemove result | > + n < 0 ifTrue: [ self errorNoSuchElement ]. > - n < 1 ifTrue: [ self errorNoSuchElement ]. > lastIndex < (lastIndexToRemove := firstIndex + n - 1) ifTrue: [ > self errorNotEnoughElements ]. > result := array copyFrom: firstIndex to: lastIndexToRemove. > array from: firstIndex to: lastIndexToRemove put: nil. > firstIndex := lastIndexToRemove + 1. > ^result! > > Item was changed: > ----- Method: OrderedCollection>>removeLast: (in category 'removing') > ----- > removeLast: n > "Remove the last n objects into an array with last in last > position." > > | firstIndexToRemove result | > + n < 0 ifTrue: [ self errorNoSuchElement ]. > - n < 1 ifTrue: [ self errorNoSuchElement ]. > (firstIndexToRemove := lastIndex - n + 1) < firstIndex ifTrue: [ > self errorNotEnoughElements ]. > result := array copyFrom: firstIndexToRemove to: lastIndex. > array from: firstIndexToRemove to: lastIndex put: nil. > lastIndex := firstIndexToRemove - 1. > ^result! > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjenve at yahoo.com Thu Jan 21 12:07:06 2021 From: arjenve at yahoo.com (Arjen van Elteren) Date: Thu, 21 Jan 2021 12:07:06 +0000 (UTC) Subject: [squeak-dev] Unloading EToys from Squeak Image References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> Message-ID: <1697231277.3880561.1611230826611@mail.yahoo.com> All, I would like to unload the EToys packages from image. I tried with the Monticello Browser, unloading seems to proceed. But at the end nothing is reacting anymore. Any hint on how to successfully unload the EToys? Should I use a workspace in an MVC project? Kind regards, Arjen From javier_diaz_r at mac.com Fri Jan 22 17:16:10 2021 From: javier_diaz_r at mac.com (Javier Diaz-Reinoso) Date: Fri, 22 Jan 2021 12:16:10 -0500 Subject: [squeak-dev] Problems with table layout in 5.x In-Reply-To: References: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> Message-ID: <395A1D66-9E3E-47EE-87CE-1A2D7D655E53@mac.com> > On 19 Jan 2021, at 06:50, Marcel Taeumel wrote: > > Hmm.... "BobsUI" uses a mix of layout policies and overrides through custom implementations of #extent: or #width: or #height:. Hmpf. Sometimes even in the same morph that actually uses such a policy. It also looks like that BobsUI fixes several layout bugs from 5.2 and before through subclassing. Unfortunately, one would have to go through all UI* classes and remove all those changes (or hacks). > > I do not have the resources to do that now. :-( What needs to be done is to replace all hacks in #width: and #height: (etc.) with proper configuration of layout properties (i.e., #hResizing, #vResizing, ...) > > The one thing you can easily fix is to replace all "#cellInset:" calls with "#cellGap:", which is explained in the Squeak 5.3 release notes. > > Best, > Marcel [... cut ...] You are blaming indeterminate hacks in BobosUi for the problems, al least for the UIGroupBoxMorph problem that is not correct. I now extracted that morph from BobsUi to UISimpleGroupBoxMorph removing all instances and selectors who are not involves in the initialization, also recreated by hand the tree of morphsusing only regular morphs, this is in the workspace 'test UISimpleGroupBox.text', the result of evaluating is: who show the same bug, also this test work in 5.2 ans with the revert of Morph>>adjustLayoutBounds. So I think this is a "clean" bug created for the changes in the table layout in 5.3. As for the other problems with the UITitleBarMorph and the extra spaces, I think is also produced by bugs in the same area, after all BobsUI are not changing that area. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-22 at 11.48.06.png Type: image/png Size: 11302 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test UISimpleGroupBox.text URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UISimpleGroupBoxMorph.st Type: application/octet-stream Size: 9672 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at jaromir.net Fri Jan 22 20:03:10 2021 From: m at jaromir.net (jaromir) Date: Fri, 22 Jan 2021 14:03:10 -0600 (CST) Subject: [squeak-dev] Transcript error when forceUpdate: false (?) Message-ID: <1611345790068-0.post@n4.nabble.com> I ran the following in Squeak 5.3: TranscriptStream forceUpdate: false. [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 When the Transcript window fills up, 'Message not understood' and 'Assertion failure' appear. I'm wondering is this a bug? Thanks. Jaromir -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From lewis at mail.msen.com Fri Jan 22 23:24:08 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 22 Jan 2021 18:24:08 -0500 Subject: [squeak-dev] 20X speedup for read file upToEnd Message-ID: <20210122232408.GA78147@shell.msen.com> Attached is a small change that gives a big performance boost for reading a file upToEnd. My use case (where I noticed this) is reading an image file, where the file is opened, the header is read, and the remainder of the file upToEnd is read in as the object memory: fs := FileStream readOnlyFileNamed: Smalltalk imageName. fs binary. t := Time millisecondsToRun: [ImageSnapshot fromStream: fs]. fs close. t ==> 12428 "original implementation" ==> 645 "new version" Overall speedup is about 20X for MultiByteFileStream and over 100x for StandardFileStream (difference due to Levente's earlier improvements in MultiByteFileStream). This small change touches two packages so I'm posting it as a change set for comment. I'll put it in trunk if there are no issues. Dave -------------- next part -------------- 'From Squeak6.0alpha of 19 January 2021 [latest update: #20168] on 22 January 2021 at 5:47:20 pm'! "Change Set: Speedup-file-upToEnd-dtl Date: 22 January 2021 Author: David T Lewis Make MultiByteFileStream>>upToEnd faster by reading 1000 at a time rather than calling a primitive once per byte. Move this method up to StandardFileStream to avoid duplication. MulitbyteFileStream was already much faster due to better buffer allocation, this improves it by reducing trips to the VM for each byte read. Overall improvement is close to 20x faster."! !StandardFileStream methodsFor: 'read, write, position' stamp: 'dtl 1/22/2021 17:37'! upToEnd "Answer a subcollection from the current access position through the last element of the receiver." ^self collectionSpecies new: self size - self position streamContents: [ :stream | | elements | [ (elements := self next: 1000) isEmpty ] whileFalse: [ stream nextPutAll: elements ] ] ! ! MultiByteFileStream removeSelector: #upToEnd! From tim at rowledge.org Fri Jan 22 23:53:00 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 22 Jan 2021 15:53:00 -0800 Subject: [squeak-dev] 20X speedup for read file upToEnd In-Reply-To: <20210122232408.GA78147@shell.msen.com> References: <20210122232408.GA78147@shell.msen.com> Message-ID: <0BC8A25A-B212-4F60-907E-CF4805B3B0B9@rowledge.org> Looks pretty sensible to me. As a small aside, I noticed when reading '.po' files (that Scratch uses for language translation dictionaries) that explicitly using StandardFileStream in place of MultiByteFileStream in appropriate places could speed up file reading immensely; I suspect your change will solve that worry. > On 2021-01-22, at 3:24 PM, David T. Lewis wrote: > > tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Who is General Failure and why is he reading my disk? From lewis at mail.msen.com Sat Jan 23 00:51:13 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 22 Jan 2021 19:51:13 -0500 Subject: [squeak-dev] 20X speedup for read file upToEnd In-Reply-To: <0BC8A25A-B212-4F60-907E-CF4805B3B0B9@rowledge.org> References: <20210122232408.GA78147@shell.msen.com> <0BC8A25A-B212-4F60-907E-CF4805B3B0B9@rowledge.org> Message-ID: <20210123005113.GA90015@shell.msen.com> On Fri, Jan 22, 2021 at 03:53:00PM -0800, tim Rowledge wrote: > > > On 2021-01-22, at 3:24 PM, David T. Lewis wrote: > > > > > > Looks pretty sensible to me. As a small aside, I noticed when reading > '.po' files (that Scratch uses for language translation dictionaries) that > explicitly using StandardFileStream in place of MultiByteFileStream in > appropriate places could speed up file reading immensely; I suspect your > change will solve that worry. > I suspect that these are two separate issues, but I'm also pretty sure there are plenty of other small places where I/O can be improved. For the case of #upToEnd I found that MultiByteFileStream was already five times faster than StandardFileStream due to improvements that Levente did back in 2009. So I took Levente's logic, added the "don't read it one byte at a time" change, and moved it up to StandardFileStream. It would be worth profiling the '.po' file reading in Scratch and seeing where the time is going. Maybe there is another I/O method that could be easily improved. Dave From lewis at mail.msen.com Sat Jan 23 01:16:30 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 22 Jan 2021 20:16:30 -0500 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: <1697231277.3880561.1611230826611@mail.yahoo.com> References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> Message-ID: <20210123011630.GA93733@shell.msen.com> On Thu, Jan 21, 2021 at 12:07:06PM +0000, Arjen van Elteren via Squeak-dev wrote: > All, > > I would like to unload the EToys packages from image. > > I tried with the Monticello Browser, unloading seems to proceed. But at the end nothing is reacting anymore. > > Any hint on how to successfully unload the EToys? > > Should I use a workspace in an MVC project? > Hello Arjen, I don't think that unloading works yet, but hopefully soon. The goal is to make Etoys reloadable, which means that it can be fully removed from the image, and also reinstalled into an image from which it has been removed. A lot of good work has gone into this in the last few years, but it is not complete. If you do any work on this yourself, any input would be welcome either as inbox contributions or messages to the list here. I should mention also that this topic came up (again!) in the last online meeting of our Squeak oversight board and it is on our agenda for the next meeting. I think everyone agrees that this is important to do, it's just a small matter of somebody doing the work ;-) Dave From lewis at mail.msen.com Sat Jan 23 01:26:10 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 22 Jan 2021 20:26:10 -0500 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: <1611345790068-0.post@n4.nabble.com> References: <1611345790068-0.post@n4.nabble.com> Message-ID: <20210123012610.GB93733@shell.msen.com> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: > I ran the following in Squeak 5.3: > > TranscriptStream forceUpdate: false. > [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 > > When the Transcript window fills up, 'Message not understood' and 'Assertion > failure' appear. I'm wondering is this a bug? Thanks. Jaromir > > > It certainly does appear to be a bug. Dave From tim at rowledge.org Sat Jan 23 05:14:48 2021 From: tim at rowledge.org (tim Rowledge) Date: Fri, 22 Jan 2021 21:14:48 -0800 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: <20210123012610.GB93733@shell.msen.com> References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> Message-ID: <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> > On 2021-01-22, at 5:26 PM, David T. Lewis wrote: > > On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: >> I ran the following in Squeak 5.3: >> >> TranscriptStream forceUpdate: false. >> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 >> >> When the Transcript window fills up, 'Message not understood' and 'Assertion >> failure' appear. I'm wondering is this a bug? Thanks. Jaromir >> >> >> > > It certainly does appear to be a bug. We had some discussion about it not so long ago; you can't use the Transcript to log bugs from Seaside very well, for example. Background processes, mutexs, that sort of thing. IIRC Levente offered an explanation? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim The hardness of the butter is proportional to the softness of the bread. From leves at caesar.elte.hu Sat Jan 23 19:58:07 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sat, 23 Jan 2021 20:58:07 +0100 (CET) Subject: [squeak-dev] 20X speedup for read file upToEnd In-Reply-To: <20210122232408.GA78147@shell.msen.com> References: <20210122232408.GA78147@shell.msen.com> Message-ID: Hi Dave, Good catch. That method of StandardFileStream, unlike #upTo: and #upToAnyOf:do:, has not been optimized. IMO, StandardFileStream >> #upToEnd should simply be ^self next: self size - self position And I suggest your implementation be added to MultiByteFileStream with the following modifications: upToEnd "Answer a subcollection from the current access position through the last element of the receiver." | remainingEstimate | self isBinary ifTrue: [ ^super upToEnd ]. remainingEstimate := self size - self position. ^self collectionSpecies new: remainingEstimate streamContents: [ :stream | | elements chunkSize | chunkSize := remainingEstimate min: 2000. "It's not worth allocating larger chunks" [ (elements := self next: chunkSize) isEmpty ] whileFalse: [ stream nextPutAll: elements ] ] Levente On Fri, 22 Jan 2021, David T. Lewis wrote: > Attached is a small change that gives a big performance boost for reading > a file upToEnd. My use case (where I noticed this) is reading an image > file, where the file is opened, the header is read, and the remainder of > the file upToEnd is read in as the object memory: > > fs := FileStream readOnlyFileNamed: Smalltalk imageName. fs binary. > t := Time millisecondsToRun: [ImageSnapshot fromStream: fs]. > fs close. > t > ==> 12428 "original implementation" > ==> 645 "new version" > > Overall speedup is about 20X for MultiByteFileStream and over 100x for > StandardFileStream (difference due to Levente's earlier improvements > in MultiByteFileStream). > > This small change touches two packages so I'm posting it as a change set > for comment. I'll put it in trunk if there are no issues. > > Dave > > From leves at caesar.elte.hu Sat Jan 23 20:04:50 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sat, 23 Jan 2021 21:04:50 +0100 (CET) Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> Message-ID: On Fri, 22 Jan 2021, tim Rowledge wrote: > > >> On 2021-01-22, at 5:26 PM, David T. Lewis wrote: >> >> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: >>> I ran the following in Squeak 5.3: >>> >>> TranscriptStream forceUpdate: false. >>> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 >>> >>> When the Transcript window fills up, 'Message not understood' and 'Assertion >>> failure' appear. I'm wondering is this a bug? Thanks. Jaromir >>> >>> >>> >> >> It certainly does appear to be a bug. > > We had some discussion about it not so long ago; you can't use the Transcript to log bugs from Seaside very well, for example. Background processes, mutexs, that sort of thing. IIRC Levente offered an explanation? It's simply not thread-safe. If you want it to be thread-safe, you can pass your message to the UI process to show it. Make sure your message is computed in its own process and is passed as a precomputed string to avoid other kinds of race conditions. E.g.: | theMessage | theMessage := 'Something very {1}.' format: { 'important' }. Project current addDeferredUIMessage: [ Transcript show: theMessage; cr ]. Levente > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > The hardness of the butter is proportional to the softness of the bread. From lewis at mail.msen.com Sat Jan 23 20:55:08 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 23 Jan 2021 15:55:08 -0500 Subject: [squeak-dev] 20X speedup for read file upToEnd In-Reply-To: References: <20210122232408.GA78147@shell.msen.com> Message-ID: <20210123205508.GA76730@shell.msen.com> Hi Levente, Thanks, that looks better. Do you want to commit the update to keep the author initials right? If not I'll commit it and credit you in the commit comment. As an aside, this also makes me notice that #upToEnd does not work for file streams that do not know their size, such as FileStream stdin, on any file stream on an OS Pipe. Here is the variation that I did (back in 2006) for OSProcess, which uses AttachableFileStream subclassed from StandardFileStream: AttachableFileStream>>upToEnd "Answer a subcollection from the current access position through the last element of the receiver. This is slower than the method in StandardFileStream, but it works with pipes which answer false to #atEnd when no further input is currently available, but the pipe is not yet closed." | newStream buffer nextBytes | buffer := buffer1 species new: 1000. newStream := WriteStream on: (buffer1 species new: 100). [self atEnd or: [(nextBytes := self nextInto: buffer) isEmpty]] whileFalse: [newStream nextPutAll: nextBytes]. ^ newStream contents The AttachableFileStream hack in OSProcess really needs to go away, so I think I'd to find a way to make these things work with good performance on any kind of file stream. But that is a topic for another thread. Thanks, Dave On Sat, Jan 23, 2021 at 08:58:07PM +0100, Levente Uzonyi wrote: > Hi Dave, > > Good catch. That method of StandardFileStream, unlike #upTo: and > #upToAnyOf:do:, has not been optimized. > > IMO, StandardFileStream >> #upToEnd should simply be > > ^self next: self size - self position > > And I suggest your implementation be added to MultiByteFileStream with the > following modifications: > > upToEnd > "Answer a subcollection from the current access position through the > last element of the receiver." > > | remainingEstimate | > self isBinary ifTrue: [ ^super upToEnd ]. > remainingEstimate := self size - self position. > ^self collectionSpecies > new: remainingEstimate > streamContents: [ :stream | > | elements chunkSize | > chunkSize := remainingEstimate min: 2000. "It's not > worth allocating larger chunks" > [ (elements := self next: chunkSize) isEmpty ] > whileFalse: [ > stream nextPutAll: elements ] ] > > > Levente > > On Fri, 22 Jan 2021, David T. Lewis wrote: > > >Attached is a small change that gives a big performance boost for reading > >a file upToEnd. My use case (where I noticed this) is reading an image > >file, where the file is opened, the header is read, and the remainder of > >the file upToEnd is read in as the object memory: > > > > fs := FileStream readOnlyFileNamed: Smalltalk imageName. fs binary. > > t := Time millisecondsToRun: [ImageSnapshot fromStream: fs]. > > fs close. > > t > > ==> 12428 "original implementation" > > ==> 645 "new version" > > > >Overall speedup is about 20X for MultiByteFileStream and over 100x for > >StandardFileStream (difference due to Levente's earlier improvements > >in MultiByteFileStream). > > > >This small change touches two packages so I'm posting it as a change set > >for comment. I'll put it in trunk if there are no issues. > > > >Dave > > > > > From commits at source.squeak.org Sun Jan 24 02:07:22 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 02:07:22 0000 Subject: [squeak-dev] The Trunk: System-eem.1211.mcz Message-ID: Eliot Miranda uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-eem.1211.mcz ==================== Summary ==================== Name: System-eem.1211 Author: eem Time: 23 January 2021, 6:07:18.034021 pm UUID: 89999499-d83c-478b-9044-5dee2fe443df Ancestors: System-dtl.1210 Update the system's copyright. =============== Diff against System-dtl.1210 =============== Item was changed: ----- Method: SmalltalkImage>>copyright (in category 'sources, changes log') ----- copyright "The Smalltalk copyright." + ^'Copyright � Xerox Corp. 1981, 1982 All rights reserved. + Copyright � Apple Computer, Inc. 1985-1996 All rights reserved; + Copyright � 2010-2021 Squeak Community Contributors.'! - ^'Copyright (c) Xerox Corp. 1981, 1982 All rights reserved. - Copyright (c) Apple Computer, Inc. 1985-1996 All rights reserved.'! From commits at source.squeak.org Sun Jan 24 02:18:37 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 02:18:37 0000 Subject: [squeak-dev] The Trunk: System-eem.1212.mcz Message-ID: Eliot Miranda uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-eem.1212.mcz ==================== Summary ==================== Name: System-eem.1212 Author: eem Time: 23 January 2021, 6:18:33.915831 pm UUID: b4abe320-97d1-4849-87af-51818eddcabe Ancestors: System-eem.1211 There are two instances of the copyright. Make them both consstent and move them out of EToys (helping a tiny bit in EToys unloading). =============== Diff against System-eem.1211 =============== Item was changed: ----- Method: SmalltalkImage>>copyright (in category 'sources, changes log') ----- copyright "The Smalltalk copyright." ^'Copyright � Xerox Corp. 1981, 1982 All rights reserved. + Copyright � Apple Computer, Inc. 1985-1996 All rights reserved. + Copyright � 1996-2009 Viewpoints Research Institute, and Contributors. - Copyright � Apple Computer, Inc. 1985-1996 All rights reserved; Copyright � 2010-2021 Squeak Community Contributors.'! Item was added: + ----- Method: SystemDictionary>>copyright (in category 'sources, change log') ----- + copyright + "The Smalltalk copyright." + + ^'Copyright � Xerox Corp. 1981, 1982 All rights reserved. + Copyright � 1996 Apple Computer, Inc. All Rights Reserved. + Copyright � 1996-2009 Viewpoints Research Institute, and Contributors. + Copyright � 2010-2021 Squeak Community Contributors'! Item was added: + ----- Method: SystemDictionary>>currentChangeSetString (in category 'sources, change log') ----- + currentChangeSetString + "Smalltalk currentChangeSetString" + ^ 'Current Change Set: ' translated, ChangeSet current name! From commits at source.squeak.org Sun Jan 24 02:19:58 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 02:19:58 0000 Subject: [squeak-dev] The Trunk: EToys-eem.417.mcz Message-ID: Eliot Miranda uploaded a new version of EToys to project The Trunk: http://source.squeak.org/trunk/EToys-eem.417.mcz ==================== Summary ==================== Name: EToys-eem.417 Author: eem Time: 23 January 2021, 6:19:52.973089 pm UUID: 90068d9d-ef84-4cb9-92d2-5bb0ec54994e Ancestors: EToys-mt.416 Move two base system methods to System. =============== Diff against EToys-mt.416 =============== Item was removed: - ----- Method: SystemDictionary>>copyright (in category '*Etoys-Squeakland-sources, change log') ----- - copyright - "The Smalltalk copyright." - - ^'Copyright (c) 1996 Apple Computer, Inc. All Rights Reserved. - Copyright (c) 1996-2009 Viewpoints Research Institute, and Contributors; - Copyright (c) 2010-2012 Squeak Community Contributors'! Item was removed: - ----- Method: SystemDictionary>>currentChangeSetString (in category '*Etoys-Squeakland-sources, change log') ----- - currentChangeSetString - "Smalltalk currentChangeSetString" - ^ 'Current Change Set: ' translated, ChangeSet current name! From commits at source.squeak.org Sun Jan 24 02:22:48 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 02:22:48 0000 Subject: [squeak-dev] The Trunk: SystemReporter-eem.48.mcz Message-ID: Eliot Miranda uploaded a new version of SystemReporter to project The Trunk: http://source.squeak.org/trunk/SystemReporter-eem.48.mcz ==================== Summary ==================== Name: SystemReporter-eem.48 Author: eem Time: 23 January 2021, 6:22:46.831925 pm UUID: ab93c373-d792-4a99-a3b4-9967fdc8a294 Ancestors: SystemReporter-eem.47 Tiny neatening. =============== Diff against SystemReporter-eem.47 =============== Item was changed: ----- Method: SystemReporter>>reportImage: (in category 'reporting') ----- reportImage: aStream self header: 'Image' on: aStream. aStream nextPutAll: Smalltalk image imageName; cr; nextPutAll: SystemVersion current version; cr; nextPutAll: Smalltalk image lastUpdateString; cr; nextPutAll: Smalltalk image currentChangeSetString; cr. + [aStream + nextPutAll: 'Image format '; + print: Smalltalk image imageFormatVersion; - [ | imageFormat bitsPerWord | - imageFormat := Smalltalk image imageFormatVersion. - bitsPerWord := Smalltalk image wordSize * 8. - aStream nextPutAll: 'Image format '; - nextPutAll: imageFormat asString; nextPutAll: ' ('; + print: Smalltalk image wordSize * 8; - nextPutAll: bitsPerWord asString; nextPutAll: ' bit)'; cr] on: Warning + do: ["primitive not present in VM"] + + "self new reportImage: Transcript. Transcript flush"! - do: ["primitive not present in VM"]. - ! From commits at source.squeak.org Sun Jan 24 14:19:51 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 14:19:51 0000 Subject: [squeak-dev] The Inbox: Kernel-ct.1368.mcz Message-ID: A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1368.mcz ==================== Summary ==================== Name: Kernel-ct.1368 Author: ct Time: 24 January 2021, 3:19:48.003384 pm UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd Ancestors: Kernel-mt.1364 Proposal: Always include process name into its print string. This facilitates debugging/inspecting of multiprocess scenarios. =============== Diff against Kernel-mt.1364 =============== Item was changed: ----- Method: Process>>longPrintOn: (in category 'printing') ----- longPrintOn: stream | ctxt | super printOn: stream. + stream + nextPut: $(; + nextPutAll: self name; + nextPut: $). stream cr. ctxt := self suspendedContext. [ctxt == nil] whileFalse: [ stream space. ctxt printOn: stream. stream cr. ctxt := ctxt sender. ]. ! Item was changed: ----- Method: Process>>printOn: (in category 'printing') ----- printOn: aStream super printOn: aStream. + aStream + nextPut: $(; + nextPutAll: self name; + nextPut: $). aStream nextPutAll: ' in '. suspendedContext printOn: aStream! From commits at source.squeak.org Sun Jan 24 14:46:54 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 14:46:54 0000 Subject: [squeak-dev] The Inbox: System-ct.1208.mcz Message-ID: Christoph Thiede uploaded a new version of System to project The Inbox: http://source.squeak.org/inbox/System-ct.1208.mcz ==================== Summary ==================== Name: System-ct.1208 Author: ct Time: 24 January 2021, 3:46:48.741384 pm UUID: d2a952ca-fe5d-0045-b089-f8702dbdbb1e Ancestors: System-eem.1207 Proposal: Adds query & browse selectors for finding certain primitive methods to SystemNavigation. Also excludes quick methods from #allPrimitiveMethods. Usage: self systemNavigation browseAllPrimitiveMethods. self systemNavigation allPrimitiveMethodsFor: 38. self systemNavigation browseAllPrimitiveMethodsFor: 62. self systemNavigation browseAllPrimitiveMethodsFor: 'primitiveFindSubstring'. =============== Diff against System-eem.1207 =============== Item was changed: ----- Method: SystemNavigation>>allPrimitiveMethods (in category 'query') ----- allPrimitiveMethods "Answer a collection of all the methods that are implemented by primitives." | result | result := OrderedCollection new. self allSelectorsAndMethodsDo: [ :behavior :selector :method | + (method isQuick not and: [method primitive ~= 0]) ifTrue: [ - method primitive ~= 0 ifTrue: [ result add: (String streamContents: [ :stream | stream nextPutAll: behavior name; space; nextPutAll: selector; space; print: method primitive ]) ] ]. ^result! Item was added: + ----- Method: SystemNavigation>>allPrimitiveMethodsFor: (in category 'query') ----- + allPrimitiveMethodsFor: primitiveIndexOrName + + ^ self allMethodsSelect: [:method | method primitive = primitiveIndexOrName + or: [method primitive = 117 and: [ | symbols | + symbols := method literalAt: 1. + symbols first = primitiveIndexOrName or: [symbols second = primitiveIndexOrName]]]]! Item was added: + ----- Method: SystemNavigation>>browseAllPrimitiveMethods (in category 'browse') ----- + browseAllPrimitiveMethods + + ^ self + browseMessageList: [self allPrimitiveMethods] + name: ('Primitive methods' translated)! Item was added: + ----- Method: SystemNavigation>>browseAllPrimitiveMethodsFor: (in category 'browse') ----- + browseAllPrimitiveMethodsFor: primitiveIndexOrName + + ^ self + browseMessageList: [self allPrimitiveMethodsFor: primitiveIndexOrName] + name: ('Primitive methods for {1}' translated format: {primitiveIndexOrName}) + autoSelect: primitiveIndexOrName asString! From eliot.miranda at gmail.com Sun Jan 24 14:55:42 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun, 24 Jan 2021 06:55:42 -0800 Subject: [squeak-dev] The Inbox: Kernel-ct.1368.mcz In-Reply-To: References: Message-ID: <0C656B9D-3EC4-483F-888E-CAA774A00C5F@gmail.com> Hi Christoph, only a few processes have a name. Surely this should test from there being a name and not print some noise if it doesn’t have a name. _,,,^..^,,,_ (phone) > On Jan 24, 2021, at 6:19 AM, commits at source.squeak.org wrote: > > A new version of Kernel was added to project The Inbox: > http://source.squeak.org/inbox/Kernel-ct.1368.mcz > > ==================== Summary ==================== > > Name: Kernel-ct.1368 > Author: ct > Time: 24 January 2021, 3:19:48.003384 pm > UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd > Ancestors: Kernel-mt.1364 > > Proposal: Always include process name into its print string. This facilitates debugging/inspecting of multiprocess scenarios. > > =============== Diff against Kernel-mt.1364 =============== > > Item was changed: > ----- Method: Process>>longPrintOn: (in category 'printing') ----- > longPrintOn: stream > > | ctxt | > super printOn: stream. > + stream > + nextPut: $(; > + nextPutAll: self name; > + nextPut: $). > stream cr. > ctxt := self suspendedContext. > [ctxt == nil] whileFalse: [ > stream space. > ctxt printOn: stream. > stream cr. > ctxt := ctxt sender. > ]. > ! > > Item was changed: > ----- Method: Process>>printOn: (in category 'printing') ----- > printOn: aStream > > super printOn: aStream. > + aStream > + nextPut: $(; > + nextPutAll: self name; > + nextPut: $). > aStream nextPutAll: ' in '. > suspendedContext printOn: aStream! > > From Christoph.Thiede at student.hpi.uni-potsdam.de Sun Jan 24 15:28:20 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Sun, 24 Jan 2021 15:28:20 +0000 Subject: [squeak-dev] The Inbox: Kernel-ct.1368.mcz In-Reply-To: <0C656B9D-3EC4-483F-888E-CAA774A00C5F@gmail.com> References: , <0C656B9D-3EC4-483F-888E-CAA774A00C5F@gmail.com> Message-ID: Hi Eliot, thanks for the feedback! I actually intended to print their short hash if they don't have a real name because this can still be very helpful in order to differentiate between multiple processes each suspended in the same method. It would also help me to identify a process from the process browser somewhere else. Do you get my point? :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Eliot Miranda Gesendet: Sonntag, 24. Januar 2021 15:55:42 An: squeak-dev at lists.squeakfoundation.org Betreff: Re: [squeak-dev] The Inbox: Kernel-ct.1368.mcz Hi Christoph, only a few processes have a name. Surely this should test from there being a name and not print some noise if it doesn’t have a name. _,,,^..^,,,_ (phone) > On Jan 24, 2021, at 6:19 AM, commits at source.squeak.org wrote: > > A new version of Kernel was added to project The Inbox: > http://source.squeak.org/inbox/Kernel-ct.1368.mcz > > ==================== Summary ==================== > > Name: Kernel-ct.1368 > Author: ct > Time: 24 January 2021, 3:19:48.003384 pm > UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd > Ancestors: Kernel-mt.1364 > > Proposal: Always include process name into its print string. This facilitates debugging/inspecting of multiprocess scenarios. > > =============== Diff against Kernel-mt.1364 =============== > > Item was changed: > ----- Method: Process>>longPrintOn: (in category 'printing') ----- > longPrintOn: stream > > | ctxt | > super printOn: stream. > + stream > + nextPut: $(; > + nextPutAll: self name; > + nextPut: $). > stream cr. > ctxt := self suspendedContext. > [ctxt == nil] whileFalse: [ > stream space. > ctxt printOn: stream. > stream cr. > ctxt := ctxt sender. > ]. > ! > > Item was changed: > ----- Method: Process>>printOn: (in category 'printing') ----- > printOn: aStream > > super printOn: aStream. > + aStream > + nextPut: $(; > + nextPutAll: self name; > + nextPut: $). > aStream nextPutAll: ' in '. > suspendedContext printOn: aStream! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Sun Jan 24 15:39:37 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 15:39:37 0000 Subject: [squeak-dev] The Inbox: KernelTests-ct.383.mcz Message-ID: A new version of KernelTests was added to project The Inbox: http://source.squeak.org/inbox/KernelTests-ct.383.mcz ==================== Summary ==================== Name: KernelTests-ct.383 Author: ct Time: 24 January 2021, 4:39:37.623504 pm UUID: 27645338-d085-9c45-ae2b-4263aade35b4 Ancestors: KernelTests-ct.382 Removes inappropriate test case for perform primitives with invalid number of arguments. Depends on KernelTests-ct.382. =============== Diff against KernelTests-ct.382 =============== Item was changed: SystemOrganization addCategory: #'KernelTests-Classes'! SystemOrganization addCategory: #'KernelTests-Methods'! SystemOrganization addCategory: #'KernelTests-Numbers'! SystemOrganization addCategory: #'KernelTests-Objects'! SystemOrganization addCategory: #'KernelTests-Processes'! + SystemOrganization addCategory: #'KernelTests-Models'! Item was added: + ----- Method: BlockClosureTest>>return: (in category 'private') ----- + return: something + + ^ something! Item was changed: ----- Method: BlockClosureTest>>testRunSimulated (in category 'tests') ----- testRunSimulated + self assert: Rectangle equals: + (Context runSimulated: aBlockClosure asContext) class. + self assert: 42 equals: + (Context runSimulated: [self return: 42]). + self + should: [Context runSimulated: [self halt]] + raise: Halt.! - self assert: Rectangle equals: (Context runSimulated: aBlockClosure asContext) class! Item was added: + ----- Method: BlockClosureTest>>testRunSimulatedContextAtEachStep (in category 'tests') ----- + testRunSimulatedContextAtEachStep + + | context | + context := aBlockClosure asContext. + self assert: Rectangle equals: (thisContext + runSimulated: context + contextAtEachStep: [:ctxt | self assert: + [ctxt == context or: [ctxt hasSender: context]]]) class.! Item was changed: ----- Method: ContextTest>>testPrimitive100 (in category 'tests') ----- testPrimitive100 { {#isNil. {}. Object}. "valid 0-arg message" {#=. {true}. UndefinedObject}. "valid unary message" {#ifNil:ifNotNil:. {[2]. [:x | x]}. Object}. "valid binary message" - {}. "missing selector" {#isNil}. "missing arguments" {#isNil. 'not an array'}. "invalid arguments" {#isNil. {}}. "missing lookupClass" {#isNil. {'excess arg'}. Object}. "too many arguments" {#=. {}. UndefinedObject}. "missing argument" {#isNil. {}. Boolean}. "lookupClass not in inheritance chain" } do: [:args | self assert: (Context runSimulated: [nil tryPrimitive: 100 withArgs: args]) equals: (nil tryPrimitive: 100 withArgs: args)].! Item was changed: ----- Method: ContextTest>>testPrimitive83 (in category 'tests') ----- testPrimitive83 { {#isNil}. "valid 0-arg message" {#=. true}. "valid unary message" {#ifNil:ifNotNil:. [2]. [:x | x]}. "valid binary message" - {}. "missing selector" {#isNil. 'excess arg'}. "too many arguments" {#=}. "missing argument" } do: [:args | self assert: (Context runSimulated: [nil tryPrimitive: 83 withArgs: args]) equals: (nil tryPrimitive: 83 withArgs: args)].! Item was changed: ----- Method: ContextTest>>testPrimitive84 (in category 'tests') ----- testPrimitive84 { {#isNil. {}}. "valid 0-arg message" {#=. {true}}. "valid unary message" {#ifNil:ifNotNil:. {[2]. [:x | x]}}. "valid binary message" - {}. "missing selector" {#isNil}. "missing arguments" {#isNil. 'not an array'}. "invalid arguments" {#isNil. {'excess arg'}}. "too many arguments" {#=. {}}. "missing argument" } do: [:args | self assert: (Context runSimulated: [nil tryPrimitive: 84 withArgs: args]) equals: (nil tryPrimitive: 84 withArgs: args)].! Item was added: + TestCase subclass: #ModelTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'KernelTests-Models'! Item was added: + ----- Method: ModelTest>>testCopyDependents (in category 'tests') ----- + testCopyDependents + + | bar foo | + foo := Model new. + foo addDependent: 42. + self assert: {42} equals: foo dependents asArray. + + bar := foo copy. + self assert: bar dependents isEmpty.! Item was added: + ----- Method: ObjectTest>>testCopyDependents (in category 'tests') ----- + testCopyDependents + + | bar foo | + foo := Object new. + foo addDependent: 42. + self assert: {42} equals: foo dependents asArray. + + bar := foo copy. + self assert: bar dependents isEmpty.! Item was added: + ----- Method: PromiseTest>>testNilErrBlockPropagation (in category 'tests - monad') ----- + testNilErrBlockPropagation + "https://promisesaplus.com section 2.2.7.4" + | p q | + p := Promise new. + q := p then: [:v | self error: 'Shouldn''t call resolvedBlock'] ifRejected: nil. + p rejectWith: 1. + self assert: p isRejected. + self assert: q isRejected. + self assert: p error equals: 1. + self assert: q error equals: 1.! Item was added: + ----- Method: PromiseTest>>testNilResolvedBlockPropagation (in category 'tests - monad') ----- + testNilResolvedBlockPropagation + "https://promisesaplus.com section 2.2.7.3" + | p q | + p := Promise new. + q := p then: nil ifRejected: [:e | self error: 'Shouldn''t call errBlock']. + p resolveWith: 1. + self assert: p isResolved. + self assert: q isResolved. + self assert: p value equals: 1. + self assert: q value equals: 1.! From commits at source.squeak.org Sun Jan 24 15:53:45 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 15:53:45 0000 Subject: [squeak-dev] The Inbox: Collections-ct.923.mcz Message-ID: A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ct.923.mcz ==================== Summary ==================== Name: Collections-ct.923 Author: ct Time: 24 January 2021, 4:53:44.716273 pm UUID: bd630b83-a77e-cb4f-a008-246786a5c7d8 Ancestors: Collections-mt.919 Fixes printString representation of Associations and Dictionarys to avoid ambiguous selectors. As a consequence, reevalabuality is not limited any longer. Examples: 1 -> 2. "--> 1->2" 1 -> -2. "--> 1 -> -2" Dictionary new at: -1 put: 1; at: 1 put: -1; yourself. "--> a Dictionary(-1->1 1 -> -1)" =============== Diff against Collections-mt.919 =============== Item was changed: ----- Method: Association>>printOn: (in category 'printing') ----- printOn: aStream + | arrow | super printOn: aStream. + + "Avoid AmbiguousSelector warnings when evaluating the stream as Smalltalk code." + arrow := ((key isSymbol and: [key isBinary]) + or: [(value printStringLimitedTo: 1) beginsWith: '-']) + ifTrue: [' -> '] + ifFalse: ['->']. - "If the key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." - arrow := (key isSymbol and: [key isBinary]) ifTrue: [' -> '] ifFalse: ['->']. aStream nextPutAll: arrow. + + value printOn: aStream.! - value printOn: aStream! Item was changed: ----- Method: Dictionary>>printElementsOn: (in category 'printing') ----- printElementsOn: aStream aStream nextPut: $(. self size > 100 ifTrue: [aStream nextPutAll: 'size '. self size printOn: aStream] ifFalse: [self keysInOrder + do: [:key | aStream print: (self associationAt: key)] + separatedBy: [aStream space]]. - do: [:key | aStream print: key; - nextPutAll: '->'; - print: (self at: key); - space]]. aStream nextPut: $)! From commits at source.squeak.org Sun Jan 24 15:55:31 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 15:55:31 0000 Subject: [squeak-dev] The Inbox: CollectionsTests-ct.348.mcz Message-ID: A new version of CollectionsTests was added to project The Inbox: http://source.squeak.org/inbox/CollectionsTests-ct.348.mcz ==================== Summary ==================== Name: CollectionsTests-ct.348 Author: ct Time: 24 January 2021, 4:55:30.561273 pm UUID: 342ca023-4467-d741-b42a-924ae0a72936 Ancestors: CollectionsTests-mt.346 Tests Collections-ct.921 (inbox, Dictionary newFromKeys:values:). =============== Diff against CollectionsTests-mt.346 =============== Item was added: + ----- Method: DictionaryTest>>testNewFromKeysValues (in category 'tests - basic') ----- + testNewFromKeysValues + + | actual expected | + actual := Dictionary + newFromKeys: #(2 3 1) + values: #(4 5 6). + expected := Dictionary new + at: 2 put: 4; + at: 3 put: 5; + at: 1 put: 6; + yourself. + + self assert: expected equals: actual.! Item was added: + ----- Method: DictionaryTest>>testNewFromPairs (in category 'tests - basic') ----- + testNewFromPairs + + | actual expected | + actual := Dictionary newFromPairs: { + #one. 'foo'. + #two. 2 @ 3 }. + expected := Dictionary new + at: #one put: 'foo'; + at: #two put: 2 @ 3; + yourself. + + self assert: expected equals: actual.! From commits at source.squeak.org Sun Jan 24 16:04:56 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 16:04:56 0000 Subject: [squeak-dev] The Inbox: Morphic-ct.1717.mcz Message-ID: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1717.mcz ==================== Summary ==================== Name: Morphic-ct.1717 Author: ct Time: 24 January 2021, 5:04:52.512273 pm UUID: c5d26f4c-059d-c54b-8c78-a7c9c06fc6db Ancestors: Morphic-mt.1710 Editor: Fixes the 9-enclosing bug, the inability to enclose a text into single quotes, and cleans up the #enclose: implementation. Pressing 9 while some text is selected now con{sist,veni}ently replaces the selection with a 9 as it is usual for every other digit key as well. If you would like to enclose the current selection within brackets, just enter the bracket (i.e. shift + 9 on a qwerty keyboard) as you would do for square brackets, quotes etc. too. Reuploaded again to replace Morphic-ct.1588, with the following changes applied: * Removed the entire keyboard-layout specific logic which was only needed for a VM hack from older times and apparently is not needed any longer * Eliminated Collections-ct.860 dependency, which will not be merged * Resolved merge conflicts * Minor refactoring, documentation, and stability improvements to the previous version * Compressed diff See also: http://forum.world.st/When-did-it-become-a-good-idea-for-selected-text-to-be-enclosed-by-instead-of-replaced-by-9-td4936276.html | http://forum.world.st/The-Inbox-Morphic-ct-1588-mcz-td5106961.html. Depends on Collections-ct.921. Please review! I'm really looking forward to see this in a Trunk soon because the Nine Bug bothers me every time I make some experiments in a fresh image ... ;-) =============== Diff against Morphic-mt.1710 =============== Item was changed: Object subclass: #Editor instanceVariableNames: 'morph' + classVariableNames: 'BlinkingCursor DestructiveBackWord DumbbellCursor EnclosingCharacterMap KeystrokeActions SelectionsMayShrink' - classVariableNames: 'BlinkingCursor DestructiveBackWord DumbbellCursor KeystrokeActions SelectionsMayShrink' poolDictionaries: '' category: 'Morphic-Text Support'! !Editor commentStamp: 'hjh 9/28/2017 11:37' prior: 0! New text editors. TextEditor provides most of the functionality that used to be in TextMorphEditor. SmalltalkEditor is has Smalltalk code specific features. ! Item was added: + ----- Method: Editor class>>enclosingCharacterMap (in category 'keyboard shortcut tables') ----- + enclosingCharacterMap + "Maps opening bracket characters to their closing equivalent. Used for encloseSelection preference. See senders." + + ^ EnclosingCharacterMap ifNil: [EnclosingCharacterMap := + Dictionary newFromKeys: '([<{|"''' values: ')]>}|"''']! Item was added: + ----- Method: Editor>>enclosingCharacterFor:ifNone: (in category 'private') ----- + enclosingCharacterFor: openingCharacter ifNone: aBlock + + ^ self enclosingCharacterMap + at: openingCharacter + ifAbsent: aBlock! Item was added: + ----- Method: Editor>>enclosingCharacterMap (in category 'accessing') ----- + enclosingCharacterMap + + ^ self class enclosingCharacterMap! Item was changed: ----- Method: TextEditor>>enclose: (in category 'editing keys') ----- enclose: aKeyboardEvent "Insert or remove bracket characters around the current selection." + | character left right startIndex stopIndex oldSelection text | - | character left right startIndex stopIndex oldSelection which t | - character := aKeyboardEvent shiftPressed - ifTrue: ['{}|"<>' at: ('[]\'',.' indexOf: aKeyboardEvent keyCharacter) ifAbsent: [aKeyboardEvent keyCharacter]] - ifFalse: [aKeyboardEvent keyCharacter]. self closeTypeIn. + + character := aKeyboardEvent keyCharacter. startIndex := self startIndex. stopIndex := self stopIndex. oldSelection := self selection. + left := character. + right := self enclosingCharacterFor: left ifNone: [^ false]. + + text := self text. + ((startIndex > 1 and: [stopIndex <= text size]) + and: [ (text at: startIndex - 1) = left and: [(text at: stopIndex) = right]]) - which := '([<{|"''9' indexOf: character ifAbsent: [ ^ false ]. - "Allow Control key in lieu of Alt+Shift for (, {, and double-quote." - left := ((Preferences cmdKeysInText and: [ aKeyboardEvent controlKeyPressed ]) - ifTrue: [ '({<{|""(' ] - ifFalse: ['([<{|"''(']) at: which. - right := ((Preferences cmdKeysInText and: [ aKeyboardEvent controlKeyPressed ]) - ifTrue: [ ')}>}|"")' ] - ifFalse: [')]>}|"'')']) at: which. - t := self text. - ((startIndex > 1 and: [stopIndex <= t size]) - and: [ (t at: startIndex-1) = left and: [(t at: stopIndex) = right]]) ifTrue: ["already enclosed; strip off brackets" self selectFrom: startIndex-1 to: stopIndex. self replaceSelectionWith: oldSelection] ifFalse: ["not enclosed; enclose by matching brackets" self replaceSelectionWith: (Text string: (String with: left), oldSelection string, (String with: right) attributes: emphasisHere). self selectFrom: startIndex+1 to: stopIndex]. ^true! From lewis at mail.msen.com Sun Jan 24 16:10:36 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 24 Jan 2021 11:10:36 -0500 Subject: [squeak-dev] The Inbox: Kernel-ct.1368.mcz In-Reply-To: References: <0C656B9D-3EC4-483F-888E-CAA774A00C5F@gmail.com> Message-ID: <20210124161036.GA46187@shell.msen.com> I like this proposal. It has no effect on the ProcessBrowser, and is helpful when looking at processes elsewhere. Most processes do not have a name, but all processes respond in a concise and useful way to #name. Process>>name ^name ifNil: [ self hash asString forceTo: 5 paddingStartWith: $ ] So +1 from me Dave On Sun, Jan 24, 2021 at 03:28:20PM +0000, Thiede, Christoph wrote: > Hi Eliot, > > > thanks for the feedback! I actually intended to print their short hash if they don't have a real name because this can still be very helpful in order to differentiate between multiple processes each suspended in the same method. It would also help me to identify a process from the process browser somewhere else. Do you get my point? :-) > > > Best, > > Christoph > > > ________________________________ > Von: Squeak-dev im Auftrag von Eliot Miranda > Gesendet: Sonntag, 24. Januar 2021 15:55:42 > An: squeak-dev at lists.squeakfoundation.org > Betreff: Re: [squeak-dev] The Inbox: Kernel-ct.1368.mcz > > Hi Christoph, > > only a few processes have a name. Surely this should test from there being a name and not print some noise if it doesn???t have a name. > > _,,,^..^,,,_ (phone) > > > On Jan 24, 2021, at 6:19 AM, commits at source.squeak.org wrote: > > > > ???A new version of Kernel was added to project The Inbox: > > http://source.squeak.org/inbox/Kernel-ct.1368.mcz > > > > ==================== Summary ==================== > > > > Name: Kernel-ct.1368 > > Author: ct > > Time: 24 January 2021, 3:19:48.003384 pm > > UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd > > Ancestors: Kernel-mt.1364 > > > > Proposal: Always include process name into its print string. This facilitates debugging/inspecting of multiprocess scenarios. > > > > =============== Diff against Kernel-mt.1364 =============== > > > > Item was changed: > > ----- Method: Process>>longPrintOn: (in category 'printing') ----- > > longPrintOn: stream > > > > | ctxt | > > super printOn: stream. > > + stream > > + nextPut: $(; > > + nextPutAll: self name; > > + nextPut: $). > > stream cr. > > ctxt := self suspendedContext. > > [ctxt == nil] whileFalse: [ > > stream space. > > ctxt printOn: stream. > > stream cr. > > ctxt := ctxt sender. > > ]. > > ! > > > > Item was changed: > > ----- Method: Process>>printOn: (in category 'printing') ----- > > printOn: aStream > > > > super printOn: aStream. > > + aStream > > + nextPut: $(; > > + nextPutAll: self name; > > + nextPut: $). > > aStream nextPutAll: ' in '. > > suspendedContext printOn: aStream! > > > > > > From commits at source.squeak.org Sun Jan 24 16:23:03 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 16:23:03 0000 Subject: [squeak-dev] The Inbox: Morphic-ct.1718.mcz Message-ID: 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.! From Christoph.Thiede at student.hpi.uni-potsdam.de Sun Jan 24 18:03:57 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Sun, 24 Jan 2021 18:03:57 +0000 Subject: [squeak-dev] The Trunk: Morphic-mt.1716.mcz In-Reply-To: References: Message-ID: <214b3aeb6f1c4406aa66e83921190da9@student.hpi.uni-potsdam.de> Hi Marcel, thanks for these fixes! :-) A few additional notes about DialogWindows in general: * We should (finally) move the grips to the window border itself to make it consistent with regular windows. * Grips & scrollbars are not hi-dpi-aware. * The minimum extent of the DialogWindow title itself is neither, I think: [cid:35e5cd17-a387-44d6-a6b7-467475958932] :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von commits at source.squeak.org Gesendet: Dienstag, 12. Januar 2021 14:52 Uhr An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org Betreff: [squeak-dev] The Trunk: Morphic-mt.1716.mcz Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1716.mcz ==================== Summary ==================== Name: Morphic-mt.1716 Author: mt Time: 12 January 2021, 2:52:47.977356 pm UUID: 93f95f53-4457-5e4c-a157-5cbf89aa7328 Ancestors: Morphic-mt.1715 Fixes a bug in resize grips (having #rigid targets) that are placed within layouted (usually #shrinkWrap) owners. This makes all grips in resizable dialogs finally work as expected. I still consider this a #workaround to be improved. =============== Diff against Morphic-mt.1715 =============== Item was changed: ----- Method: BorderedMorph>>doFastWindowReframe: (in category 'resize handling') ----- doFastWindowReframe: ptName + | newBounds delta | - | newBounds | "For fast display, only higlight the rectangle during loop" newBounds := self bounds newRectButtonPressedDo: [:f | f withSideOrCorner: ptName setToPoint: (self pointFromWorld: Sensor cursorPoint) minExtent: self minimumExtent]. + delta := newBounds origin - self bounds origin. self bounds: newBounds. + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner topLeft: owner topLeft + delta]]. ^newBounds.! Item was changed: ----- Method: BottomLeftGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner + (0 @ delta y)). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner left: owner left + delta x]].! - bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner + (0 @ delta y))! Item was changed: ----- Method: LeftGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner left: owner left + delta x]].! - bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner)! Item was changed: ----- Method: TopGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + (0 @ delta y) corner: oldBounds corner). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner top: owner top + delta y]].! - bounds: (oldBounds origin + (0 @ delta y) corner: oldBounds corner)! Item was changed: ----- Method: TopLeftGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + delta corner: oldBounds corner). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner topLeft: owner topLeft + delta]].! - bounds: (oldBounds origin + delta corner: oldBounds corner)! Item was changed: ----- Method: TopRightGripMorph>>apply: (in category 'target resize') ----- apply: delta | oldBounds | oldBounds := self target bounds. self target + bounds: (oldBounds origin + (0 at delta y) corner: oldBounds corner + (delta x @ 0)). + self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." + self target allOwnersDo: [:owner | + owner layoutPolicy ifNotNil: [owner top: owner top + delta y]].! - bounds: (oldBounds origin + (0 at delta y) corner: oldBounds corner + (delta x @ 0))! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedImage.png Type: image/png Size: 6873 bytes Desc: pastedImage.png URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Sun Jan 24 18:06:41 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Sun, 24 Jan 2021 18:06:41 +0000 Subject: [squeak-dev] The Trunk: Tools-mt.1024.mcz In-Reply-To: References: , Message-ID: <0a899bd15d2c4f91b73c41411a09a85f@student.hpi.uni-potsdam.de> Beautiful! Nearly "too" modern to fit into the entire Squeak appearance - but a very nice step into the right direction ... :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 14. Januar 2021 13:24:13 An: squeak-dev Betreff: Re: [squeak-dev] The Trunk: Tools-mt.1024.mcz [cid:bd0db97b-c71b-4b55-8971-cac77123c8a3] [cid:c6093f57-b2bc-4492-8da6-e84c83a209cd] [cid:e75d4543-f749-4fbe-af37-1dc8f5b33e01] Best, Marcel Am 14.01.2021 13:21:28 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-mt.1024.mcz ==================== Summary ==================== Name: Tools-mt.1024 Author: mt Time: 14 January 2021, 1:21:15.354081 pm UUID: 0ef67378-0ca6-4743-be9c-5a60621c07cd Ancestors: Tools-mt.1023 Improves the description of several confirmation dialogs for removing batches of source code. =============== Diff against Tools-mt.1023 =============== Item was changed: ----- Method: Browser>>removeMessageCategory (in category 'message category functions') ----- removeMessageCategory "If a message category is selected, create a Confirmer so the user can verify that the currently selected message category should be removed from the system. If so, remove it." | messageCategoryName | self hasMessageCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. messageCategoryName := self selectedMessageCategoryName. (self messageList size = 0 + or: [Project uiManager confirm: ('Are you sure you want to remove\the message category\\ {1}\ in {2}\\and all its {3} methods? Maybe save\your image before doing this.' translated withCRs asText format: { + messageCategoryName asText allBold. + self selectedClassOrMetaClass name. + (self selectedClassOrMetaClass organization listAtCategoryNamed: messageCategoryName) size asString asText allBold + + }) title: 'Remove Message Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this method category - and all its methods?']) ifTrue: [self selectedClassOrMetaClass removeCategory: messageCategoryName. self selectMessageCategoryNamed: nil. self changed: #classSelectionChanged]. self changed: #messageCategoryList. ! Item was changed: ----- Method: Browser>>removeSystemCategory (in category 'system category functions') ----- removeSystemCategory "If a class category is selected, create a Confirmer so the user can verify that the currently selected class category and all of its classes should be removed from the system. If so, remove it." self hasSystemCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. (self classList size = 0 + or: [Project uiManager + confirm: ('Are you sure you want to remove\the system category\\ {1}\\and all its {2} classes? Maybe save\your image before doing this.' translated withCRs asText + format: { + self selectedSystemCategory asText allBold. + (systemOrganizer listAtCategoryNamed: self selectedSystemCategory) size asString asText allBold}) + title: 'Remove System Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this system category - and all its classes?']) ifTrue: [| nextSelectedCat | nextSelectedCat := self systemCategoryList before: self selectedSystemCategory ifAbsent: [nil]. systemOrganizer removeSystemCategory: self selectedSystemCategory. self selectSystemCategory: nextSelectedCat. self changed: #systemCategoryList]! Item was changed: ----- Method: CodeHolder>>removeClass (in category 'commands') ----- removeClass "Remove the selected class from the system, at interactive user request. Make certain the user really wants to do this, since it is not reversible. Answer true if removal actually happened." | message className classToRemove result | self okToChange ifFalse: [^ false]. classToRemove := self selectedClassOrMetaClass ifNil: [Beeper beep. ^ false]. classToRemove := classToRemove theNonMetaClass. className := classToRemove name. + message := 'Are you sure that you want to remove\the class\\ {1}\\and all its {2} methods? Maybe save\your image before doing this.{3}' translated withCRs asText format: { + className asText allBold. + (classToRemove methodDict size + classToRemove class methodDict size) asString asText allBold. + classToRemove subclasses size > 0 ifFalse: [''] ifTrue: [ + '\\(There are {1} subclasses, whose superclass\must be updated manually after this.)' translated withCRs asText format: { classToRemove subclasses size asString asText allBold }]}. + (result := Project uiManager confirm: message title: 'Remove Class' translated) - message := 'Are you certain that you - want to REMOVE the class ', className, ' - from the system?'. - (result := self confirm: message) ifTrue: [classToRemove subclasses size > 0 ifTrue: [(self confirm: 'class has subclasses: ' , message) ifFalse: [^ false]]. classToRemove removeFromSystem. self changed: #classList. true]. ^ result! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 29075 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 22215 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24309 bytes Desc: image.png URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Sun Jan 24 18:08:21 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Sun, 24 Jan 2021 18:08:21 +0000 Subject: [squeak-dev] The Trunk: System-eem.1211.mcz In-Reply-To: References: Message-ID: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> Hm ... would it be presumptuous to say: 'Copyright © 2010-{1} Squeak Community Contributors.' format: {2021 max: Date today year} ? :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von commits at source.squeak.org Gesendet: Sonntag, 24. Januar 2021 03:07:22 An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org Betreff: [squeak-dev] The Trunk: System-eem.1211.mcz Eliot Miranda uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-eem.1211.mcz ==================== Summary ==================== Name: System-eem.1211 Author: eem Time: 23 January 2021, 6:07:18.034021 pm UUID: 89999499-d83c-478b-9044-5dee2fe443df Ancestors: System-dtl.1210 Update the system's copyright. =============== Diff against System-dtl.1210 =============== Item was changed: ----- Method: SmalltalkImage>>copyright (in category 'sources, changes log') ----- copyright "The Smalltalk copyright." + ^'Copyright © Xerox Corp. 1981, 1982 All rights reserved. + Copyright © Apple Computer, Inc. 1985-1996 All rights reserved; + Copyright © 2010-2021 Squeak Community Contributors.'! - ^'Copyright (c) Xerox Corp. 1981, 1982 All rights reserved. - Copyright (c) Apple Computer, Inc. 1985-1996 All rights reserved.'! -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Sun Jan 24 18:39:01 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sun, 24 Jan 2021 19:39:01 +0100 (CET) Subject: [squeak-dev] 20X speedup for read file upToEnd In-Reply-To: <20210123205508.GA76730@shell.msen.com> References: <20210122232408.GA78147@shell.msen.com> <20210123205508.GA76730@shell.msen.com> Message-ID: Hi Dave, On Sat, 23 Jan 2021, David T. Lewis wrote: > Hi Levente, > > Thanks, that looks better. Do you want to commit the update to keep > the author initials right? If not I'll commit it and credit you in > the commit comment. I'll commit those two methods. > > As an aside, this also makes me notice that #upToEnd does not work > for file streams that do not know their size, such as FileStream > stdin, on any file stream on an OS Pipe. It depends on what the expected behavior is in that case. If it is to read all available data, then I think it works. If it is to read until the stream is #atEnd, then no, it doesn't work. Levente > > Here is the variation that I did (back in 2006) for OSProcess, which > uses AttachableFileStream subclassed from StandardFileStream: > > AttachableFileStream>>upToEnd > "Answer a subcollection from the current access position through the last element > of the receiver. This is slower than the method in StandardFileStream, but it > works with pipes which answer false to #atEnd when no further input is > currently available, but the pipe is not yet closed." > > | newStream buffer nextBytes | > buffer := buffer1 species new: 1000. > newStream := WriteStream on: (buffer1 species new: 100). > [self atEnd or: [(nextBytes := self nextInto: buffer) isEmpty]] > whileFalse: [newStream nextPutAll: nextBytes]. > ^ newStream contents > > The AttachableFileStream hack in OSProcess really needs to go away, > so I think I'd to find a way to make these things work with good > performance on any kind of file stream. But that is a topic for another > thread. > > Thanks, > Dave > > On Sat, Jan 23, 2021 at 08:58:07PM +0100, Levente Uzonyi wrote: >> Hi Dave, >> >> Good catch. That method of StandardFileStream, unlike #upTo: and >> #upToAnyOf:do:, has not been optimized. >> >> IMO, StandardFileStream >> #upToEnd should simply be >> >> ^self next: self size - self position >> >> And I suggest your implementation be added to MultiByteFileStream with the >> following modifications: >> >> upToEnd >> "Answer a subcollection from the current access position through the >> last element of the receiver." >> >> | remainingEstimate | >> self isBinary ifTrue: [ ^super upToEnd ]. >> remainingEstimate := self size - self position. >> ^self collectionSpecies >> new: remainingEstimate >> streamContents: [ :stream | >> | elements chunkSize | >> chunkSize := remainingEstimate min: 2000. "It's not >> worth allocating larger chunks" >> [ (elements := self next: chunkSize) isEmpty ] >> whileFalse: [ >> stream nextPutAll: elements ] ] >> >> >> Levente >> >> On Fri, 22 Jan 2021, David T. Lewis wrote: >> >> >Attached is a small change that gives a big performance boost for reading >> >a file upToEnd. My use case (where I noticed this) is reading an image >> >file, where the file is opened, the header is read, and the remainder of >> >the file upToEnd is read in as the object memory: >> > >> > fs := FileStream readOnlyFileNamed: Smalltalk imageName. fs binary. >> > t := Time millisecondsToRun: [ImageSnapshot fromStream: fs]. >> > fs close. >> > t >> > ==> 12428 "original implementation" >> > ==> 645 "new version" >> > >> >Overall speedup is about 20X for MultiByteFileStream and over 100x for >> >StandardFileStream (difference due to Levente's earlier improvements >> >in MultiByteFileStream). >> > >> >This small change touches two packages so I'm posting it as a change set >> >for comment. I'll put it in trunk if there are no issues. >> > >> >Dave >> > >> > >> From christoph.thiede at student.hpi.uni-potsdam.de Sun Jan 24 18:57:33 2021 From: christoph.thiede at student.hpi.uni-potsdam.de (Christoph Thiede) Date: Sun, 24 Jan 2021 12:57:33 -0600 (CST) Subject: [squeak-dev] Fwd: [OpenSmalltalk/opensmalltalk-vm] Trouble running OSVM in an Ubuntu 20/aarch64 docker (raspi) (#544) In-Reply-To: References: <5b2c27a3e2b64e5dbfcfd3b41b555e1f@student.hpi.uni-potsdam.de> <1609352251-e5fe5cf9bc6eae7a6a88106269547f22@pckswarms.ch> <1609352459-5256fcd7eb69c2aa1bfee8434efb77f3@pckswarms.ch> <3bdb5f914f0d4dc08061f0344fef19d9@student.hpi.uni-potsdam.de> Message-ID: <1611514653533-0.post@n4.nabble.com> Hi all, thanks a lot for your help. In the meantime, I have finally been able to succeed in the entire build process. Because it was a quite costly setup, I have summarized all relevant docker files and build scripts in this repository: https://github.com/LinqLover/squeak-raspi-docker Please feel free to add your suggestions for improvements or to share this link! :-) Happy Squeaking, Christoph ----- Carpe Squeak! -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From commits at source.squeak.org Sun Jan 24 20:24:28 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 24 Jan 2021 20:24:28 0000 Subject: [squeak-dev] The Inbox: CommandLine-ct.19.mcz Message-ID: Christoph Thiede uploaded a new version of CommandLine to project The Inbox: http://source.squeak.org/inbox/CommandLine-ct.19.mcz ==================== Summary ==================== Name: CommandLine-ct.19 Author: ct Time: 24 January 2021, 9:24:27.349384 pm UUID: 14c388f7-bb9a-874f-9759-e2e6e8b27957 Ancestors: CommandLine-TheresaHMartenK.17 Don't quit the VM when a warning was raised in a command-line context. The intention of a Warning is to "be brought to the attention of the user", but is only a kind of Notification ("if it is not handled, it will pass by without effect"), so in contrast to an error ("the current computation is terminated"), there is no need to interrupt the entire execution. Au contraire, this has often been a very tedious behavior; for example, if you use a deprecated selector in smalltalkCI, it is a good thing to be notified about this incident, but it is a bad thing to interrupt the entire execution just because such an incident has been reported. Note that smalltalkCI is only one example of many; any headless server image should not crash upon a simple deprecation warning for the same reason. =============== Diff against CommandLine-TheresaHMartenK.17 =============== Item was changed: ----- Method: CommandLineToolSet class>>handleWarning: (in category 'debugging - handlers') ----- handleWarning: aWarning + aWarning printVerboseOn: FileStream stderr. + FileStream stderr flush.! - self handleError: aWarning.! From lewis at mail.msen.com Sun Jan 24 20:56:59 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 24 Jan 2021 15:56:59 -0500 Subject: [squeak-dev] 20X speedup for read file upToEnd In-Reply-To: References: <20210122232408.GA78147@shell.msen.com> <20210123205508.GA76730@shell.msen.com> Message-ID: <20210124205659.GA86197@shell.msen.com> On Sun, Jan 24, 2021 at 07:39:01PM +0100, Levente Uzonyi wrote: > Hi Dave, > > On Sat, 23 Jan 2021, David T. Lewis wrote: > > >Hi Levente, > > > >Thanks, that looks better. Do you want to commit the update to keep > >the author initials right? If not I'll commit it and credit you in > >the commit comment. > > I'll commit those two methods. > Thanks. I should add that with your final version, I now see a 35x speedup for MultiByteFileSteam and 200x speedup for StandardFileStream. Not bad for a small tweak :-) Dave From eliot.miranda at gmail.com Sun Jan 24 21:57:21 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun, 24 Jan 2021 13:57:21 -0800 Subject: [squeak-dev] The Trunk: System-eem.1211.mcz In-Reply-To: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> References: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> Message-ID: > On Jan 24, 2021, at 10:08 AM, Thiede, Christoph wrote: > >  > Hm ... would it be presumptuous to say: > > > > 'Copyright © 2010-{1} Squeak Community Contributors.' format: {2021 max: Date today year} > > > > ? :-) > I *love* it! Commit it immediately!! > > Best, > > Christoph > > Von: Squeak-dev im Auftrag von commits at source.squeak.org > Gesendet: Sonntag, 24. Januar 2021 03:07:22 > An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org > Betreff: [squeak-dev] The Trunk: System-eem.1211.mcz > > Eliot Miranda uploaded a new version of System to project The Trunk: > http://source.squeak.org/trunk/System-eem.1211.mcz > > ==================== Summary ==================== > > Name: System-eem.1211 > Author: eem > Time: 23 January 2021, 6:07:18.034021 pm > UUID: 89999499-d83c-478b-9044-5dee2fe443df > Ancestors: System-dtl.1210 > > Update the system's copyright. > > =============== Diff against System-dtl.1210 =============== > > Item was changed: > ----- Method: SmalltalkImage>>copyright (in category 'sources, changes log') ----- > copyright > "The Smalltalk copyright." > > + ^'Copyright © Xerox Corp. 1981, 1982 All rights reserved. > + Copyright © Apple Computer, Inc. 1985-1996 All rights reserved; > + Copyright © 2010-2021 Squeak Community Contributors.'! > - ^'Copyright (c) Xerox Corp. 1981, 1982 All rights reserved. > - Copyright (c) Apple Computer, Inc. 1985-1996 All rights reserved.'! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Mon Jan 25 01:17:03 2021 From: tim at rowledge.org (tim Rowledge) Date: Sun, 24 Jan 2021 17:17:03 -0800 Subject: [squeak-dev] Squeak 5.3 suitable FFI version(s)? Message-ID: Whilst loading FFI into a *5.3* image (ie not trunk) I notice that the latest versions (post FFI-Kernel-mt.106, 13 June 2020) changed Parser>>externalFunctionDeclaration to use #beWritableObject which is not part of the 5.3 image. The question is "which version of FFI-Pools and FFI-Kernel are actually the preferred ones for a 5.3 image"? The SqueakMap entry didn't get updated, so that offers no clues. None of the MC packages I've trawled through have any comment about being The Right One. Does anyone remember? I'd quite like to use the versions that we released with the image for this. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: WFL: Wave FLag From marcel.taeumel at hpi.de Mon Jan 25 10:12:43 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 11:12:43 +0100 Subject: [squeak-dev] Squeak 5.3 suitable FFI version(s)? In-Reply-To: References: Message-ID: Hi Tim. For Squeak 5.3, use the Metacello script: Metacello new configuration: 'FFI'; load. Latest version for 5.3 is FFI version 1.13 with: - FFI-Pools.TorstenBergmann.4 - FFI-Kernel-nice.68 - FFI-Tests-nice.14 - FFI-MacOS-spd.5 - FFI-Win32-cbc.16 - FFI-Unix-mtf.4 Best, Marcel Am 25.01.2021 02:17:19 schrieb tim Rowledge : Whilst loading FFI into a *5.3* image (ie not trunk) I notice that the latest versions (post FFI-Kernel-mt.106, 13 June 2020) changed Parser>>externalFunctionDeclaration to use #beWritableObject which is not part of the 5.3 image. The question is "which version of FFI-Pools and FFI-Kernel are actually the preferred ones for a 5.3 image"? The SqueakMap entry didn't get updated, so that offers no clues. None of the MC packages I've trawled through have any comment about being The Right One. Does anyone remember? I'd quite like to use the versions that we released with the image for this. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: WFL: Wave FLag -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Mon Jan 25 10:20:00 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 25 Jan 2021 10:20:00 0000 Subject: [squeak-dev] The Trunk: System-mt.1213.mcz Message-ID: Marcel Taeumel uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-mt.1213.mcz ==================== Summary ==================== Name: System-mt.1213 Author: mt Time: 25 January 2021, 11:19:56.266394 am UUID: 636c816e-5594-a445-bfc8-1f6e9681cdc3 Ancestors: System-eem.1212 Updates copyright in license. =============== Diff against System-eem.1212 =============== Item was changed: ----- Method: SmalltalkImage>>license (in category 'license') ----- license "This method was automatically generated. Edit it using:" "SqueakLicenseHelp edit: #officialLicense" ^ ( 'The current release of Squeak is a combination of source code originating from Apple which Apple agreed to license under the Apache License and more recent contributions licensed under the MIT license. The vast majority of the code is under the MIT License: MIT License + Copyright (c) The individual, corporate, and institutional contributors who have collectively contributed elements to this software ("The Squeak Community"), 1996-2021 All rights reserved. - Copyright (c) The individual, corporate, and institutional contributors who have collectively contributed elements to this software ("The Squeak Community"), 1996-2020 All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Portions of Squeak are covered by the Apache License: Apache License, Version 2.0 Copyright (c) Xerox Corp. 1981, 1982 All rights reserved. Copyright (c) Apple Computer, Inc. 1985-1996 All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. !! ]style[(258 1 11 1216 53 2 27 297 42 308)c159159159,,b,,c159159159,,b,,Rhttp://www.apache.org/licenses/LICENSE-2.0;,!!' readStream nextChunkText)! From marcel.taeumel at hpi.de Mon Jan 25 10:22:34 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 11:22:34 +0100 Subject: [squeak-dev] The Trunk: System-eem.1211.mcz In-Reply-To: References: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> Message-ID: Why is that "1996-2010 Viewpoints" not reflected in Squeak's #license? Maybe we can remove the #copyright method alltogether because #license contains all copyright information? Best, Marcel Am 24.01.2021 22:57:35 schrieb Eliot Miranda : On Jan 24, 2021, at 10:08 AM, Thiede, Christoph wrote:  Hm ... would it be presumptuous to say: 'Copyright © 2010-{1} Squeak Community Contributors.' format: {2021 max: Date today year} ? :-) I *love* it!  Commit it immediately!! Best, Christoph [http://www.hpi.de/] Von: Squeak-dev im Auftrag von commits at source.squeak.org Gesendet: Sonntag, 24. Januar 2021 03:07:22 An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org Betreff: [squeak-dev] The Trunk: System-eem.1211.mcz   Eliot Miranda uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-eem.1211.mcz [http://source.squeak.org/trunk/System-eem.1211.mcz] ==================== Summary ==================== Name: System-eem.1211 Author: eem Time: 23 January 2021, 6:07:18.034021 pm UUID: 89999499-d83c-478b-9044-5dee2fe443df Ancestors: System-dtl.1210 Update the system's copyright. =============== Diff against System-dtl.1210 =============== Item was changed:   ----- Method: SmalltalkImage>>copyright (in category 'sources, changes log') -----   copyright          "The Smalltalk copyright."   +        ^'Copyright © Xerox Corp. 1981, 1982 All rights reserved. + Copyright © Apple Computer, Inc. 1985-1996 All rights reserved; + Copyright © 2010-2021 Squeak Community Contributors.'! -        ^'Copyright (c) Xerox Corp. 1981, 1982 All rights reserved. - Copyright (c) Apple Computer, Inc. 1985-1996 All rights reserved.'! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 25 10:26:15 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 11:26:15 +0100 Subject: [squeak-dev] The Trunk: Tools-mt.1024.mcz In-Reply-To: <0a899bd15d2c4f91b73c41411a09a85f@student.hpi.uni-potsdam.de> References: <,> <0a899bd15d2c4f91b73c41411a09a85f@student.hpi.uni-potsdam.de> Message-ID: > Nearly "too" modern to fit into [...] How come? Too wordy? :-) > but a very nice step into the right direction ... :-) Unfortunately, "manual checkpointing" is the only "undo method" we can provide at this level.  Best, Marcel Am 24.01.2021 19:06:56 schrieb Thiede, Christoph : Beautiful! Nearly "too" modern to fit into the entire Squeak appearance - but a very nice step into the right direction ... :-) Best, Christoph [http://www.hpi.de/] Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 14. Januar 2021 13:24:13 An: squeak-dev Betreff: Re: [squeak-dev] The Trunk: Tools-mt.1024.mcz   Best, Marcel Am 14.01.2021 13:21:28 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-mt.1024.mcz ==================== Summary ==================== Name: Tools-mt.1024 Author: mt Time: 14 January 2021, 1:21:15.354081 pm UUID: 0ef67378-0ca6-4743-be9c-5a60621c07cd Ancestors: Tools-mt.1023 Improves the description of several confirmation dialogs for removing batches of source code. =============== Diff against Tools-mt.1023 =============== Item was changed: ----- Method: Browser>>removeMessageCategory (in category 'message category functions') ----- removeMessageCategory "If a message category is selected, create a Confirmer so the user can verify that the currently selected message category should be removed from the system. If so, remove it." | messageCategoryName | self hasMessageCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. messageCategoryName := self selectedMessageCategoryName. (self messageList size = 0 + or: [Project uiManager confirm: ('Are you sure you want to remove\the message category\\ {1}\ in {2}\\and all its {3} methods? Maybe save\your image before doing this.' translated withCRs asText format: { + messageCategoryName asText allBold. + self selectedClassOrMetaClass name. + (self selectedClassOrMetaClass organization listAtCategoryNamed: messageCategoryName) size asString asText allBold + + }) title: 'Remove Message Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this method category - and all its methods?']) ifTrue: [self selectedClassOrMetaClass removeCategory: messageCategoryName. self selectMessageCategoryNamed: nil. self changed: #classSelectionChanged]. self changed: #messageCategoryList. ! Item was changed: ----- Method: Browser>>removeSystemCategory (in category 'system category functions') ----- removeSystemCategory "If a class category is selected, create a Confirmer so the user can verify that the currently selected class category and all of its classes should be removed from the system. If so, remove it." self hasSystemCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. (self classList size = 0 + or: [Project uiManager + confirm: ('Are you sure you want to remove\the system category\\ {1}\\and all its {2} classes? Maybe save\your image before doing this.' translated withCRs asText + format: { + self selectedSystemCategory asText allBold. + (systemOrganizer listAtCategoryNamed: self selectedSystemCategory) size asString asText allBold}) + title: 'Remove System Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this system category - and all its classes?']) ifTrue: [| nextSelectedCat | nextSelectedCat := self systemCategoryList before: self selectedSystemCategory ifAbsent: [nil]. systemOrganizer removeSystemCategory: self selectedSystemCategory. self selectSystemCategory: nextSelectedCat. self changed: #systemCategoryList]! Item was changed: ----- Method: CodeHolder>>removeClass (in category 'commands') ----- removeClass "Remove the selected class from the system, at interactive user request. Make certain the user really wants to do this, since it is not reversible. Answer true if removal actually happened." | message className classToRemove result | self okToChange ifFalse: [^ false]. classToRemove := self selectedClassOrMetaClass ifNil: [Beeper beep. ^ false]. classToRemove := classToRemove theNonMetaClass. className := classToRemove name. + message := 'Are you sure that you want to remove\the class\\ {1}\\and all its {2} methods? Maybe save\your image before doing this.{3}' translated withCRs asText format: { + className asText allBold. + (classToRemove methodDict size + classToRemove class methodDict size) asString asText allBold. + classToRemove subclasses size > 0 ifFalse: [''] ifTrue: [ + '\\(There are {1} subclasses, whose superclass\must be updated manually after this.)' translated withCRs asText format: { classToRemove subclasses size asString asText allBold }]}. + (result := Project uiManager confirm: message title: 'Remove Class' translated) - message := 'Are you certain that you - want to REMOVE the class ', className, ' - from the system?'. - (result := self confirm: message) ifTrue: [classToRemove subclasses size > 0 ifTrue: [(self confirm: 'class has subclasses: ' , message) ifFalse: [^ false]]. classToRemove removeFromSystem. self changed: #classList. true]. ^ result! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 29075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 22215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24309 bytes Desc: not available URL: From marcel.taeumel at hpi.de Mon Jan 25 10:30:27 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 11:30:27 +0100 Subject: [squeak-dev] The Trunk: Morphic-mt.1716.mcz In-Reply-To: <214b3aeb6f1c4406aa66e83921190da9@student.hpi.uni-potsdam.de> References: <214b3aeb6f1c4406aa66e83921190da9@student.hpi.uni-potsdam.de> Message-ID: > We should (finally) move the grips to the window border itself to make it consistent with regular windows. It's a compromise. Given the mixed uses of dialog window, having the grips in the inner content makes the code easier to implement. But have a look at it yourself. :-) > Grips & scrollbars are not hi-dpi-aware. See "handle length" and "grip thickness" in the preferences. Disabling "scrollbars narrow" can help in hi-dpi. Yet, "ScrollPane class >> #scrollBarThickness" is still hard-coded. > The minimum extent of the DialogWindow title itself is neither, [...] Unfortunately, (New)Paragraph cannot avoid sub-word wrapping. Best, Marcel Am 24.01.2021 19:04:08 schrieb Thiede, Christoph : Hi Marcel, thanks for these fixes! :-) A few additional notes about DialogWindows in general: * We should (finally) move the grips to the window border itself to make it consistent with regular windows. * Grips & scrollbars are not hi-dpi-aware. * The minimum extent of the DialogWindow title itself is neither, I think: :-) [http://www.hpi.de/] Best, Christoph Von: Squeak-dev im Auftrag von commits at source.squeak.org Gesendet: Dienstag, 12. Januar 2021 14:52 Uhr An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org Betreff: [squeak-dev] The Trunk: Morphic-mt.1716.mcz   Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1716.mcz [http://source.squeak.org/trunk/Morphic-mt.1716.mcz] ==================== Summary ==================== Name: Morphic-mt.1716 Author: mt Time: 12 January 2021, 2:52:47.977356 pm UUID: 93f95f53-4457-5e4c-a157-5cbf89aa7328 Ancestors: Morphic-mt.1715 Fixes a bug in resize grips (having #rigid targets) that are placed within layouted (usually #shrinkWrap) owners. This makes all grips in resizable dialogs finally work as expected. I still consider this a #workaround to be improved. =============== Diff against Morphic-mt.1715 =============== Item was changed:   ----- Method: BorderedMorph>>doFastWindowReframe: (in category 'resize handling') -----   doFastWindowReframe: ptName   +        | newBounds delta | -        | newBounds |          "For fast display, only higlight the rectangle during loop"          newBounds := self bounds newRectButtonPressedDo: [:f |                  f                          withSideOrCorner: ptName                          setToPoint: (self pointFromWorld: Sensor cursorPoint)                          minExtent: self minimumExtent]. +        delta := newBounds origin - self bounds origin.          self bounds: newBounds. +        self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." +        self allOwnersDo: [:owner | +                owner layoutPolicy ifNotNil: [owner topLeft: owner topLeft + delta]].          ^newBounds.! Item was changed:   ----- Method: BottomLeftGripMorph>>apply: (in category 'target resize') -----   apply: delta          | oldBounds |          oldBounds := self target bounds.          self target +                bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner + (0 @ delta y)). +        self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." +        self target allOwnersDo: [:owner | +                owner layoutPolicy ifNotNil: [owner left: owner left + delta x]].! -                bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner + (0 @ delta y))! Item was changed:   ----- Method: LeftGripMorph>>apply: (in category 'target resize') -----   apply: delta          | oldBounds |          oldBounds := self target bounds.          self target +                bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner). +        self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." +        self target allOwnersDo: [:owner | +                owner layoutPolicy ifNotNil: [owner left: owner left + delta x]].! -                bounds: (oldBounds origin + (delta x @ 0) corner: oldBounds corner)! Item was changed:   ----- Method: TopGripMorph>>apply: (in category 'target resize') -----   apply: delta          | oldBounds |          oldBounds := self target bounds.          self target +                bounds: (oldBounds origin + (0 @ delta y) corner: oldBounds corner). +        self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." +        self target allOwnersDo: [:owner | +                owner layoutPolicy ifNotNil: [owner top: owner top + delta y]].! -                bounds: (oldBounds origin + (0 @ delta y) corner: oldBounds corner)! Item was changed:   ----- Method: TopLeftGripMorph>>apply: (in category 'target resize') -----   apply: delta          | oldBounds |          oldBounds := self target bounds.          self target +                bounds: (oldBounds origin + delta corner: oldBounds corner). +        self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." +        self target allOwnersDo: [:owner | +                owner layoutPolicy ifNotNil: [owner topLeft: owner topLeft + delta]].! -                bounds: (oldBounds origin + delta corner: oldBounds corner)! Item was changed:   ----- Method: TopRightGripMorph>>apply: (in category 'target resize') -----   apply: delta          | oldBounds |          oldBounds := self target bounds.          self target +                bounds: (oldBounds origin + (0 at delta y) corner: oldBounds corner + (delta x @ 0)). +        self flag: #workaround. "mt: Due to a layout-specific 'let us start in the top-left corner of a layout cell'-behavior, we have to go up the owner chain and propagate the delta. See Morph >> #layoutInBounds:positioning: and there section 1.2." +        self target allOwnersDo: [:owner | +                owner layoutPolicy ifNotNil: [owner top: owner top + delta y]].! -                bounds: (oldBounds origin + (0 at delta y) corner: oldBounds corner + (delta x @ 0))! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedImage.png Type: image/png Size: 6873 bytes Desc: not available URL: From hannes.hirzel at gmail.com Mon Jan 25 10:36:01 2021 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Mon, 25 Jan 2021 10:36:01 +0000 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: <20210123011630.GA93733@shell.msen.com> References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> <20210123011630.GA93733@shell.msen.com> Message-ID: Hi Arjen The instructions in http://wiki.squeak.org/squeak/2848 (Squeak 5.3) worked for me some time ago. 1. The main point before unloading is to reclassify some methods currently belonging to Etoys to the general Squeak as they are needed for Squeak to work. 2. After reclassifying unloading of Etoys works. 3. However some more fixes need to be done in order to have the remaining code not call Etoys methods which are no longer there. To all: the necessary fixes are all quite simple. However the steps need to be checked also with the current trunk image. The fixes would also be useful to be added to Squeak 5.3 HTH Hannes On 1/23/21, David T. Lewis wrote: > On Thu, Jan 21, 2021 at 12:07:06PM +0000, Arjen van Elteren via Squeak-dev > wrote: >> All, >> >> I would like to unload the EToys packages from image. >> >> I tried with the Monticello Browser, unloading seems to proceed. But at >> the end nothing is reacting anymore. >> >> Any hint on how to successfully unload the EToys? >> >> Should I use a workspace in an MVC project? >> > > Hello Arjen, > > I don't think that unloading works yet, but hopefully soon. The > goal is to make Etoys reloadable, which means that it can be fully > removed from the image, and also reinstalled into an image from > which it has been removed. > > A lot of good work has gone into this in the last few years, but > it is not complete. If you do any work on this yourself, any input > would be welcome either as inbox contributions or messages to > the list here. > > I should mention also that this topic came up (again!) in the > last online meeting of our Squeak oversight board and it is on > our agenda for the next meeting. I think everyone agrees that > this is important to do, it's just a small matter of somebody > doing the work ;-) > > Dave > > > From Das.Linux at gmx.de Mon Jan 25 10:38:18 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon, 25 Jan 2021 11:38:18 +0100 Subject: [squeak-dev] The Trunk: System-eem.1211.mcz In-Reply-To: References: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> Message-ID: <2A34E0BF-002C-4D4C-9A34-23DA955E4B20@gmx.de> > On 25. Jan 2021, at 11:22, Marcel Taeumel wrote: > > Why is that "1996-2010 Viewpoints" not reflected in Squeak's #license? Maybe we can remove the #copyright method alltogether because #license contains all copyright information? No, that's slightly different :) -t > > Best, > Marcel >> Am 24.01.2021 22:57:35 schrieb Eliot Miranda : >> >> >> >>> On Jan 24, 2021, at 10:08 AM, Thiede, Christoph wrote: >>> >>>  >>> Hm ... would it be presumptuous to say: >>> >>> >>> 'Copyright © 2010-{1} Squeak Community Contributors.' format: {2021 max: Date today year} >>> >>> >>> ? :-) >>> >> >> I *love* it! Commit it immediately!! >> >>> >>> >>> Best, >>> >>> Christoph >>> >>> Von: Squeak-dev im Auftrag von commits at source.squeak.org >>> Gesendet: Sonntag, 24. Januar 2021 03:07:22 >>> An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org >>> Betreff: [squeak-dev] The Trunk: System-eem.1211.mcz >>> >>> Eliot Miranda uploaded a new version of System to project The Trunk: >>> http://source.squeak.org/trunk/System-eem.1211.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: System-eem.1211 >>> Author: eem >>> Time: 23 January 2021, 6:07:18.034021 pm >>> UUID: 89999499-d83c-478b-9044-5dee2fe443df >>> Ancestors: System-dtl.1210 >>> >>> Update the system's copyright. >>> >>> =============== Diff against System-dtl.1210 =============== >>> >>> Item was changed: >>> ----- Method: SmalltalkImage>>copyright (in category 'sources, changes log') ----- >>> copyright >>> "The Smalltalk copyright." >>> >>> + ^'Copyright © Xerox Corp. 1981, 1982 All rights reserved. >>> + Copyright © Apple Computer, Inc. 1985-1996 All rights reserved; >>> + Copyright © 2010-2021 Squeak Community Contributors.'! >>> - ^'Copyright (c) Xerox Corp. 1981, 1982 All rights reserved. >>> - Copyright (c) Apple Computer, Inc. 1985-1996 All rights reserved.'! >>> >>> > From marcel.taeumel at hpi.de Mon Jan 25 10:39:33 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 11:39:33 +0100 Subject: [squeak-dev] The Inbox: Morphic-ct.1718.mcz In-Reply-To: References: Message-ID: Hi :-) -1 for adding #skipOnceScrollSelectionIntoView this way What's exactly the benefit of putting this extra effort into the implementation? Under which circumstances is that extra scrolling a distraction? What do you want to do after "select all"? For all that we know, it might be accidental in other systems. :-)  Yet, I do like "visual stability" for such interactions. Maybe we can find a better "rule" to achieve that. Or maybe we can establish a paramter to "selectFrom:to:". There is already "invisible selection". Maybe we can add "stableSelection"? Or something like that. Best, Marcel P.S.: All these "skip once if"-blah rules with little to no benefits can quickly blow up the code base. ;-)  Am 24.01.2021 17:23:15 schrieb commits at source.squeak.org : 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.! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 25 10:41:07 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 11:41:07 +0100 Subject: [squeak-dev] The Trunk: System-eem.1211.mcz In-Reply-To: <2A34E0BF-002C-4D4C-9A34-23DA955E4B20@gmx.de> References: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> <2A34E0BF-002C-4D4C-9A34-23DA955E4B20@gmx.de> Message-ID: > No, that's slightly different :) Then we might want to synchronize that information. Best, Marcel Am 25.01.2021 11:38:29 schrieb Tobias Pape : > On 25. Jan 2021, at 11:22, Marcel Taeumel wrote: > > Why is that "1996-2010 Viewpoints" not reflected in Squeak's #license? Maybe we can remove the #copyright method alltogether because #license contains all copyright information? No, that's slightly different :) -t > > Best, > Marcel >> Am 24.01.2021 22:57:35 schrieb Eliot Miranda : >> >> >> >>> On Jan 24, 2021, at 10:08 AM, Thiede, Christoph wrote: >>> >>>  >>> Hm ... would it be presumptuous to say: >>> >>> >>> 'Copyright © 2010-{1} Squeak Community Contributors.' format: {2021 max: Date today year} >>> >>> >>> ? :-) >>> >> >> I *love* it! Commit it immediately!! >> >>> >>> >>> Best, >>> >>> Christoph >>> >>> Von: Squeak-dev im Auftrag von commits at source.squeak.org >>> Gesendet: Sonntag, 24. Januar 2021 03:07:22 >>> An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org >>> Betreff: [squeak-dev] The Trunk: System-eem.1211.mcz >>> >>> Eliot Miranda uploaded a new version of System to project The Trunk: >>> http://source.squeak.org/trunk/System-eem.1211.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: System-eem.1211 >>> Author: eem >>> Time: 23 January 2021, 6:07:18.034021 pm >>> UUID: 89999499-d83c-478b-9044-5dee2fe443df >>> Ancestors: System-dtl.1210 >>> >>> Update the system's copyright. >>> >>> =============== Diff against System-dtl.1210 =============== >>> >>> Item was changed: >>> ----- Method: SmalltalkImage>>copyright (in category 'sources, changes log') ----- >>> copyright >>> "The Smalltalk copyright." >>> >>> + ^'Copyright © Xerox Corp. 1981, 1982 All rights reserved. >>> + Copyright © Apple Computer, Inc. 1985-1996 All rights reserved; >>> + Copyright © 2010-2021 Squeak Community Contributors.'! >>> - ^'Copyright (c) Xerox Corp. 1981, 1982 All rights reserved. >>> - Copyright (c) Apple Computer, Inc. 1985-1996 All rights reserved.'! >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 25 11:09:55 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 12:09:55 +0100 Subject: [squeak-dev] The Inbox: CollectionsTests-ct.348.mcz In-Reply-To: References: Message-ID: What happens when the collection for keys as a different size than values? Should there be an error? A test could document that behavior. :-) Best, Marcel Am 24.01.2021 16:55:37 schrieb commits at source.squeak.org : A new version of CollectionsTests was added to project The Inbox: http://source.squeak.org/inbox/CollectionsTests-ct.348.mcz ==================== Summary ==================== Name: CollectionsTests-ct.348 Author: ct Time: 24 January 2021, 4:55:30.561273 pm UUID: 342ca023-4467-d741-b42a-924ae0a72936 Ancestors: CollectionsTests-mt.346 Tests Collections-ct.921 (inbox, Dictionary newFromKeys:values:). =============== Diff against CollectionsTests-mt.346 =============== Item was added: + ----- Method: DictionaryTest>>testNewFromKeysValues (in category 'tests - basic') ----- + testNewFromKeysValues + + | actual expected | + actual := Dictionary + newFromKeys: #(2 3 1) + values: #(4 5 6). + expected := Dictionary new + at: 2 put: 4; + at: 3 put: 5; + at: 1 put: 6; + yourself. + + self assert: expected equals: actual.! Item was added: + ----- Method: DictionaryTest>>testNewFromPairs (in category 'tests - basic') ----- + testNewFromPairs + + | actual expected | + actual := Dictionary newFromPairs: { + #one. 'foo'. + #two. 2 @ 3 }. + expected := Dictionary new + at: #one put: 'foo'; + at: #two put: 2 @ 3; + yourself. + + self assert: expected equals: actual.! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 25 11:15:19 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 12:15:19 +0100 Subject: [squeak-dev] The Inbox: Collections-ct.923.mcz In-Reply-To: References: Message-ID: If we want to optimize this for code artifacts, why not add that extra space *all the time*. Then again, only #storeOn: should do that, right? Putting so much effort into making #printOn: fit for something it is not meant to be, worries me. :-/ Best, Marcel Am 24.01.2021 16:53:54 schrieb commits at source.squeak.org : A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ct.923.mcz ==================== Summary ==================== Name: Collections-ct.923 Author: ct Time: 24 January 2021, 4:53:44.716273 pm UUID: bd630b83-a77e-cb4f-a008-246786a5c7d8 Ancestors: Collections-mt.919 Fixes printString representation of Associations and Dictionarys to avoid ambiguous selectors. As a consequence, reevalabuality is not limited any longer. Examples: 1 -> 2. "--> 1->2" 1 -> -2. "--> 1 -> -2" Dictionary new at: -1 put: 1; at: 1 put: -1; yourself. "--> a Dictionary(-1->1 1 -> -1)" =============== Diff against Collections-mt.919 =============== Item was changed: ----- Method: Association>>printOn: (in category 'printing') ----- printOn: aStream + | arrow | super printOn: aStream. + + "Avoid AmbiguousSelector warnings when evaluating the stream as Smalltalk code." + arrow := ((key isSymbol and: [key isBinary]) + or: [(value printStringLimitedTo: 1) beginsWith: '-']) + ifTrue: [' -> '] + ifFalse: ['->']. - "If the key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." - arrow := (key isSymbol and: [key isBinary]) ifTrue: [' -> '] ifFalse: ['->']. aStream nextPutAll: arrow. + + value printOn: aStream.! - value printOn: aStream! Item was changed: ----- Method: Dictionary>>printElementsOn: (in category 'printing') ----- printElementsOn: aStream aStream nextPut: $(. self size > 100 ifTrue: [aStream nextPutAll: 'size '. self size printOn: aStream] ifFalse: [self keysInOrder + do: [:key | aStream print: (self associationAt: key)] + separatedBy: [aStream space]]. - do: [:key | aStream print: key; - nextPutAll: '->'; - print: (self at: key); - space]]. aStream nextPut: $)! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 25 11:25:56 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 12:25:56 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> Message-ID: > It's simply not thread-safe. Hmm... in particular, there is a side effect (i.e. layout update) in the window's pluggable text morph. Even if #forceUpdate is false. In #endEntry, we could check for "Processor activeProcess == Project current uiProcess" to then use "Project current addDeferredUIMessage..." automatically. Best, Marcel Am 23.01.2021 21:05:05 schrieb Levente Uzonyi : On Fri, 22 Jan 2021, tim Rowledge wrote: > > >> On 2021-01-22, at 5:26 PM, David T. Lewis wrote: >> >> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: >>> I ran the following in Squeak 5.3: >>> >>> TranscriptStream forceUpdate: false. >>> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 >>> >>> When the Transcript window fills up, 'Message not understood' and 'Assertion >>> failure' appear. I'm wondering is this a bug? Thanks. Jaromir >>> >>> >>> >> >> It certainly does appear to be a bug. > > We had some discussion about it not so long ago; you can't use the Transcript to log bugs from Seaside very well, for example. Background processes, mutexs, that sort of thing. IIRC Levente offered an explanation? It's simply not thread-safe. If you want it to be thread-safe, you can pass your message to the UI process to show it. Make sure your message is computed in its own process and is passed as a precomputed string to avoid other kinds of race conditions. E.g.: | theMessage | theMessage := 'Something very {1}.' format: { 'important' }. Project current addDeferredUIMessage: [ Transcript show: theMessage; cr ]. Levente > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > The hardness of the butter is proportional to the softness of the bread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Jan 25 11:46:14 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 12:46:14 +0100 Subject: [squeak-dev] Problems with table layout in 5.x In-Reply-To: <395A1D66-9E3E-47EE-87CE-1A2D7D655E53@mac.com> References: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> <395A1D66-9E3E-47EE-87CE-1A2D7D655E53@mac.com> Message-ID: > You are blaming indeterminate hacks in BobosUi for the problems Sorry. I was just saying, that BobsUI subclassed almost all UI classes in Morphic and made changes that override many things in the base system. For this, of course, it assumes a certain behavior (or misbhevior) in the base system. Consequently, compatibility issues could arise anywhere. :-/ >who show the same bug, also this test work in 5.2 ans with the revert of Morph>>adjustLayoutBounds. Reverting this method produces many bugs. 5 tests in TableLayout fail, for example. > So I think this is a "clean" bug created for the changes in the table layout in 5.3. Thank you, for reproducing the behavior. I will take a look at it. Best, Marcel Am 22.01.2021 18:16:29 schrieb Javier Diaz-Reinoso via Squeak-dev : On 19 Jan 2021, at 06:50, Marcel Taeumel wrote: Hmm.... "BobsUI" uses a mix of layout policies and overrides through custom implementations of #extent: or #width: or #height:. Hmpf. Sometimes even in the same morph that actually uses such a policy. It also looks like that BobsUI fixes several layout bugs from 5.2 and before through subclassing. Unfortunately, one would have to go through all UI* classes and remove all those changes (or hacks). I do not have the resources to do that now. :-( What needs to be done is to replace all hacks in #width: and #height: (etc.) with proper configuration of layout properties (i.e., #hResizing, #vResizing, ...) The one thing you can easily fix is to replace all "#cellInset:" calls with "#cellGap:", which is explained in the Squeak 5.3 release notes. Best, Marcel [... cut ...] You are blaming indeterminate hacks in BobosUi for the problems, al least for the UIGroupBoxMorph problem that is not correct. I now extracted that morph from BobsUi to  UISimpleGroupBoxMorph [http://UISimpleGroupBoxMorph.st] removing all instances and selectors who are not involves in the initialization, also recreated by hand the tree of morphsusing only regular morphs, this is in the workspace 'test UISimpleGroupBox.text', the result of evaluating is: who show the same bug, also this test work in 5.2 ans with the revert of Morph>>adjustLayoutBounds. So I think this is a "clean" bug created for the changes in the table layout in 5.3. As for the other problems with the UITitleBarMorph and the extra spaces, I think is also produced by bugs in the same area, after all BobsUI are not changing that area. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-22 at 11.48.06.png Type: image/png Size: 11302 bytes Desc: not available URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Mon Jan 25 12:24:42 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Mon, 25 Jan 2021 12:24:42 +0000 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> , Message-ID: > In #endEntry, we could check for "Processor activeProcess == Project current uiProcess" to then use "Project current addDeferredUIMessage..." automatically. But wouldn't violate that the #forceUpdate preference when a non-UI process blocks the image for a while? Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Montag, 25. Januar 2021 12:25:56 An: squeak-dev Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?) > It's simply not thread-safe. Hmm... in particular, there is a side effect (i.e. layout update) in the window's pluggable text morph. Even if #forceUpdate is false. In #endEntry, we could check for "Processor activeProcess == Project current uiProcess" to then use "Project current addDeferredUIMessage..." automatically. Best, Marcel Am 23.01.2021 21:05:05 schrieb Levente Uzonyi : On Fri, 22 Jan 2021, tim Rowledge wrote: > > >> On 2021-01-22, at 5:26 PM, David T. Lewis wrote: >> >> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: >>> I ran the following in Squeak 5.3: >>> >>> TranscriptStream forceUpdate: false. >>> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 >>> >>> When the Transcript window fills up, 'Message not understood' and 'Assertion >>> failure' appear. I'm wondering is this a bug? Thanks. Jaromir >>> >>> >>> >> >> It certainly does appear to be a bug. > > We had some discussion about it not so long ago; you can't use the Transcript to log bugs from Seaside very well, for example. Background processes, mutexs, that sort of thing. IIRC Levente offered an explanation? It's simply not thread-safe. If you want it to be thread-safe, you can pass your message to the UI process to show it. Make sure your message is computed in its own process and is passed as a precomputed string to avoid other kinds of race conditions. E.g.: | theMessage | theMessage := 'Something very {1}.' format: { 'important' }. Project current addDeferredUIMessage: [ Transcript show: theMessage; cr ]. Levente > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > The hardness of the butter is proportional to the softness of the bread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Mon Jan 25 12:27:35 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Mon, 25 Jan 2021 12:27:35 +0000 Subject: [squeak-dev] The Inbox: Collections-ct.923.mcz In-Reply-To: References: , Message-ID: <4dc9116c7c9c46ec8dff5fd61ac93765@student.hpi.uni-potsdam.de> I remember we had a similar discussion about printString reevaluability some time ago. :-) IMO, the check is quite cheap and saves me from unnecessary syntax slip errors when reusing the output of an every-day printIt snippet. > why not add that extra space *all the time*. Also +1. Considering today's screen sizes a few more spaces really shouldn't matter ... Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Montag, 25. Januar 2021 12:15:19 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Collections-ct.923.mcz If we want to optimize this for code artifacts, why not add that extra space *all the time*. Then again, only #storeOn: should do that, right? Putting so much effort into making #printOn: fit for something it is not meant to be, worries me. :-/ Best, Marcel Am 24.01.2021 16:53:54 schrieb commits at source.squeak.org : A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ct.923.mcz ==================== Summary ==================== Name: Collections-ct.923 Author: ct Time: 24 January 2021, 4:53:44.716273 pm UUID: bd630b83-a77e-cb4f-a008-246786a5c7d8 Ancestors: Collections-mt.919 Fixes printString representation of Associations and Dictionarys to avoid ambiguous selectors. As a consequence, reevalabuality is not limited any longer. Examples: 1 -> 2. "--> 1->2" 1 -> -2. "--> 1 -> -2" Dictionary new at: -1 put: 1; at: 1 put: -1; yourself. "--> a Dictionary(-1->1 1 -> -1)" =============== Diff against Collections-mt.919 =============== Item was changed: ----- Method: Association>>printOn: (in category 'printing') ----- printOn: aStream + | arrow | super printOn: aStream. + + "Avoid AmbiguousSelector warnings when evaluating the stream as Smalltalk code." + arrow := ((key isSymbol and: [key isBinary]) + or: [(value printStringLimitedTo: 1) beginsWith: '-']) + ifTrue: [' -> '] + ifFalse: ['->']. - "If the key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." - arrow := (key isSymbol and: [key isBinary]) ifTrue: [' -> '] ifFalse: ['->']. aStream nextPutAll: arrow. + + value printOn: aStream.! - value printOn: aStream! Item was changed: ----- Method: Dictionary>>printElementsOn: (in category 'printing') ----- printElementsOn: aStream aStream nextPut: $(. self size > 100 ifTrue: [aStream nextPutAll: 'size '. self size printOn: aStream] ifFalse: [self keysInOrder + do: [:key | aStream print: (self associationAt: key)] + separatedBy: [aStream space]]. - do: [:key | aStream print: key; - nextPutAll: '->'; - print: (self at: key); - space]]. aStream nextPut: $)! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Mon Jan 25 12:35:43 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Mon, 25 Jan 2021 12:35:43 +0000 Subject: [squeak-dev] The Trunk: Tools-mt.1024.mcz In-Reply-To: References: <,> <0a899bd15d2c4f91b73c41411a09a85f@student.hpi.uni-potsdam.de>, Message-ID: > How come? Too wordy? :-) Not at all, just an elaborate layout, better than pure plain text - elaborate enough that I start wondering whether we could need some set of formatting markup instead of all the "format:", "addAttribute:", "asString asText allBold" etc. ... Improve the HTML support, for example a tag for text indent? Or finally implement #asTextFromMarkdown? :-) (By the way, this "maybe save your image before doing this" reminds me of #isScarySelector: - should we use a similar concept here to prevent too many warnings?) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Montag, 25. Januar 2021 11:26:15 An: squeak-dev Betreff: Re: [squeak-dev] The Trunk: Tools-mt.1024.mcz > Nearly "too" modern to fit into [...] How come? Too wordy? :-) > but a very nice step into the right direction ... :-) Unfortunately, "manual checkpointing" is the only "undo method" we can provide at this level. Best, Marcel Am 24.01.2021 19:06:56 schrieb Thiede, Christoph : Beautiful! Nearly "too" modern to fit into the entire Squeak appearance - but a very nice step into the right direction ... :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 14. Januar 2021 13:24:13 An: squeak-dev Betreff: Re: [squeak-dev] The Trunk: Tools-mt.1024.mcz [cid:bd0db97b-c71b-4b55-8971-cac77123c8a3] [cid:c6093f57-b2bc-4492-8da6-e84c83a209cd] [cid:e75d4543-f749-4fbe-af37-1dc8f5b33e01] Best, Marcel Am 14.01.2021 13:21:28 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-mt.1024.mcz ==================== Summary ==================== Name: Tools-mt.1024 Author: mt Time: 14 January 2021, 1:21:15.354081 pm UUID: 0ef67378-0ca6-4743-be9c-5a60621c07cd Ancestors: Tools-mt.1023 Improves the description of several confirmation dialogs for removing batches of source code. =============== Diff against Tools-mt.1023 =============== Item was changed: ----- Method: Browser>>removeMessageCategory (in category 'message category functions') ----- removeMessageCategory "If a message category is selected, create a Confirmer so the user can verify that the currently selected message category should be removed from the system. If so, remove it." | messageCategoryName | self hasMessageCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. messageCategoryName := self selectedMessageCategoryName. (self messageList size = 0 + or: [Project uiManager confirm: ('Are you sure you want to remove\the message category\\ {1}\ in {2}\\and all its {3} methods? Maybe save\your image before doing this.' translated withCRs asText format: { + messageCategoryName asText allBold. + self selectedClassOrMetaClass name. + (self selectedClassOrMetaClass organization listAtCategoryNamed: messageCategoryName) size asString asText allBold + + }) title: 'Remove Message Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this method category - and all its methods?']) ifTrue: [self selectedClassOrMetaClass removeCategory: messageCategoryName. self selectMessageCategoryNamed: nil. self changed: #classSelectionChanged]. self changed: #messageCategoryList. ! Item was changed: ----- Method: Browser>>removeSystemCategory (in category 'system category functions') ----- removeSystemCategory "If a class category is selected, create a Confirmer so the user can verify that the currently selected class category and all of its classes should be removed from the system. If so, remove it." self hasSystemCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. (self classList size = 0 + or: [Project uiManager + confirm: ('Are you sure you want to remove\the system category\\ {1}\\and all its {2} classes? Maybe save\your image before doing this.' translated withCRs asText + format: { + self selectedSystemCategory asText allBold. + (systemOrganizer listAtCategoryNamed: self selectedSystemCategory) size asString asText allBold}) + title: 'Remove System Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this system category - and all its classes?']) ifTrue: [| nextSelectedCat | nextSelectedCat := self systemCategoryList before: self selectedSystemCategory ifAbsent: [nil]. systemOrganizer removeSystemCategory: self selectedSystemCategory. self selectSystemCategory: nextSelectedCat. self changed: #systemCategoryList]! Item was changed: ----- Method: CodeHolder>>removeClass (in category 'commands') ----- removeClass "Remove the selected class from the system, at interactive user request. Make certain the user really wants to do this, since it is not reversible. Answer true if removal actually happened." | message className classToRemove result | self okToChange ifFalse: [^ false]. classToRemove := self selectedClassOrMetaClass ifNil: [Beeper beep. ^ false]. classToRemove := classToRemove theNonMetaClass. className := classToRemove name. + message := 'Are you sure that you want to remove\the class\\ {1}\\and all its {2} methods? Maybe save\your image before doing this.{3}' translated withCRs asText format: { + className asText allBold. + (classToRemove methodDict size + classToRemove class methodDict size) asString asText allBold. + classToRemove subclasses size > 0 ifFalse: [''] ifTrue: [ + '\\(There are {1} subclasses, whose superclass\must be updated manually after this.)' translated withCRs asText format: { classToRemove subclasses size asString asText allBold }]}. + (result := Project uiManager confirm: message title: 'Remove Class' translated) - message := 'Are you certain that you - want to REMOVE the class ', className, ' - from the system?'. - (result := self confirm: message) ifTrue: [classToRemove subclasses size > 0 ifTrue: [(self confirm: 'class has subclasses: ' , message) ifFalse: [^ false]]. classToRemove removeFromSystem. self changed: #classList. true]. ^ result! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 29075 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 22215 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24309 bytes Desc: image.png URL: From marcel.taeumel at hpi.de Mon Jan 25 12:41:52 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 13:41:52 +0100 Subject: [squeak-dev] Problems with table layout in 5.x In-Reply-To: References: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> <395A1D66-9E3E-47EE-87CE-1A2D7D655E53@mac.com> Message-ID: Hi Javier. Since UISimpleGroupBoxMorph manages the layout of label and contents, it needs a TableLayoutPolicy. Then it works as expected: Still, I wonder why #adjustLayoutBounds does not wrap around the misaligned submorphs when not having that layout: At least, I would expect this: Hmmm..... Best, Marcel Am 25.01.2021 12:46:14 schrieb Marcel Taeumel : > You are blaming indeterminate hacks in BobosUi for the problems Sorry. I was just saying, that BobsUI subclassed almost all UI classes in Morphic and made changes that override many things in the base system. For this, of course, it assumes a certain behavior (or misbhevior) in the base system. Consequently, compatibility issues could arise anywhere. :-/ >who show the same bug, also this test work in 5.2 ans with the revert of Morph>>adjustLayoutBounds. Reverting this method produces many bugs. 5 tests in TableLayout fail, for example. > So I think this is a "clean" bug created for the changes in the table layout in 5.3. Thank you, for reproducing the behavior. I will take a look at it. Best, Marcel Am 22.01.2021 18:16:29 schrieb Javier Diaz-Reinoso via Squeak-dev : On 19 Jan 2021, at 06:50, Marcel Taeumel wrote: Hmm.... "BobsUI" uses a mix of layout policies and overrides through custom implementations of #extent: or #width: or #height:. Hmpf. Sometimes even in the same morph that actually uses such a policy. It also looks like that BobsUI fixes several layout bugs from 5.2 and before through subclassing. Unfortunately, one would have to go through all UI* classes and remove all those changes (or hacks). I do not have the resources to do that now. :-( What needs to be done is to replace all hacks in #width: and #height: (etc.) with proper configuration of layout properties (i.e., #hResizing, #vResizing, ...) The one thing you can easily fix is to replace all "#cellInset:" calls with "#cellGap:", which is explained in the Squeak 5.3 release notes. Best, Marcel [... cut ...] You are blaming indeterminate hacks in BobosUi for the problems, al least for the UIGroupBoxMorph problem that is not correct. I now extracted that morph from BobsUi to  UISimpleGroupBoxMorph [http://UISimpleGroupBoxMorph.st] removing all instances and selectors who are not involves in the initialization, also recreated by hand the tree of morphsusing only regular morphs, this is in the workspace 'test UISimpleGroupBox.text', the result of evaluating is: who show the same bug, also this test work in 5.2 ans with the revert of Morph>>adjustLayoutBounds. So I think this is a "clean" bug created for the changes in the table layout in 5.3. As for the other problems with the UITitleBarMorph and the extra spaces, I think is also produced by bugs in the same area, after all BobsUI are not changing that area. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 5257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 3932 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 3902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-22 at 11.48.06.png Type: image/png Size: 11302 bytes Desc: not available URL: From frank-lesser at lesser-software.com Mon Jan 25 14:34:04 2021 From: frank-lesser at lesser-software.com (Frank Lesser) Date: Mon, 25 Jan 2021 15:34:04 +0100 Subject: [squeak-dev] [offtopic] DNG In-Reply-To: <5bc85424-6cbb-bfaa-f23d-e7396f0e17b3@lesser-software.com> References: <5bc85424-6cbb-bfaa-f23d-e7396f0e17b3@lesser-software.com> Message-ID: hi all, just an update from Dolphin Next Generation resume. still work - but progressing. Frank https://twitter.com/LesserFrank/status/1353705980912144387?s=20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Mon Jan 25 15:17:01 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 25 Jan 2021 15:17:01 0000 Subject: [squeak-dev] The Trunk: MorphicTests-mt.68.mcz Message-ID: Marcel Taeumel uploaded a new version of MorphicTests to project The Trunk: http://source.squeak.org/trunk/MorphicTests-mt.68.mcz ==================== Summary ==================== Name: MorphicTests-mt.68 Author: mt Time: 25 January 2021, 4:17:01.036158 pm UUID: e250ac43-cfde-8d47-9c60-87045f7c0061 Ancestors: MorphicTests-mt.67 Adds tests for check-box group layout and a #shrinkWrap issue. =============== Diff against MorphicTests-mt.67 =============== Item was added: + ----- Method: TableLayoutTest>>testCheckBoxGroup (in category 'tests - example layouts') ----- + testCheckBoxGroup + + | group groupContents labels | + labels := Dictionary new. + group := self newContainer + hResizing: #shrinkWrap; + vResizing: #shrinkWrap; + layoutPolicy: TableLayout new; + listDirection: #topToBottom; + layoutInset: 0; + cellPositioning: #topLeft; + borderStyle: (SimpleBorder color: Color black width: 2); + yourself. + group addMorphBack: (labels at: #groupLabel put: 'Favorite Ice Cream' asMorph). + + groupContents := self newContainer + hResizing: #shrinkWrap; + vResizing: #shrinkWrap; + layoutPolicy: TableLayout new; + listDirection: #topToBottom; + cellGap: 0; + cellPositioning: #topLeft; + yourself. + group addMorphBack: groupContents. + + #('Vanilla' 'Chocolate') withIndexDo: [:label :index | + | checkBox | + checkBox := self newContainer + hResizing: #shrinkWrap; + vResizing: #shrinkWrap; + layoutPolicy: TableLayout new; + listDirection: #rightToLeft; + yourself. + checkBox + addMorphBack: (labels at: (#box, index asString) asSymbol put: label asMorph); + addMorphBack: (self newMorph extent: 16 at 16; borderColor: Color black; borderWidth: 2). + groupContents addMorphBack: checkBox]. + + self ensureLayout: group. + self + assert: (labels at: #groupLabel) width + (group borderWidth * 2) + equals: group width. + self + assert: (labels at: #groupLabel) height + + (labels at: #box1) height + + (labels at: #box2) height + + (group borderWidth * 2) + equals: group height.! Item was added: + ----- Method: TableLayoutTest>>testShrinkWrapIssue (in category 'tests') ----- + testShrinkWrapIssue + "A container that has no layout policy does MUST trigger layout computation for its submorphs in time." + + | container inner item1 item2 | + container := Morph new + hResizing: #shrinkWrap; + vResizing: #shrinkWrap; + yourself. + inner := self newContainer + listDirection: #topToBottom; + yourself. + container addMorphBack: inner. + + inner + addMorphBack: (item1 := self newMorph extent: 50 at 50; yourself); + addMorphBack: (item2 := self newMorph extent: 50 at 50; yourself). + + self ensureLayout: container. + self assert: 50 at 100 equals: container extent. + + item1 width: 100. + item2 width: 200. + self ensureLayout: container. + self assert: 200 at 100 equals: container extent.! From commits at source.squeak.org Mon Jan 25 15:20:12 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 25 Jan 2021 15:20:12 0000 Subject: [squeak-dev] The Trunk: Morphic-mt.1718.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1718.mcz ==================== Summary ==================== Name: Morphic-mt.1718 Author: mt Time: 25 January 2021, 4:20:06.658158 pm UUID: 96f371e0-9b54-7949-b083-894f3322467b Ancestors: Morphic-mt.1717 Fixes #testShrinkWrapIssue. Thanks to Javier (jdr) for pointing this out! =============== Diff against Morphic-mt.1717 =============== Item was changed: ----- Method: Morph>>doLayoutIn: (in category 'layout') ----- doLayoutIn: layoutBounds "Compute a new layout based on the given layout bounds." | box priorBounds | "0) Quick return. No children means no effect in layout policies. Use #minWidth and #minHeight to implement #shrinkWrap for morphs without submorphs." self hasSubmorphs ifFalse: [^ fullBounds := self outerBounds]. "X.1) Prepare redraw. Testing for #bounds or #layoutBounds would be sufficient to figure out if we need an invalidation afterwards but #outerBounds is what we need for all leaf nodes so we use that" priorBounds := self outerBounds. "1) Give our children a chance to manually adjust *before* layout (cell) computation. This allows morphs to layout in their owner without having to use a layout policy." self submorphsDo: [:m | m ownerChanged]. "2) Compute the new layout. This goes down the entire morph hierarchy. See #layoutInBounds: and #minExtent, which are the usual layout-policy callbacks." + self layoutPolicy ifNil: [self submorphsDo: [:m | m fullBounds]] ifNotNil: [:layout | - self layoutPolicy ifNotNil: [:layout | "2.1) Compute the new layout." self removeProperty: #doLayoutAgain. layout layout: self in: layoutBounds. "2.2) Do one additional run on the layout if requested in #layoutInBounds:." (self hasProperty: #doLayoutAgain) ifTrue: [ self removeProperty: #doLayoutAgain. layout flushLayoutCache. layout layout: self in: layoutBounds]. self assert: (self hasProperty: #doLayoutAgain) not]. "3) Watch out for minimal extent and apply #shrinkWrap constraints." self adjustLayoutBounds. "4) Compute and set the new full bounds. IMPORTANT to finish layout computation." fullBounds := self privateFullBounds. "X.2) Redraw." box := self outerBounds. box = priorBounds ifFalse: [ self invalidRect: (priorBounds quickMerge: box)].! From marcel.taeumel at hpi.de Mon Jan 25 15:31:10 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 16:31:10 +0100 Subject: [squeak-dev] Problems with table layout in 5.x In-Reply-To: References: <8AABC7DE-F9B8-458F-AEA9-A0599C638071@mac.com> <395A1D66-9E3E-47EE-87CE-1A2D7D655E53@mac.com> Message-ID: Hi Javier. I backported that #shrinkWrap fix to 5.3. Maybe this helps a little bit. Still, UISimpleGroupBoxMorph should really have its own table layout. :-) Best, Marcel Am 25.01.2021 13:41:52 schrieb Marcel Taeumel : Hi Javier. Since UISimpleGroupBoxMorph manages the layout of label and contents, it needs a TableLayoutPolicy. Then it works as expected: Still, I wonder why #adjustLayoutBounds does not wrap around the misaligned submorphs when not having that layout: At least, I would expect this: Hmmm..... Best, Marcel Am 25.01.2021 12:46:14 schrieb Marcel Taeumel : > You are blaming indeterminate hacks in BobosUi for the problems Sorry. I was just saying, that BobsUI subclassed almost all UI classes in Morphic and made changes that override many things in the base system. For this, of course, it assumes a certain behavior (or misbhevior) in the base system. Consequently, compatibility issues could arise anywhere. :-/ >who show the same bug, also this test work in 5.2 ans with the revert of Morph>>adjustLayoutBounds. Reverting this method produces many bugs. 5 tests in TableLayout fail, for example. > So I think this is a "clean" bug created for the changes in the table layout in 5.3. Thank you, for reproducing the behavior. I will take a look at it. Best, Marcel Am 22.01.2021 18:16:29 schrieb Javier Diaz-Reinoso via Squeak-dev : On 19 Jan 2021, at 06:50, Marcel Taeumel wrote: Hmm.... "BobsUI" uses a mix of layout policies and overrides through custom implementations of #extent: or #width: or #height:. Hmpf. Sometimes even in the same morph that actually uses such a policy. It also looks like that BobsUI fixes several layout bugs from 5.2 and before through subclassing. Unfortunately, one would have to go through all UI* classes and remove all those changes (or hacks). I do not have the resources to do that now. :-( What needs to be done is to replace all hacks in #width: and #height: (etc.) with proper configuration of layout properties (i.e., #hResizing, #vResizing, ...) The one thing you can easily fix is to replace all "#cellInset:" calls with "#cellGap:", which is explained in the Squeak 5.3 release notes. Best, Marcel [... cut ...] You are blaming indeterminate hacks in BobosUi for the problems, al least for the UIGroupBoxMorph problem that is not correct. I now extracted that morph from BobsUi to  UISimpleGroupBoxMorph [http://UISimpleGroupBoxMorph.st] removing all instances and selectors who are not involves in the initialization, also recreated by hand the tree of morphsusing only regular morphs, this is in the workspace 'test UISimpleGroupBox.text', the result of evaluating is: who show the same bug, also this test work in 5.2 ans with the revert of Morph>>adjustLayoutBounds. So I think this is a "clean" bug created for the changes in the table layout in 5.3. As for the other problems with the UITitleBarMorph and the extra spaces, I think is also produced by bugs in the same area, after all BobsUI are not changing that area. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 5257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 3932 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 3902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-01-22 at 11.48.06.png Type: image/png Size: 11302 bytes Desc: not available URL: From marcel.taeumel at hpi.de Mon Jan 25 15:44:54 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 16:44:54 +0100 Subject: [squeak-dev] The Trunk: Tools-mt.1024.mcz In-Reply-To: References: <,> <0a899bd15d2c4f91b73c41411a09a85f@student.hpi.uni-potsdam.de> <,> Message-ID: > Improve the HTML support, for example a tag for text indent? Or finally implement #asTextFromMarkdown? :-) Hmmm... and should work with #asTextFromHtml. Then we could get rid of (all those) "asString asText allBold" :-)  Best, Marcel Am 25.01.2021 13:35:52 schrieb Thiede, Christoph : > How come? Too wordy? :-) Not at all, just an elaborate layout, better than pure plain text - elaborate enough that I start wondering whether we could need some set of formatting markup instead of all the "format:", "addAttribute:", "asString asText allBold" etc. ... Improve the HTML support, for example a tag for text indent? Or finally implement #asTextFromMarkdown? :-) (By the way, this "maybe save your image before doing this" reminds me of #isScarySelector: - should we use a similar concept here to prevent too many warnings?) Best, Christoph Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Montag, 25. Januar 2021 11:26:15 An: squeak-dev Betreff: Re: [squeak-dev] The Trunk: Tools-mt.1024.mcz   > Nearly "too" modern to fit into [...] How come? Too wordy? :-) > but a very nice step into the right direction ... :-) Unfortunately, "manual checkpointing" is the only "undo method" we can provide at this level.  Best, Marcel Am 24.01.2021 19:06:56 schrieb Thiede, Christoph : Beautiful! Nearly "too" modern to fit into the entire Squeak appearance - but a very nice step into the right direction ... :-) Best, Christoph [http://www.hpi.de/] Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 14. Januar 2021 13:24:13 An: squeak-dev Betreff: Re: [squeak-dev] The Trunk: Tools-mt.1024.mcz   Best, Marcel Am 14.01.2021 13:21:28 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-mt.1024.mcz ==================== Summary ==================== Name: Tools-mt.1024 Author: mt Time: 14 January 2021, 1:21:15.354081 pm UUID: 0ef67378-0ca6-4743-be9c-5a60621c07cd Ancestors: Tools-mt.1023 Improves the description of several confirmation dialogs for removing batches of source code. =============== Diff against Tools-mt.1023 =============== Item was changed: ----- Method: Browser>>removeMessageCategory (in category 'message category functions') ----- removeMessageCategory "If a message category is selected, create a Confirmer so the user can verify that the currently selected message category should be removed from the system. If so, remove it." | messageCategoryName | self hasMessageCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. messageCategoryName := self selectedMessageCategoryName. (self messageList size = 0 + or: [Project uiManager confirm: ('Are you sure you want to remove\the message category\\ {1}\ in {2}\\and all its {3} methods? Maybe save\your image before doing this.' translated withCRs asText format: { + messageCategoryName asText allBold. + self selectedClassOrMetaClass name. + (self selectedClassOrMetaClass organization listAtCategoryNamed: messageCategoryName) size asString asText allBold + + }) title: 'Remove Message Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this method category - and all its methods?']) ifTrue: [self selectedClassOrMetaClass removeCategory: messageCategoryName. self selectMessageCategoryNamed: nil. self changed: #classSelectionChanged]. self changed: #messageCategoryList. ! Item was changed: ----- Method: Browser>>removeSystemCategory (in category 'system category functions') ----- removeSystemCategory "If a class category is selected, create a Confirmer so the user can verify that the currently selected class category and all of its classes should be removed from the system. If so, remove it." self hasSystemCategorySelected ifFalse: [^ self]. self okToChange ifFalse: [^ self]. (self classList size = 0 + or: [Project uiManager + confirm: ('Are you sure you want to remove\the system category\\ {1}\\and all its {2} classes? Maybe save\your image before doing this.' translated withCRs asText + format: { + self selectedSystemCategory asText allBold. + (systemOrganizer listAtCategoryNamed: self selectedSystemCategory) size asString asText allBold}) + title: 'Remove System Category' translated]) - or: [self confirm: 'Are you sure you want to - remove this system category - and all its classes?']) ifTrue: [| nextSelectedCat | nextSelectedCat := self systemCategoryList before: self selectedSystemCategory ifAbsent: [nil]. systemOrganizer removeSystemCategory: self selectedSystemCategory. self selectSystemCategory: nextSelectedCat. self changed: #systemCategoryList]! Item was changed: ----- Method: CodeHolder>>removeClass (in category 'commands') ----- removeClass "Remove the selected class from the system, at interactive user request. Make certain the user really wants to do this, since it is not reversible. Answer true if removal actually happened." | message className classToRemove result | self okToChange ifFalse: [^ false]. classToRemove := self selectedClassOrMetaClass ifNil: [Beeper beep. ^ false]. classToRemove := classToRemove theNonMetaClass. className := classToRemove name. + message := 'Are you sure that you want to remove\the class\\ {1}\\and all its {2} methods? Maybe save\your image before doing this.{3}' translated withCRs asText format: { + className asText allBold. + (classToRemove methodDict size + classToRemove class methodDict size) asString asText allBold. + classToRemove subclasses size > 0 ifFalse: [''] ifTrue: [ + '\\(There are {1} subclasses, whose superclass\must be updated manually after this.)' translated withCRs asText format: { classToRemove subclasses size asString asText allBold }]}. + (result := Project uiManager confirm: message title: 'Remove Class' translated) - message := 'Are you certain that you - want to REMOVE the class ', className, ' - from the system?'. - (result := self confirm: message) ifTrue: [classToRemove subclasses size > 0 ifTrue: [(self confirm: 'class has subclasses: ' , message) ifFalse: [^ false]]. classToRemove removeFromSystem. self changed: #classList. true]. ^ result! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 29075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 22215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24309 bytes Desc: not available URL: From commits at source.squeak.org Mon Jan 25 15:48:08 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 25 Jan 2021 15:48:08 0000 Subject: [squeak-dev] The Trunk: Multilingual-ul.254.mcz Message-ID: Levente Uzonyi uploaded a new version of Multilingual to project The Trunk: http://source.squeak.org/trunk/Multilingual-ul.254.mcz ==================== Summary ==================== Name: Multilingual-ul.254 Author: ul Time: 25 January 2021, 4:45:35.267328 pm UUID: ba4ade3a-e1eb-4bfd-b130-a46de80bfe0c Ancestors: Multilingual-eem.253 - speed up MultiByteFileStream >> #upToEnd by processing the file in larger chunks and reusing the implementation of StandardFileStream if the stream is binary =============== Diff against Multilingual-eem.253 =============== Item was changed: ----- Method: MultiByteFileStream>>upToEnd (in category 'public') ----- upToEnd + "Answer a subcollection from the current access position through the last element of the receiver." + | remainingEstimate | + self isBinary ifTrue: [ ^super upToEnd ]. + remainingEstimate := self size - self position. ^self collectionSpecies + new: remainingEstimate - new: self size - self position streamContents: [ :stream | + | elements chunkSize | + chunkSize := remainingEstimate min: 20000. + [ (elements := self next: chunkSize) isEmpty ] whileFalse: [ + stream nextPutAll: elements ] ]! - | element | - [ (element := self next) == nil ] whileFalse: [ - stream nextPut: element ] ] - ! From commits at source.squeak.org Mon Jan 25 15:48:28 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 25 Jan 2021 15:48:28 0000 Subject: [squeak-dev] The Trunk: Files-ul.186.mcz Message-ID: Levente Uzonyi uploaded a new version of Files to project The Trunk: http://source.squeak.org/trunk/Files-ul.186.mcz ==================== Summary ==================== Name: Files-ul.186 Author: ul Time: 25 January 2021, 4:46:58.396742 pm UUID: 2ae84c53-ba51-4aa6-9840-891243638cc6 Ancestors: Files-dtl.185 - speed up StandardFileStream >> #upToEnd by reading the remaining data all at once =============== Diff against Files-dtl.185 =============== Item was changed: ----- Method: StandardFileStream>>upToEnd (in category 'read, write, position') ----- upToEnd "Answer a subcollection from the current access position through the last element of the receiver." + ^self next: self size - self position! - ^self collectionSpecies streamContents: [ :newStream | - | next | - [ (next := self next) == nil ] whileFalse: [ - newStream nextPut: next ] ]! From marcel.taeumel at hpi.de Mon Jan 25 15:49:26 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 25 Jan 2021 16:49:26 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <,> Message-ID: > But wouldn't violate that the #forceUpdate preference when a non-UI process blocks the image for a while? ... "violate" is such a strong word. ^__^ I know that we have a "lock" in Transcript to at least not mix up the buffer contents. "forceUpdate" could be enabled by adding an extra semaphore to let the non-ui process sleep until that deferred UI message got processed. Best, Marcel Am 25.01.2021 13:24:51 schrieb Thiede, Christoph : > In #endEntry, we could check for "Processor activeProcess == Project current uiProcess" to then use "Project current addDeferredUIMessage..." automatically. But wouldn't violate that the #forceUpdate preference when a non-UI process blocks the image for a while? Best, Christoph Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Montag, 25. Januar 2021 12:25:56 An: squeak-dev Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?)   > It's simply not thread-safe. Hmm... in particular, there is a side effect (i.e. layout update) in the window's pluggable text morph. Even if #forceUpdate is false. In #endEntry, we could check for "Processor activeProcess == Project current uiProcess" to then use "Project current addDeferredUIMessage..." automatically. Best, Marcel Am 23.01.2021 21:05:05 schrieb Levente Uzonyi : On Fri, 22 Jan 2021, tim Rowledge wrote: > > >> On 2021-01-22, at 5:26 PM, David T. Lewis wrote: >> >> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: >>> I ran the following in Squeak 5.3: >>> >>> TranscriptStream forceUpdate: false. >>> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 >>> >>> When the Transcript window fills up, 'Message not understood' and 'Assertion >>> failure' appear. I'm wondering is this a bug? Thanks. Jaromir >>> >>> >>> >> >> It certainly does appear to be a bug. > > We had some discussion about it not so long ago; you can't use the Transcript to log bugs from Seaside very well, for example. Background processes, mutexs, that sort of thing. IIRC Levente offered an explanation? It's simply not thread-safe. If you want it to be thread-safe, you can pass your message to the UI process to show it. Make sure your message is computed in its own process and is passed as a precomputed string to avoid other kinds of race conditions. E.g.: | theMessage | theMessage := 'Something very {1}.' format: { 'important' }. Project current addDeferredUIMessage: [ Transcript show: theMessage; cr ]. Levente > > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > The hardness of the butter is proportional to the softness of the bread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank-lesser at lesser-software.com Mon Jan 25 16:11:35 2021 From: frank-lesser at lesser-software.com (Frank Lesser) Date: Mon, 25 Jan 2021 17:11:35 +0100 Subject: [squeak-dev] [offtopic] WxSqueak In-Reply-To: References: <5bc85424-6cbb-bfaa-f23d-e7396f0e17b3@lesser-software.com> Message-ID: https://twitter.com/LesserFrank/status/1353736646102020096?s=20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From motivkin at gmail.com Mon Jan 25 16:36:05 2021 From: motivkin at gmail.com (zumzum12) Date: Mon, 25 Jan 2021 10:36:05 -0600 (CST) Subject: [squeak-dev] Online tutor Message-ID: <1611592565429-0.post@n4.nabble.com> Hi, is anyone free for some payed help with some simple smalltalk squeak stuff (a number of lessons) ? -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From m at jaromir.net Mon Jan 25 18:30:06 2021 From: m at jaromir.net (jaromir) Date: Mon, 25 Jan 2021 12:30:06 -0600 (CST) Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> Message-ID: <1611599406320-0.post@n4.nabble.com> > It's simply not thread-safe. Are you saying whenever the UI process interrupts Transcript printing from a lower-priority non-UI process a failure occurs? I tried [ 20 timesRepeat: [ 1000 factorial . Transcript show: 'x' ] ] forkAt: 39 a few times while having the Transcript window full and sooner rather than later it failed *regardless *of the #forceUpdate setting. > In #endEntry, we could check for "Processor activeProcess == Project > current uiProcess" to then use "Project current addDeferredUIMessage..." > automatically. Deferring automatically would actually mean #forceUpdate = true no longer means anything for lower-priority non-UI processes, right? (Because the problem seems to occur regardless of #forceUpdate setting) It still seems to me it has something to do with scrolling the full Transcript window... Regards, Jaromir -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From jecel at merlintec.com Mon Jan 25 19:50:42 2021 From: jecel at merlintec.com (Jecel Assumpcao Jr) Date: Mon, 25 Jan 2021 16:50:42 -0300 Subject: [squeak-dev] copyright (was: The Trunk: System-eem.1211.mcz) In-Reply-To: References: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> <2A34E0BF-002C-4D4C-9A34-23DA955E4B20@gmx.de> Message-ID: <20210125195051.5E60B5E012D@proxy.email-ssl.com.br> Contributions from the Squeak community started in 1996. So much so that the bulk of the relicensing effort was tracking down the individual copyright owners for these early contributions and getting them to sign a relicensing agreement to move from SqueakL to MIT. Later on we got developer initials added to the system, but before Squeak 2.0 contributions were sent this this list and then copy/pasted by Dan Ingalls into the official image. While we asked these people to relicense their code we did not ask them to reassign their copyright to some other entity, so they are still the owners of those code fragments (supposing they are still present in current Squeaks). -- Jecel From m at jaromir.net Mon Jan 25 20:38:26 2021 From: m at jaromir.net (jaromir) Date: Mon, 25 Jan 2021 14:38:26 -0600 (CST) Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: <1611599406320-0.post@n4.nabble.com> References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> Message-ID: <1611607106337-0.post@n4.nabble.com> Well, I tried deferring the whole Transcript endEntry machinery to the UI doOneCycle (bypassing the changed: #appendEntryLater mechanism) for #forceUpdate = false only ... and it seems to avoid the problem! TranscriptStream >> endEntry deferredEntry ifNil: [ false ]. "this is a new instance variable" self semaphore critical:[ self class forceUpdate ifTrue: [self changed: #appendEntry; reset] ifFalse: [deferredEntry := true]. TranscriptStream >> flushDeferredEntry "This is run every UI cycle in doOneCycleNowFor:" deferredEntry ifTrue: [ self class forceUpdate: true. self endEntry. deferredEntry := false. self class forceUpdate: false. ] doOneCycleNowFor: aWorld "... the whole body remains unchanged except:" capturingGesture ifFalse: [aWorld runStepMethods. Transcript flushDeferredEntry. "this is printing for #forceUpdate = false" self displayWorldSafely: aWorld]. For #forceUpdate = true the endEntry mechanism remains unchanged and failing as before... -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From forums.jakob at resfarm.de Mon Jan 25 21:41:24 2021 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Mon, 25 Jan 2021 15:41:24 -0600 (CST) Subject: [squeak-dev] The Trunk: System-eem.1211.mcz In-Reply-To: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> References: <5b8d53dc775f4f4f9d9f7152d49c6427@student.hpi.uni-potsdam.de> Message-ID: <1611610884086-0.post@n4.nabble.com> Christoph Thiede wrote > Hm ... would it be presumptuous to say: > > > 'Copyright © 2010-{1} Squeak Community Contributors.' format: {2021 max: > Date today year} > > > ? :-) For what it is worth, then you could also just drop the numbers altogether. My vote would be: update the number manually when a release is made. Don't update it automatically or in the meantime. Let's pretend (and hope the opposite) that Squeak gets no further contributions after 70 years from now. Just like, I would assume, nobody is working on software for 1950's computers any longer. It would be ridiculous if a Squeak image from 2030 were rediscovered by archeologists (or aliens if you like) and it would claim a copyright to the year 3157. Related reading and opinions: https://www.reddit.com/r/webdev/comments/1p9tao/auto_updating_the_year_on_copyright_notices/ https://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From eliot.miranda at gmail.com Tue Jan 26 01:05:05 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon, 25 Jan 2021 17:05:05 -0800 Subject: [squeak-dev] The Inbox: Kernel-ct.1368.mcz In-Reply-To: <20210124161036.GA46187@shell.msen.com> References: <0C656B9D-3EC4-483F-888E-CAA774A00C5F@gmail.com> <20210124161036.GA46187@shell.msen.com> Message-ID: Hi David, On Sun, Jan 24, 2021 at 8:10 AM David T. Lewis wrote: > I like this proposal. It has no effect on the ProcessBrowser, and is > helpful when looking at processes elsewhere. > > Most processes do not have a name, but all processes respond in a concise > and useful way to #name. > > Process>>name > ^name ifNil: [ self hash asString forceTo: 5 paddingStartWith: $ ] > 5 is too short. The identityHash in Spur has 7 digits of significance and hash => scaledIdentityHash => identityHash * 256. Also asString is lazy; it just calls printString. I wouldn't contract at all: Process>>name ^name ifNil: [self hash printString] > So +1 from me > > Dave > > On Sun, Jan 24, 2021 at 03:28:20PM +0000, Thiede, Christoph wrote: > > Hi Eliot, > > > > > > thanks for the feedback! I actually intended to print their short hash > if they don't have a real name because this can still be very helpful in > order to differentiate between multiple processes each suspended in the > same method. It would also help me to identify a process from the process > browser somewhere else. Do you get my point? :-) > > > > > > Best, > > > > Christoph > > > > > > ________________________________ > > Von: Squeak-dev im > Auftrag von Eliot Miranda > > Gesendet: Sonntag, 24. Januar 2021 15:55:42 > > An: squeak-dev at lists.squeakfoundation.org > > Betreff: Re: [squeak-dev] The Inbox: Kernel-ct.1368.mcz > > > > Hi Christoph, > > > > only a few processes have a name. Surely this should test from > there being a name and not print some noise if it doesn???t have a name. > > > > _,,,^..^,,,_ (phone) > > > > > On Jan 24, 2021, at 6:19 AM, commits at source.squeak.org wrote: > > > > > > ???A new version of Kernel was added to project The Inbox: > > > http://source.squeak.org/inbox/Kernel-ct.1368.mcz > > > > > > ==================== Summary ==================== > > > > > > Name: Kernel-ct.1368 > > > Author: ct > > > Time: 24 January 2021, 3:19:48.003384 pm > > > UUID: c62a6062-b240-9149-a2ed-78fdc1079dfd > > > Ancestors: Kernel-mt.1364 > > > > > > Proposal: Always include process name into its print string. This > facilitates debugging/inspecting of multiprocess scenarios. > > > > > > =============== Diff against Kernel-mt.1364 =============== > > > > > > Item was changed: > > > ----- Method: Process>>longPrintOn: (in category 'printing') ----- > > > longPrintOn: stream > > > > > > | ctxt | > > > super printOn: stream. > > > + stream > > > + nextPut: $(; > > > + nextPutAll: self name; > > > + nextPut: $). > > > stream cr. > > > ctxt := self suspendedContext. > > > [ctxt == nil] whileFalse: [ > > > stream space. > > > ctxt printOn: stream. > > > stream cr. > > > ctxt := ctxt sender. > > > ]. > > > ! > > > > > > Item was changed: > > > ----- Method: Process>>printOn: (in category 'printing') ----- > > > printOn: aStream > > > > > > super printOn: aStream. > > > + aStream > > > + nextPut: $(; > > > + nextPutAll: self name; > > > + nextPut: $). > > > aStream nextPutAll: ' in '. > > > suspendedContext printOn: aStream! > > > > > > > > > > > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Tue Jan 26 02:19:27 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 25 Jan 2021 21:19:27 -0500 Subject: [squeak-dev] The Inbox: Kernel-ct.1368.mcz In-Reply-To: References: <0C656B9D-3EC4-483F-888E-CAA774A00C5F@gmail.com> <20210124161036.GA46187@shell.msen.com> Message-ID: <20210126021927.GA46698@shell.msen.com> On Mon, Jan 25, 2021 at 05:05:05PM -0800, Eliot Miranda wrote: > Hi David, > > On Sun, Jan 24, 2021 at 8:10 AM David T. Lewis wrote: > > > I like this proposal. It has no effect on the ProcessBrowser, and is > > helpful when looking at processes elsewhere. > > > > Most processes do not have a name, but all processes respond in a concise > > and useful way to #name. > > > > Process>>name > > ^name ifNil: [ self hash asString forceTo: 5 paddingStartWith: $ ] > > > > 5 is too short. The identityHash in Spur has 7 digits of significance and > hash => scaledIdentityHash => identityHash * 256. Also asString is lazy; > it just calls printString. I wouldn't contract at all: > > Process>>name > ^name ifNil: [self hash printString] > > > > So +1 from me > > What I said is that I like Christoph's proposal, that's all. If we think that we should change the implementation of Process>>name that's fine too, but let's not it get in the way of merging Christoph's suggestion into trunk. OK? Dave From tim at rowledge.org Tue Jan 26 04:40:07 2021 From: tim at rowledge.org (tim Rowledge) Date: Mon, 25 Jan 2021 20:40:07 -0800 Subject: [squeak-dev] Squeak 5.3 suitable FFI version(s)? In-Reply-To: References: Message-ID: <754B3115-1B03-4CB5-ABA4-D0804E52F570@rowledge.org> > On 2021-01-25, at 2:12 AM, Marcel Taeumel wrote: > > Hi Tim. > > For Squeak 5.3, use the Metacello script: > > Metacello new > configuration: 'FFI'; > load. Mmmm.. not for this Scratch release. I don't want the fairly considerable weight of it in the release image that will go on actual millions of Pi. > > Latest version for 5.3 is FFI version 1.13 with: > - FFI-Pools.TorstenBergmann.4 > - FFI-Kernel-nice.68 > - FFI-Tests-nice.14 > - FFI-MacOS-spd.5 > - FFI-Win32-cbc.16 > - FFI-Unix-mtf.4 That's the info I needed! Thanks! tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Oxymorons: Airline Food From commits at source.squeak.org Tue Jan 26 12:56:58 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 26 Jan 2021 12:56:58 0000 Subject: [squeak-dev] The Inbox: Collections-mt.923.mcz Message-ID: A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-mt.923.mcz ==================== Summary ==================== Name: Collections-mt.923 Author: mt Time: 26 January 2021, 1:56:55.975966 pm UUID: 7d07d822-4bdf-486c-bf81-0af98356ee28 Ancestors: Collections-ul.922 Makes Transcript's #endEntry thread-safe. Supports #forceUpdate property across processes, too. =============== Diff against Collections-ul.922 =============== Item was changed: WriteStream subclass: #TranscriptStream + instanceVariableNames: 'lastChar lock shouldFlush' - instanceVariableNames: 'lastChar lock' classVariableNames: 'CharacterLimit ForceUpdate RedirectToStdOut' poolDictionaries: '' category: 'Collections-Streams'! !TranscriptStream commentStamp: 'fbs 12/30/2013 09:53' prior: 0! This class is a much simpler implementation of Transcript protocol that supports multiple views and very simple conversion to morphic. Because it inherits from Stream, it is automatically compatible with code that is designed to write to streams.! Item was added: + ----- Method: TranscriptStream>>doFlushToUiDependents (in category 'stream extensions - flush') ----- + doFlushToUiDependents + + self changed: #appendEntryLater. "mt: Maybe we can change #appendEntry in pluggable text fields and remove #appendEntryLater." + self class forceUpdate ifTrue: [Project current restore]. + self reset.! Item was changed: ----- Method: TranscriptStream>>endEntry (in category 'stream extensions') ----- endEntry "Display all the characters since the last endEntry, and reset the stream" self lock critical: + [self redirectToStdOut - [(self == Transcript and: [self class redirectToStdOut]) ifTrue: + [self flushToStdOut] - [FileStream stdout nextPutAll: self contents; flush] ifFalse: + [self flushToUiDependents]]! - [self changed: (self class forceUpdate - ifTrue: [#appendEntry] - ifFalse: [#appendEntryLater])]. - self reset]! Item was changed: + ----- Method: TranscriptStream>>flush (in category 'stream extensions - flush') ----- - ----- Method: TranscriptStream>>flush (in category 'stream extensions') ----- flush self endEntry ! Item was added: + ----- Method: TranscriptStream>>flushToStdOut (in category 'stream extensions - flush') ----- + flushToStdOut + + FileStream stdout + nextPutAll: self contents; + flush. + self reset.! Item was added: + ----- Method: TranscriptStream>>flushToUiDependents (in category 'stream extensions - flush') ----- + flushToUiDependents + + Project current uiProcess == Processor activeProcess + ifTrue: [self doFlushToUiDependents] + ifFalse: [self triggerFlushToUiDependents].! Item was added: + ----- Method: TranscriptStream>>redirectToStdOut (in category 'testing') ----- + redirectToStdOut + "The global property only controls the global Transcript. Extra transcripts are not redirected." + + ^ self == Transcript and: [self class redirectToStdOut]! Item was removed: - ----- Method: TranscriptStream>>target (in category 'stream extensions') ----- - target - ^(self == Transcript and: [self class redirectToStdOut]) - ifTrue: [FileStream stdout] - ifFalse: [self]! Item was added: + ----- Method: TranscriptStream>>triggerFlushToUiDependents (in category 'stream extensions - flush') ----- + triggerFlushToUiDependents + + | signal | + self assert: [Processor activeProcess ~~ Project current uiProcess]. + + signal := Semaphore new. + shouldFlush := true. + Project current addDeferredUIMessage: [ + shouldFlush == true ifTrue: [ + shouldFlush := false. + self doFlushToUiDependents]. + signal signal]. + + self class forceUpdate ifTrue: [signal wait].! From marcel.taeumel at hpi.de Tue Jan 26 12:59:58 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 26 Jan 2021 13:59:58 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: <1611607106337-0.post@n4.nabble.com> References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> Message-ID: Hi Jaromir, please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) @all: Would Transcript now be thread-safe? Did I miss something? Best, Marcel Am 25.01.2021 21:38:36 schrieb jaromir : Well, I tried deferring the whole Transcript endEntry machinery to the UI doOneCycle (bypassing the changed: #appendEntryLater mechanism) for #forceUpdate = false only ... and it seems to avoid the problem! TranscriptStream >> endEntry deferredEntry ifNil: [ false ]. "this is a new instance variable" self semaphore critical:[ self class forceUpdate ifTrue: [self changed: #appendEntry; reset] ifFalse: [deferredEntry := true]. TranscriptStream >> flushDeferredEntry "This is run every UI cycle in doOneCycleNowFor:" deferredEntry ifTrue: [ self class forceUpdate: true. self endEntry. deferredEntry := false. self class forceUpdate: false. ] doOneCycleNowFor: aWorld "... the whole body remains unchanged except:" capturingGesture ifFalse: [aWorld runStepMethods. Transcript flushDeferredEntry. "this is printing for #forceUpdate = false" self displayWorldSafely: aWorld]. For #forceUpdate = true the endEntry mechanism remains unchanged and failing as before... -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Jan 26 15:48:13 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 26 Jan 2021 15:48:13 0000 Subject: [squeak-dev] The Inbox: Morphic-mt.1719.mcz Message-ID: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-mt.1719.mcz ==================== Summary ==================== Name: Morphic-mt.1719 Author: mt Time: 26 January 2021, 4:48:07.757802 pm UUID: 613d0cd1-c5b4-4baf-ae61-45025f85b4ea Ancestors: Morphic-mt.1718 Quick experiment to improve discoverability of modal dialogs. (Might be too annoying when planning to close-confirm many windows in a row.) =============== Diff against Morphic-mt.1718 =============== Item was changed: ----- Method: DialogWindow>>getUserResponse (in category 'running') ----- getUserResponse + | hand world shade | - | hand world | self message ifEmpty: [messageMorph delete]. "Do not waste space." self paneMorph submorphs ifEmpty: ["Do not waste space and avoid strange button-row wraps." self paneMorph delete. self buttonRowMorph wrapDirection: #none]. hand := self currentHand. world := self currentWorld. self fullBounds. self moveToPreferredPosition. + + self exclusive ifTrue: [ + world addMorphFront: (shade := Morph new color: (Color black alpha: 0.5); bounds: world bounds; lock; yourself). + SystemWindow topWindow ifNotNil: #comeToFront]. self openInWorld: world. hand showTemporaryCursor: nil. "Since we are out of context, reset the cursor." hand keyboardFocus in: [:priorKeyboardFocus | hand mouseFocus in: [:priorMouseFocus | self exclusive ifTrue: [hand newMouseFocus: self]. hand newKeyboardFocus: self. [[self isInWorld] whileTrue: [world doOneSubCycle]] ifCurtailed: [self cancelDialog]. + shade ifNotNil: #abandon. hand newKeyboardFocus: priorKeyboardFocus. self flag: #discuss. "Since 2016 we are having this *ping pong* between (a) restoring the prior mouse focus and (b) just clearing it globally. The former solution makes more sense while the latter fixes issues with some modal dialogs. We have to investigate this further." hand releaseMouseFocus. "hand newMouseFocus: priorMouseFocus."]]. ^ result! From marcel.taeumel at hpi.de Tue Jan 26 15:49:26 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 26 Jan 2021 16:49:26 +0100 Subject: [squeak-dev] The Inbox: Morphic-mt.1719.mcz In-Reply-To: References: Message-ID: Am 26.01.2021 16:48:26 schrieb commits at source.squeak.org : A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-mt.1719.mcz ==================== Summary ==================== Name: Morphic-mt.1719 Author: mt Time: 26 January 2021, 4:48:07.757802 pm UUID: 613d0cd1-c5b4-4baf-ae61-45025f85b4ea Ancestors: Morphic-mt.1718 Quick experiment to improve discoverability of modal dialogs. (Might be too annoying when planning to close-confirm many windows in a row.) =============== Diff against Morphic-mt.1718 =============== Item was changed: ----- Method: DialogWindow>>getUserResponse (in category 'running') ----- getUserResponse + | hand world shade | - | hand world | self message ifEmpty: [messageMorph delete]. "Do not waste space." self paneMorph submorphs ifEmpty: ["Do not waste space and avoid strange button-row wraps." self paneMorph delete. self buttonRowMorph wrapDirection: #none]. hand := self currentHand. world := self currentWorld. self fullBounds. self moveToPreferredPosition. + + self exclusive ifTrue: [ + world addMorphFront: (shade := Morph new color: (Color black alpha: 0.5); bounds: world bounds; lock; yourself). + SystemWindow topWindow ifNotNil: #comeToFront]. self openInWorld: world. hand showTemporaryCursor: nil. "Since we are out of context, reset the cursor." hand keyboardFocus in: [:priorKeyboardFocus | hand mouseFocus in: [:priorMouseFocus | self exclusive ifTrue: [hand newMouseFocus: self]. hand newKeyboardFocus: self. [[self isInWorld] whileTrue: [world doOneSubCycle]] ifCurtailed: [self cancelDialog]. + shade ifNotNil: #abandon. hand newKeyboardFocus: priorKeyboardFocus. self flag: #discuss. "Since 2016 we are having this *ping pong* between (a) restoring the prior mouse focus and (b) just clearing it globally. The former solution makes more sense while the latter fixes issues with some modal dialogs. We have to investigate this further." hand releaseMouseFocus. "hand newMouseFocus: priorMouseFocus."]]. ^ result! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 408672 bytes Desc: not available URL: From eliot.miranda at gmail.com Tue Jan 26 22:17:24 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue, 26 Jan 2021 14:17:24 -0800 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> <20210123011630.GA93733@shell.msen.com> Message-ID: Hi Hannes, Hi All, On Mon, Jan 25, 2021 at 2:36 AM H. Hirzel wrote: > Hi Arjen > > The instructions in > http://wiki.squeak.org/squeak/2848 > (Squeak 5.3) > worked for me some time ago. > > 1. > The main point before unloading is to reclassify some methods > currently belonging to Etoys to the general Squeak as they are needed > for Squeak to work. > > 2. > After reclassifying unloading of Etoys works. > > 3. > However some more fixes need to be done in order to have the remaining > code not call Etoys methods which are no longer there. > > To all: the necessary fixes are all quite simple. However the steps > need to be checked also with the current trunk image. The fixes would > also be useful to be added to Squeak 5.3 > Let's do this work. I just moved a couple of copyright methods from EToys to System in System-eem.1212. What is preventing people from committing changes to get us to the goal of an unloadable EToys? I also heard recently that EToys is not functional. IIRC this isn't quite correct; it's that older ETys projects don't currently load into a Squeak trunk EToys. But now that Vanessa has implemented the segment loader above the VM we at least have the infrastructure. Who has the time and energy to try and get older EToys projects to load and run? And does someone have a (hopefully short) list of older EToys projects of particular value we should focus on? > HTH > > Hannes > > On 1/23/21, David T. Lewis wrote: > > On Thu, Jan 21, 2021 at 12:07:06PM +0000, Arjen van Elteren via > Squeak-dev > > wrote: > >> All, > >> > >> I would like to unload the EToys packages from image. > >> > >> I tried with the Monticello Browser, unloading seems to proceed. But at > >> the end nothing is reacting anymore. > >> > >> Any hint on how to successfully unload the EToys? > >> > >> Should I use a workspace in an MVC project? > >> > > > > Hello Arjen, > > > > I don't think that unloading works yet, but hopefully soon. The > > goal is to make Etoys reloadable, which means that it can be fully > > removed from the image, and also reinstalled into an image from > > which it has been removed. > > > > A lot of good work has gone into this in the last few years, but > > it is not complete. If you do any work on this yourself, any input > > would be welcome either as inbox contributions or messages to > > the list here. > > > > I should mention also that this topic came up (again!) in the > > last online meeting of our Squeak oversight board and it is on > > our agenda for the next meeting. I think everyone agrees that > > this is important to do, it's just a small matter of somebody > > doing the work ;-) > > > > Dave > > > > > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Tue Jan 26 22:45:55 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue, 26 Jan 2021 14:45:55 -0800 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> Message-ID: Hi Marcel, Hi All, On Mon, Jan 25, 2021 at 3:26 AM Marcel Taeumel wrote: > > It's simply not thread-safe. > > Hmm... in particular, there is a side effect (i.e. layout update) in the > window's pluggable text morph. Even if #forceUpdate is false. > > In #endEntry, we could check for "Processor activeProcess == Project > current uiProcess" to then use "Project current addDeferredUIMessage..." > automatically. > That gave me a scare. At first I thought that the effectiveProcess changes to ProcessorScheduler>>activeProcess could have made that expression no longer thread safe. But it isn't anyway, and the above is very bad style. Let me explain. The suspension points in the VM are - the first bytecode of any non-quick method (following a primitive if it has one) - the first bytecode of any block - a backward branch In the JIT there are fewer suspension points: - the first bytecode of any method containing a send other than #== and/or #class (and given that ifNil:ifNotNil: is inlined into a send of #== and jumps, ifNil: sends don't count) - the first bytecode of any block containing a send other than #== and/or #class - a backward branch So given ProcessorScheduler>>#activeProcess "suspension point here on an interpreter VM, and the first time in the JIT VM" ^activeProcess effectiveProcess Process>>#effectiveProcess "suspension point here on an interpreter VM, and the first time in the JIT VM" ^effectiveProcess ifNil: [self] Project class>>#current "suspension point here on an interpreter VM, and the first time in the JIT VM" ^CurrentProject MVCProject>>#uiProcess "suspension point here on an interpreter VM, and the first time in the JIT VM" ^ world activeControllerProcess MorphicProject>>#uiProcess "no suspension point here on any VM obeying the blue-book spec" ^uiProcess we can see that "Processor activeProcess == Project current uiProcess" is not thread-safe in the interpreter; there is a suspension point in Project current before CurrentProject is returned (but not in the JIT); there is a suspension point in MVC in uiProcess. There is a suspension point in ProcessorScheduler>>#activeProcess before the send of effectiveProcess to activeProcess, but since no data is fetched until the process resumes this is harmless. However, were the expression written as "Project current uiProcess == Processor activeProcess" then this would no longer be harmless. So on all VMs this is not reliably thread-safe. Even on the JIT VM the first use of any method (except a doit) is interpreted. Once the JIT VM, once it has started up and the methods have been jitted, "Processor activeProcess == Project current uiProcess" is thread-safe on Morphic, but not on MVC. So we really shouldn't be using things like this. They'll appear to work and in very rare circumstances they won't. So let's please use the proper construct, Mutex. But that makes me realize that the effectiveProcess changes are unsafe on an interpreter VM (and hence we're on;y getting away with it on the JIT VM). Se really need some way of saying that ProcessorScheduler>>#activeProcess is atomic, e.g. Process>>#effectiveProcess ^effectiveProcess ifNil: [self] But I don't know how to implement this right now. Note that we do have BlockClosure>>#valueNoContextSwitch "An exact copy of BlockClosure>>value except that this version will not preempt the current process on block activation if a higher-priority process is runnable. Primitive. Essential." numArgs ~= 0 ifTrue: [self numArgsError: 0]. self primitiveFailed FullBlockClosure>>#valueNoContextSwitch "An exact copy of BlockClosure>>value except that this version will not preempt the current process on block activation if a higher-priority process is runnable. Primitive. Essential." numArgs ~= 0 ifTrue: [self numArgsError: 0]. self primitiveFailed but the VM uses the primitive numbers to control context switching. We don't have a mechanism the VM can use to label a normal method such as Process>>#effectiveProcess as not to allow an interrupt. > Best, > Marcel > > Am 23.01.2021 21:05:05 schrieb Levente Uzonyi : > On Fri, 22 Jan 2021, tim Rowledge wrote: > > > > > > >> On 2021-01-22, at 5:26 PM, David T. Lewis wrote: > >> > >> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: > >>> I ran the following in Squeak 5.3: > >>> > >>> TranscriptStream forceUpdate: false. > >>> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 > >>> > >>> When the Transcript window fills up, 'Message not understood' and > 'Assertion > >>> failure' appear. I'm wondering is this a bug? Thanks. Jaromir > >>> > >>> > >>> > >> > >> It certainly does appear to be a bug. > > > > We had some discussion about it not so long ago; you can't use the > Transcript to log bugs from Seaside very well, for example. Background > processes, mutexs, that sort of thing. IIRC Levente offered an explanation? > > It's simply not thread-safe. > If you want it to be thread-safe, you can pass your message to the UI > process to show it. Make sure your message is computed in its own process > and is passed as a precomputed string to avoid other kinds of race > conditions. E.g.: > > | theMessage | > theMessage := 'Something very {1}.' format: { 'important' }. > Project current addDeferredUIMessage: [ Transcript show: theMessage; cr ]. > > > Levente > > > > > > > tim > > -- > > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > > The hardness of the butter is proportional to the softness of the bread. > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Wed Jan 27 00:28:01 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 27 Jan 2021 00:28:01 0000 Subject: [squeak-dev] The Trunk: Kernel-eem.1366.mcz Message-ID: Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.1366.mcz ==================== Summary ==================== Name: Kernel-eem.1366 Author: eem Time: 26 January 2021, 4:27:57.204259 pm UUID: 3a706d32-c2d6-416f-82c1-bbf735650385 Ancestors: Kernel-eem.1365 Slightly faster implementation of Context>>#isPrimFailToken:. Improve the comments in Context>>#isHandlerContext/#isUnwindContext. Nuke an obsolete method. =============== Diff against Kernel-eem.1365 =============== Item was changed: ----- Method: Context>>isHandlerContext (in category 'private-exceptions') ----- isHandlerContext + "Answer if the receiver is for a method that is marked as an exception handler. + BlockClosure>>#on:do: uses this primitive to identify itself to the VM + as an exception handler method, which the VM uses in primitive 197 + Context>>#findNextHandlerContextStarting, primitiveFindHandlerContext, + to accelerate the search for exception handlers." - "is this context for method that is marked?" ^method primitive = 199! Item was changed: ----- Method: Context>>isPrimFailToken: (in category 'private') ----- isPrimFailToken: anObject + ^(self objectClass: anObject) isArray - ^(self objectClass: anObject) == Array and: [anObject size = 2 + and: [(anObject at: 1) == PrimitiveFailToken]]! - and: [anObject first == PrimitiveFailToken]]! Item was changed: ----- Method: Context>>isUnwindContext (in category 'private-exceptions') ----- isUnwindContext + "Answer if the receiver is for a method that is marked as a non-local return/exception unwind protect. + BlockClosure>>#ensure: and BlockClosure>>#ifCurtailed: use this primitive to identify + themseves to the VM as unwind protect methods. The VM uses this in primitive 195 + Context>>#findNextUnwindContextUpTo:, primitiveFindNextUnwindContext, to + accelerate the search for unwind protects." - "is this context for method that is marked?" ^method primitive = 198! Item was removed: - ----- Method: Context>>tryPrimitiveFor:receiver:args: (in category 'private') ----- - tryPrimitiveFor: method receiver: receiver args: arguments - "If this method has a primitive index, then run the primitive and return its result. - Otherwise (and also if the primitive fails) return PrimitiveFailToken, - as an indication that the method should be activated and run as bytecodes." - | primIndex | - (primIndex := method primitive) = 0 ifTrue: [^{PrimitiveFailToken. nil}]. - ^ self doPrimitive: primIndex method: method receiver: receiver args: arguments! From eliot.miranda at gmail.com Wed Jan 27 00:34:41 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue, 26 Jan 2021 16:34:41 -0800 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> Message-ID: On Tue, Jan 26, 2021 at 2:45 PM Eliot Miranda wrote: > Hi Marcel, Hi All, > > On Mon, Jan 25, 2021 at 3:26 AM Marcel Taeumel > wrote: > >> > It's simply not thread-safe. >> >> Hmm... in particular, there is a side effect (i.e. layout update) in the >> window's pluggable text morph. Even if #forceUpdate is false. >> >> In #endEntry, we could check for "Processor activeProcess == Project >> current uiProcess" to then use "Project current addDeferredUIMessage..." >> automatically. >> > > That gave me a scare. At first I thought that the effectiveProcess > changes to ProcessorScheduler>>activeProcess could have made that > expression no longer thread safe. But it isn't anyway, and the above is > very bad style. Let me explain. > > The suspension points in the VM are > - the first bytecode of any non-quick method (following a primitive if it > has one) > - the first bytecode of any block > - a backward branch > > In the JIT there are fewer suspension points: > - the first bytecode of any method containing a send other than #== and/or > #class (and given that ifNil:ifNotNil: is inlined into a send of #== and > jumps, ifNil: sends don't count) > - the first bytecode of any block containing a send other than #== and/or > #class > - a backward branch > > So given > > ProcessorScheduler>>#activeProcess > "suspension point here on an interpreter VM, and the first time in > the JIT VM" > ^activeProcess effectiveProcess > > Process>>#effectiveProcess > "suspension point here on an interpreter VM, and the first time in > the JIT VM" > ^effectiveProcess ifNil: [self] > > Project class>>#current > "suspension point here on an interpreter VM, and the first time in > the JIT VM" > ^CurrentProject > > MVCProject>>#uiProcess > "suspension point here on an interpreter VM, and the first time in > the JIT VM" > ^ world activeControllerProcess > > MorphicProject>>#uiProcess > "no suspension point here on any VM obeying the blue-book spec" > ^uiProcess > > we can see that "Processor activeProcess == Project current uiProcess" is > not thread-safe in the interpreter; there is a suspension point in Project > current before CurrentProject is returned (but not in the JIT); there is > a suspension point in MVC in uiProcess. There is a suspension point in ProcessorScheduler>>#activeProcess > before the send of effectiveProcess to activeProcess, but since no data > is fetched until the process resumes this is harmless. However, were the > expression written as "Project current uiProcess == Processor > activeProcess" then this would no longer be harmless. > > So on all VMs this is not reliably thread-safe. Even on the JIT VM the > first use of any method (except a doit) is interpreted. Once the JIT VM, > once it has started up and the methods have been jitted, "Processor > activeProcess == Project current uiProcess" is thread-safe on Morphic, but > not on MVC. So we really shouldn't be using things like this. They'll > appear to work and in very rare circumstances they won't. So let's please > use the proper construct, Mutex. > > > But that makes me realize that the effectiveProcess changes are unsafe on > an interpreter VM (and hence we're on;y getting away with it on the JIT > VM). Se really need some way of saying that ProcessorScheduler>>#activeProcess > is atomic, e.g. > > Process>>#effectiveProcess > > ^effectiveProcess ifNil: [self] > > But I don't know how to implement this right now. Note that we do have > > BlockClosure>>#valueNoContextSwitch > "An exact copy of BlockClosure>>value except that this version will not > preempt > the current process on block activation if a higher-priority process is > runnable. > Primitive. Essential." > > numArgs ~= 0 ifTrue: > [self numArgsError: 0]. > self primitiveFailed > > FullBlockClosure>>#valueNoContextSwitch > "An exact copy of BlockClosure>>value except that this version will not > preempt > the current process on block activation if a higher-priority process is > runnable. > Primitive. Essential." > > numArgs ~= 0 ifTrue: > [self numArgsError: 0]. > self primitiveFailed > > but the VM uses the primitive numbers to control context switching. We > don't have a mechanism the VM can use to label a normal method such > as Process>>#effectiveProcess as not to allow an interrupt. > Doh! We have primitive numbers. We already use primitive 19 as a "simulation guard" in the debugger machinery as a "simulation guard" to avoid I'm not sure what. Any unused numeric primitive could be used as a marker to avoid context switches. I propose that we use it, hiding it behind a suitable pragma for syntactic sugar (i.e. ). 123 used to be primitiveValueUninteruptibly, which we no longer use. I propose we use this. Best, >> Marcel >> >> Am 23.01.2021 21:05:05 schrieb Levente Uzonyi : >> On Fri, 22 Jan 2021, tim Rowledge wrote: >> >> > >> > >> >> On 2021-01-22, at 5:26 PM, David T. Lewis wrote: >> >> >> >> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: >> >>> I ran the following in Squeak 5.3: >> >>> >> >>> TranscriptStream forceUpdate: false. >> >>> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 >> >>> >> >>> When the Transcript window fills up, 'Message not understood' and >> 'Assertion >> >>> failure' appear. I'm wondering is this a bug? Thanks. Jaromir >> >>> >> >>> >> >>> >> >> >> >> It certainly does appear to be a bug. >> > >> > We had some discussion about it not so long ago; you can't use the >> Transcript to log bugs from Seaside very well, for example. Background >> processes, mutexs, that sort of thing. IIRC Levente offered an explanation? >> >> It's simply not thread-safe. >> If you want it to be thread-safe, you can pass your message to the UI >> process to show it. Make sure your message is computed in its own process >> and is passed as a precomputed string to avoid other kinds of race >> conditions. E.g.: >> >> | theMessage | >> theMessage := 'Something very {1}.' format: { 'important' }. >> Project current addDeferredUIMessage: [ Transcript show: theMessage; cr ]. >> >> >> Levente >> >> > >> > >> > tim >> > -- >> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim >> > The hardness of the butter is proportional to the softness of the bread. >> >> >> > > -- > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Wed Jan 27 08:41:08 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Wed, 27 Jan 2021 09:41:08 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> Message-ID: Hi Eliot. Thanks for the clarification of VM suspension points. > So let's please use the proper construct, Mutex. Hmmm. I suppose it's not that easy. If #endEntry is running inside the ui process, we must not wait to not block the ui process (given that we want to implement #forceUpdate) -- but instead complete all deferred messages or just trigger a drawing cycle. A simple mutex wouldn't do because we want to avoid context switching altogether while executing methods that use such process comparision. Thread-safety might be an issue in several places, which kind of use "Processor activeProcess == Project current uiProcess": MorphicProject >> #spawnNewProcessIfThisIsUI: (Morphic|MVC)Debugger class >> #openOn:... Even there, a mutex would not do because we want to avoid comparing the wrong objects, not to avoid reentering that section. The entire expression "Processor activeProcess == Project current uiProcess" should be atomic. > Any unused numeric primitive could be used as a marker to avoid context switches.  I propose that we use it, hiding it behind a suitable pragma for syntactic sugar (i.e. ).  123 used to be primitiveValueUninteruptibly, which we no longer use.  I propose we use this. +1 :-) Best, Marcel Am 27.01.2021 01:35:09 schrieb Eliot Miranda : On Tue, Jan 26, 2021 at 2:45 PM Eliot Miranda wrote: Hi Marcel, Hi All, On Mon, Jan 25, 2021 at 3:26 AM Marcel Taeumel wrote: > It's simply not thread-safe. Hmm... in particular, there is a side effect (i.e. layout update) in the window's pluggable text morph. Even if #forceUpdate is false. In #endEntry, we could check for "Processor activeProcess == Project current uiProcess" to then use "Project current addDeferredUIMessage..." automatically. That gave me a scare.  At first I thought that the effectiveProcess changes to ProcessorScheduler>>activeProcess could have made that expression no longer thread safe.  But it isn't anyway, and the above is very bad style.  Let me explain. The suspension points in the VM are  - the first bytecode of any non-quick method (following a primitive if it has one) - the first bytecode of any block - a backward branch In the JIT there are fewer suspension points: - the first bytecode of any method containing a send other than #== and/or #class (and given that ifNil:ifNotNil: is inlined into a send of #== and jumps, ifNil: sends don't count) - the first bytecode of any block containing a send other than #== and/or #class - a backward branch So given ProcessorScheduler>>#activeProcess         "suspension point here on an interpreter VM, and the first time in the JIT VM" ^activeProcess effectiveProcess Process>>#effectiveProcess         "suspension point here on an interpreter VM, and the first time in the JIT VM" ^effectiveProcess ifNil: [self] Project class>>#current         "suspension point here on an interpreter VM, and the first time in the JIT VM" ^CurrentProject MVCProject>>#uiProcess         "suspension point here on an interpreter VM, and the first time in the JIT VM" ^ world activeControllerProcess MorphicProject>>#uiProcess         "no suspension point here on any VM obeying the blue-book spec" ^uiProcess we can see that "Processor activeProcess == Project current uiProcess" is not thread-safe in the interpreter; there is a suspension point in Project current before CurrentProject is returned (but not in the JIT); there is a suspension point in MVC in uiProcess.  There is a suspension point in ProcessorScheduler>>#activeProcess before the send of effectiveProcess to activeProcess, but since no data is fetched until the process resumes this is harmless.  However, were the expression written as "Project current uiProcess == Processor activeProcess" then this would no longer be harmless. So on all VMs this is not reliably thread-safe.  Even on the JIT VM the first use of any method (except a doit) is interpreted.  Once the JIT VM, once it has started up and the methods have been jitted, "Processor activeProcess == Project current uiProcess" is thread-safe on Morphic, but not on MVC.  So we really shouldn't be using things like this.  They'll appear to work and in very rare circumstances they won't.  So let's please use the proper construct, Mutex. But that makes me realize that the effectiveProcess changes are unsafe on an interpreter VM (and hence we're on;y getting away with it on the JIT VM).  Se really need some way of saying that ProcessorScheduler>>#activeProcess is atomic, e.g. Process>>#effectiveProcess         ^effectiveProcess ifNil: [self] But I don't know how to implement this right now.  Note that we do have  BlockClosure>>#valueNoContextSwitch "An exact copy of BlockClosure>>value except that this version will not preempt the current process on block activation if a higher-priority process is runnable. Primitive. Essential." numArgs ~= 0 ifTrue: [self numArgsError: 0]. self primitiveFailed FullBlockClosure>>#valueNoContextSwitch "An exact copy of BlockClosure>>value except that this version will not preempt the current process on block activation if a higher-priority process is runnable. Primitive. Essential." numArgs ~= 0 ifTrue: [self numArgsError: 0]. self primitiveFailed but the VM uses the primitive numbers to control context switching.  We don't have a mechanism the VM can use to label a normal method such as Process>>#effectiveProcess as not to allow an interrupt. Doh!  We have primitive numbers.  We already use primitive 19 as a "simulation guard" in the debugger machinery as a "simulation guard" to avoid I'm not sure what.  Any unused numeric primitive could be used as a marker to avoid context switches.  I propose that we use it, hiding it behind a suitable pragma for syntactic sugar (i.e. ).  123 used to be primitiveValueUninteruptibly, which we no longer use.  I propose we use this. Best, Marcel Am 23.01.2021 21:05:05 schrieb Levente Uzonyi : On Fri, 22 Jan 2021, tim Rowledge wrote: > > >> On 2021-01-22, at 5:26 PM, David T. Lewis wrote: >> >> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote: >>> I ran the following in Squeak 5.3: >>> >>> TranscriptStream forceUpdate: false. >>> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39 >>> >>> When the Transcript window fills up, 'Message not understood' and 'Assertion >>> failure' appear. I'm wondering is this a bug? Thanks. Jaromir >>> >>> >>> >> >> It certainly does appear to be a bug. > > We had some discussion about it not so long ago; you can't use the Transcript to log bugs from Seaside very well, for example. Background processes, mutexs, that sort of thing. IIRC Levente offered an explanation? It's simply not thread-safe. If you want it to be thread-safe, you can pass your message to the UI process to show it. Make sure your message is computed in its own process and is passed as a precomputed string to avoid other kinds of race conditions. E.g.: | theMessage | theMessage := 'Something very {1}.' format: { 'important' }. Project current addDeferredUIMessage: [ Transcript show: theMessage; cr ]. Levente > > > tim > -- > tim Rowledge; tim at rowledge.org [mailto:tim at rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] > The hardness of the butter is proportional to the softness of the bread. -- _,,,^..^,,,_ best, Eliot -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Wed Jan 27 09:31:47 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 27 Jan 2021 09:31:47 0000 Subject: [squeak-dev] The Inbox: Compiler-mt.454.mcz Message-ID: A new version of Compiler was added to project The Inbox: http://source.squeak.org/inbox/Compiler-mt.454.mcz ==================== Summary ==================== Name: Compiler-mt.454 Author: mt Time: 27 January 2021, 10:31:47.057422 am UUID: 6e01e1e3-e3b2-41a4-9749-37f1dab71fba Ancestors: Compiler-eem.453 Adds pragma, which maps to . For this, allow parser extensions to be non-keyword (i.e. unary) pragmas. Might have a tiny performance impact when parsing methods with lots of non-keyword pragmas. =============== Diff against Compiler-eem.453 =============== Item was added: + ----- Method: Parser>>noContextSwitch (in category 'pragmas - code evaluation') ----- + noContextSwitch + "By adding this pragma to a method, it will not be preempt the current process on method activation if a higher-priority process is runnable. Any numbered primitive without side effects will do here." + + + "Note that primitive 123 once was primitiveValueUninteruptibly but is no longer in use." + self addPragma: (Pragma keyword: #primitive: arguments: #(123)). + + self advance. + ^ true! Item was changed: ----- Method: Parser>>pragmaStatement (in category 'pragmas') ----- pragmaStatement "Parse a pragma statement. The leading '<' has already been consumed. The 'here' token is the first one in the pragma. Use that token to dispatch to a custom pragma-parsing method if one can be found with a selector that matches it. Note that custom pragma parsers need to fulfill two requirements: - method selector must match the current token as simple getter, e.g., matches #apicall or matches #primitive - method must have pragma to be called." "0) Early exit" (hereType = #keyword or: [ hereType = #word or: [ hereType = #binary ] ]) ifFalse: [ ^ self expected: 'pragma declaration' ]. + "1) Avoid interning new symbols for made-up pragmas such as #my for ." + (Symbol lookup: (here last == $: ifTrue: [here allButLast] ifFalse: [here])) ifNotNil: [:parserSelector | + Parser methodDict at: parserSelector ifPresent: [:parserMethod | + "2) Only call methods that claim to be a custom pragma parser via ." + (parserMethod hasPragma: #pragmaParser) + ifTrue: [^ self executeMethod: parserMethod]]]. - "1) Do not consider one-word pragmas such as and . Only keyword pragmas." - here last == $: ifTrue: [ - "2) Avoid interning new symbols for made-up pragmas such as #my for ." - (Symbol lookup: here allButLast) ifNotNil: [:parserSelector | - Parser methodDict at: parserSelector ifPresent: [:parserMethod | - "3) Only call methods that claim to be a custom pragma parser via ." - (parserMethod hasPragma: #pragmaParser) - ifTrue: [^ self executeMethod: parserMethod]]]]. "X) No custom pragma parser found. Use the default one." ^ self pragmaStatementKeywords! From marcel.taeumel at hpi.de Wed Jan 27 09:32:59 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Wed, 27 Jan 2021 10:32:59 +0100 Subject: [squeak-dev] The Inbox: Compiler-mt.454.mcz In-Reply-To: References: Message-ID: Hi Eliot, please review. :-) It connects to this discussion: http://forum.world.st/Transcript-error-when-forceUpdate-false-tp5126397p5126559.html Best, Marcel Am 27.01.2021 10:31:57 schrieb commits at source.squeak.org : A new version of Compiler was added to project The Inbox: http://source.squeak.org/inbox/Compiler-mt.454.mcz ==================== Summary ==================== Name: Compiler-mt.454 Author: mt Time: 27 January 2021, 10:31:47.057422 am UUID: 6e01e1e3-e3b2-41a4-9749-37f1dab71fba Ancestors: Compiler-eem.453 Adds pragma, which maps to . For this, allow parser extensions to be non-keyword (i.e. unary) pragmas. Might have a tiny performance impact when parsing methods with lots of non-keyword pragmas. =============== Diff against Compiler-eem.453 =============== Item was added: + ----- Method: Parser>>noContextSwitch (in category 'pragmas - code evaluation') ----- + noContextSwitch + "By adding this pragma to a method, it will not be preempt the current process on method activation if a higher-priority process is runnable. Any numbered primitive without side effects will do here." + + + "Note that primitive 123 once was primitiveValueUninteruptibly but is no longer in use." + self addPragma: (Pragma keyword: #primitive: arguments: #(123)). + + self advance. + ^ true! Item was changed: ----- Method: Parser>>pragmaStatement (in category 'pragmas') ----- pragmaStatement "Parse a pragma statement. The leading ' Note that custom pragma parsers need to fulfill two requirements: - method selector must match the current token as simple getter, e.g., matches #apicall or matches #primitive - method must have pragma to be called." "0) Early exit" (hereType = #keyword or: [ hereType = #word or: [ hereType = #binary ] ]) ifFalse: [ ^ self expected: 'pragma declaration' ]. + "1) Avoid interning new symbols for made-up pragmas such as #my for ." + (Symbol lookup: (here last == $: ifTrue: [here allButLast] ifFalse: [here])) ifNotNil: [:parserSelector | + Parser methodDict at: parserSelector ifPresent: [:parserMethod | + "2) Only call methods that claim to be a custom pragma parser via ." + (parserMethod hasPragma: #pragmaParser) + ifTrue: [^ self executeMethod: parserMethod]]]. - "1) Do not consider one-word pragmas such as and . Only keyword pragmas." - here last == $: ifTrue: [ - "2) Avoid interning new symbols for made-up pragmas such as #my for ." - (Symbol lookup: here allButLast) ifNotNil: [:parserSelector | - Parser methodDict at: parserSelector ifPresent: [:parserMethod | - "3) Only call methods that claim to be a custom pragma parser via ." - (parserMethod hasPragma: #pragmaParser) - ifTrue: [^ self executeMethod: parserMethod]]]]. "X) No custom pragma parser found. Use the default one." ^ self pragmaStatementKeywords! -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Wed Jan 27 22:05:07 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Wed, 27 Jan 2021 23:05:07 +0100 (CET) Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> Message-ID: Hi Marcel, On Tue, 26 Jan 2021, Marcel Taeumel wrote: > Hi Jaromir, > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) > > @all: Would Transcript now be thread-safe? Did I miss something? Not at all. The problem is not #endEntry but all the other methods writing to the stream e.g.: #nextPutAll:. The real solution is to replace the stream-like API with one that provides an easy way to write messages in a thread-safe way. E.g.: Transcript showStream: [ :stream | stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] Which guarantees that 'Hello World!' appears on the Transcript without being mixed with other messages. or Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. The implementations could be e.g.: showStream: aBlock | string | string := String streamContents: aBlock. self safelyNextPutAll: string show: aString format: arguments | string | string := aString format: arguments. self safelyNextPutAll: string The last challenge is to implement #safelyNextPutAll: which involves making Transcript not be a TranscriptStream. Transcript should encapsulate the stream and use a Mutex (not a global one because its pointless) to provide thread-safety while writing the characters on it or reading its contents. E.g.: safelyNextPutAll: aString mutex critical: [ stream nextPutAll: aString ] For backwards compatibility, the stream-API methods must be provided for a while but those methods should be thread-safe on their own. E.g.: nextPutAll: aString self safelyNextPutAll: aString nextPut: aCharacter self safelyNextPutAll: aCharacter asString Levente > > Best, > Marcel > > Am 25.01.2021 21:38:36 schrieb jaromir : > > Well, I tried deferring the whole Transcript endEntry machinery to the UI > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for > #forceUpdate = false only ... and it seems to avoid the problem! > > TranscriptStream >> endEntry > > deferredEntry ifNil: [ false ]. "this is a new instance variable" > self semaphore critical:[ > self class forceUpdate > ifTrue: [self changed: #appendEntry; reset] > ifFalse: [deferredEntry := true]. > > > TranscriptStream >> flushDeferredEntry > "This is run every UI cycle in doOneCycleNowFor:" > > deferredEntry ifTrue: [ > self class forceUpdate: true. > self endEntry. > deferredEntry := false. > self class forceUpdate: false. > ] > > doOneCycleNowFor: aWorld > > "... the whole body remains unchanged except:" > > capturingGesture ifFalse: > [aWorld runStepMethods. > Transcript flushDeferredEntry. "this is printing for #forceUpdate = > false" > self displayWorldSafely: aWorld]. > > > For #forceUpdate = true the endEntry mechanism remains unchanged and failing > as before... > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html > > > From marcel.taeumel at hpi.de Thu Jan 28 08:05:16 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 28 Jan 2021 09:05:16 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> Message-ID: Hi Levente. Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 Best, Marcel Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : Hi Marcel, On Tue, 26 Jan 2021, Marcel Taeumel wrote: > Hi Jaromir, > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) > > @all: Would Transcript now be thread-safe? Did I miss something? Not at all. The problem is not #endEntry but all the other methods writing to the stream e.g.: #nextPutAll:. The real solution is to replace the stream-like API with one that provides an easy way to write messages in a thread-safe way. E.g.: Transcript showStream: [ :stream | stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] Which guarantees that 'Hello World!' appears on the Transcript without being mixed with other messages. or Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. The implementations could be e.g.: showStream: aBlock | string | string := String streamContents: aBlock. self safelyNextPutAll: string show: aString format: arguments | string | string := aString format: arguments. self safelyNextPutAll: string The last challenge is to implement #safelyNextPutAll: which involves making Transcript not be a TranscriptStream. Transcript should encapsulate the stream and use a Mutex (not a global one because its pointless) to provide thread-safety while writing the characters on it or reading its contents. E.g.: safelyNextPutAll: aString mutex critical: [ stream nextPutAll: aString ] For backwards compatibility, the stream-API methods must be provided for a while but those methods should be thread-safe on their own. E.g.: nextPutAll: aString self safelyNextPutAll: aString nextPut: aCharacter self safelyNextPutAll: aCharacter asString Levente > > Best, > Marcel > > Am 25.01.2021 21:38:36 schrieb jaromir : > > Well, I tried deferring the whole Transcript endEntry machinery to the UI > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for > #forceUpdate = false only ... and it seems to avoid the problem! > > TranscriptStream >> endEntry > > deferredEntry ifNil: [ false ]. "this is a new instance variable" > self semaphore critical:[ > self class forceUpdate > ifTrue: [self changed: #appendEntry; reset] > ifFalse: [deferredEntry := true]. > > > TranscriptStream >> flushDeferredEntry > "This is run every UI cycle in doOneCycleNowFor:" > > deferredEntry ifTrue: [ > self class forceUpdate: true. > self endEntry. > deferredEntry := false. > self class forceUpdate: false. > ] > > doOneCycleNowFor: aWorld > > "... the whole body remains unchanged except:" > > capturingGesture ifFalse: > [aWorld runStepMethods. > Transcript flushDeferredEntry. "this is printing for #forceUpdate = > false" > self displayWorldSafely: aWorld]. > > > For #forceUpdate = true the endEntry mechanism remains unchanged and failing > as before... > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Thu Jan 28 09:32:06 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu, 28 Jan 2021 10:32:06 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> Message-ID: <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> Hi apart from the debuggers, why bother making Transcript thread-safe in the first place? The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. Thread safety could be addressed there without complicating Transcript more… my 2ct -tobias > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: > > Hi Levente. > > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. > > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) > > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 > > Best, > Marcel >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >> >> Hi Marcel, >> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >> >> > Hi Jaromir, >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >> > >> > @all: Would Transcript now be thread-safe? Did I miss something? >> >> Not at all. The problem is not #endEntry but all the other >> methods writing to the stream e.g.: #nextPutAll:. >> The real solution is to replace the stream-like API with one that provides >> an easy way to write messages in a thread-safe way. E.g.: >> >> Transcript showStream: [ :stream | >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >> >> Which guarantees that 'Hello World!' appears on the Transcript without >> being mixed with other messages. >> >> or >> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >> >> The implementations could be e.g.: >> >> showStream: aBlock >> >> | string | >> string := String streamContents: aBlock. >> self safelyNextPutAll: string >> >> show: aString format: arguments >> >> | string | >> string := aString format: arguments. >> self safelyNextPutAll: string >> >> The last challenge is to implement #safelyNextPutAll: which involves >> making Transcript not be a TranscriptStream. >> Transcript should encapsulate the stream and use a Mutex (not a global one >> because its pointless) to provide thread-safety while writing the >> characters on it or reading its contents. E.g.: >> >> safelyNextPutAll: aString >> >> mutex critical: [ >> stream nextPutAll: aString ] >> >> For backwards compatibility, the stream-API methods must be provided for a >> while but those methods should be thread-safe on their own. E.g.: >> >> nextPutAll: aString >> >> self safelyNextPutAll: aString >> >> nextPut: aCharacter >> >> self safelyNextPutAll: aCharacter asString >> >> >> Levente >> >> > >> > Best, >> > Marcel >> > >> > Am 25.01.2021 21:38:36 schrieb jaromir : >> > >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >> > #forceUpdate = false only ... and it seems to avoid the problem! >> > >> > TranscriptStream >> endEntry >> > >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >> > self semaphore critical:[ >> > self class forceUpdate >> > ifTrue: [self changed: #appendEntry; reset] >> > ifFalse: [deferredEntry := true]. >> > >> > >> > TranscriptStream >> flushDeferredEntry >> > "This is run every UI cycle in doOneCycleNowFor:" >> > >> > deferredEntry ifTrue: [ >> > self class forceUpdate: true. >> > self endEntry. >> > deferredEntry := false. >> > self class forceUpdate: false. >> > ] >> > >> > doOneCycleNowFor: aWorld >> > >> > "... the whole body remains unchanged except:" >> > >> > capturingGesture ifFalse: >> > [aWorld runStepMethods. >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >> > false" >> > self displayWorldSafely: aWorld]. >> > >> > >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >> > as before... >> > >> > >> > >> > -- >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >> > >> > >> > >> > From marcel.taeumel at hpi.de Thu Jan 28 09:41:03 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 28 Jan 2021 10:41:03 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> Message-ID: Hi Tobias > A separate kind of log (that optionally could output to the transcript) Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) Best, Marcel Am 28.01.2021 10:32:27 schrieb Tobias Pape : Hi apart from the debuggers, why bother making Transcript thread-safe in the first place? The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. Thread safety could be addressed there without complicating Transcript more… my 2ct -tobias > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: > > Hi Levente. > > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. > > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) > > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 > > Best, > Marcel >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >> >> Hi Marcel, >> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >> >> > Hi Jaromir, >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >> > >> > @all: Would Transcript now be thread-safe? Did I miss something? >> >> Not at all. The problem is not #endEntry but all the other >> methods writing to the stream e.g.: #nextPutAll:. >> The real solution is to replace the stream-like API with one that provides >> an easy way to write messages in a thread-safe way. E.g.: >> >> Transcript showStream: [ :stream | >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >> >> Which guarantees that 'Hello World!' appears on the Transcript without >> being mixed with other messages. >> >> or >> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >> >> The implementations could be e.g.: >> >> showStream: aBlock >> >> | string | >> string := String streamContents: aBlock. >> self safelyNextPutAll: string >> >> show: aString format: arguments >> >> | string | >> string := aString format: arguments. >> self safelyNextPutAll: string >> >> The last challenge is to implement #safelyNextPutAll: which involves >> making Transcript not be a TranscriptStream. >> Transcript should encapsulate the stream and use a Mutex (not a global one >> because its pointless) to provide thread-safety while writing the >> characters on it or reading its contents. E.g.: >> >> safelyNextPutAll: aString >> >> mutex critical: [ >> stream nextPutAll: aString ] >> >> For backwards compatibility, the stream-API methods must be provided for a >> while but those methods should be thread-safe on their own. E.g.: >> >> nextPutAll: aString >> >> self safelyNextPutAll: aString >> >> nextPut: aCharacter >> >> self safelyNextPutAll: aCharacter asString >> >> >> Levente >> >> > >> > Best, >> > Marcel >> > >> > Am 25.01.2021 21:38:36 schrieb jaromir : >> > >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >> > #forceUpdate = false only ... and it seems to avoid the problem! >> > >> > TranscriptStream >> endEntry >> > >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >> > self semaphore critical:[ >> > self class forceUpdate >> > ifTrue: [self changed: #appendEntry; reset] >> > ifFalse: [deferredEntry := true]. >> > >> > >> > TranscriptStream >> flushDeferredEntry >> > "This is run every UI cycle in doOneCycleNowFor:" >> > >> > deferredEntry ifTrue: [ >> > self class forceUpdate: true. >> > self endEntry. >> > deferredEntry := false. >> > self class forceUpdate: false. >> > ] >> > >> > doOneCycleNowFor: aWorld >> > >> > "... the whole body remains unchanged except:" >> > >> > capturingGesture ifFalse: >> > [aWorld runStepMethods. >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >> > false" >> > self displayWorldSafely: aWorld]. >> > >> > >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >> > as before... >> > >> > >> > >> > -- >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Thu Jan 28 09:58:21 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu, 28 Jan 2021 10:58:21 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> Message-ID: > On 28. Jan 2021, at 10:41, Marcel Taeumel wrote: > > Hi Tobias > > > A separate kind of log (that optionally could output to the transcript) > > Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) > That's not what I meant. Transcript is Smalltalk for stdout, I would say. Complicating it to act like a proper logger is IMHO ill-directed. Neither C printf nor Java System.out.println[1] nor (i think) Racket display are thread safe. And I think this is ok. Transcript shouldn't break when used concurrently, but I don't think it should do something sophisticated… Transcript is not a good logger. We shouldn't pretend it is. Maybe GemStone's object log is a neat abstraction. Thread-safe, object based, with time stamps. Best regards -Tobias [1]: https://stackoverflow.com/questions/32880557/is-system-out-println-thread-safe-by-default > Best, > Marcel >> Am 28.01.2021 10:32:27 schrieb Tobias Pape : >> >> Hi >> >> apart from the debuggers, why bother making Transcript thread-safe in the first place? >> >> The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. >> >> A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. >> Thread safety could be addressed there without complicating Transcript more… >> >> my 2ct >> -tobias >> >> >> > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: >> > >> > Hi Levente. >> > >> > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. >> > >> > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) >> > >> > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 >> > >> > Best, >> > Marcel >> >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >> >> >> >> Hi Marcel, >> >> >> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >> >> >> >> > Hi Jaromir, >> >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >> >> > >> >> > @all: Would Transcript now be thread-safe? Did I miss something? >> >> >> >> Not at all. The problem is not #endEntry but all the other >> >> methods writing to the stream e.g.: #nextPutAll:. >> >> The real solution is to replace the stream-like API with one that provides >> >> an easy way to write messages in a thread-safe way. E.g.: >> >> >> >> Transcript showStream: [ :stream | >> >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >> >> >> >> Which guarantees that 'Hello World!' appears on the Transcript without >> >> being mixed with other messages. >> >> >> >> or >> >> >> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >> >> >> >> The implementations could be e.g.: >> >> >> >> showStream: aBlock >> >> >> >> | string | >> >> string := String streamContents: aBlock. >> >> self safelyNextPutAll: string >> >> >> >> show: aString format: arguments >> >> >> >> | string | >> >> string := aString format: arguments. >> >> self safelyNextPutAll: string >> >> >> >> The last challenge is to implement #safelyNextPutAll: which involves >> >> making Transcript not be a TranscriptStream. >> >> Transcript should encapsulate the stream and use a Mutex (not a global one >> >> because its pointless) to provide thread-safety while writing the >> >> characters on it or reading its contents. E.g.: >> >> >> >> safelyNextPutAll: aString >> >> >> >> mutex critical: [ >> >> stream nextPutAll: aString ] >> >> >> >> For backwards compatibility, the stream-API methods must be provided for a >> >> while but those methods should be thread-safe on their own. E.g.: >> >> >> >> nextPutAll: aString >> >> >> >> self safelyNextPutAll: aString >> >> >> >> nextPut: aCharacter >> >> >> >> self safelyNextPutAll: aCharacter asString >> >> >> >> >> >> Levente >> >> >> >> > >> >> > Best, >> >> > Marcel >> >> > >> >> > Am 25.01.2021 21:38:36 schrieb jaromir : >> >> > >> >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >> >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >> >> > #forceUpdate = false only ... and it seems to avoid the problem! >> >> > >> >> > TranscriptStream >> endEntry >> >> > >> >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >> >> > self semaphore critical:[ >> >> > self class forceUpdate >> >> > ifTrue: [self changed: #appendEntry; reset] >> >> > ifFalse: [deferredEntry := true]. >> >> > >> >> > >> >> > TranscriptStream >> flushDeferredEntry >> >> > "This is run every UI cycle in doOneCycleNowFor:" >> >> > >> >> > deferredEntry ifTrue: [ >> >> > self class forceUpdate: true. >> >> > self endEntry. >> >> > deferredEntry := false. >> >> > self class forceUpdate: false. >> >> > ] >> >> > >> >> > doOneCycleNowFor: aWorld >> >> > >> >> > "... the whole body remains unchanged except:" >> >> > >> >> > capturingGesture ifFalse: >> >> > [aWorld runStepMethods. >> >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >> >> > false" >> >> > self displayWorldSafely: aWorld]. >> >> > >> >> > >> >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >> >> > as before... >> >> > >> >> > >> >> > >> >> > -- >> >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >> >> > >> >> > >> >> > >> >> >> > >> >> >> > From Christoph.Thiede at student.hpi.uni-potsdam.de Thu Jan 28 09:59:27 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Thu, 28 Jan 2021 09:59:27 +0000 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de>, Message-ID: <1ce14508a1654e369a26a946e546ae1d@student.hpi.uni-potsdam.de> Hi all, this is an interesting discussion, two thoughts from my side: 1. What is the problem with "Processor activeProcess == Project current uiProcess" not being a thread-safe expression? I see that it could be possible at many points that the VM interrupts the current process and resumes another one first; but still, activeProcess will always hold the same Process instance when the same process is active, independently of any interruptions, won't it? What is that dangerous thing that could happen during a suspension point in the VM? What am I missing here? :-) 2. To Levente's proposal of making Transcript calls thread-safe: > safelyNextPutAll: aString > > mutex critical: [ > stream nextPutAll: aString ] So this would delay the execution of any process that uses the Transcript, wouldn't it? Hm ... I would rather have expected the Transcript calls to be deferred when the Transcript is locked ATM - *unless* #forceUpdate is enabled, maybe. Let's keep everyday Transcript clients blocking-free whenever possible. Or imagine several processes writing to the Transcript, but the transcript not being opened at this time. There should no need to block any of the calling processes? Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 28. Januar 2021 10:41:03 An: squeak-dev Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?) Hi Tobias > A separate kind of log (that optionally could output to the transcript) Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) Best, Marcel Am 28.01.2021 10:32:27 schrieb Tobias Pape : Hi apart from the debuggers, why bother making Transcript thread-safe in the first place? The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. Thread safety could be addressed there without complicating Transcript more… my 2ct -tobias > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: > > Hi Levente. > > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. > > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) > > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 > > Best, > Marcel >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >> >> Hi Marcel, >> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >> >> > Hi Jaromir, >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >> > >> > @all: Would Transcript now be thread-safe? Did I miss something? >> >> Not at all. The problem is not #endEntry but all the other >> methods writing to the stream e.g.: #nextPutAll:. >> The real solution is to replace the stream-like API with one that provides >> an easy way to write messages in a thread-safe way. E.g.: >> >> Transcript showStream: [ :stream | >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >> >> Which guarantees that 'Hello World!' appears on the Transcript without >> being mixed with other messages. >> >> or >> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >> >> The implementations could be e.g.: >> >> showStream: aBlock >> >> | string | >> string := String streamContents: aBlock. >> self safelyNextPutAll: string >> >> show: aString format: arguments >> >> | string | >> string := aString format: arguments. >> self safelyNextPutAll: string >> >> The last challenge is to implement #safelyNextPutAll: which involves >> making Transcript not be a TranscriptStream. >> Transcript should encapsulate the stream and use a Mutex (not a global one >> because its pointless) to provide thread-safety while writing the >> characters on it or reading its contents. E.g.: >> >> safelyNextPutAll: aString >> >> mutex critical: [ >> stream nextPutAll: aString ] >> >> For backwards compatibility, the stream-API methods must be provided for a >> while but those methods should be thread-safe on their own. E.g.: >> >> nextPutAll: aString >> >> self safelyNextPutAll: aString >> >> nextPut: aCharacter >> >> self safelyNextPutAll: aCharacter asString >> >> >> Levente >> >> > >> > Best, >> > Marcel >> > >> > Am 25.01.2021 21:38:36 schrieb jaromir : >> > >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >> > #forceUpdate = false only ... and it seems to avoid the problem! >> > >> > TranscriptStream >> endEntry >> > >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >> > self semaphore critical:[ >> > self class forceUpdate >> > ifTrue: [self changed: #appendEntry; reset] >> > ifFalse: [deferredEntry := true]. >> > >> > >> > TranscriptStream >> flushDeferredEntry >> > "This is run every UI cycle in doOneCycleNowFor:" >> > >> > deferredEntry ifTrue: [ >> > self class forceUpdate: true. >> > self endEntry. >> > deferredEntry := false. >> > self class forceUpdate: false. >> > ] >> > >> > doOneCycleNowFor: aWorld >> > >> > "... the whole body remains unchanged except:" >> > >> > capturingGesture ifFalse: >> > [aWorld runStepMethods. >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >> > false" >> > self displayWorldSafely: aWorld]. >> > >> > >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >> > as before... >> > >> > >> > >> > -- >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Thu Jan 28 10:13:55 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 28 Jan 2021 11:13:55 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: <1ce14508a1654e369a26a946e546ae1d@student.hpi.uni-potsdam.de> References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> <,> <1ce14508a1654e369a26a946e546ae1d@student.hpi.uni-potsdam.de> Message-ID: Hi Christoph. >  What is that dangerous thing that could happen during a suspension point in the VM? What am I missing here? :-) It's only part of the problem. There could be a disconnect between the former "Project current uiProcess" comparison and how "addDeferredUIMessage" is processed later in the code. It would be better to no preempt this call as a whole. Best, Marcel Am 28.01.2021 10:59:50 schrieb Thiede, Christoph : Hi all, this is an interesting discussion, two thoughts from my side: 1. What is the problem with "Processor activeProcess == Project current uiProcess" not being a thread-safe expression? I see that it could be possible at many points that the VM interrupts the current process and resumes another one first; but still, activeProcess will always hold the same Process instance when the same process is active, independently of any interruptions, won't it? What is that dangerous thing that could happen during a suspension point in the VM? What am I missing here? :-) 2. To Levente's proposal of making Transcript calls thread-safe: > safelyNextPutAll: aString >  >          mutex critical: [ >                  stream nextPutAll: aString ] So this would delay the execution of any process that uses the Transcript, wouldn't it? Hm ... I would rather have expected the Transcript calls to be deferred when the Transcript is locked ATM - *unless* #forceUpdate is enabled, maybe. Let's keep everyday Transcript clients blocking-free whenever possible. Or imagine several processes writing to the Transcript, but the transcript not being opened at this time. There should no need to block any of the calling processes? Best, Christoph Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 28. Januar 2021 10:41:03 An: squeak-dev Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?)   Hi Tobias > A separate kind of log (that optionally could output to the transcript) Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) Best, Marcel Am 28.01.2021 10:32:27 schrieb Tobias Pape : Hi apart from the debuggers, why bother making Transcript thread-safe in the first place? The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. Thread safety could be addressed there without complicating Transcript more… my 2ct -tobias > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: > > Hi Levente. > > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. > > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) > > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 > > Best, > Marcel >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >> >> Hi Marcel, >> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >> >> > Hi Jaromir, >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >> > >> > @all: Would Transcript now be thread-safe? Did I miss something? >> >> Not at all. The problem is not #endEntry but all the other >> methods writing to the stream e.g.: #nextPutAll:. >> The real solution is to replace the stream-like API with one that provides >> an easy way to write messages in a thread-safe way. E.g.: >> >> Transcript showStream: [ :stream | >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >> >> Which guarantees that 'Hello World!' appears on the Transcript without >> being mixed with other messages. >> >> or >> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >> >> The implementations could be e.g.: >> >> showStream: aBlock >> >> | string | >> string := String streamContents: aBlock. >> self safelyNextPutAll: string >> >> show: aString format: arguments >> >> | string | >> string := aString format: arguments. >> self safelyNextPutAll: string >> >> The last challenge is to implement #safelyNextPutAll: which involves >> making Transcript not be a TranscriptStream. >> Transcript should encapsulate the stream and use a Mutex (not a global one >> because its pointless) to provide thread-safety while writing the >> characters on it or reading its contents. E.g.: >> >> safelyNextPutAll: aString >> >> mutex critical: [ >> stream nextPutAll: aString ] >> >> For backwards compatibility, the stream-API methods must be provided for a >> while but those methods should be thread-safe on their own. E.g.: >> >> nextPutAll: aString >> >> self safelyNextPutAll: aString >> >> nextPut: aCharacter >> >> self safelyNextPutAll: aCharacter asString >> >> >> Levente >> >> > >> > Best, >> > Marcel >> > >> > Am 25.01.2021 21:38:36 schrieb jaromir : >> > >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >> > #forceUpdate = false only ... and it seems to avoid the problem! >> > >> > TranscriptStream >> endEntry >> > >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >> > self semaphore critical:[ >> > self class forceUpdate >> > ifTrue: [self changed: #appendEntry; reset] >> > ifFalse: [deferredEntry := true]. >> > >> > >> > TranscriptStream >> flushDeferredEntry >> > "This is run every UI cycle in doOneCycleNowFor:" >> > >> > deferredEntry ifTrue: [ >> > self class forceUpdate: true. >> > self endEntry. >> > deferredEntry := false. >> > self class forceUpdate: false. >> > ] >> > >> > doOneCycleNowFor: aWorld >> > >> > "... the whole body remains unchanged except:" >> > >> > capturingGesture ifFalse: >> > [aWorld runStepMethods. >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >> > false" >> > self displayWorldSafely: aWorld]. >> > >> > >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >> > as before... >> > >> > >> > >> > -- >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Thu Jan 28 10:28:12 2021 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Thu, 28 Jan 2021 10:28:12 +0000 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> <,> <1ce14508a1654e369a26a946e546ae1d@student.hpi.uni-potsdam.de>, Message-ID: <9129c3b2dc13472e9875e00290276f76@student.hpi.uni-potsdam.de> I still don't see the point. Are you saying that the current project or it's UI process could change during a VM suspension point? Then, what about something like "Project current evaluateUIMessage: [...]", which will unpreemptedly (using the new primitive solution) check the UI process and either evaluate the message directly or defer it? :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 28. Januar 2021 11:13:55 An: squeak-dev Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?) Hi Christoph. > What is that dangerous thing that could happen during a suspension point in the VM? What am I missing here? :-) It's only part of the problem. There could be a disconnect between the former "Project current uiProcess" comparison and how "addDeferredUIMessage" is processed later in the code. It would be better to no preempt this call as a whole. Best, Marcel Am 28.01.2021 10:59:50 schrieb Thiede, Christoph : Hi all, this is an interesting discussion, two thoughts from my side: 1. What is the problem with "Processor activeProcess == Project current uiProcess" not being a thread-safe expression? I see that it could be possible at many points that the VM interrupts the current process and resumes another one first; but still, activeProcess will always hold the same Process instance when the same process is active, independently of any interruptions, won't it? What is that dangerous thing that could happen during a suspension point in the VM? What am I missing here? :-) 2. To Levente's proposal of making Transcript calls thread-safe: > safelyNextPutAll: aString > > mutex critical: [ > stream nextPutAll: aString ] So this would delay the execution of any process that uses the Transcript, wouldn't it? Hm ... I would rather have expected the Transcript calls to be deferred when the Transcript is locked ATM - *unless* #forceUpdate is enabled, maybe. Let's keep everyday Transcript clients blocking-free whenever possible. Or imagine several processes writing to the Transcript, but the transcript not being opened at this time. There should no need to block any of the calling processes? Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 28. Januar 2021 10:41:03 An: squeak-dev Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?) Hi Tobias > A separate kind of log (that optionally could output to the transcript) Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) Best, Marcel Am 28.01.2021 10:32:27 schrieb Tobias Pape : Hi apart from the debuggers, why bother making Transcript thread-safe in the first place? The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. Thread safety could be addressed there without complicating Transcript more… my 2ct -tobias > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: > > Hi Levente. > > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. > > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) > > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 > > Best, > Marcel >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >> >> Hi Marcel, >> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >> >> > Hi Jaromir, >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >> > >> > @all: Would Transcript now be thread-safe? Did I miss something? >> >> Not at all. The problem is not #endEntry but all the other >> methods writing to the stream e.g.: #nextPutAll:. >> The real solution is to replace the stream-like API with one that provides >> an easy way to write messages in a thread-safe way. E.g.: >> >> Transcript showStream: [ :stream | >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >> >> Which guarantees that 'Hello World!' appears on the Transcript without >> being mixed with other messages. >> >> or >> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >> >> The implementations could be e.g.: >> >> showStream: aBlock >> >> | string | >> string := String streamContents: aBlock. >> self safelyNextPutAll: string >> >> show: aString format: arguments >> >> | string | >> string := aString format: arguments. >> self safelyNextPutAll: string >> >> The last challenge is to implement #safelyNextPutAll: which involves >> making Transcript not be a TranscriptStream. >> Transcript should encapsulate the stream and use a Mutex (not a global one >> because its pointless) to provide thread-safety while writing the >> characters on it or reading its contents. E.g.: >> >> safelyNextPutAll: aString >> >> mutex critical: [ >> stream nextPutAll: aString ] >> >> For backwards compatibility, the stream-API methods must be provided for a >> while but those methods should be thread-safe on their own. E.g.: >> >> nextPutAll: aString >> >> self safelyNextPutAll: aString >> >> nextPut: aCharacter >> >> self safelyNextPutAll: aCharacter asString >> >> >> Levente >> >> > >> > Best, >> > Marcel >> > >> > Am 25.01.2021 21:38:36 schrieb jaromir : >> > >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >> > #forceUpdate = false only ... and it seems to avoid the problem! >> > >> > TranscriptStream >> endEntry >> > >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >> > self semaphore critical:[ >> > self class forceUpdate >> > ifTrue: [self changed: #appendEntry; reset] >> > ifFalse: [deferredEntry := true]. >> > >> > >> > TranscriptStream >> flushDeferredEntry >> > "This is run every UI cycle in doOneCycleNowFor:" >> > >> > deferredEntry ifTrue: [ >> > self class forceUpdate: true. >> > self endEntry. >> > deferredEntry := false. >> > self class forceUpdate: false. >> > ] >> > >> > doOneCycleNowFor: aWorld >> > >> > "... the whole body remains unchanged except:" >> > >> > capturingGesture ifFalse: >> > [aWorld runStepMethods. >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >> > false" >> > self displayWorldSafely: aWorld]. >> > >> > >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >> > as before... >> > >> > >> > >> > -- >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Thu Jan 28 11:14:11 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 28 Jan 2021 12:14:11 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: <9129c3b2dc13472e9875e00290276f76@student.hpi.uni-potsdam.de> References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> <,> <1ce14508a1654e369a26a946e546ae1d@student.hpi.uni-potsdam.de> <,> <9129c3b2dc13472e9875e00290276f76@student.hpi.uni-potsdam.de> Message-ID: > I still don't see the point. Are you saying that the current project or it's UI process could change during a VM suspension point? If that code runs at 39 and the user switches projects at 40, yes, this can happen. > Then, what about something like "Project current evaluateUIMessage: [...]", which will unpreemptedly (using the new primitive solution) check the UI process and either evaluate the message directly or defer it? :-) Even the implementation of #evaluateUIMessage: would need something like :-) So, one could directly add this pragma to, for example, #endEntry, without adding such a new indirection. And at lower levels or more concise scopes, access should be controlled with a mutex. I suppose that the "trick" with only works in a green-threading model where exactly 1 thread (or Squeak process) is actually running at a time. Best, Marcel P.S.: Is every fallback code for failing primitives evaluated without preemption?  Am 28.01.2021 11:28:24 schrieb Thiede, Christoph : I still don't see the point. Are you saying that the current project or it's UI process could change during a VM suspension point? Then, what about something like "Project current evaluateUIMessage: [...]", which will unpreemptedly (using the new primitive solution) check the UI process and either evaluate the message directly or defer it? :-) Best, Christoph [http://www.hpi.de/] Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 28. Januar 2021 11:13:55 An: squeak-dev Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?)   Hi Christoph. >  What is that dangerous thing that could happen during a suspension point in the VM? What am I missing here? :-) It's only part of the problem. There could be a disconnect between the former "Project current uiProcess" comparison and how "addDeferredUIMessage" is processed later in the code. It would be better to no preempt this call as a whole. Best, Marcel Am 28.01.2021 10:59:50 schrieb Thiede, Christoph : Hi all, this is an interesting discussion, two thoughts from my side: 1. What is the problem with "Processor activeProcess == Project current uiProcess" not being a thread-safe expression? I see that it could be possible at many points that the VM interrupts the current process and resumes another one first; but still, activeProcess will always hold the same Process instance when the same process is active, independently of any interruptions, won't it? What is that dangerous thing that could happen during a suspension point in the VM? What am I missing here? :-) 2. To Levente's proposal of making Transcript calls thread-safe: > safelyNextPutAll: aString >  >          mutex critical: [ >                  stream nextPutAll: aString ] So this would delay the execution of any process that uses the Transcript, wouldn't it? Hm ... I would rather have expected the Transcript calls to be deferred when the Transcript is locked ATM - *unless* #forceUpdate is enabled, maybe. Let's keep everyday Transcript clients blocking-free whenever possible. Or imagine several processes writing to the Transcript, but the transcript not being opened at this time. There should no need to block any of the calling processes? Best, Christoph Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 28. Januar 2021 10:41:03 An: squeak-dev Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?)   Hi Tobias > A separate kind of log (that optionally could output to the transcript) Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) Best, Marcel Am 28.01.2021 10:32:27 schrieb Tobias Pape : Hi apart from the debuggers, why bother making Transcript thread-safe in the first place? The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. Thread safety could be addressed there without complicating Transcript more… my 2ct -tobias > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: > > Hi Levente. > > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. > > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) > > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 > > Best, > Marcel >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >> >> Hi Marcel, >> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >> >> > Hi Jaromir, >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >> > >> > @all: Would Transcript now be thread-safe? Did I miss something? >> >> Not at all. The problem is not #endEntry but all the other >> methods writing to the stream e.g.: #nextPutAll:. >> The real solution is to replace the stream-like API with one that provides >> an easy way to write messages in a thread-safe way. E.g.: >> >> Transcript showStream: [ :stream | >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >> >> Which guarantees that 'Hello World!' appears on the Transcript without >> being mixed with other messages. >> >> or >> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >> >> The implementations could be e.g.: >> >> showStream: aBlock >> >> | string | >> string := String streamContents: aBlock. >> self safelyNextPutAll: string >> >> show: aString format: arguments >> >> | string | >> string := aString format: arguments. >> self safelyNextPutAll: string >> >> The last challenge is to implement #safelyNextPutAll: which involves >> making Transcript not be a TranscriptStream. >> Transcript should encapsulate the stream and use a Mutex (not a global one >> because its pointless) to provide thread-safety while writing the >> characters on it or reading its contents. E.g.: >> >> safelyNextPutAll: aString >> >> mutex critical: [ >> stream nextPutAll: aString ] >> >> For backwards compatibility, the stream-API methods must be provided for a >> while but those methods should be thread-safe on their own. E.g.: >> >> nextPutAll: aString >> >> self safelyNextPutAll: aString >> >> nextPut: aCharacter >> >> self safelyNextPutAll: aCharacter asString >> >> >> Levente >> >> > >> > Best, >> > Marcel >> > >> > Am 25.01.2021 21:38:36 schrieb jaromir : >> > >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >> > #forceUpdate = false only ... and it seems to avoid the problem! >> > >> > TranscriptStream >> endEntry >> > >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >> > self semaphore critical:[ >> > self class forceUpdate >> > ifTrue: [self changed: #appendEntry; reset] >> > ifFalse: [deferredEntry := true]. >> > >> > >> > TranscriptStream >> flushDeferredEntry >> > "This is run every UI cycle in doOneCycleNowFor:" >> > >> > deferredEntry ifTrue: [ >> > self class forceUpdate: true. >> > self endEntry. >> > deferredEntry := false. >> > self class forceUpdate: false. >> > ] >> > >> > doOneCycleNowFor: aWorld >> > >> > "... the whole body remains unchanged except:" >> > >> > capturingGesture ifFalse: >> > [aWorld runStepMethods. >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >> > false" >> > self displayWorldSafely: aWorld]. >> > >> > >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >> > as before... >> > >> > >> > >> > -- >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Thu Jan 28 11:36:57 2021 From: gettimothy at zoho.com (gettimothy) Date: Thu, 28 Jan 2021 06:36:57 -0500 Subject: [squeak-dev] UnicodeHack <- [\x0020-\xE007F] Message-ID: <17748c83b66.b61bc2233721.184428826919768082@zoho.com> Hi Folks, Is it true that the character range in that PEG rule maps to Character codePoint:16rE0020 through Character codePoint:16rE007F   thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Thu Jan 28 11:42:56 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 28 Jan 2021 12:42:56 +0100 Subject: [squeak-dev] CfP | Programming Experience Workshop PX/21 Message-ID: ===== PX/21 Call for Papers ===== Welcome to the 7th Edition of the Programming Experience Workshop   https://2021.programming-conference.org/home/px-2021 [https://2021.programming-conference.org/home/px-2021] Co-located with 2021   https://2021.programming-conference.org/ [https://2021.programming-conference.org/] ## Abstract Some programming feels fun, other programming feels annoying. Why? For a while now the study of programming has forced improvements to be described through the Fordist lens of usability and productivity, where the thing that matters is how much software can get built, how quickly. But along the way, something has gone missing. What makes programmers feel the way they do when they’re programming? It’s not usually fun to spend an age doing something that could have been done easily, so efficiency and usability still matter, but they’re not the end of the story. Some environments, activities, contexts, languages, infrastructures make programming feel alive, others feel like working in a bureaucracy. This is not purely technologically determined, writing Lisp to do your taxes probably still isn’t fun, but it’s also not technologically neutral, writing XML to produce performance art is still likely to be . Whilst we can probably mostly agree about what isn’t fun, what is remains more personal and without a space within the academy to describe it. In its past editions, PX set its focus on questions like: Do programmers create text that is transformed into running behavior (the old way), or do they operate on behavior directly (“liveness”); are they exploring the live domain to understand the true nature of the requirements; are they like authors creating new worlds; does visualization matter; is the experience immediate, immersive, vivid and continuous; do fluency, literacy, and learning matter; do they build tools, meta-tools; are they creating languages to express new concepts quickly and easily; and curiously, is joy relevant to the experience? In this 7th edition of PX, we will expand its focus to also cover the experience that programmers have. What makes it and what breaks it? For whom? What can we build to share the joy of programming with others? Here is a list of topic areas to get you thinking:  - creating programs  - experience of programming  - exploratory programming  - liveness  - non-standard tools  - visual, auditory, tactile, and other non-textual languages  - text and more than text  - program understanding  - domain-specific languages  - psychology of programming  - error tolerance  - user studies Correctness, performance, standard tools, foundations, and text-as-program are important traditional research areas, but the experience of programming and how to improve and evolve it are the focus of this workshop. We also welcome a wide spectrum of contributions on programming experience. ## Submissions Submissions are solicited for Programming Experience 2021 (PX/21). The thrust of the workshop is to explore the human experience of programming—what it feels like to program, or what it should feel like. The technical topics include exploratory programming, live programming, authoring, representation of active content, visualization, navigation, modularity mechanisms, immediacy, literacy, fluency, learning, tool building, and language engineering. Submissions by academics, professional programmers, and non-professional programmer are welcome. Submissions can be in any form and format, including but not limited to papers, presentations, demos, videos, panels, debates, essays, writers’ workshops, and art. Presentation slots are expected to be between 20 minutes and one hour (if time allows), depending on quality, form, and relevance to the workshop. Submissions of academic papers directed toward publication should be so marked, and the program committee will engage in peer review for all such papers. All artifacts are to be submitted via EasyChair [2]. Papers and essays must be written in English, provided as PDF documents, and follow the new ACM Conference ‘acmart’ Format with the ‘sigconf’ option [3] using the Times New Roman font family with 10 point font size. If you are formatting your paper using LaTeX, you will need to set the ‘10pt’ option in the ‘\documentclass’ command. If you are formatting your paper using Word, you may wish to use the provided Word template that supports this font size. Please include page numbers in your submission for review using the LaTeX command ‘\settopmatter{printfolios=true}’ (see examples in template). Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. There is no page limit on submitted papers and essays. It is, however, the responsibility of the authors to keep the reviewers interested and motivated to read the paper. Reviewers are under no obligation to read all or even a substantial portion of a paper or essay if they do not find the initial part of it interesting. ## Publication Authors of accepted contributions will be invited to present their work at the workshop. *Papers accepted for publication* will appear in the ACM Digital Library (ACM DL) as part of the ‹Programming› 2021 Conference Companion. ## Upcoming Deadlines (AoE UTC-12h) Submissions:   Sun 14 Feb 2021 Notifications:   Sun 28 Feb 2021 Pre-workshop versions:   Sun 14 Mar 2021 Workshop:   Mon 22 Mar 2021 Final versions:   Fri 9 Apr 2021 ## More Information [1] https://2021.programming-conference.org/home/px-2021 [https://2021.programming-conference.org/home/px-2021] [2] https://easychair.org/conferences/?conf=px21 [https://easychair.org/conferences/?conf=px21] [3] http://www.acm.org/publications/proceedings-template [http://www.acm.org/publications/proceedings-template] -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Thu Jan 28 12:25:12 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Thu, 28 Jan 2021 13:25:12 +0100 (CET) Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> <, > <1ce14508a1654e369a26a946e546ae1d@student.hpi.uni-potsdam.de> Message-ID: Hi Christoph, On Thu, 28 Jan 2021, Marcel Taeumel wrote: > Hi Christoph. > >  What is that dangerous thing that could happen during a suspension point in the VM? What am I missing here? :-) > > It's only part of the problem. There could be a disconnect between the former "Project current uiProcess" comparison and how "addDeferredUIMessage" is processed later in the code. It would be better to no preempt this call as > a whole. > > Best, > Marcel > > Am 28.01.2021 10:59:50 schrieb Thiede, Christoph : > > Hi all, > > > this is an interesting discussion, two thoughts from my side: > > > 1. What is the problem with "Processor activeProcess == Project current uiProcess" not being a thread-safe expression? I see that it could be possible at many points that the VM interrupts the current process and > resumes another one first; but still, activeProcess will always hold the same Process instance when the same process is active, independently of any interruptions, won't it? What is that dangerous thing that could > happen during a suspension point in the VM? What am I missing here? :-) > > > 2. To Levente's proposal of making Transcript calls thread-safe: > > > > safelyNextPutAll: aString > > >  > >          mutex critical: [ > >                  stream nextPutAll: aString ] > > So this would delay the execution of any process that uses the Transcript, wouldn't it? Hm ... I would rather have expected the Transcript calls to be deferred when the Transcript is locked ATM - *unless* #forceUpdate If you mean that the calling process has to wait until the mutex is available and then until the string is written to the stream, then yes, it is delayed. But that's no different from current behavior other than having to synchronize with the other processes writing to/reading from the stream which does not happen now and results in race conditions. What do you mean by "Transcript calls to be deferred"? If you think that holding the mutex would make the characters appear on the Transcript's target, then no, they would just get written to the internal buffer. When the message would be displayed is up to the UI. > is enabled, maybe. Let's keep everyday Transcript clients blocking-free whenever possible. Or imagine several processes writing to the Transcript, but the transcript not being opened at this time. There should no need > to block any of the calling processes? What would be the reason to push the burden of Transcript synchronization (which is actually impossible) onto the users? Levente > > Best, > Christoph > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: Squeak-dev im Auftrag von Taeumel, Marcel > Gesendet: Donnerstag, 28. Januar 2021 10:41:03 > An: squeak-dev > Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?)   > Hi Tobias > > A separate kind of log (that optionally could output to the transcript) > > Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) > > Best, > Marcel > > Am 28.01.2021 10:32:27 schrieb Tobias Pape : > > Hi > > apart from the debuggers, why bother making Transcript thread-safe in the first place? > > The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. > > A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. > Thread safety could be addressed there without complicating Transcript more… > > my 2ct > -tobias > > > > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: > > > > Hi Levente. > > > > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the > order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. > > > > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a > Transcript window is open.) > > > > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 > > > > Best, > > Marcel > >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : > >> > >> Hi Marcel, > >> > >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: > >> > >> > Hi Jaromir, > >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) > >> > > >> > @all: Would Transcript now be thread-safe? Did I miss something? > >> > >> Not at all. The problem is not #endEntry but all the other > >> methods writing to the stream e.g.: #nextPutAll:. > >> The real solution is to replace the stream-like API with one that provides > >> an easy way to write messages in a thread-safe way. E.g.: > >> > >> Transcript showStream: [ :stream | > >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] > >> > >> Which guarantees that 'Hello World!' appears on the Transcript without > >> being mixed with other messages. > >> > >> or > >> > >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. > >> > >> The implementations could be e.g.: > >> > >> showStream: aBlock > >> > >> | string | > >> string := String streamContents: aBlock. > >> self safelyNextPutAll: string > >> > >> show: aString format: arguments > >> > >> | string | > >> string := aString format: arguments. > >> self safelyNextPutAll: string > >> > >> The last challenge is to implement #safelyNextPutAll: which involves > >> making Transcript not be a TranscriptStream. > >> Transcript should encapsulate the stream and use a Mutex (not a global one > >> because its pointless) to provide thread-safety while writing the > >> characters on it or reading its contents. E.g.: > >> > >> safelyNextPutAll: aString > >> > >> mutex critical: [ > >> stream nextPutAll: aString ] > >> > >> For backwards compatibility, the stream-API methods must be provided for a > >> while but those methods should be thread-safe on their own. E.g.: > >> > >> nextPutAll: aString > >> > >> self safelyNextPutAll: aString > >> > >> nextPut: aCharacter > >> > >> self safelyNextPutAll: aCharacter asString > >> > >> > >> Levente > >> > >> > > >> > Best, > >> > Marcel > >> > > >> > Am 25.01.2021 21:38:36 schrieb jaromir : > >> > > >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI > >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for > >> > #forceUpdate = false only ... and it seems to avoid the problem! > >> > > >> > TranscriptStream >> endEntry > >> > > >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" > >> > self semaphore critical:[ > >> > self class forceUpdate > >> > ifTrue: [self changed: #appendEntry; reset] > >> > ifFalse: [deferredEntry := true]. > >> > > >> > > >> > TranscriptStream >> flushDeferredEntry > >> > "This is run every UI cycle in doOneCycleNowFor:" > >> > > >> > deferredEntry ifTrue: [ > >> > self class forceUpdate: true. > >> > self endEntry. > >> > deferredEntry := false. > >> > self class forceUpdate: false. > >> > ] > >> > > >> > doOneCycleNowFor: aWorld > >> > > >> > "... the whole body remains unchanged except:" > >> > > >> > capturingGesture ifFalse: > >> > [aWorld runStepMethods. > >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = > >> > false" > >> > self displayWorldSafely: aWorld]. > >> > > >> > > >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing > >> > as before... > >> > > >> > > >> > > >> > -- > >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html > >> > > >> > > >> > > >> > > > > > > > From leves at caesar.elte.hu Thu Jan 28 12:31:15 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Thu, 28 Jan 2021 13:31:15 +0100 (CET) Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> Message-ID: Hi Tobias, On Thu, 28 Jan 2021, Tobias Pape wrote: > > >> On 28. Jan 2021, at 10:41, Marcel Taeumel wrote: >> >> Hi Tobias >> >> > A separate kind of log (that optionally could output to the transcript) >> >> Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) >> > > That's not what I meant. > > Transcript is Smalltalk for stdout, I would say. > Complicating it to act like a proper logger is IMHO ill-directed. > > Neither C printf nor Java System.out.println[1] nor (i think) Racket display are thread safe. Great examples. Let's not do what they do. We can easily provide a thread-safe Transcript, so why not do so? > > And I think this is ok. > > Transcript shouldn't break when used concurrently, but I don't think it should do something sophisticated… It does break now. > > Transcript is not a good logger. We shouldn't pretend it is. > > Maybe GemStone's object log is a neat abstraction. Thread-safe, object based, with time stamps. Perhaps because Transcript is not a logger. It's just a place you can write things to which will appear somewhere the user can see it. It can do that trhing right or wrong. I think we all agree it does not do it right now. Levente > > > > Best regards > -Tobias > > [1]: https://stackoverflow.com/questions/32880557/is-system-out-println-thread-safe-by-default >> Best, >> Marcel >>> Am 28.01.2021 10:32:27 schrieb Tobias Pape : >>> >>> Hi >>> >>> apart from the debuggers, why bother making Transcript thread-safe in the first place? >>> >>> The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. >>> >>> A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. >>> Thread safety could be addressed there without complicating Transcript more… >>> >>> my 2ct >>> -tobias >>> >>> >>> > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: >>> > >>> > Hi Levente. >>> > >>> > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. >>> > >>> > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) >>> > >>> > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 >>> > >>> > Best, >>> > Marcel >>> >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >>> >> >>> >> Hi Marcel, >>> >> >>> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >>> >> >>> >> > Hi Jaromir, >>> >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >>> >> > >>> >> > @all: Would Transcript now be thread-safe? Did I miss something? >>> >> >>> >> Not at all. The problem is not #endEntry but all the other >>> >> methods writing to the stream e.g.: #nextPutAll:. >>> >> The real solution is to replace the stream-like API with one that provides >>> >> an easy way to write messages in a thread-safe way. E.g.: >>> >> >>> >> Transcript showStream: [ :stream | >>> >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >>> >> >>> >> Which guarantees that 'Hello World!' appears on the Transcript without >>> >> being mixed with other messages. >>> >> >>> >> or >>> >> >>> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >>> >> >>> >> The implementations could be e.g.: >>> >> >>> >> showStream: aBlock >>> >> >>> >> | string | >>> >> string := String streamContents: aBlock. >>> >> self safelyNextPutAll: string >>> >> >>> >> show: aString format: arguments >>> >> >>> >> | string | >>> >> string := aString format: arguments. >>> >> self safelyNextPutAll: string >>> >> >>> >> The last challenge is to implement #safelyNextPutAll: which involves >>> >> making Transcript not be a TranscriptStream. >>> >> Transcript should encapsulate the stream and use a Mutex (not a global one >>> >> because its pointless) to provide thread-safety while writing the >>> >> characters on it or reading its contents. E.g.: >>> >> >>> >> safelyNextPutAll: aString >>> >> >>> >> mutex critical: [ >>> >> stream nextPutAll: aString ] >>> >> >>> >> For backwards compatibility, the stream-API methods must be provided for a >>> >> while but those methods should be thread-safe on their own. E.g.: >>> >> >>> >> nextPutAll: aString >>> >> >>> >> self safelyNextPutAll: aString >>> >> >>> >> nextPut: aCharacter >>> >> >>> >> self safelyNextPutAll: aCharacter asString >>> >> >>> >> >>> >> Levente >>> >> >>> >> > >>> >> > Best, >>> >> > Marcel >>> >> > >>> >> > Am 25.01.2021 21:38:36 schrieb jaromir : >>> >> > >>> >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >>> >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >>> >> > #forceUpdate = false only ... and it seems to avoid the problem! >>> >> > >>> >> > TranscriptStream >> endEntry >>> >> > >>> >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >>> >> > self semaphore critical:[ >>> >> > self class forceUpdate >>> >> > ifTrue: [self changed: #appendEntry; reset] >>> >> > ifFalse: [deferredEntry := true]. >>> >> > >>> >> > >>> >> > TranscriptStream >> flushDeferredEntry >>> >> > "This is run every UI cycle in doOneCycleNowFor:" >>> >> > >>> >> > deferredEntry ifTrue: [ >>> >> > self class forceUpdate: true. >>> >> > self endEntry. >>> >> > deferredEntry := false. >>> >> > self class forceUpdate: false. >>> >> > ] >>> >> > >>> >> > doOneCycleNowFor: aWorld >>> >> > >>> >> > "... the whole body remains unchanged except:" >>> >> > >>> >> > capturingGesture ifFalse: >>> >> > [aWorld runStepMethods. >>> >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >>> >> > false" >>> >> > self displayWorldSafely: aWorld]. >>> >> > >>> >> > >>> >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >>> >> > as before... >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >>> >> > >>> >> > >>> >> > >>> >> >>> > >>> >>> >>> >> From leves at caesar.elte.hu Thu Jan 28 12:39:08 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Thu, 28 Jan 2021 13:39:08 +0100 (CET) Subject: [squeak-dev] UnicodeHack <- [\x0020-\xE007F] In-Reply-To: <17748c83b66.b61bc2233721.184428826919768082@zoho.com> References: <17748c83b66.b61bc2233721.184428826919768082@zoho.com> Message-ID: Hi Tim, If you mean that \x0020-\xE007F in the Xtreams PEG parser's language is equal to the Smalltalk character range 16rE0020 asCharacter to: 16rE007F asCharacter then the answer is no, because there is an extra E in the Smalltalk code's range start. \x0020-\xE007F is the same range as 16r0020 asCharacter to: 16rE007F asCharacter. Levente On Thu, 28 Jan 2021, gettimothy via Squeak-dev wrote: > Hi Folks, > > Is it true that the character range in that PEG rule maps to > > Character codePoint:16rE0020 through Character codePoint:16rE007F   thanks in advance. > > > > > From Das.Linux at gmx.de Thu Jan 28 12:45:50 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu, 28 Jan 2021 13:45:50 +0100 Subject: [squeak-dev] Transcript error when forceUpdate: false (?) In-Reply-To: References: <1611345790068-0.post@n4.nabble.com> <20210123012610.GB93733@shell.msen.com> <8C121027-CFF5-4DF2-9D2E-18DA658DD743@rowledge.org> <1611599406320-0.post@n4.nabble.com> <1611607106337-0.post@n4.nabble.com> <9D4C563E-7F9D-454F-B5F3-CA7887DF7619@gmx.de> Message-ID: <8CC3679A-3BB2-4417-99F7-0A2B0FA7E734@gmx.de> Hi > On 28. Jan 2021, at 13:31, Levente Uzonyi wrote: > > Hi Tobias, > > On Thu, 28 Jan 2021, Tobias Pape wrote: > >> >> >>> On 28. Jan 2021, at 10:41, Marcel Taeumel wrote: >>> Hi Tobias >>> > A separate kind of log (that optionally could output to the transcript) >>> Transcript can use stdout already. Not sure we want to shift the problem to the user again ... :-/ "Every time you provide an option, you expect users to make a decision." :-) >> >> That's not what I meant. >> >> Transcript is Smalltalk for stdout, I would say. >> Complicating it to act like a proper logger is IMHO ill-directed. >> >> Neither C printf nor Java System.out.println[1] nor (i think) Racket display are thread safe. > > Great examples. Let's not do what they do. We can easily provide a thread-safe Transcript, so why not do so? > >> >> And I think this is ok. >> >> Transcript shouldn't break when used concurrently, but I don't think it should do something sophisticated… > > It does break now. Yeah i see. > >> >> Transcript is not a good logger. We shouldn't pretend it is. >> >> Maybe GemStone's object log is a neat abstraction. Thread-safe, object based, with time stamps. > > Perhaps because Transcript is not a logger. It's just a place you can write things to which will appear somewhere the user can see it. > It can do that trhing right or wrong. I think we all agree it does not do it right now. agreed. But I'd rather see Transcript dumbed down, not clevered up. -t > > > Levente > >> >> >> >> Best regards >> -Tobias >> >> [1]: https://stackoverflow.com/questions/32880557/is-system-out-println-thread-safe-by-default >>> Best, >>> Marcel >>>> Am 28.01.2021 10:32:27 schrieb Tobias Pape : >>>> Hi >>>> apart from the debuggers, why bother making Transcript thread-safe in the first place? >>>> The Transcript is a mere output stream for debugging/logging etc., our stdout or stderr. >>>> A separate kind of log (that optionally could output to the transcript) would be more apt IMHO. >>>> Thread safety could be addressed there without complicating Transcript more… >>>> my 2ct >>>> -tobias >>>> > On 28. Jan 2021, at 09:05, Marcel Taeumel wrote: >>>> > > Hi Levente. >>>> > > Thanks für clarification. We are talking about more than one problem here. :-) I did just address the issue with errors/debuggers happening due to UI process disruptions. You are also concerned about the order of contents in the Transcript's contents. Both are very important and required for claiming that it would be thread-safe. >>>> > > (Which reminds me that I find it very strange that the UI components (e.g. PluggableTextMorph) do also check the Transcript's internal characterLimit. I would expect an append-only behavior when a Transcript window is open.) >>>> > > Anyway, your proposal about a safelyNextPut(All): looks good. :-) +1 >>>> > > Best, >>>> > Marcel >>>> >> Am 27.01.2021 23:05:21 schrieb Levente Uzonyi : >>>> >> >> Hi Marcel, >>>> >> >> On Tue, 26 Jan 2021, Marcel Taeumel wrote: >>>> >> >> > Hi Jaromir, >>>> >> > please take a look at Collections-mt.923 (inbox). Maybe those changes would satisfy all your current needs in this regard. :-) >>>> >> > >> > @all: Would Transcript now be thread-safe? Did I miss something? >>>> >> >> Not at all. The problem is not #endEntry but all the other >> methods writing to the stream e.g.: #nextPutAll:. >>>> >> The real solution is to replace the stream-like API with one that provides >> an easy way to write messages in a thread-safe way. E.g.: >>>> >> >> Transcript showStream: [ :stream | >>>> >> stream nextPutAll: 'Hello'; space; nextPutAll: ' World!'; cr ] >>>> >> >> Which guarantees that 'Hello World!' appears on the Transcript without >> being mixed with other messages. >>>> >> >> or >>>> >> >> Transcript show: 'Hello {1}!{2}' format: { 'World'. String cr }. >>>> >> >> The implementations could be e.g.: >>>> >> >> showStream: aBlock >>>> >> >> | string | >>>> >> string := String streamContents: aBlock. >>>> >> self safelyNextPutAll: string >>>> >> >> show: aString format: arguments >>>> >> >> | string | >>>> >> string := aString format: arguments. >>>> >> self safelyNextPutAll: string >>>> >> >> The last challenge is to implement #safelyNextPutAll: which involves >> making Transcript not be a TranscriptStream. >>>> >> Transcript should encapsulate the stream and use a Mutex (not a global one >> because its pointless) to provide thread-safety while writing the >> characters on it or reading its contents. E.g.: >>>> >> >> safelyNextPutAll: aString >>>> >> >> mutex critical: [ >>>> >> stream nextPutAll: aString ] >>>> >> >> For backwards compatibility, the stream-API methods must be provided for a >> while but those methods should be thread-safe on their own. E.g.: >>>> >> >> nextPutAll: aString >>>> >> >> self safelyNextPutAll: aString >>>> >> >> nextPut: aCharacter >>>> >> >> self safelyNextPutAll: aCharacter asString >>>> >> >> >> Levente >>>> >> >> > >> > Best, >>>> >> > Marcel >>>> >> > >>>> >> > Am 25.01.2021 21:38:36 schrieb jaromir : >>>> >> > >>>> >> > Well, I tried deferring the whole Transcript endEntry machinery to the UI >>>> >> > doOneCycle (bypassing the changed: #appendEntryLater mechanism) for >>>> >> > #forceUpdate = false only ... and it seems to avoid the problem! >>>> >> > >>>> >> > TranscriptStream >> endEntry >>>> >> > >>>> >> > deferredEntry ifNil: [ false ]. "this is a new instance variable" >>>> >> > self semaphore critical:[ >>>> >> > self class forceUpdate >>>> >> > ifTrue: [self changed: #appendEntry; reset] >>>> >> > ifFalse: [deferredEntry := true]. >>>> >> > >> > >>>> >> > TranscriptStream >> flushDeferredEntry >>>> >> > "This is run every UI cycle in doOneCycleNowFor:" >>>> >> > >>>> >> > deferredEntry ifTrue: [ >>>> >> > self class forceUpdate: true. >>>> >> > self endEntry. >>>> >> > deferredEntry := false. >>>> >> > self class forceUpdate: false. >>>> >> > ] >>>> >> > >>>> >> > doOneCycleNowFor: aWorld >>>> >> > >>>> >> > "... the whole body remains unchanged except:" >>>> >> > >>>> >> > capturingGesture ifFalse: >>>> >> > [aWorld runStepMethods. >>>> >> > Transcript flushDeferredEntry. "this is printing for #forceUpdate = >>>> >> > false" >>>> >> > self displayWorldSafely: aWorld]. >>>> >> > >> > >>>> >> > For #forceUpdate = true the endEntry mechanism remains unchanged and failing >>>> >> > as before... >>>> >> > >> > >> > >>>> >> > -- >>>> >> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html >>>> >> > >> > >> > >>>> >> > > From leves at caesar.elte.hu Thu Jan 28 12:46:01 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Thu, 28 Jan 2021 13:46:01 +0100 (CET) Subject: [squeak-dev] The Trunk: Kernel-eem.1366.mcz In-Reply-To: References: Message-ID: Hi Eliot, On Wed, 27 Jan 2021, commits at source.squeak.org wrote: > Eliot Miranda uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-eem.1366.mcz > > ==================== Summary ==================== > > Name: Kernel-eem.1366 > Author: eem > Time: 26 January 2021, 4:27:57.204259 pm > UUID: 3a706d32-c2d6-416f-82c1-bbf735650385 > Ancestors: Kernel-eem.1365 > > Slightly faster implementation of Context>>#isPrimFailToken:. > Improve the comments in Context>>#isHandlerContext/#isUnwindContext. > Nuke an obsolete method. > > =============== Diff against Kernel-eem.1365 =============== > > Item was changed: > ----- Method: Context>>isHandlerContext (in category 'private-exceptions') ----- > isHandlerContext > + "Answer if the receiver is for a method that is marked as an exception handler. > + BlockClosure>>#on:do: uses this primitive to identify itself to the VM > + as an exception handler method, which the VM uses in primitive 197 > + Context>>#findNextHandlerContextStarting, primitiveFindHandlerContext, > + to accelerate the search for exception handlers." > - "is this context for method that is marked?" > ^method primitive = 199! > > Item was changed: > ----- Method: Context>>isPrimFailToken: (in category 'private') ----- > isPrimFailToken: anObject > + ^(self objectClass: anObject) isArray > - ^(self objectClass: anObject) == Array I think you meant to write ^(anObject isArray I also wonder why you used #objectClass: there instead of #class in the previous version. Perhaps there was a good reason. Levente > and: [anObject size = 2 > + and: [(anObject at: 1) == PrimitiveFailToken]]! > - and: [anObject first == PrimitiveFailToken]]! > > Item was changed: > ----- Method: Context>>isUnwindContext (in category 'private-exceptions') ----- > isUnwindContext > + "Answer if the receiver is for a method that is marked as a non-local return/exception unwind protect. > + BlockClosure>>#ensure: and BlockClosure>>#ifCurtailed: use this primitive to identify > + themseves to the VM as unwind protect methods. The VM uses this in primitive 195 > + Context>>#findNextUnwindContextUpTo:, primitiveFindNextUnwindContext, to > + accelerate the search for unwind protects." > - "is this context for method that is marked?" > ^method primitive = 198! > > Item was removed: > - ----- Method: Context>>tryPrimitiveFor:receiver:args: (in category 'private') ----- > - tryPrimitiveFor: method receiver: receiver args: arguments > - "If this method has a primitive index, then run the primitive and return its result. > - Otherwise (and also if the primitive fails) return PrimitiveFailToken, > - as an indication that the method should be activated and run as bytecodes." > - | primIndex | > - (primIndex := method primitive) = 0 ifTrue: [^{PrimitiveFailToken. nil}]. > - ^ self doPrimitive: primIndex method: method receiver: receiver args: arguments! From marcel.taeumel at hpi.de Thu Jan 28 12:51:25 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 28 Jan 2021 13:51:25 +0100 Subject: [squeak-dev] The Trunk: Kernel-eem.1366.mcz In-Reply-To: References: Message-ID: Hi Levente. > I also wonder why you used #objectClass: there instead of #class in the previous version. Perhaps there was a good reason. Maybe because of ProtoObject (and proxies)? I think the long-term plan was to not treat #class as a special send anymore so that proxies can override that interface. Best, Marcel Am 28.01.2021 13:46:12 schrieb Levente Uzonyi : Hi Eliot, On Wed, 27 Jan 2021, commits at source.squeak.org wrote: > Eliot Miranda uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-eem.1366.mcz > > ==================== Summary ==================== > > Name: Kernel-eem.1366 > Author: eem > Time: 26 January 2021, 4:27:57.204259 pm > UUID: 3a706d32-c2d6-416f-82c1-bbf735650385 > Ancestors: Kernel-eem.1365 > > Slightly faster implementation of Context>>#isPrimFailToken:. > Improve the comments in Context>>#isHandlerContext/#isUnwindContext. > Nuke an obsolete method. > > =============== Diff against Kernel-eem.1365 =============== > > Item was changed: > ----- Method: Context>>isHandlerContext (in category 'private-exceptions') ----- > isHandlerContext > + "Answer if the receiver is for a method that is marked as an exception handler. > + BlockClosure>>#on:do: uses this primitive to identify itself to the VM > + as an exception handler method, which the VM uses in primitive 197 > + Context>>#findNextHandlerContextStarting, primitiveFindHandlerContext, > + to accelerate the search for exception handlers." > - "is this context for method that is marked?" > ^method primitive = 199! > > Item was changed: > ----- Method: Context>>isPrimFailToken: (in category 'private') ----- > isPrimFailToken: anObject > + ^(self objectClass: anObject) isArray > - ^(self objectClass: anObject) == Array I think you meant to write ^(anObject isArray I also wonder why you used #objectClass: there instead of #class in the previous version. Perhaps there was a good reason. Levente > and: [anObject size = 2 > + and: [(anObject at: 1) == PrimitiveFailToken]]! > - and: [anObject first == PrimitiveFailToken]]! > > Item was changed: > ----- Method: Context>>isUnwindContext (in category 'private-exceptions') ----- > isUnwindContext > + "Answer if the receiver is for a method that is marked as a non-local return/exception unwind protect. > + BlockClosure>>#ensure: and BlockClosure>>#ifCurtailed: use this primitive to identify > + themseves to the VM as unwind protect methods. The VM uses this in primitive 195 > + Context>>#findNextUnwindContextUpTo:, primitiveFindNextUnwindContext, to > + accelerate the search for unwind protects." > - "is this context for method that is marked?" > ^method primitive = 198! > > Item was removed: > - ----- Method: Context>>tryPrimitiveFor:receiver:args: (in category 'private') ----- > - tryPrimitiveFor: method receiver: receiver args: arguments > - "If this method has a primitive index, then run the primitive and return its result. > - Otherwise (and also if the primitive fails) return PrimitiveFailToken, > - as an indication that the method should be activated and run as bytecodes." > - | primIndex | > - (primIndex := method primitive) = 0 ifTrue: [^{PrimitiveFailToken. nil}]. > - ^ self doPrimitive: primIndex method: method receiver: receiver args: arguments! -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Thu Jan 28 14:56:07 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Thu, 28 Jan 2021 15:56:07 +0100 (CET) Subject: [squeak-dev] The Trunk: Kernel-eem.1366.mcz In-Reply-To: References: Message-ID: Hi Marcel, On Thu, 28 Jan 2021, Marcel Taeumel wrote: > Hi Levente. > > I also wonder why you used #objectClass: there instead of #class in the > previous version. Perhaps there was a good reason. > Maybe because of ProtoObject (and proxies)? I think the long-term plan was to not treat #class as a special send anymore so that proxies can override that interface. In that case there are two problems with the rewrite. Btw, Eliot didn't mention it in the other thread, but #class is currently a way to avoid suspension points, just like #==, #ifNil:ifNotNil:, #caseOf:otherwise:, ifTrue:ifFalse:, etc. Levente > > Best, > Marcel > > Am 28.01.2021 13:46:12 schrieb Levente Uzonyi : > > Hi Eliot, > > On Wed, 27 Jan 2021, commits at source.squeak.org wrote: > > > Eliot Miranda uploaded a new version of Kernel to project The Trunk: > > http://source.squeak.org/trunk/Kernel-eem.1366.mcz > > > > ==================== Summary ==================== > > > > Name: Kernel-eem.1366 > > Author: eem > > Time: 26 January 2021, 4:27:57.204259 pm > > UUID: 3a706d32-c2d6-416f-82c1-bbf735650385 > > Ancestors: Kernel-eem.1365 > > > > Slightly faster implementation of Context>>#isPrimFailToken:. > > Improve the comments in Context>>#isHandlerContext/#isUnwindContext. > > Nuke an obsolete method. > > > > =============== Diff against Kernel-eem.1365 =============== > > > > Item was changed: > > ----- Method: Context>>isHandlerContext (in category 'private-exceptions') ----- > > isHandlerContext > > + "Answer if the receiver is for a method that is marked as an exception handler. > > + BlockClosure>>#on:do: uses this primitive to identify itself to the VM > > + as an exception handler method, which the VM uses in primitive 197 > > + Context>>#findNextHandlerContextStarting, primitiveFindHandlerContext, > > + to accelerate the search for exception handlers." > > - "is this context for method that is marked?" > > ^method primitive = 199! > > > > Item was changed: > > ----- Method: Context>>isPrimFailToken: (in category 'private') ----- > > isPrimFailToken: anObject > > + ^(self objectClass: anObject) isArray > > - ^(self objectClass: anObject) == Array > > I think you meant to write > > ^(anObject isArray > > I also wonder why you used #objectClass: there instead of #class in the > previous version. Perhaps there was a good reason. > > > Levente > > > and: [anObject size = 2 > > + and: [(anObject at: 1) == PrimitiveFailToken]]! > > - and: [anObject first == PrimitiveFailToken]]! > > > > Item was changed: > > ----- Method: Context>>isUnwindContext (in category 'private-exceptions') ----- > > isUnwindContext > > + "Answer if the receiver is for a method that is marked as a non-local return/exception unwind protect. > > + BlockClosure>>#ensure: and BlockClosure>>#ifCurtailed: use this primitive to identify > > + themseves to the VM as unwind protect methods. The VM uses this in primitive 195 > > + Context>>#findNextUnwindContextUpTo:, primitiveFindNextUnwindContext, to > > + accelerate the search for unwind protects." > > - "is this context for method that is marked?" > > ^method primitive = 198! > > > > Item was removed: > > - ----- Method: Context>>tryPrimitiveFor:receiver:args: (in category 'private') ----- > > - tryPrimitiveFor: method receiver: receiver args: arguments > > - "If this method has a primitive index, then run the primitive and return its result. > > - Otherwise (and also if the primitive fails) return PrimitiveFailToken, > > - as an indication that the method should be activated and run as bytecodes." > > - | primIndex | > > - (primIndex := method primitive) = 0 ifTrue: [^{PrimitiveFailToken. nil}]. > > - ^ self doPrimitive: primIndex method: method receiver: receiver args: arguments! > > > From gettimothy at zoho.com Thu Jan 28 20:03:38 2021 From: gettimothy at zoho.com (gettimothy) Date: Thu, 28 Jan 2021 15:03:38 -0500 Subject: [squeak-dev] Given an interval of numbers from 1 to 100 how to split them into 10 collections(?) of 1 to 10. Message-ID: <1774a981c98.11dcab5a811641.4362547871920805621@zoho.com> Hi Folks, For a development tool and Unicode grok exercise, I am recreating the functionality of:  https://jrgraphix.net/r/Unicode/ For the Latin unicode characters, I would like to create a table 10 things wide in a table row. There has got to be an elegant way rather than the kludge I am imagining... Here is my current code that has one TD for each row. render000020to00007F: html       html table             with:[                   html tableHead with: [html strong: ' Basic Latin'].                   html tableBody with:[                   (16r000020 asCharacter to: 16r00007F asCharacter)                         do:[:each|                                     html tableRow with:[                                           html tableHeading: (each asInteger).                                           html tableData: each]]]] If I could "chunk" that  (16r000020 asCharacter to: 16r00007F asCharacter) or the Interval (16r000020 to: 16r00007F) into subsets of 10, it would be  easy to code this. thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Thu Jan 28 21:17:15 2021 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Thu, 28 Jan 2021 22:17:15 +0100 (CET) Subject: [squeak-dev] Given an interval of numbers from 1 to 100 how to split them into 10 collections(?) of 1 to 10. In-Reply-To: <1774a981c98.11dcab5a811641.4362547871920805621@zoho.com> References: <1774a981c98.11dcab5a811641.4362547871920805621@zoho.com> Message-ID: Hi Tim, On Thu, 28 Jan 2021, gettimothy via Squeak-dev wrote: > Hi Folks, > > > For a development tool and Unicode grok exercise, I am recreating the functionality of:  https://jrgraphix.net/r/Unicode/ > > > For the Latin unicode characters, I would like to create a table 10 things wide in a table row. > > There has got to be an elegant way rather than the kludge I am imagining... > > Here is my current code that has one TD for each row. > render000020to00007F: html >       html table >             with:[ >                   html tableHead with: [html strong: ' Basic Latin']. >                   html tableBody with:[ >                   (16r000020 asCharacter to: 16r00007F asCharacter) >                         do:[:each| >                                     html tableRow with:[ >                                           html tableHeading: (each asInteger). >                                           html tableData: each]]]] If the size of the collection would be a multiple of 10, you could use #groupsOf:atATimeDo:, but it's not, so I'd try something like this: | start end step | start := 16r000020. end := 16r00007F. step := 10. start to: end by: step do: [ :groupStart | | group | group := groupStart to: (groupStart + step - 1 min: end). html tableRow: [ group do: [ :each | html tableHead: each ] ]; tableRow: [ group do: [ :each | html tableData: each asCharacter ] ] ] Levente > > > If I could "chunk" that  (16r000020 asCharacter to: 16r00007F asCharacter) or the Interval (16r000020 to: 16r00007F) into subsets of 10, it would be  easy to code this. > > > > thanks in advance. > > > From gettimothy at zoho.com Thu Jan 28 23:13:22 2021 From: gettimothy at zoho.com (gettimothy) Date: Thu, 28 Jan 2021 18:13:22 -0500 Subject: [squeak-dev] Given an interval of numbers from 1 to 100 how to split them into 10 collections(?) of 1 to 10. In-Reply-To: References: <1774a981c98.11dcab5a811641.4362547871920805621@zoho.com> Message-ID: <1774b45d041.e30362c947262.4085658285817163760@zoho.com> Levente Thank you! I will tussle with that tomorrow. As an aside, fior he purposes of seaside I learned that xml only supports a subset of available Unicode. https://en.m.wikipedia.org/wiki/Valid_characters_in_XML This may simplify my PEG filters. The larger and intriguing issue of getting every  printable unicode character to display in squeak  is now on my want to do list! . A fun experiment will be seeing if out putting "delete the e" to the Transcript followed by the delete character (127?) results in "delete the "  (: cheers! t ---- On Thu, 28 Jan 2021 16:17:15 -0500 leves at caesar.elte.hu wrote ---- Hi Tim, On Thu, 28 Jan 2021, gettimothy via Squeak-dev wrote: > Hi Folks, > > > For a development tool and Unicode grok exercise, I am recreating the functionality of:  https://jrgraphix.net/r/Unicode/ > > > For the Latin unicode characters, I would like to create a table 10 things wide in a table row. > > There has got to be an elegant way rather than the kludge I am imagining... > > Here is my current code that has one TD for each row. > render000020to00007F: html >       html table >             with:[ >                   html tableHead with: [html strong: ' Basic Latin']. >                   html tableBody with:[ >                   (16r000020 asCharacter to: 16r00007F asCharacter) >                         do:[:each| >                                     html tableRow with:[ >                                           html tableHeading: (each asInteger). >                                           html tableData: each]]]] If the size of the collection would be a multiple of 10, you could use #groupsOf:atATimeDo:, but it's not, so I'd try something like this: | start end step | start := 16r000020. end := 16r00007F. step := 10. start to: end by: step do: [ :groupStart |     | group |     group := groupStart to: (groupStart + step - 1 min: end).     html         tableRow: [             group do: [ :each |                 html tableHead: each ] ];         tableRow: [             group do: [ :each |                 html tableData: each asCharacter ] ] ] Levente > > > If I could "chunk" that  (16r000020 asCharacter to: 16r00007F asCharacter) or the Interval (16r000020 to: 16r00007F) into subsets of 10, it would be  easy to code this. > > > > thanks in advance. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Fri Jan 29 02:15:46 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 29 Jan 2021 02:15:46 0000 Subject: [squeak-dev] The Trunk: Collections-dtl.923.mcz Message-ID: David T. Lewis uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-dtl.923.mcz ==================== Summary ==================== Name: Collections-dtl.923 Author: dtl Time: 28 January 2021, 8:05:25.25265 pm UUID: 94598e44-a095-4a19-a2f5-f5630fe1dae8 Ancestors: Collections-ul.922 For reloadable Etoys per instructions at http://wiki.squeak.org/squeak/2848 section 2.1 Reclassify Inteval>>start and stop (Etoys, Collections) =============== Diff against Collections-ul.922 =============== Item was added: + ----- Method: Interval>>start (in category 'accessing') ----- + start + ^ start! Item was added: + ----- Method: Interval>>stop (in category 'accessing') ----- + stop + ^ stop! From commits at source.squeak.org Fri Jan 29 02:16:36 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 29 Jan 2021 02:16:36 0000 Subject: [squeak-dev] The Trunk: EToys-dtl.418.mcz Message-ID: David T. Lewis uploaded a new version of EToys to project The Trunk: http://source.squeak.org/trunk/EToys-dtl.418.mcz ==================== Summary ==================== Name: EToys-dtl.418 Author: dtl Time: 28 January 2021, 6:31:01.641276 pm UUID: 27efb6c6-38aa-46df-904e-858fb4155f2b Ancestors: EToys-eem.417 For reloadable Etoys per instructions at http://wiki.squeak.org/squeak/2848 section 2.1 Reclassify isVirtualScreen (EToys, Graphics) Reclassify curvePrototype, trianglePrototype (Etoys, MorphicExtras) Reclassify Inteval>>start and stop (Etoys, Collections) =============== Diff against EToys-eem.417 =============== Item was removed: - ----- Method: Form>>isVirtualScreen (in category '*Etoys-OLPC-Display') ----- - isVirtualScreen - "Am I a virtual display screen?" - ^false! Item was removed: - ----- Method: Interval>>start (in category '*Etoys-Squeakland-accessing') ----- - start - ^ start! Item was removed: - ----- Method: Interval>>stop (in category '*Etoys-Squeakland-accessing') ----- - stop - ^ stop! Item was removed: - ----- Method: PolygonMorph class>>curvePrototype (in category '*Etoys-Squeakland-instance creation') ----- - curvePrototype - "Answer an instance of the receiver that will serve as a prototypical curve" - - | aa | - aa := self new. - aa vertices: (Array with: 0 at 80 with: 70 at 90 with: 60 at 0) - color: Color orange lighter - borderWidth: 4 - borderColor: Color black. - aa beSmoothCurve. - aa setNameTo: 'Curve'. - aa makeForwardArrow. "is already open" - aa computeBounds. - ^ aa - - " - PolygonMorph curvePrototype openInHand - "! Item was removed: - ----- Method: PolygonMorph class>>trianglePrototype (in category '*Etoys-Squeakland-instance creation') ----- - trianglePrototype - "Answer an instance of the receiver that will serve as a prototypical triangle" - - | aa | - aa := self new. - aa vertices: {0.0 at 0.0. 138.0 at 0.0. -37.0@ -74.0} - color: (TranslucentColor r: 0.387 g: 1.0 b: 0.548 alpha: 0.463) - borderWidth: 3 - borderColor: Color black. - aa setProperty: #noNewVertices toValue: true. - aa setNameTo: 'Triangle'. - aa makeForwardArrow. "is already open" - aa computeBounds. - aa addHandles. - ^ aa - - " - PolygonMorph trianglePrototype openInHand - "! From commits at source.squeak.org Fri Jan 29 02:17:13 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 29 Jan 2021 02:17:13 0000 Subject: [squeak-dev] The Trunk: Graphics-dtl.445.mcz Message-ID: David T. Lewis uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-dtl.445.mcz ==================== Summary ==================== Name: Graphics-dtl.445 Author: dtl Time: 28 January 2021, 8:09:03.217107 pm UUID: 177084b2-8451-4cb2-9f19-c3382b927242 Ancestors: Graphics-nice.444 For reloadable Etoys per instructions at http://wiki.squeak.org/squeak/2848 section 2.1 Reclassify isVirtualScreen (EToys, Graphics) =============== Diff against Graphics-nice.444 =============== Item was added: + ----- Method: Form>>isVirtualScreen (in category 'testing') ----- + isVirtualScreen + "Am I a virtual display screen?" + ^false! From commits at source.squeak.org Fri Jan 29 02:17:37 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 29 Jan 2021 02:17:37 0000 Subject: [squeak-dev] The Trunk: MorphicExtras-dtl.283.mcz Message-ID: David T. Lewis uploaded a new version of MorphicExtras to project The Trunk: http://source.squeak.org/trunk/MorphicExtras-dtl.283.mcz ==================== Summary ==================== Name: MorphicExtras-dtl.283 Author: dtl Time: 28 January 2021, 8:12:14.767195 pm UUID: 66550323-c456-4887-8a55-25d69ad05053 Ancestors: MorphicExtras-mt.282 For reloadable Etoys per instructions at http://wiki.squeak.org/squeak/2848 section 2.1 Reclassify curvePrototype, trianglePrototype (Etoys, MorphicExtras) =============== Diff against MorphicExtras-mt.282 =============== Item was added: + ----- Method: PolygonMorph class>>curvePrototype (in category '*MorphicExtras-instance creation') ----- + curvePrototype + "Answer an instance of the receiver that will serve as a prototypical curve" + + | aa | + aa := self new. + aa vertices: (Array with: 0 at 80 with: 70 at 90 with: 60 at 0) + color: Color orange lighter + borderWidth: 4 + borderColor: Color black. + aa beSmoothCurve. + aa setNameTo: 'Curve'. + aa makeForwardArrow. "is already open" + aa computeBounds. + ^ aa + + " + PolygonMorph curvePrototype openInHand + "! Item was added: + ----- Method: PolygonMorph class>>trianglePrototype (in category '*MorphicExtras-instance creation') ----- + trianglePrototype + "Answer an instance of the receiver that will serve as a prototypical triangle" + + | aa | + aa := self new. + aa vertices: {0.0 at 0.0. 138.0 at 0.0. -37.0@ -74.0} + color: (TranslucentColor r: 0.387 g: 1.0 b: 0.548 alpha: 0.463) + borderWidth: 3 + borderColor: Color black. + aa setProperty: #noNewVertices toValue: true. + aa setNameTo: 'Triangle'. + aa makeForwardArrow. "is already open" + aa computeBounds. + aa addHandles. + ^ aa + + " + PolygonMorph trianglePrototype openInHand + "! From lewis at mail.msen.com Fri Jan 29 02:39:56 2021 From: lewis at mail.msen.com (David T. Lewis) Date: Thu, 28 Jan 2021 21:39:56 -0500 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> <20210123011630.GA93733@shell.msen.com> Message-ID: <20210129023956.GA40172@shell.msen.com> On Tue, Jan 26, 2021 at 02:17:24PM -0800, Eliot Miranda wrote: > On Mon, Jan 25, 2021 at 2:36 AM H. Hirzel wrote: > > > > To all: the necessary fixes are all quite simple. However the steps > > need to be checked also with the current trunk image. The fixes would > > also be useful to be added to Squeak 5.3 > > > Let's do this work. I just moved a couple of copyright methods from EToys > to System in System-eem.1212. What is preventing people from committing > changes to get us to the goal of an unloadable EToys? > I followed the instructions at http://wiki.squeak.org/squeak/2848 and completed the steps in paragraph 2.1. Dave From marcel.taeumel at hpi.de Fri Jan 29 09:24:23 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Fri, 29 Jan 2021 10:24:23 +0100 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: <20210129023956.GA40172@shell.msen.com> References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> <20210123011630.GA93733@shell.msen.com> <20210129023956.GA40172@shell.msen.com> Message-ID: Hi all! Note that having the Etoys package as part of Trunk helps us very much to untangle Etoys-specific stuff not labeled "Etoys" at category or class level. In particular, it makes the "senders" and "implementors" tools more useful. Some examples: Morph >> #player in "Morphic-Kernel" / "accessing" BookMorph >> #goto: in "MorphicExtras-Books" / "navigation" HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer" Morph >> #isTileMorph in "Morphic-Kernel" / "classification" HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles" So, it's good that the system keeps running after trying to unload the Etoys package. Let's not do this in Trunk (for now). :-) Best, Marcel P.S.: Etoys is basically working in Squeak 5.3 and Trunk. Yes, there are many bugs or regressions because only very few people are "using" it these days. Am 29.01.2021 03:40:05 schrieb David T. Lewis : On Tue, Jan 26, 2021 at 02:17:24PM -0800, Eliot Miranda wrote: > On Mon, Jan 25, 2021 at 2:36 AM H. Hirzel wrote: > > > > To all: the necessary fixes are all quite simple. However the steps > > need to be checked also with the current trunk image. The fixes would > > also be useful to be added to Squeak 5.3 > > > Let's do this work. I just moved a couple of copyright methods from EToys > to System in System-eem.1212. What is preventing people from committing > changes to get us to the goal of an unloadable EToys? > I followed the instructions at http://wiki.squeak.org/squeak/2848 and completed the steps in paragraph 2.1. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From kksubbu.ml at gmail.com Fri Jan 29 12:22:38 2021 From: kksubbu.ml at gmail.com (K K Subbu) Date: Fri, 29 Jan 2021 17:52:38 +0530 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> <20210123011630.GA93733@shell.msen.com> <20210129023956.GA40172@shell.msen.com> Message-ID: <5fd2a9ac-23ba-048d-d3b5-55aab2448f61@gmail.com> On 29/01/21 2:54 pm, Marcel Taeumel wrote: > > Morph >> #player in "Morphic-Kernel" / "accessing" > BookMorph >> #goto: in "MorphicExtras-Books" / "navigation" > HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer" > Morph >> #isTileMorph in "Morphic-Kernel" / "classification" > HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles" IIRC, Etoys was an experiment in visual programming for children too young to program via text but made fairly (hindsight!) intrusive changes to Morphic. Etoys was organically bound into Squeak; like conjoint twins. But that was then and this is now. Instead of shooting for a reloadable Etoys, what if the next Squeak release makes a clean break from Etoys? I propose that we slim down Squeak by removing all Etoys-related code by without trying to ensure that existing Etoys package successfully loads back into the image. This will slim down Squeak significantly and ease its maintenance. The largest user base for Etoys was on XO laptop. Those users are unlikely to upgrade to new Squeak. Also, porting Etoys package to load into slimmer Squeak may be an easier and better way to continue research than striving to maintain both in the released image. Regards .. Subbu From marcel.taeumel at hpi.de Fri Jan 29 12:31:03 2021 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Fri, 29 Jan 2021 13:31:03 +0100 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: <5fd2a9ac-23ba-048d-d3b5-55aab2448f61@gmail.com> References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> <20210123011630.GA93733@shell.msen.com> <20210129023956.GA40172@shell.msen.com> <5fd2a9ac-23ba-048d-d3b5-55aab2448f61@gmail.com> Message-ID: Hi Subbu. > But that was then and this is now. Instead of shooting for a reloadable > Etoys, what if the next Squeak release makes a clean break from Etoys? That's not what I was going for. Etoys includes hints for userful extension points in the base system. Instead of just deleting code, one could take a look at it and rewrite it to present a less invasive extension. ;-) This takes some effort, of course. Best, Marcel Am 29.01.2021 13:22:54 schrieb K K Subbu : On 29/01/21 2:54 pm, Marcel Taeumel wrote: > > Morph >> #player in "Morphic-Kernel" / "accessing" > BookMorph >> #goto: in "MorphicExtras-Books" / "navigation" > HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer" > Morph >> #isTileMorph in "Morphic-Kernel" / "classification" > HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles" IIRC, Etoys was an experiment in visual programming for children too young to program via text but made fairly (hindsight!) intrusive changes to Morphic. Etoys was organically bound into Squeak; like conjoint twins. But that was then and this is now. Instead of shooting for a reloadable Etoys, what if the next Squeak release makes a clean break from Etoys? I propose that we slim down Squeak by removing all Etoys-related code by without trying to ensure that existing Etoys package successfully loads back into the image. This will slim down Squeak significantly and ease its maintenance. The largest user base for Etoys was on XO laptop. Those users are unlikely to upgrade to new Squeak. Also, porting Etoys package to load into slimmer Squeak may be an easier and better way to continue research than striving to maintain both in the released image. Regards .. Subbu -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Sat Jan 30 01:50:53 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 29 Jan 2021 17:50:53 -0800 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: <5fd2a9ac-23ba-048d-d3b5-55aab2448f61@gmail.com> References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> <20210123011630.GA93733@shell.msen.com> <20210129023956.GA40172@shell.msen.com> <5fd2a9ac-23ba-048d-d3b5-55aab2448f61@gmail.com> Message-ID: On Fri, Jan 29, 2021 at 4:22 AM K K Subbu wrote: > On 29/01/21 2:54 pm, Marcel Taeumel wrote: > > > > Morph >> #player in "Morphic-Kernel" / "accessing" > > BookMorph >> #goto: in "MorphicExtras-Books" / "navigation" > > HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer" > > Morph >> #isTileMorph in "Morphic-Kernel" / "classification" > > HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles" > > IIRC, Etoys was an experiment in visual programming for children too > young to program via text but made fairly (hindsight!) intrusive changes > to Morphic. Etoys was organically bound into Squeak; like conjoint twins. > > But that was then and this is now. Instead of shooting for a reloadable > Etoys, what if the next Squeak release makes a clean break from Etoys? > > I propose that we slim down Squeak by removing all Etoys-related code by > without trying to ensure that existing Etoys package successfully loads > back into the image. This will slim down Squeak significantly and ease > its maintenance. > -1000!!! > > The largest user base for Etoys was on XO laptop. Those users are > unlikely to upgrade to new Squeak. Also, porting Etoys package to load > into slimmer Squeak may be an easier and better way to continue research > than striving to maintain both in the released image. > > Regards .. Subbu > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Sat Jan 30 05:13:21 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 30 Jan 2021 05:13:21 0000 Subject: [squeak-dev] The Trunk: EToys-dtl.419.mcz Message-ID: David T. Lewis uploaded a new version of EToys to project The Trunk: http://source.squeak.org/trunk/EToys-dtl.419.mcz ==================== Summary ==================== Name: EToys-dtl.419 Author: dtl Time: 30 January 2021, 12:13:17.431593 am UUID: 6785ecb9-7abc-4a2a-a554-861f572e77cc Ancestors: EToys-dtl.418 Reloadable Etoys: Fix TileMorph class initialization for loading Etoys package =============== Diff against EToys-dtl.418 =============== Item was changed: ----- Method: TileMorph class>>initialize (in category 'class initialization') ----- initialize "TileMorph readInArrowGraphics -- call manually if necessary to bring graphics forward" "TileMorph initialize" UpdatingOperators := Dictionary new. UpdatingOperators at: #incr: put: #+. UpdatingOperators at: #decr: put: #-. UpdatingOperators at: #set: put: ''. RetractPicture ifNil: [ + RetractPicture := (self suffixPicture flipBy: #horizontal centerAt: (SuffixPicture center))]. - RetractPicture := (SuffixPicture flipBy: #horizontal centerAt: (SuffixPicture center))]. SuffixArrowAllowance := 5 + SuffixPicture width + RetractPicture width. UpArrowAllowance := 10. EqualityOperators := Dictionary new. EqualityOperators at: #< put: #eToysLT:. EqualityOperators at: #<= put: #eToysLE:. EqualityOperators at: #> put: #eToysGT:. EqualityOperators at: #>= put: #eToysGE:. EqualityOperators at: #= put: #eToysEQ:. EqualityOperators at: #~= put: #eToysNE:. ! From LEnglish5 at cox.net Sat Jan 30 05:40:33 2021 From: LEnglish5 at cox.net (LawsonEnglish) Date: Fri, 29 Jan 2021 22:40:33 -0700 Subject: [squeak-dev] Testing mail server Message-ID: I’m getting odd messages when I try to reply to a message from squeak dev so this is a pristine message L From kksubbu.ml at gmail.com Sat Jan 30 07:42:27 2021 From: kksubbu.ml at gmail.com (K K Subbu) Date: Sat, 30 Jan 2021 13:12:27 +0530 Subject: [squeak-dev] Unloading EToys from Squeak Image In-Reply-To: References: <1697231277.3880561.1611230826611.ref@mail.yahoo.com> <1697231277.3880561.1611230826611@mail.yahoo.com> <20210123011630.GA93733@shell.msen.com> <20210129023956.GA40172@shell.msen.com> <5fd2a9ac-23ba-048d-d3b5-55aab2448f61@gmail.com> Message-ID: On 29/01/21 6:01 pm, Marcel Taeumel wrote: > > But that was then and this is now. Instead of shooting for a reloadable >> Etoys, what if the next Squeak release makes a clean break from Etoys? > > That's not what I was going for. Etoys includes hints for userful > extension points in the base system. Instead of just deleting code, one > could take a look at it and rewrite it to present a less invasive > extension. ;-) This takes some effort, of course. I did mean to delete only Etoys-specific code like player, costumers, tiles etc. My initial draft included these qualifications but got elided while editing for brevity. I am glad you pointed them out. Yes, Morphic extensions and enhancements introduced by Etoys can be retained in Squeak image. BTW, I do like Etoys and have helped school teachers and children use it. It is important for Etoys to retain backward compatibility with all its projects. I believe it will be better off as a separate loadable package than organically conjoined to Squeak. Regards .. Subbu From ron at usmedrec.com Sat Jan 30 15:22:49 2021 From: ron at usmedrec.com (Ron Teitelbaum) Date: Sat, 30 Jan 2021 10:22:49 -0500 Subject: [squeak-dev] Testing mail server In-Reply-To: References: Message-ID: Got it. On Sat, Jan 30, 2021 at 12:40 AM LawsonEnglish wrote: > I’m getting odd messages when I try to reply to a message from squeak dev > so this is a pristine message > > > L > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Sun Jan 31 08:16:08 2021 From: gettimothy at zoho.com (gettimothy) Date: Sun, 31 Jan 2021 03:16:08 -0500 Subject: [squeak-dev] (16r00E007F + 16r000001) asCharacter Message-ID: <177578374ed.e6b7ad6d541.8090525015360322235@zoho.com> Hi Folks, I am diving into Unicode and resultant parts for  my WikitextParser  work and am asking for some pointers on where to look in Squeak/Morphic for how fonts interact with Morphic. The maximum unicode character per here: https://jrgraphix.net/research/unicode_blocks.php is 16r00E007F So, I decided to see what Character would do if I dialed it up to 11 a bit... (16r00E007F + 16r000001) asCharacter What this tells me is that Character just has an integer and that the display of the character associated with that integer is "delegated" to something else (which makes sense). So, as I try to "duplicate" the displayed characters at https://jrgraphix.net/research/unicode_blocks.php  with an appropriate Font (or "Font strategy...meaning, detect the font required and load it on the fly in a particular use-case)  I figured I would ask for help in clarifying my presuppositions on how we get from 16r00E0041 asCharacter to 16r00E0042 asCharacter  (get it? from A to B....heh). to expand a bit. I have characters that do show up in Chrome that do not show up in Squeak. I assume this only has to do with the Font not supporting that particular integer. Is this assumption correct?  thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Sun Jan 31 12:19:48 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun, 31 Jan 2021 04:19:48 -0800 Subject: [squeak-dev] (16r00E007F + 16r000001) asCharacter In-Reply-To: <177578374ed.e6b7ad6d541.8090525015360322235@zoho.com> References: <177578374ed.e6b7ad6d541.8090525015360322235@zoho.com> Message-ID: <20BA03ED-8BE6-4396-97EB-943F45CA3624@gmail.com> > On Jan 31, 2021, at 12:16 AM, gettimothy via Squeak-dev wrote: > >  > Hi Folks, > > I am diving into Unicode and resultant parts for my WikitextParser work and am asking for some pointers on where to look in Squeak/Morphic for how fonts interact with Morphic. > > The maximum unicode character per here: https://jrgraphix.net/research/unicode_blocks.php is 16r00E007F > > So, I decided to see what Character would do if I dialed it up to 11 a bit... > > (16r00E007F + 16r000001) asCharacter > > What this tells me is that Character just has an integer and that the display of the character associated with that integer is "delegated" to something else (which makes sense). > > So, as I try to "duplicate" the displayed characters at https://jrgraphix.net/research/unicode_blocks.php with an appropriate Font (or "Font strategy...meaning, detect the font required and load it on the fly in a particular use-case) > I figured I would ask for help in clarifying my presuppositions on how we get from 16r00E0041 asCharacter to 16r00E0042 asCharacter > > (get it? from A to B....heh). > > to expand a bit. > > I have characters that do show up in Chrome that do not show up in Squeak. I assume this only has to do with the Font not supporting that particular integer. Is this assumption correct? Yes. Character can represent all the character codes from 0 to 2^30-1. I think that (2 raisedTo: 30) asCharacter should raise an error on 64 bits. It should definitely raise an error on 32 bits. Note that in V3 we can (but should not) create Character instances with LargeInteger codes. This is not a good idea ;-) > thanks in advance. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Sun Jan 31 12:20:04 2021 From: gettimothy at zoho.com (gettimothy) Date: Sun, 31 Jan 2021 07:20:04 -0500 Subject: [squeak-dev] Unicode Ranges you might want to copy Message-ID: <1775862c6d8.10f71a9b5728.3911329244202033832@zoho.com> Hi Folks, You might find the below handy. Fwiw, I have coded the UnicodeRangeBrowser  SeasideApp to display all the below (it times out before all display, I will be doing refactor and more development). I am also coding a utility class to provide information such as below in a variety of ways. fwiw, here are my current todo notes for this font information. unifont provide link to the unicode spec. provide browser fonts list. provide squeak fonts list. provide phare fonts list ^self squeak fonts list: what are Variant Selectors ? show gaps in the ranges. provide a link(s) to required fonts that will make a range display. displays on: browser list, squeak, emacs, xterm... status bar...broken, partial, full. use cases for fonts pairs with xyz   example superscripts and subscripts The goal is to show what works and to find/test fonts that will support stuff. I am modelling the Seaside app on https://jrgraphix.net/research/unicode_blocks.php   But...for each unicode range, I intend to display smalltalk specific helpers on what/where to get fonts for both the browser side and the image side. --------------snip ------------------- (16r000020 asCharacter to: 16r00007F asCharacter) -> 'Basic Latin' (16r0000A0 asCharacter to: 16r0000FF asCharacter) -> 'Latin-1 Supplement' (16r000100 asCharacter to: 16r00017F asCharacter) -> 'Latin Extended-A' (16r000180 asCharacter to: 16r00024F asCharacter) -> 'Latin Extended-B' (16r000250 asCharacter to: 16r0002AF asCharacter) -> 'IPA Extensions' (16r0002B0 asCharacter to: 16r0002FF asCharacter) -> 'Spacing Modifier Letters' (16r000300 asCharacter to: 16r00036F asCharacter) -> 'Combining Diacritical Marks' (16r000370 asCharacter to: 16r0003FF asCharacter) -> 'Greek and Coptic' (16r000400 asCharacter to: 16r0004FF asCharacter) -> 'Cyrillic' (16r000500 asCharacter to: 16r00052F asCharacter) -> 'Cyrillic Supplementary' (16r000530 asCharacter to: 16r00058F asCharacter) -> 'Armenian' (16r000590 asCharacter to: 16r0005FF asCharacter) -> 'Hebrew' (16r000600 asCharacter to: 16r0006FF asCharacter) -> 'Arabic' (16r000700 asCharacter to: 16r00074F asCharacter) -> 'Syriac' (16r000780 asCharacter to: 16r0007BF asCharacter) -> 'Thaana' (16r000900 asCharacter to: 16r00097F asCharacter) -> 'Devanagari' (16r000980 asCharacter to: 16r0009FF asCharacter) -> 'Bengali' (16r000A00 asCharacter to: 16r000A7F asCharacter) -> 'Gurmukhi' (16r000A80 asCharacter to: 16r000AFF asCharacter) -> 'Gujarati' (16r000B00 asCharacter to: 16r000B7F asCharacter) -> 'Oriya' (16r000B80 asCharacter to: 16r000BFF asCharacter) -> 'Tamil' (16r000C00 asCharacter to: 16r000C7F asCharacter) -> 'Telugu' (16r000C80 asCharacter to: 16r000CFF asCharacter) -> 'Kannada' (16r000D00 asCharacter to: 16r000D7F asCharacter) -> 'Malayalam' (16r000D80 asCharacter to: 16r000DFF asCharacter) -> 'Sinhala' (16r000E00 asCharacter to: 16r000E7F asCharacter) -> 'Thai' (16r000E80 asCharacter to: 16r000EFF asCharacter) -> 'Lao' (16r000F00 asCharacter to: 16r000FFF asCharacter) -> 'Tibetan' (16r001000 asCharacter to: 16r00109F asCharacter) -> 'Myanmar' (16r0010A0 asCharacter to: 16r0010FF asCharacter) -> 'Georgian' (16r001100 asCharacter to: 16r0011FF asCharacter) -> 'Hangul Jamo' (16r001200 asCharacter to: 16r00137F asCharacter) -> 'Ethiopic' (16r0013A0 asCharacter to: 16r0013FF asCharacter) -> 'Cherokee' (16r001400 asCharacter to: 16r00167F asCharacter) -> 'Unified Canadian Aboriginal Syllabics' (16r001680 asCharacter to: 16r00169F asCharacter) -> 'Ogham' (16r0016A0 asCharacter to: 16r0016FF asCharacter) -> 'Runic' (16r001700 asCharacter to: 16r00171F asCharacter) -> 'Tagalog' (16r001720 asCharacter to: 16r00173F asCharacter) -> 'Hanunoo' (16r001740 asCharacter to: 16r00175F asCharacter) -> 'Buhid' (16r001760 asCharacter to: 16r00177F asCharacter) -> 'Tagbanwa' (16r001780 asCharacter to: 16r0017FF asCharacter) -> 'Khmer' (16r001800 asCharacter to: 16r0018AF asCharacter) -> 'Mongolian' (16r001900 asCharacter to: 16r00194F asCharacter) -> 'Limbu' (16r001950 asCharacter to: 16r00197F asCharacter) -> 'Tai Le' (16r0019E0 asCharacter to: 16r0019FF asCharacter) -> 'Khmer Symbols' (16r001D00 asCharacter to: 16r001D7F asCharacter) -> 'Phonetic Extensions' (16r001E00 asCharacter to: 16r001EFF asCharacter) -> 'Latin Extended Additional' (16r001F00 asCharacter to: 16r001FFF asCharacter) -> 'Greek Extended' (16r002000 asCharacter to: 16r00206F asCharacter) -> 'General Punctuation' (16r002070 asCharacter to: 16r00209F asCharacter) -> 'Superscripts and Subscripts' (16r0020A0 asCharacter to: 16r0020CF asCharacter) -> 'Currency Symbols' (16r0020D0 asCharacter to: 16r0020FF asCharacter) -> 'Combining Diacritical Marks for Symbols' (16r002100 asCharacter to: 16r00214F asCharacter) -> 'Letterlike Symbols' (16r002150 asCharacter to: 16r00218F asCharacter) -> 'Number Forms' (16r002190 asCharacter to: 16r0021FF asCharacter) -> 'Arrows' (16r002200 asCharacter to: 16r0022FF asCharacter) -> 'Mathematical Operators' (16r002300 asCharacter to: 16r0023FF asCharacter) -> 'Miscellaneous Technical' (16r002400 asCharacter to: 16r00243F asCharacter) -> 'Control Pictures' (16r002440 asCharacter to: 16r00245F asCharacter) -> 'Optical Character Recognition' (16r002460 asCharacter to: 16r0024FF asCharacter) -> 'Enclosed Alphanumerics' (16r002500 asCharacter to: 16r00257F asCharacter) -> 'Box Drawing' (16r002580 asCharacter to: 16r00259F asCharacter) -> 'Block Elements' (16r0025A0 asCharacter to: 16r0025FF asCharacter) -> 'Geometric Shapes' (16r002600 asCharacter to: 16r0026FF asCharacter) -> 'Miscellaneous Symbols' (16r002700 asCharacter to: 16r0027BF asCharacter) -> 'Dingbats' (16r0027C0 asCharacter to: 16r0027EF asCharacter) -> 'Miscellaneous Mathematical Symbols-A' (16r0027F0 asCharacter to: 16r0027FF asCharacter) -> 'Supplemental Arrows-A' (16r002800 asCharacter to: 16r0028FF asCharacter) -> 'Braille Patterns' (16r002900 asCharacter to: 16r00297F asCharacter) -> 'Supplemental Arrows-B' (16r002980 asCharacter to: 16r0029FF asCharacter) -> 'Miscellaneous Mathematical Symbols-B' (16r002A00 asCharacter to: 16r002AFF asCharacter) -> 'Supplemental Mathematical Operators' (16r002B00 asCharacter to: 16r002BFF asCharacter) -> 'Miscellaneous Symbols and Arrows' (16r002E80 asCharacter to: 16r002EFF asCharacter) -> 'CJK Radicals Supplement' (16r002F00 asCharacter to: 16r002FDF asCharacter) -> 'Kangxi Radicals' (16r002FF0 asCharacter to: 16r002FFF asCharacter) -> 'Ideographic Description Characters' (16r003000 asCharacter to: 16r00303F asCharacter) -> 'CJK Symbols and Punctuation' (16r003040 asCharacter to: 16r00309F asCharacter) -> 'Hiragana' (16r0030A0 asCharacter to: 16r0030FF asCharacter) -> 'Katakana' (16r003100 asCharacter to: 16r00312F asCharacter) -> 'Bopomofo' (16r003130 asCharacter to: 16r00318F asCharacter) -> 'Hangul Compatibility Jamo' (16r003190 asCharacter to: 16r00319F asCharacter) -> 'Kanbun' (16r0031A0 asCharacter to: 16r0031BF asCharacter) -> 'Bopomofo Extended' (16r0031F0 asCharacter to: 16r0031FF asCharacter) -> 'Katakana Phonetic Extensions' (16r003200 asCharacter to: 16r0032FF asCharacter) -> 'Enclosed CJK Letters and Months' (16r003300 asCharacter to: 16r0033FF asCharacter) -> 'CJK Compatibility' (16r003400 asCharacter to: 16r004DBF asCharacter) -> 'CJK Unified Ideographs Extension A' (16r004DC0 asCharacter to: 16r004DFF asCharacter) -> 'Yijing Hexagram Symbols' (16r004E00 asCharacter to: 16r009FFF asCharacter) -> 'CJK Unified Ideographs' (16r00A000 asCharacter to: 16r00A48F asCharacter) -> 'Yi Syllables' (16r00A490 asCharacter to: 16r00A4CF asCharacter) -> 'Yi Radicals' (16r00AC00 asCharacter to: 16r00D7AF asCharacter) -> 'Hangul Syllables' (16r00D800 asCharacter to: 16r00DB7F asCharacter) -> 'High Surrogates' (16r00DB80 asCharacter to: 16r00DBFF asCharacter) -> 'High Private Use Surrogates' (16r00DC00 asCharacter to: 16r00DFFF asCharacter) -> 'Low Surrogates' (16r00E000 asCharacter to: 16r00F8FF asCharacter) -> 'Private Use Area' (16r00F900 asCharacter to: 16r00FAFF asCharacter) -> 'CJK Compatibility Ideographs' (16r00FB00 asCharacter to: 16r00FB4F asCharacter) -> 'Alphabetic Presentation Forms' (16r00FB50 asCharacter to: 16r00FDFF asCharacter) -> 'Arabic Presentation Forms-A' (16r00FE00 asCharacter to: 16r00FE0F asCharacter) -> 'Variation Selectors' (16r00FE20 asCharacter to: 16r00FE2F asCharacter) -> 'Combining Half Marks' (16r00FE30 asCharacter to: 16r00FE4F asCharacter) -> 'CJK Compatibility Forms' (16r00FE50 asCharacter to: 16r00FE6F asCharacter) -> 'Small Form Variants' (16r00FE70 asCharacter to: 16r00FEFF asCharacter) -> 'Arabic Presentation Forms-B' (16r00FF00 asCharacter to: 16r00FFEF asCharacter) -> 'Halfwidth and Fullwidth Forms' (16r00FFF0 asCharacter to: 16r00FFFF asCharacter) -> 'Specials' (16r010000 asCharacter to: 16r01007F asCharacter) -> 'Linear B Syllabary' (16r010080 asCharacter to: 16r0100FF asCharacter) -> 'Linear B Ideograms' (16r010100 asCharacter to: 16r01013F asCharacter) -> 'Aegean Numbers' (16r010300 asCharacter to: 16r01032F asCharacter) -> 'Old Italic' (16r010330 asCharacter to: 16r01034F asCharacter) -> 'Gothic' (16r010380 asCharacter to: 16r01039F asCharacter) -> 'Ugaritic' (16r010400 asCharacter to: 16r01044F asCharacter) -> 'Deseret' (16r010450 asCharacter to: 16r01047F asCharacter) -> 'Shavian' (16r010480 asCharacter to: 16r0104AF asCharacter) -> 'Osmanya' (16r010800 asCharacter to: 16r01083F asCharacter) -> 'Cypriot Syllabary' (16r01D000 asCharacter to: 16r01D0FF asCharacter) -> 'Byzantine Musical Symbols' (16r01D100 asCharacter to: 16r01D1FF asCharacter) -> 'Musical Symbols' (16r01D300 asCharacter to: 16r01D35F asCharacter) -> 'Tai Xuan Jing Symbols' (16r01D400 asCharacter to: 16r01D7FF asCharacter) -> 'Mathematical Alphanumeric Symbols' (16r020000 asCharacter to: 16r02A6DF asCharacter) -> 'CJK Unified Ideographs Extension B' (16r02F800 asCharacter to: 16r02FA1F asCharacter) -> 'CJK Compatibility Ideographs Supplement' (16r0E0000 asCharacter to: 16r0E007F asCharacter) -> 'Tags' -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Sun Jan 31 12:36:36 2021 From: Das.Linux at gmx.de (Tobias Pape) Date: Sun, 31 Jan 2021 13:36:36 +0100 Subject: [squeak-dev] (16r00E007F + 16r000001) asCharacter In-Reply-To: <20BA03ED-8BE6-4396-97EB-943F45CA3624@gmail.com> References: <177578374ed.e6b7ad6d541.8090525015360322235@zoho.com> <20BA03ED-8BE6-4396-97EB-943F45CA3624@gmail.com> Message-ID: <0D10D78F-557B-44DC-A25B-57F3EB1BBFED@gmx.de> Hi > On 31. Jan 2021, at 13:19, Eliot Miranda wrote: > >> >> On Jan 31, 2021, at 12:16 AM, gettimothy via Squeak-dev wrote: >> >>  >> Hi Folks, >> >> I am diving into Unicode and resultant parts for my WikitextParser work and am asking for some pointers on where to look in Squeak/Morphic for how fonts interact with Morphic. >> >> The maximum unicode character per here: https://jrgraphix.net/research/unicode_blocks.php is 16r00E007F >> >> So, I decided to see what Character would do if I dialed it up to 11 a bit... >> >> (16r00E007F + 16r000001) asCharacter >> >> What this tells me is that Character just has an integer and that the display of the character associated with that integer is "delegated" to something else (which makes sense). >> >> So, as I try to "duplicate" the displayed characters at https://jrgraphix.net/research/unicode_blocks.php with an appropriate Font (or "Font strategy...meaning, detect the font required and load it on the fly in a particular use-case) >> I figured I would ask for help in clarifying my presuppositions on how we get from 16r00E0041 asCharacter to 16r00E0042 asCharacter >> >> (get it? from A to B....heh). >> >> to expand a bit. >> >> I have characters that do show up in Chrome that do not show up in Squeak. I assume this only has to do with the Font not supporting that particular integer. Is this assumption correct? > > Yes. Character can represent all the character codes from 0 to 2^30-1. I think that (2 raisedTo: 30) asCharacter should raise an error on 64 bits. It should definitely raise an error on 32 bits. Mind the leading character… -t > > Note that in V3 we can (but should not) create Character instances with LargeInteger codes. This is not a good idea ;-) > >> thanks in advance. From m at jaromir.net Sun Jan 31 17:28:14 2021 From: m at jaromir.net (jaromir) Date: Sun, 31 Jan 2021 11:28:14 -0600 (CST) Subject: [squeak-dev] Transcript losing output when #processPreemptionYields = true Message-ID: <1612114094246-0.post@n4.nabble.com> Transcript may lose some output for #processPreemptionYields = true Example (semaphore prearmed with 2 signals): |accessProtect| Smalltalk vm processPreemptionYields: true. Transcript cr. accessProtect := Semaphore new signal signal. [accessProtect critical: [ Transcript cr; show: 'Process 1a '. 10000 factorial. Transcript cr; show: 'Process 1b '. ]] fork. Processor yield. [accessProtect critical: [ Transcript cr; show: 'Process 2a '. 10000 factorial. Transcript cr; show: 'Process 2b '. ]] forkAt: 41. Transcript cr; show: 'Process UIa '. 0.3 second wait. Transcript cr; show: 'Process UIb '. Output: "this is ok" Process 1a Process 2a Process 2b Process 1b Process UIa Process UIb "Here Process 2a output missing!" Process 1a Process 2b Process UIa Process 1b Process UIb "Or even this came out" Process 1a Process 2b Process 1b Process UIb The problem is probably related to the post: Transcript error when forceUpdate: false http://forum.world.st/Transcript-error-when-forceUpdate-false-td5126397.html Similar workaround (Collections-mt.923 @ inbox) may fix this issue too. Tested on Squeak6.0alpha-20182-64bit-freshCopy (Collections-dtl.923 @ trunk) -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From eliot.miranda at gmail.com Sun Jan 31 17:58:04 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun, 31 Jan 2021 09:58:04 -0800 Subject: [squeak-dev] Transcript losing output when #processPreemptionYields = true In-Reply-To: <1612114094246-0.post@n4.nabble.com> References: <1612114094246-0.post@n4.nabble.com> Message-ID: Hi Jaromir, hi All, > On Jan 31, 2021, at 9:28 AM, jaromir wrote: > > Transcript may lose some output for #processPreemptionYields = true But processPreemptionYields should be false. I put in the ability to make it false precisely because of the kinds of problems below that are caused when processPreemptionYields = true. How come we still have trunk images where processPreemptionYields = true? > > Example (semaphore prearmed with 2 signals): > > |accessProtect| > Smalltalk vm processPreemptionYields: true. > Transcript cr. > accessProtect := Semaphore new signal signal. > [accessProtect critical: [ > Transcript cr; show: 'Process 1a '. > 10000 factorial. > Transcript cr; show: 'Process 1b '. > ]] fork. > Processor yield. > [accessProtect critical: [ > Transcript cr; show: 'Process 2a '. > 10000 factorial. > Transcript cr; show: 'Process 2b '. > ]] forkAt: 41. > Transcript cr; show: 'Process UIa '. > 0.3 second wait. > Transcript cr; show: 'Process UIb '. > > Output: > "this is ok" > Process 1a > Process 2a > Process 2b > Process 1b > Process UIa > Process UIb > > "Here Process 2a output missing!" > Process 1a > Process 2b > Process UIa > Process 1b > Process UIb > > "Or even this came out" > Process 1a > Process 2b > Process 1b > Process UIb > > The problem is probably related to the post: Transcript error when > forceUpdate: false > http://forum.world.st/Transcript-error-when-forceUpdate-false-td5126397.html > > Similar workaround (Collections-mt.923 @ inbox) may fix this issue too. > Tested on Squeak6.0alpha-20182-64bit-freshCopy (Collections-dtl.923 @ trunk) Eliot, _,,,^..^,,,_ (phone) From m at jaromir.net Sun Jan 31 18:11:23 2021 From: m at jaromir.net (jaromir) Date: Sun, 31 Jan 2021 12:11:23 -0600 (CST) Subject: [squeak-dev] Transcript losing output when #processPreemptionYields = true In-Reply-To: References: <1612114094246-0.post@n4.nabble.com> Message-ID: <1612116683800-0.post@n4.nabble.com> No no, it's set to true by default but I'm learning and have tested behavior with processPreemptionYields = false :) I was not aware this is not supposed to be a "production" feature. I applied the fix from the other Transcript issue and it seemingly 'works' so it seemed to be another bug related to the other one. -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From eliot.miranda at gmail.com Sun Jan 31 19:14:25 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun, 31 Jan 2021 11:14:25 -0800 Subject: [squeak-dev] Transcript losing output when #processPreemptionYields = true In-Reply-To: <1612116683800-0.post@n4.nabble.com> References: <1612116683800-0.post@n4.nabble.com> Message-ID: <1551EFA6-AA72-485A-B857-8BA8AF693AA0@gmail.com> _,,,^..^,,,_ (phone) > On Jan 31, 2021, at 10:11 AM, jaromir wrote: > > No no, it's set to true by default but I'm learning and have tested behavior > with processPreemptionYields = false :) I was not aware this is not supposed > to be a "production" feature. I applied the fix from the other Transcript > issue and it seemingly 'works' so it seemed to be another bug related to the > other one. D’u hear that folks? We badly need to make sure that processPreemptionYields = false is the default. > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html > From eliot.miranda at gmail.com Sun Jan 31 19:16:26 2021 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun, 31 Jan 2021 11:16:26 -0800 Subject: [squeak-dev] Transcript losing output when #processPreemptionYields = true In-Reply-To: <1612116683800-0.post@n4.nabble.com> References: <1612116683800-0.post@n4.nabble.com> Message-ID: <0C26F716-F092-42C4-BE09-5D66690C0867@gmail.com> _,,,^..^,,,_ (phone) > On Jan 31, 2021, at 10:11 AM, jaromir wrote: > > No no, it's set to true by default That is not supposed to be the case. Some mistake has happened along the way. processPreemptionYields = true is a clearly broken policy (as your transcript bugs show) and is only supported for backwards compatibility. It should be false by default. > but I'm learning and have tested behavior > with processPreemptionYields = false :) I was not aware this is not supposed > to be a "production" feature. I applied the fix from the other Transcript > issue and it seemingly 'works' so it seemed to be another bug related to the > other one. > > > > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html > From m at jaromir.net Sun Jan 31 19:22:21 2021 From: m at jaromir.net (jaromir) Date: Sun, 31 Jan 2021 13:22:21 -0600 (CST) Subject: [squeak-dev] Transcript losing output when #processPreemptionYields = true In-Reply-To: <0C26F716-F092-42C4-BE09-5D66690C0867@gmail.com> References: <1612114094246-0.post@n4.nabble.com> <1612116683800-0.post@n4.nabble.com> <0C26F716-F092-42C4-BE09-5D66690C0867@gmail.com> Message-ID: <1612120941808-0.post@n4.nabble.com> I messed my reply, sorry; it FALSE by default - no problem there Jaromir -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From commits at source.squeak.org Sun Jan 31 19:25:57 2021 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 31 Jan 2021 19:25:57 0000 Subject: [squeak-dev] The Inbox: System-ct.1213.mcz Message-ID: Christoph Thiede uploaded a new version of System to project The Inbox: http://source.squeak.org/inbox/System-ct.1213.mcz ==================== Summary ==================== Name: System-ct.1213 Author: ct Time: 31 January 2021, 8:25:50.362826 pm UUID: 389f6bbe-a0cb-764c-815d-369887fc2d39 Ancestors: System-eem.1212 Improves SmalltalkImage>>isHeadless to recognize double-dash arguments correctly. (It's still not perfect just because one could delete the empty DISPLAY env var on Linux, but accessing env vars in Trunk would probably be a larger project ...) =============== Diff against System-eem.1212 =============== Item was changed: ----- Method: SmalltalkImage>>isHeadless (in category 'vm parameters') ----- isHeadless "Answer whether the command-line specified to launch the VM headless." + | headlessOptions | + headlessOptions := #('display=none' '-headless' '-nodisplay' '-vm-display-null') + gather: [:option | {option. option copyWithFirst: $-}]. self optionsDo: + [ : each | (headlessOptions includes: each) ifTrue: [ ^ true ] ]. - [ : each | (#('display=none' '-headless' '-nodisplay' '-vm-display-null' ) includes: each) ifTrue: [ ^ true ] ]. ^ false!