April 2022 - Pharo-users - lists.pharo.org

Re: [Vm-dev] HiDpi support in MacOS

by Steffen MÃ¤rcker

Is there a way to take advantage of that VM-change to enhance sharpness in Pharo 10 already on MacBook retina displays? Kind regards, Steffen Marcel Taeumel schrieb am Donnerstag, 28. April 2022 10:18:46 (+02:00): Hi all -- I documented this here: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/628 Best, Marcel Am 28.04.2022 09:51:22 schrieb Marcel Taeumel <marcel.taeumel(a)hpi.de>: Hi Juan -- Currently, we only use the backingScaleFactor. For current systems this can only ever be 1.0 or 2.0. I have yet to discover the macOS API that let's us work with native pixels for that other (older) form other scaling on macOS. I will open an issue for that. Best, Marcel Am 28.04.2022 00:39:12 schrieb Juan Vuletich <juanvuletich(a)zoho.com>: Hi Folks, I just discovered that the recent 202204190959 Mac VM includes Tobias HiDpi support on the Mac. This is very good news indeed, but It is not exactly what most users would prefer. On a Retina MacBook, you can set an apparent display resolution (System Preferences.../ Displays). By default, my 2019 15" MBP suggest half "real" resolution ("Looks like 1440x900" when LCD is 2880x1800). In this case, the new VM offers the true native resolution to Cuis / Squeak. So, in this case, it works perfectly well, and everything looks really great. The problem is that MacOs supports several other apparent resolutions. Many people, me included, prefer "Looks like 1680x1050" or "Looks like 1920x1200") to have more room for other Mac apps. But in these cases, the VM doesn't offer the LCD native resolution to Cuis / Squeak anymore. It offers twice the apparent resolution, i.e. 3360x2100 or 3840x2400. Then MacOs scales this higher virtual resolution to the actual 2880x1800, but it generates visual artifacts and a decrease in visual quality. For my own private use, the solution is to use the EasyRes application, and set the display to the true 2880x1800 resolution. When I do this, Cuis gets the corrrect Display size both with previous and newer VMs. But it would be great if there was a way for other Cuis / Squeak users to get their true Display resolution by default, and without needing to change OS settings each time they start their favorite Smalltalk. Thanks, -- Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev https://github.com/jvuletich https://www.linkedin.com/in/juan-vuletich-75611b3 https://independent.academia.edu/JuanVuletich https://www.researchgate.net/profile/Juan-Vuletich https://patents.justia.com/inventor/juan-manuel-vuletich https://twitter.com/JuanVuletich -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

April 28, 2022

Re: Pharo is unresponsive after forcing quit

by Yanni Chiu

Try switching focus to another app on your Mac (e.g. Finder or web browser), then back to Pharo On Wed, Apr 27, 2022 at 8:44 PM Stewart MacLean <stewart(a)xtra.co.nz> wrote: > Hi, > > [Pharo 10 on Mac Monterey] > > Due to the multi-process nature of Bonjour that I'm attempting to > interface to, I am crashing the system ALOT as it disappears down a black > hole and I try to figure out the cause. > > However, I've noticed that most of the time when I restart Pharo it is > unresponsive to clicks and I have to relaunch Pharo AGAIN! Argh....! > > The mouse moves but no one is at home. Right click brings up menus, but > they don't respond. > > As I move the mouse, list items are highlighted. > > As this is a completely new OS process, I'm wondering what is causing this > behaviour? > > Has anyone else experienced this, or have an explanation? > > Cheers, > > Stewart >

April 28, 2022

Re: Pharo is unresponsive after forcing quit

by James Foster

Pharo 10 on Mac Monterey works fine for me. > On Apr 27, 2022, at 5:43 PM, Stewart MacLean <stewart(a)xtra.co.nz> wrote: > > Hi, > > [Pharo 10 on Mac Monterey] > > Due to the multi-process nature of Bonjour that I'm attempting to interface to, I am crashing the system ALOT as it disappears down a black hole and I try to figure out the cause. > > However, I've noticed that most of the time when I restart Pharo it is unresponsive to clicks and I have to relaunch Pharo AGAIN! Argh....! > > The mouse moves but no one is at home. Right click brings up menus, but they don't respond. > > As I move the mouse, list items are highlighted. > > As this is a completely new OS process, I'm wondering what is causing this behaviour? > > Has anyone else experienced this, or have an explanation? > > Cheers, > > Stewart

April 28, 2022

Pharo is unresponsive after forcing quit

by Stewart MacLean

Hi, [Pharo 10 on Mac Monterey] Due to the multi-process nature of Bonjour that I'm attempting to interface to, I am crashing the system ALOT as it disappears down a black hole and I try to figure out the cause. However, I've noticed that most of the time when I restart Pharo it is unresponsive to clicks and I have to relaunch Pharo AGAIN! Argh....! The mouse moves but no one is at home. Right click brings up menus, but they don't respond. As I move the mouse, list items are highlighted. As this is a completely new OS process, I'm wondering what is causing this behaviour? Has anyone else experienced this, or have an explanation? Cheers, Stewart

April 28, 2022

[ANN] Willow-Playground v9.1.1 [v9.1.1] released!

by Buenos Aires Smalltalk

April 27, 2022

Re: How to show the process name in the debugger?

by Stewart MacLean

Thanks Norbert - I was meaning how to show it in the title of the Debugger for when I get a lot of debuggers on different processes. Please see Steven Costiou's solution. Cheers, Stewart On Tue, Apr 26, 2022 at 9:57 PM Norbert Hartl <norbert(a)hartl.name> wrote: > Try > > Processor activeProcess name > > regards, > > Norbert > > > Am 26.04.2022 um 10:45 schrieb Stewart MacLean <stewart(a)xtra.co.nz>: > > > > Hi, > > > > I am working on a multi green and OS threaded implementation of Apple's > Bonjour service discovery. > > > > I'd like to show the current Smalltalk process name in the Halt window > title. > > > > Any clues are very much appreciated. > > > > Thanks, > > > > Stewart >

April 27, 2022

Re: How to show the process name in the debugger?

by Stewart MacLean

Thanks Steven - exactly what I needed to know! Cheers, Stewart On Tue, Apr 26, 2022 at 10:08 PM Steven Costiou <steven.costiou(a)kloum.io> wrote: > Hi, > > in Pharo 9-11, from the StDebugger you can access the debugged process > using > > self session interruptedProcess name > > In the debugger class you can prepend that instruction in the window title > update methods: > > StDebugger>>initializeWindow: aWindowPresenter > > super initializeWindow: aWindowPresenter. > aWindowPresenter > title: self session interruptedProcess name , ': ' > , self debuggerActionModel statusStringForContext; > initialExtent: self initialExtent; > whenClosedDo: [ self clear ]. > > self initializeShortcuts: aWindowPresenter > > > > StDebugger>>newTitle > > ^ self session interruptedProcess name , ': ' > , self debuggerActionModel statusStringForContext > > > > There is no other ways yet to customize the window title. > > I do not know how to do it in prior versions of Pharo. > > Steven. > > > > Le 2022-04-26 10:45, Stewart MacLean a Ã©crit : > > Hi, > > I am working on a multi green and OS threaded implementation of Apple's > Bonjour service discovery. > > I'd like to show the current Smalltalk process name in the Halt window > title. > > Any clues are very much appreciated. > > Thanks, > > Stewart > > >

April 27, 2022

[ANN] docker-pharo-runtime v10.0.0-1.0.0 [v10.0.0 + 1.0.0] released!

by Buenos Aires Smalltalk

April 26, 2022

Re: A question about #beginsWith: and #endsWith:

by Steffen MÃ¤rcker

Maybe I should add an example. Consider the following natural proposition: > (A, B) beginsWith: A and: [(A, B) endsWith: B] This breaks for A := '' or B := '' ". Best, Steffen Kasper Osterbye schrieb am Dienstag, 26. April 2022 14:50:51 (+02:00): I have now raised it as an issue on the issue tracker Issue #11165 in https://github.com/pharo-project/pharo/issues/11165 Best, Kasper On 26 Apr 2022, at 12.11, Steffen MÃ¤rcker <merkste(a)web.de> wrote: I can only fully agree to Richard's explanation. Also, not having the empty string pre/suf-fixing every string breaks the free monoid that describes concatenation of strings and forms the basis of regular expressions. In effect, this will lead to subtle inconsistencies. Hence, I consider this a bug rather than a feature. Kind regards, Steffen -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

April 26, 2022

Re: A question about #beginsWith: and #endsWith:

by Richard O'Keefe

I discovered that my own code-base was inconsistent due to sometimes following Pharo and sometimes not. I've just spent the last day making it consistent and you would not BELIEVE how many methods suddenly became simpler. I finally understood why some of the test cases I had for XPath were broken. XPath specifies that the empty string is a prefix and suffix of every string. Perhaps better support for XPath may have some persuasive value. (Though support for XPath collations will be a long way off. There's a LOT of other Unicode support I need to develop first.) On Tue, 26 Apr 2022 at 22:12, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > I can only fully agree to Richard's explanation. Also, not having the > empty string pre/suf-fixing every string breaks the free monoid that > describes concatenation of strings and forms the basis of regular > expressions. In effect, this will lead to subtle inconsistencies. Hence, I > consider this a bug rather than a feature. > > Kind regards, > Steffen > > > > Richard O'Keefe schrieb am Samstag, 23. April 2022 02:37:48 (+02:00): > > Dan Ingalls is of course a big NAME in the > world of Smalltalk, but the stated reason > for changing the behaviour of #beginsWith: > and #endsWith: makes no sense. > > > We have many ways to define a partial order > on strings. > x <= y iff y beginsWith: x > x <= y iff y endsWith: x > x <= y iff y includesSubCollection: x > x <= y iff y includesSubSequence: x > These things are supposed to obey laws: > if a beginsWith: b , c > then a beginsWith: b > if a endsWith: b , c > then a endsWith: c > if a includesSubCollection: b , c > then a includesSubCollection: b > and a includesSubCollection: c > if a includesSubSequence: b , c > then a includesSubSequence: b > and a includesSubSequence: c. > > We also expect the usual rules of equality > to hold. So > (1) a beginsWith: a > (2) a = '' , a > (3) THEREFORE a beginsWith: '' > > (1) a endsWith: a > (2) a = a , '' > (3) THEREFORE a endsWith: '' > > (1) a includesSubCollection: a > (2) a = '' , a > (3) THEREFORE a includesSubCollect: '' > > Reasoning about strings (as values) gets > enormously more complicated if the operations > do not follow simple sensible rules, and > having '' be the least string under these > orderings and having '' be a prefix and a > suffix of any string is essential if the > rules are going to be simple and coherent. > > '' is to strings (and more generally > empty sequences are to sequences) pretty > much what 0 is to integers. Denying that > 'abc' beginsWith: '' is *structurally* > just like denying that 0 <= 123. > > Now as it happens I *can* see a use for > versions of #beginsWith: and #endsWith: > that diverge from the ones we have, but > *this* is not where they need to diverge. > a beginsWithGraphemesOf: b > iff a asGraphemes = b asGraphemes , c asGraphemes > for some c, where s asGraphemes returns a > sequence of strings each of which is a maximally > long grapheme cluster, such that concatenating > s asGraphemes recovers s. That is, > #beginsWithGraphemesOf: and > #endsWithGraphemesOf: would respect the > Unicode Text Segmentation boundaries. > But s beginsWithGraphemesOf: '' > would still need to be true. > > The thing is, in practice you often DON'T > KNOW whether a potential affix is empty or > not. Here are some of my test cases. > > testTestData > "Ensure that the sample string has no duplicates." > [(Set withAll: string) size = stringSize] assert. > > testBeginsWith > "Test that every prefix of the sample IS a prefix of it." > 0 to: stringSize do: [:n | > [string beginsWith: (string copyFrom: 1 to: n)] assert]. > > testEndsWith > "Test that every suffix of the sample IS a suffix of it." > 0 to: stringSize do: [:n | > [string endsWith: (string copyFrom: stringSize - n + 1 to: > stringSize)] assert]. > > testIndexOfSubCollectionAtBeginning > "Test that every prefix of 'abcd' is found at the beginning." > 0 to: stringSize do: [:n | |s i t| > s := string copyFrom: 1 to: n. > i := string indexOfSubCollection: s startingAt: 1. > [1 = i] assert. > t := string copyFrom: i to: i - 1 + n. > [t = s] assert]. > > testIndexOfSubCollectionAtEnd > "Test that every proper suffix of the sample is found at the end." > 1 to: stringSize do: [:n | |s i t| > s := string copyFrom: stringSize - n + 1 to: stringSize. > i := string indexOfSubCollection: s startingAt: 1. > [stringSize + 1 - n = i] assert. > t := string copyFrom: i to: i - 1 + n. > [t = s] assert]. > > testLastIndexOfSubCollectionAtBeginning > "Test that every proper prefix of the sample is found at the > beginning." > 1 to: stringSize do: [:n | |s i t| > s := string copyFrom: 1 to: n. > i := string lastIndexOfSubCollection: s startingAt: stringSize. > [1 = i] assert. > t := string copyFrom: i to: i - 1 + n. > [t = s] assert]. > > testLastIndexOfSubCollectionAtEnd > "Test that every suffix of the sample is found at the end." > 0 to: stringSize do: [:n | |s i t| > s := string copyFrom: stringSize - n + 1 to: stringSize. > i := string lastIndexOfSubCollection: s startingAt: stringSize. > [stringSize + 1 - n = i] assert. > t := string copyFrom: i to: i - 1 + n. > [t = s] assert]. > > testOccurrencesOfEmptyCollection > "Test that the empty string occurs at the beginning, > at the end, and in between every pair of adjacent characters." > [(string occurrencesOfSubCollection: '') = (stringSize + 1)] assert. > > testOccurrencesOfUniqueParts > "Test that unique parts occur as many times as they should." > |repeated| > repeated := string , string , string. > 1 to: stringSize do: [:start | > start to: stringSize do: [:finish | |s n| > s := string copyFrom: start to: finish. > n := string occurrencesOfSubCollection: s. > [n = 1] assert. > n := repeated occurrencesOfSubCollection: s. > [n = 3] assert]]. > > On Fri, 22 Apr 2022 at 13:57, David T. Lewis <lewis(a)mail.msen.com> wrote: > >> Hi Richard, >> >> (CC squeak-dev list, replies to the relevant list please) >> >> On Thu, Apr 21, 2022 at 12:07:32AM +1200, Richard O'Keefe wrote: >> > I've just tracked down a nasty little problem >> > porting some code to Pharo. As a result, I >> > have added to the comments in my own versions >> > of these methods. beginsWith: aSequence >> > "Answer true if aSequence is a prefix of the receiver. >> > This makes sense for all sequences. >> > There is a compatibility issue concerning 'abc' beginsWith: '' >> > + VisualWorks, Dolphin, astc, GNU ST (where the method is >> > called #startsWith:) and VisualAge (where the method >> > is called #wbBeginsWith:) >> > agree than EVERY sequence begins with an empty prefix. >> > - Squeak and Pharo >> > agree that NO sequence begins with an empty sequence. >> > # ST/X chooses compatibility with Squeak, heaving a big unhappy >> > sigh, and adds #startsWith: to have something sensible to use. >> > Now ST/X *thinks* it is compatible with VW, though it isn't, so >> > I wonder if this was a bug that VW fixed and Squeak didn't? >> > astc goes with the majority here. This is also compatible with >> > Haskell, ML, and with StartsWith in C# and startsWith in Java." >> > ^self beginsWith: aSequence ignoringCase: false >> > >> > endsWith: aSequence >> > "Answer true if aSequence is a suffix of the receiver. >> > This makes sense for all sequences. >> > There is a compatibility issue concerning 'abc' endsWith: ''. >> > + VisualWorks, Dolphin, astc, GNU ST, and VisualAge (where >> > the method is called #wbEndsWith:) >> > agree that EVERY sequence ends with an empty suffix. >> > - Squeak and Pharo >> > agree that NO sequence ends with an empty suffix. >> > # ST/X chooses compatibility with the majority, apparently >> > unaware that this makes #beginsWith: and #endsWith: >> inconsistent. >> > astc goes with the majority here. This is also compatible with >> > Haskell, ML, C#, and Java." >> > ^self endsWith: aSequence ignoringCase: false >> > >> > Does anyone have any idea >> > - why Squeak and Pharo are the odd ones out? >> > - why anyone thought making #beginsWith: and #endsWith:, um, "quirky" >> > was a good idea (it's pretty standard in books on the theory of >> > strings to define "x is a prefix of y iff there is a z such that >> > y = x concatenated with z") >> >> The Squeak behavior was introduced in November 1998 by Dan Ingalls >> in conjunction with some VM improvements that he was doing, and was >> included in the Squeak2.2 release at that time. >> >> Prior to that update, Squeak did this: >> 'abc' beginsWith: '' ==> true >> 'abc' endsWith: '' ==> true >> >> For Squeak2.2 and later it is: >> 'abc' beginsWith: '' ==> false >> 'abc' endsWith: '' ==> false >> >> Pharo presumably inherits this from Squeak. >> >> I am attaching Dan's original change set from the early Squeak >> update stream so you can see the context. >> >> The change set comment says that "endsWith:, beginsWith:, and match >> have been rewritten to take advantage of this considerably faster method" >> (referring to a new primitive that Dan had added to the VM in this >> change set). >> >> > >> > I was about to try to file a bug report for the first time, >> > then realised that maybe other people don't think this IS a bug. >> >> I don't think it is a bug. I can't think of a case where it makes >> sense to say that a string of characters "begins with" or "ends with" >> a string that contains nothing. >> >> In any case, that's the history of the change in Squeak and Pharo as >> best as I can reconstruct it. >> >> HTH, >> Dave >> >> > -- > Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com > herunter. >

April 26, 2022