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

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

by Sean P. DeNigris

Herby VojÄÃk wrote > â¦ detectMin: [ :x | x ] Or `detectMin: #yourself` if you prefer ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 21, 2018

Re: [Pharo-users] min:max:

by Hilaire

The #min:max: message is present in the Squeak/Pharo/Cuis familly but not in GNU Smalltalk for example. No idea about the other ones. Le 21/04/2018 Ã 00:12, Chris Cunningham a Ã©critÂ : > A name like this would be clearer (although much more annoying): > > returnAtLeast: minValue butNoMoreThan: maxValue > Â Â 10 returnAtLeast: 12 butNoMoreThan: 48 > -- Dr. Geo http://drgeo.eu

April 21, 2018

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

by Hilaire

But these two does not return the same result. I don't think the message #min:max: in its self is confusing but more on the its arguments meaning. If implemented as: min: min max: max Â Â Â ^ (self min: max) max: min One could have meaningful message with arguments: 33 min: 12 max: 48. "33" 113 min: 12 max: 48. "48" 1 min: 12 max: 48. "12" For me it will be just fine. There are not so many users of this message. Oh by the way, in P7 there is TComparable traits with this message but Magnitude class is not a user. Hilaire Le 21/04/2018 Ã 13:55, Richard O'Keefe a Ã©critÂ : > 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] -- Dr. Geo http://drgeo.eu

April 21, 2018

Re: [Pharo-users] Where do we go now ?

by Stephane Ducasse

What I find sad is that people spent hours talking instead of doing. This is why Smalltalk is for them. Personally I prefer Pharo. Let me migrate another Seaside chapter so that people can complain after all. Stef On Sat, Apr 21, 2018 at 11:48 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > How a project is named is a choice of the author. Nobody gets to demand how > someone should name their projects. > > Now how project is actually named is not a issue if it is properly handled > on pharo side, which in some places is, in some places isn't. > >> For instance, there's a gazillion UI frameworks out there and, most of the >> time, the name used for them is one of a famous painter. > > > We have Magritte, which is a meta-data description framework, not UI > framework. :) > >> How many Pharo *users* (not regular contributors!) know what those >> tools/frameworks/packages do ??? > > > Probably not many, because they never encounter them, nor care about whether > they exist or not. > >> A very quick look at what's in Pharo 7 shows the following names : >> Iceberg, Ombu, Calypso, Flashback, Nautilus, Renraku, Zodiac, Shift, Zinc, >> Hermes, Beacon, Cargo, Hermes, Opal, Shoreline, Epicea, Balloon, BlueInk, >> Commander, Fuel, Glamorous, Glamour, Gofer, Hiedra, Metacello, Moose, Ring, >> Rubric, Shout, Spec, etc... > > > Calypso + Nautilus: as a user you don't get to encounter the names, there's > only "System Browser" > Did you know that there are other code browsers you can install? (e.g. Code > Panels, Alt Browser, ...) > > Iceberg: as someone pointed out, this would be nice to have a "(Git) > Versionner" or whatever entry instead > > Metacello: npm => "Package manager 1", pip => "Package manager 2", ... > > Ombu/Epicea: you access it via "Code Changes", names are hidden from the > user > > Flashback, Renraku, Hermes, Opal, Shoreline, BlueInk, Hiedra, Ring, Rubric, > Shout, Glamorous, Glamour: not something a regular user ever encounters > directly, and if they need to, the unique name helps a lot in finding > information/docs about it > > Moose: are you serious? should Pharo be called "Programming Language 28301" > too? > > Commander: Commander is a library to implement commands. You literally > cannot have a more descriptive name and yet you still complain. > > Spec: ... maybe we can rename > * Morphic "UI 1" > * Baloon "UI -1" > * Spec "UI 2" > * Rubric "UI 3" > * Tx "UI A" > * Bloc "UI ×" > * Athens "UI Îµ" > * Cairo "UI Ð©" > * Sparta "UI ã" > > and then try to find any information about anything. > >> Was it really that hard to replace the old workspace with Workspace2 or >> WhateverWorkspace ? Or even better : get rid of the old Workspace and >> replace it with Playground while retaining the name "Workspace" ??? > > > Well I could claim that "Workspace" is a very confusing name, because it is > not actually workspace, just a trivial Text Box. If anything, Playground is > a much more fitting name. > >> Or somethings as simple as Regex, the regex package from Bykov. > > > Which variant of regular expressions though? > >> Unless we *clearly* publicize/describe what those names are, there's no >> way in a thousand years you could tell that BlueInk is not a package dealing >> with fonts (that was my first guess) ! > > > I fully agree with this, and as I've mentioned (here, or maybe in another > thread), this has improved greatly with move to GitHub, as people finally > started to care about describing their projects. But the transition takes > time. Btw BlueInk is a "pretty printer", so the name isn't really misleading > once you know what it is. But being "clever" with names is sure way to get > it misinterpreted. (E.g. "grafoscopio" which has nothing to do with graphs > or visualizations, as it is text/nodes/code snippets organization tool.) > > (For the record I tend to name projects with the most boring name I can come > up with (tonel-migration, IconFactory, file-dialog, xml-magritte-generator, > uml-xmi, ...), but it only works if there's only one such thing... if there > are competing projects, than sharing the name doesn't help anyone.) > > Peter > > On Sat, Apr 21, 2018 at 1:34 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >> On Fri, Apr 20, 2018 at 07:08:29AM -0700, Sean P. DeNigris wrote: >> > Stephane Ducasse-3 wrote >> > > I like when developers are talking about names: >> > > They use a mac and not a computer, they were nike, lewis and not shoes >> > > and pants.... >> > > So guys can we focus our energy on positive things. >> > >> > IHMO this is certainly a positive subject because it highlights the >> > as-yet-to-be-resolved tension regarding understandability of the system >> > between having a unique name (good for googling, distinguishing between >> > versions) and a name that reveals what the project does/is for. What is >> > the >> > plan to resolve this because it is a real problem? >> > >> > Nike and Levis are designed to stand on their own in front of the >> > consumer >> > market. Is this true of Nautilus, Calypso, or Epicea? >> >> Sean, >> >> Thank you for this clarification! I read Stef's message this morning >> and I honestly thought that my name ("lewis") might have something to >> do with pants. That probably would not be a good thing. But now I see >> that we are talking about "levis" so I feel much better now :-) >> >> Dave (Lewis, not Levis) >> >> >

April 21, 2018

Re: [Pharo-users] min:max:

by Stephane Ducasse

Yes :) On Sat, Apr 21, 2018 at 4:21 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 21 Apr 2018, at 15:35, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Oh yes!!!! >> >> On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham >> <cunningham.cb(a)gmail.com> wrote: >>> A name like this would be clearer (although much more annoying): >>> >>> returnAtLeast: minValue butNoMoreThan: maxValue >>> 10 returnAtLeast: 12 butNoMoreThan: 48 > > why 'return' ? most methods return something. > > 10 atLeast: 12 butNoMoreThan: 48 > >>> Thanks, >>> cbc >>> >>> On Fri, Apr 20, 2018 at 12:51 PM, 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? >>>> >>>> Hilaire >>>> >>>> -- >>>> Dr. Geo >>>> http://drgeo.eu >>>> >>>> >>>> >>> >> > >

April 21, 2018

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

by Herbert VojÄÃk

Note: no need for #collect:thenFold: family, one can implement min as min ^ self detectMin: [ :x | x ] if you want to reuse existing one. But actually, the issue is, min: and max: are not there (correctly) for strings. Herby Richard O'Keefe wrote: > #('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] min:max:

by Sven Van Caekenberghe

> On 21 Apr 2018, at 15:35, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Oh yes!!!! > > On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham > <cunningham.cb(a)gmail.com> wrote: >> A name like this would be clearer (although much more annoying): >> >> returnAtLeast: minValue butNoMoreThan: maxValue >> 10 returnAtLeast: 12 butNoMoreThan: 48 why 'return' ? most methods return something. 10 atLeast: 12 butNoMoreThan: 48 >> Thanks, >> cbc >> >> On Fri, Apr 20, 2018 at 12:51 PM, 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? >>> >>> Hilaire >>> >>> -- >>> Dr. Geo >>> http://drgeo.eu >>> >>> >>> >> >

April 21, 2018

Re: [Pharo-users] min:max:

by Stephane Ducasse

Oh yes!!!! On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > A name like this would be clearer (although much more annoying): > > returnAtLeast: minValue butNoMoreThan: maxValue > 10 returnAtLeast: 12 butNoMoreThan: 48 > > Thanks, > cbc > > On Fri, Apr 20, 2018 at 12:51 PM, 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? >> >> Hilaire >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >

April 21, 2018

Re: [Pharo-users] min:max:

by Stephane Ducasse

On Fri, Apr 20, 2018 at 9:51 PM, 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 I do not understand the result :) To me this method is illnamed. > > 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? > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > >

April 21, 2018

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

by Stephane Ducasse

Hi richard do you have some tests around? Stef On Sat, Apr 21, 2018 at 3:07 PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > #('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