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

[ANN] Pharo Launcher 3.0.1 released!

by Christophe Demarey

Hi all, Pharo Launcher 3.0.1 has just been released! It is available from http://pharo.org/download <http://pharo.org/download>. It fixes some issues reported on Pharo Launcher 3.0. Here is the changelog: Pharo Launcher v3.0.1 Bug fixes: #554 <https://github.com/pharo-project/pharo-launcher/issues/554> UI does not show up on Windows #551 <https://github.com/pharo-project/pharo-launcher/issues/551> Show folder button is broken in Windows 10 #550 <https://github.com/pharo-project/pharo-launcher/issues/550> About Box shows "untitled Window" #549 <https://github.com/pharo-project/pharo-launcher/issues/549> Better display of download error messages. #358 <https://github.com/pharo-project/pharo-launcher/issues/358> Restore proxy authentication settings. Regards, The Pharo team.

April 29, 2022

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

by Steffen MÃ¤rcker

Hi Kasper, I've thought about that approach too. But then asked myself whether it is more likely that there is code that relies on this bug than code where this went unnoticed and is therefore broken. What do the other think about that matter and the fix in Squeak? Best, Steffen Kasper Osterbye schrieb am Donnerstag, 28. April 2022 19:03:07 (+02:00): 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 If I may suggest a solution it will be to: add two new methods - prefixedBy: and suffixedBy: to handle the empty prefix/suffix correctly add comments to beginsWith: and endsWith: referring to the two new methods The problem is that there is client code which depend on the (wrong) implementation of the beginsWith and endsWith methods.

April 29, 2022

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

by David T. Lewis

FYI it was fixed in Squeak a couple of days ago: http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-April/220089.ht… Richard O'Keefe's point of view was overwhelmingly supported, notably including this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-April/220038.ht… Dave On Sat, Apr 23, 2022 at 12:37:48PM +1200, Richard O'Keefe wrote: > 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 > > > >

April 29, 2022

Re: Pharo is unresponsive after forcing quit

by Mark O'Donoghue

FWIW I've seen similar issues with P9 and P10 in my simple project - which has nothing fancy happening with threads or processes . Typically the system would sometimes freeze for about 20 minutes and then resolve by itself. Days of trying workarounds finally revealed the Spec2 layout calculations were very very busy. Perhaps the geometry calculations aren't readily converging? Changing the initial window size seemed to magically sidestep the problem. Also slightly changing some values for #add:height: #add:widget: constraints in the layouts seemed to avoid the problem too. Finicky indeed... I also occassionally see the P9 and P10 environment freeze if left unattended too long. No idea why. Sometimes a presenter won't display properly unless and until I click in another window. No idea why. SpTablePresenters often paint with column alignment problems - you need to click the table - or reset with #items: to get a neatly aligned result... Coping with these behaviours can be incredibly time consuming... I wonder how many people are seeing similar quirky behaviours...? On Fri, 29 Apr 2022, 3:50 am Stewart MacLean, <stewart(a)xtra.co.nz> wrote: > Thanks all for your suggestions/replies. > > Nothing fixes it for now. I accept that due to the single threaded nature > of the UI that there will be glitches occasionally, and when you are using > low level interfaces. > > The weird thing is this happens after restarting, when everything should > be pristine! > > Cheers, > > Stewart > > On Thu, Apr 28, 2022 at 9:41 PM Noury Bouraqadi <bouraqadi(a)gmail.com> > wrote: > >> I've got it too with P9 when I leave an image open for a while. I becomes >> unresponsive and I have to kill it from the Mac OS "force quit" popup. >> Hppened to me with the Pharo launcher too. >> >> >> Noury >> On Apr 28 2022, at 3:47 am, Yanni Chiu <yannix7db(a)gmail.com> wrote: >> >> 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 29, 2022

Re: Pharo is unresponsive after forcing quit

by Stewart MacLean

Thanks all for your suggestions/replies. Nothing fixes it for now. I accept that due to the single threaded nature of the UI that there will be glitches occasionally, and when you are using low level interfaces. The weird thing is this happens after restarting, when everything should be pristine! Cheers, Stewart On Thu, Apr 28, 2022 at 9:41 PM Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > I've got it too with P9 when I leave an image open for a while. I becomes > unresponsive and I have to kill it from the Mac OS "force quit" popup. > Hppened to me with the Pharo launcher too. > > > Noury > On Apr 28 2022, at 3:47 am, Yanni Chiu <yannix7db(a)gmail.com> wrote: > > 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: Loading from a git repository with Metacello on a running seaside image

by Dale Henrichs

Emilio, I wasn't quite sure whether or not you were concerned about having the BaselineOf refreshed or a reload of the packages managed by the BaselineOf and as Gabriel mentions, the missing #projectClass method is the most common problem ... By default Metacello does not refresh a BaselieOf in your image if it is already present, however, you can force a refresh of a BaselineOf by using the the Metcello #get command: > Metacello new baseline:'MyProject'; > repository: 'github://myUser/MyProject:main/myProject'; > get; > load. This would be a good pattern to follow when reloading projects after updating from github ... and I am a bit surprised that this question is not asked more often :) Dale On Mon, Apr 25, 2022 at 6:06 PM Emilio Oca <emiliooca(a)gmail.com> wrote: > Hi Gabriel, Dale! > > My BaselineOf had only #baseline: > Added #projectClass > But is still not working. > It seems to be doing the load, but not the pull before the load. > > I had implemented no more than #baseLine: and now projectClass. > > If I go through the UI and do the pull it works perfectly. > Can I replicate that with a script? > > Best > > Emilio > > On Mon, Apr 25, 2022 at 6:49 PM Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> Emilio, >> >> Are you using a repository without Monticello meta data? If so, then you >> need to change the #projectClass of you your baseline to: >> >>> projectClass >>> Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl | ^ >>> cl ]. >>> ^ super projectClass >> >> >> unless the #projectClass is MetacelloCypressBaselineProject, Metacello >> will think that your package versions are 'cypress.1' and Metacello will >> not load packages with the same version .... when the #projectClass is >> MetacelloCypressBaselineProject, Metacello will always load the package and >> let Monticello filter out the changes ... >> >> Dale >> >> On Mon, Apr 25, 2022 at 2:39 PM Esteban Lorenzano <estebanlm(a)netc.eu> >> wrote: >> >>> mmm, you may be having another problem elsewhere, because what I typed >>> should be working (is how we enforce the load of new versions to run the >>> tests, for example). >>> >>> Esteban >>> >>> On Apr 25 2022, at 11:30 pm, Emilio Oca <emiliooca(a)gmail.com> wrote: >>> >>> Hi Esteban >>> >>> Thanks for the hint. >>> It is still not working. >>> Even if I remove BaselineOfMyProject and MyProject. >>> When it reloads, it doesn't loads the last version of head at github but >>> the one that was already at the image. >>> >>> I just want to update up to what is at gibhub head. Is there another way? >>> >>> Best >>> >>> Emilio >>> >>> On Sat, Apr 23, 2022 at 1:56 AM Esteban Lorenzano <estebanlm(a)netc.eu> >>> wrote: >>> >>> Hi Emilio, >>> >>> You need something like this: >>> >>> Metacello new >>> repository: 'github://pharo-spec/Spec:Pharo10'; >>> baseline: 'Spec2'; >>> onConflict: [ :e | e useIncoming ]; >>> onUpgrade: [ :e | e useIncoming ]; >>> ignoreImage; >>> load >>> >>> ignoreImage, onConflict, onUpgrade. >>> >>> BUT if your image already has a baseline for your project then Metacello >>> will not reload it (hence your project may not be loaded correctly, since >>> baseline may have changed). >>> >>> In that case, I always execute before something like: >>> >>> #( 'BaselineOfSpec2' 'BaselineOfSpecCore' ) do: [ :each | >>> (RPackageOrganizer default packageNamed: each ifAbsent: [ nil ]) >>> ifNotNil: [ :aPackage | aPackage removeFromSystem ] ] >>> >>> >>> I ack this is hacky, but it works :) >>> >>> Esteban >>> >>> On Apr 23 2022, at 3:21 am, Emilio Oca <emiliooca(a)gmail.com> wrote: >>> >>> Hi List >>> >>> I need some help with Metacello, and may be git too >>> >>> I would like to be able to, in a running headless image, load the last >>> commit of a git repo >>> >>> Something like >>> Metacello new baseline:'MyProject'; >>> repository: 'github://myUser/MyProject:main/myProject'; >>> load. >>> works just once and may open some dialogs >>> >>> Something like this >>> [ >>> [ >>> Metacello new baseline:'MyProject'; >>> repository: 'github://myUser/MyProject:main/myProject'; >>> onConflictUseIncoming; >>> load. >>> ] on: MetacelloSkipDirtyPackageLoad do: [ :ex | ex resume: false ]. >>> ] on: MCMergeOrLoadWarning do: [ :ex | ex load ]. >>> Avoids the dialogs and alerts but the code is still not updated. >>> >>> My intention is to be able to 'refresh' a running seaside image with its >>> latest development version from a git repo (avoiding to personally reach >>> the server and rebuild the docker image) >>> What am I missing? >>> >>> Best >>> >>> Emilio >>> >>>

April 28, 2022

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

by Buenos Aires Smalltalk

April 28, 2022

[ANN] docker-pharo-vm v9.0.14-1.0.1 [v9.0.14 + 1.0.1] released!

by Buenos Aires Smalltalk

April 28, 2022

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

by Kasper Osterbye

> 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 <https://github.com/pharo-project/pharo/issues/11165> in https://github.com/pharo-project/pharo/issues/11165 <https://github.com/pharo-project/pharo/issues/11165> If I may suggest a solution it will be to: add two new methods - prefixedBy: and suffixedBy: to handle the empty prefix/suffix correctly add comments to beginsWith: and endsWith: referring to the two new methods The problem is that there is client code which depend on the (wrong) implementation of the beginsWith and endsWith methods.

April 28, 2022

Re: Pharo is unresponsive after forcing quit

by Noury Bouraqadi

I've got it too with P9 when I leave an image open for a while. I becomes unresponsive and I have to kill it from the Mac OS "force quit" popup. Hppened to me with the Pharo launcher too. Noury On Apr 28 2022, at 3:47 am, Yanni Chiu <yannix7db(a)gmail.com> wrote: > 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 (mailto:stewart@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