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

Re: [Pharo-users] #(foo bar baz) min

by Richard O'Keefe

#('a' 'b' 'c') min also fails on the grounds that ByteStrings don't understand #min:. What's worse is that ByteString and ByteSymbol *do* have #max:, but it's something quite different (and arguably broken). max: aBlock | max | self ifEmpty: [ ^ nil ]. max := aBlock value: self first. self allButFirstDo: [ :each | | value | value := aBlock value: each. max := max max: value ]. ^ max It would be better if the TComparable #min: and #max: were available and the current #max: renamed to something else. I have this in an extension to GNU Smalltalk: Collection extend [ collect: collectBlock thenFold: foldBlock [ |started result| started := result := nil. self do: [:each | |v| v := collectBlock value: each. result := started ifNil: [started := self. v] ifNotNil: [foldBlock value: result value: v]]. ^started ifNil: [SystemExceptions.EmptyCollection signalOn: self] ifNotNil: [result] ] collectThenMin: collectBlock [ ^self collect: collectBlock thenFold: [:acc :y | acc min: y] ] min [ ^self collectThenMin: [:each | each] ] collectThenMax: collectBlock [ ^self collect: collectBlock thenFold: [:acc :y | acc max: y] ] max [ ^self collectThenMax: [:each | each] ] ] CharacterArray extend [ max: other [ ^self < other ifTrue: [other] ifFalse: [self] ] min: other [ ^self < other ifTrue: [self] ifFalse: [other] ] ]

April 21, 2018

Re: [Pharo-users] [squeak-dev] min:max:

by Richard O'Keefe

I looked hard at #min:max: some years ago and decided it was way too confusing to ever use. My own library has Magnitude>> median: lower and: upper "I considered adding a method clampedBetween: lower and: upper ^self < lower ifTrue: [lower] ifFalse: [ upper < self ifTrue: [upper] ifFalse: [self]] This sends #< once or twice. The only snag is that it doesn't make much sense unless lower <= upper, and it doesn't check that. Squeak has a method min: min max: max ^(self min: min) max: max which could be simplified to min: min max: max |t| t := min < self ifTrue: [min] ifFalse: [self]. ^max < t ifTrue: [max] ifFalse: [t] The name here is a little confusing. min: x max: y is pretty much the same as clampedBetween: y and: x. This version always does two comparisons, but still makes little or no sense unless min >= max, which it does not check. It would be easy enough for me to add the Squeak method, but I find it far too confusing to use. I wanted a method which gave the same result as clampedBetween:and: whenever that made sense, and which took no more than two comparisons whenever clampedBetween:and: or min:max: would have made sense, but which always makes sense as long as all the arguments are comparable. The answer is simple: the median. Actually, it isn't quite the answer. If the receiver lies between lower and upper, it takes two comparisons. If not, it takes a third comparison to decide which of the two end-points to return, which seems fair enough, because if we don't _assume_ the relative order of the end-points, we have to _find out_." ^self < lower ifTrue: [ "self < lower" self < upper ifFalse: [ "upper <= self < lower" self] ifTrue: [ "self < lower, self < upper" upper < lower ifTrue: ["self < upper < lower" upper] ifFalse: ["self < lower <= upper" lower]]] ifFalse: [ "lower <= self" upper < self ifFalse: [ "lower <= self <= upper" self] ifTrue: [ "lower <= self, upper <= self" upper < lower ifTrue: ["upper < lower <= self" lower] ifFalse: ["lower <= upper <= self" upper]]] That is, (x median: y and: z) returns the middle value, whatever order x y and z are in. On 21 April 2018 at 23:41, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sat, 21 Apr 2018, Ben Coman wrote: >> >> On 21 April 2018 at 03:51, Hilaire <hilaire(a)drgeo.eu> wrote: >>> Hi, >>> >>> Out of curiosity. >>> >>> I always found the #min:max: confusing and lost in its >>> expressiveness. >>> >>> One should write: >>> >>> 10 min: 48 max: 12 >>> >>> to expect 12. >>> >>> but logically one (at least me) may want to express it as: >>> >>> 10 min: 12 max: 48 >>> >>> Then when reading its source code, it is even more confusing: >>> >>> min: aMin max: aMax >>> ^ (self min: aMin) max: aMax >>> >>> Are not the argument names inversed in their meaning, if any? >>> >>> >>> I would agree. I see most use by Color like... >>> >>> Color>>adjustBrightness: brightness >>> "Adjust the relative brightness of this color. (lowest value is >>> 0.005 so that hue information is not lost)" >>> >>> ^ self class >>> h: self hue >>> s: self saturation >>> v: (self brightness + brightness min: 1.0 max: 0.005) >>> alpha: self alpha >>> >>> Trying to read that twists my brain. >>> >>> >>> I can understand the intent from the implementation >>> min: aMin max: aMax >>> ^ (self min: aMin) max: aMax >>> >>> but that message might more properly be #min:thenMax: >>> However something like >>> (self brightness + brightness boundedBy: 0.005 and: 1.0) >>> (self brightness + brightness boundedMin: 0.005 max: 1.0) >>> seems more intention revealing. >>> >>> >>> Altering #min:max semantics would make awful portability, >>> but perhaps it should forward to a new method to make it clear the other >>> is preferred. >>> >>> Would the Squeak community be amenable to a similar change? >>> I'd be happy to contribute the changes to the Squeak Inbox. >>> >> > On 21 April 2018 at 17:56, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > >> Squeak has #clampLow:high: for this reason. >> >> > Thanks Levente. Thats a good one. > With similar usage clamping signals in electronics, this is worthwhile to > adopt. > > https://pharo.fogbugz.com/f/cases/21758/Replace-min-max-with-clampLow-High > > cheers -ben > >

April 21, 2018

Re: [Pharo-users] [squeak-dev] min:max:

by Ben Coman

On Sat, 21 Apr 2018, Ben Coman wrote: > > On 21 April 2018 at 03:51, Hilaire <hilaire(a)drgeo.eu> wrote: >> Hi, >> >> Out of curiosity. >> >> I always found the #min:max: confusing and lost in its >> expressiveness. >> >> One should write: >> >> 10 min: 48 max: 12 >> >> to expect 12. >> >> but logically one (at least me) may want to express it as: >> >> 10 min: 12 max: 48 >> >> Then when reading its source code, it is even more confusing: >> >> min: aMin max: aMax >> ^ (self min: aMin) max: aMax >> >> Are not the argument names inversed in their meaning, if any? >> >> >> I would agree. I see most use by Color like... >> >> Color>>adjustBrightness: brightness >> "Adjust the relative brightness of this color. (lowest value is >> 0.005 so that hue information is not lost)" >> >> ^ self class >> h: self hue >> s: self saturation >> v: (self brightness + brightness min: 1.0 max: 0.005) >> alpha: self alpha >> >> Trying to read that twists my brain. >> >> >> I can understand the intent from the implementation >> min: aMin max: aMax >> ^ (self min: aMin) max: aMax >> >> but that message might more properly be #min:thenMax: >> However something like >> (self brightness + brightness boundedBy: 0.005 and: 1.0) >> (self brightness + brightness boundedMin: 0.005 max: 1.0) >> seems more intention revealing. >> >> >> Altering #min:max semantics would make awful portability, >> but perhaps it should forward to a new method to make it clear the other >> is preferred. >> >> Would the Squeak community be amenable to a similar change? >> I'd be happy to contribute the changes to the Squeak Inbox. >> > On 21 April 2018 at 17:56, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > Squeak has #clampLow:high: for this reason. > > Thanks Levente. Thats a good one. With similar usage clamping signals in electronics, this is worthwhile to adopt. https://pharo.fogbugz.com/f/cases/21758/Replace-min-max-with-clampLow-High cheers -ben

April 21, 2018

Re: [Pharo-users] Proper way to file in code

by Sven Van Caekenberghe

> On 21 Apr 2018, at 13:18, Hilaire <hilaire(a)drgeo.eu> wrote: > > Not in my working P7 image. Is it a recent change? Yes, relatively recent, weeks I guess, maybe a month, at least since half March. FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements. BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector. > Hilaire > > > Le 21/04/2018 Ã 13:01, Sven Van Caekenberghe a Ã©crit : >> The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn: > > -- > Dr. Geo > http://drgeo.eu > > >

April 21, 2018

Re: [Pharo-users] Proper way to file in code

by Hilaire

Not in my working P7 image. Is it a recent change? Hilaire Le 21/04/2018 Ã 13:01, Sven Van Caekenberghe a Ã©critÂ : > The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn: -- Dr. Geo http://drgeo.eu

April 21, 2018

Re: [Pharo-users] Proper way to file in code

by Sven Van Caekenberghe

> On 21 Apr 2018, at 10:34, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > To use Smalltalk sketch scripts for additional unit tests, I need to file in these script files. > > I found FileStream>>fileIn: does the job. Is it the proper way to do it? The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn: > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > >

April 21, 2018

Re: [Pharo-users] min:max:

by Peter UhnÃ¡k

> > #beBetween:and: +1. Goes nicely with `(x beBetween: y and: z) between: y and: z` being always true. Peter On Sat, Apr 21, 2018 at 11:56 AM, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Looking at senders of #min:max:, I found in BitBlt>>roundNumbers the > following: > > > > destX := destX asInteger > > min: maxVal > > max: minVal. > > > > Which seems to summarize the illogicality very well. > > > > However, note that PetitParser, PetitParser2 and Magritte all implement > #min:max: as a method to set upper and lower limits, and there the meaning > is the logical one. It all looks a mess. > > > > Peter Kenny > > > > > > *From:* Pharo-users <pharo-users-bounces(a)lists.pharo.org> *On Behalf Of *Ben > Coman > *Sent:* 21 April 2018 02:16 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org>; > The general-purpose Squeak developers list <squeak-dev@lists. > squeakfoundation.org> > *Subject:* Re: [Pharo-users] min:max: > > > > > > > > On 21 April 2018 at 03:51, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > Out of curiosity. > > I always found the #min:max: confusing and lost in its expressiveness. > > One should write: > > 10 min: 48 max: 12 > > to expect 12. > > but logically one (at least me) may want to express it as: > > 10 min: 12 max: 48 > > Then when reading its source code, it is even more confusing: > > min: aMin max: aMax > ^ (self min: aMin) max: aMax > > Are not the argument names inversed in their meaning, if any? > > > > I would agree. I see most use by Color like... > > > > Color>>adjustBrightness: brightness > > "Adjust the relative brightness of this color. (lowest value is > 0.005 so that hue information is not lost)" > > > > ^ self class > > h: self hue > > s: self saturation > > v: (self brightness + brightness min: 1.0 max: 0.005) > > alpha: self alpha > > > > Trying to read that twists my brain. > > > > > > I can understand the intent from the implementation > > min: aMin max: aMax > > ^ (self min: aMin) max: aMax > > > > but that message might more properly be #min:thenMax: > > However something like > > (self brightness + brightness boundedBy: 0.005 and: 1.0) > > (self brightness + brightness boundedMin: 0.005 max: 1.0) > > seems more intention revealing. > > > > > > Altering #min:max semantics would make awful portability, > > but perhaps it should forward to a new method to make it clear the other > is preferred. > > > > Would the Squeak community be amenable to a similar change? > > I'd be happy to contribute the changes to the Squeak Inbox. > > > > cheers -ben >

April 21, 2018

Re: [Pharo-users] Time limit to execute a test

by Hilaire

Ah yes, it does it. Thanks Le 21/04/2018 Ã 11:58, Cyril Ferlicot a Ã©critÂ : > I don't have a computer to check but inside the test you should be > able to call a method as #timeLimit:. I'm not sure of the name. > -- Dr. Geo http://drgeo.eu

April 21, 2018

Re: [Pharo-users] Time limit to execute a test

by Cyril Ferlicot

On sam. 21 avr. 2018 at 11:55, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > I have a test taking more than the 10 seconds limit to execute completely. > > I tried to adjust this limit but failed to get it taken in > consideration. I tried from 3 places: > > - in the test method itself > > - in TestCase setUp > > - in a dedicated TestResources > > The adjustment seems to alway been too late, the limit is still at 10s. > > To adjust the limit I did as following, for example in a dedicated > TestResource: > > setUp > "Some recursive scripts need more time to execute completely" > defaultTimeLimitBackup := TestCase defaultTimeLimit. > TestCase defaultTimeLimit: 60 seconds. > > tearDown > TestCase defaultTimeLimit: defaultTimeLimitBackup > > From the debugger raised at the test fail, I can see the > DefaultTimeLimit is correctly set to 60s. > > If I adjust this time limit before executing test case, for example from > the settings browser, it is going fine. But I will prefer adjust it > programmatically. > > Any idea? > Hi, I don't have a computer to check but inside the test you should be able to call a method as #timeLimit:. I'm not sure of the name. Also, if you want to raise the time limit of all the tests of the class, you don't need to call #defaultTimeLimit: but you need to override #defaultTimeLimit. > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > > -- Cyril Ferlicot https://ferlicot.fr

April 21, 2018

Re: [Pharo-users] min:max:

by PBKResearch

Looking at senders of #min:max:, I found in BitBlt>>roundNumbers the following: destX := destX asInteger min: maxVal max: minVal. Which seems to summarize the illogicality very well. However, note that PetitParser, PetitParser2 and Magritte all implement #min:max: as a method to set upper and lower limits, and there the meaning is the logical one. It all looks a mess. Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Ben Coman Sent: 21 April 2018 02:16 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>; The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Subject: Re: [Pharo-users] min:max: On 21 April 2018 at 03:51, Hilaire <hilaire(a)drgeo.eu <mailto:hilaire@drgeo.eu> > wrote: Hi, Out of curiosity. I always found the #min:max: confusing and lost in its expressiveness. One should write: 10 min: 48 max: 12 to expect 12. but logically one (at least me) may want to express it as: 10 min: 12 max: 48 Then when reading its source code, it is even more confusing: min: aMin max: aMax ^ (self min: aMin) max: aMax Are not the argument names inversed in their meaning, if any? I would agree. I see most use by Color like... Color>>adjustBrightness: brightness "Adjust the relative brightness of this color. (lowest value is 0.005 so that hue information is not lost)" ^ self class h: self hue s: self saturation v: (self brightness + brightness min: 1.0 max: 0.005) alpha: self alpha Trying to read that twists my brain. I can understand the intent from the implementation min: aMin max: aMax ^ (self min: aMin) max: aMax but that message might more properly be #min:thenMax: However something like (self brightness + brightness boundedBy: 0.005 and: 1.0) (self brightness + brightness boundedMin: 0.005 max: 1.0) seems more intention revealing. Altering #min:max semantics would make awful portability, but perhaps it should forward to a new method to make it clear the other is preferred. Would the Squeak community be amenable to a similar change? I'd be happy to contribute the changes to the Squeak Inbox. cheers -ben

April 21, 2018