[Pharo-users] Migrating Seaside book to Pillar on github
Hi I decided to start to migrate the Seaside book to Pillar and make it a community-oriented book. I will work regularly on it and offer it as a gift to the community. https://github.com/SquareBracketAssociates/DynamicWebDevelopmentWithSeaside If some of you want to join the effort, you are welcome. Stef
[Pharo-users] Proper way to file in code
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? Thanks Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Proper way to file in code
I think so On Sat, Apr 21, 2018 at 10:34 AM, Hilaire 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? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > >
Re: [Pharo-users] Projects using Magritte meta models
Cool I will have a look when I go back to Magritte Rafael if you see mistake in the booklet please report them to me. I will do a pass in a couple of weeks I hope On Sat, Apr 21, 2018 at 4:07 AM, Sean P. DeNigris wrote: > Rafael Luque wrote >> I wonder if there are other relevant projects I could study to discover >> other possible >> uses cases of Magritte. > > I use it in nearly all my personal projects, almost always via Morphic, not > Seaside. Here is a public one you can have a look at: > https://github.com/seandenigris/Small-World > > Load in Pharo 6.1 via: > Metacello new > baseline: 'SmallWorld'; > repository: 'github://seandenigris/SmallWorld:master/repository'; > onConflict: [ :ex | ex allow ]; > load. > > Browse senders of magritteDescription for classes prefixed with "Small". > > > > - > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >
Re: [Pharo-users] Where do we go now ?
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 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)
>
>
>
[Pharo-users] Time limit to execute a test
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? Thanks Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Time limit to execute a test
On sam. 21 avr. 2018 at 11:55, Hilaire 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
Re: [Pharo-users] Time limit to execute a test
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
Re: [Pharo-users] Proper way to file in code
> On 21 Apr 2018, at 10:34, Hilaire 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 > > >
Re: [Pharo-users] Proper way to file in code
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
Re: [Pharo-users] Proper way to file in code
> On 21 Apr 2018, at 13:18, Hilaire 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 > > >
Re: [Pharo-users] [squeak-dev] min:max:
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 wrote: > > > On Sat, 21 Apr 2018, Ben Coman wrote: >> >> On 21 April 2018 at 03:51, Hilaire 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 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 > >
Re: [Pharo-users] #(foo bar baz) min
#('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]
]
]
Re: [Pharo-users] #(foo bar baz) min
Hi richard
do you have some tests around?
Stef
On Sat, Apr 21, 2018 at 3:07 PM, 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]
> ]
> ]
>
Re: [Pharo-users] min:max:
On Fri, Apr 20, 2018 at 9:51 PM, Hilaire 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 > > >
Re: [Pharo-users] min:max:
Oh yes On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham 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 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 >> >> >> >
Re: [Pharo-users] min:max:
> On 21 Apr 2018, at 15:35, Stephane Ducasse wrote: > > Oh yes > > On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham > 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 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 >>> >>> >>> >> >
Re: [Pharo-users] #(foo bar baz) min
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]
]
]
Re: [Pharo-users] min:max:
Yes :) On Sat, Apr 21, 2018 at 4:21 PM, Sven Van Caekenberghe wrote: > > >> On 21 Apr 2018, at 15:35, Stephane Ducasse wrote: >> >> Oh yes >> >> On Sat, Apr 21, 2018 at 12:12 AM, Chris Cunningham >> 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 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 >>> >> > >
Re: [Pharo-users] Where do we go now ?
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 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 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 Naut
Re: [Pharo-users] min:max:
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
Re: [Pharo-users] #(foo bar baz) min
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
Re: [Pharo-users] min:max:
I can find no reference to #min:max: in Dolphin X6.1. Peter Kenny -Original Message- From: Pharo-users On Behalf Of Hilaire Sent: 21 April 2018 17:36 To: pharo-users@lists.pharo.org Subject: Re: [Pharo-users] min:max: 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
Re: [Pharo-users] [ANN] Agile Artificial Intelligence: Programming Neural Networks in Pharo
abergel wrote > Feedback is very welcome. Copy edit pass on Chapters 1 & 2: https://github.com/AgileArtificialIntelligence/AgileArtificialIntelligence.github.io/pull/2 A few more observations on Chapter 2 requiring deeper investigation: - When you introduce the #assert:equals:, it would be great to show a GT debugger with the diff pane at the bottom, which gives a hint at what makes Pharo special - Capitalized temps in `#digitalComparator:`?! Sacrilege ;-) - "Grapher" is introduced as if the reader already knows what that is. Is that assumed to be the case? - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] [ANN] Agile Artificial Intelligence: Programming Neural Networks in Pharo
Thanks Sean! This is really a great review! I owe you one! Alexandre > On Apr 21, 2018, at 9:16 PM, Sean P. DeNigris wrote: > > abergel wrote >> Feedback is very welcome. > > Copy edit pass on Chapters 1 & 2: > https://github.com/AgileArtificialIntelligence/AgileArtificialIntelligence.github.io/pull/2 > > A few more observations on Chapter 2 requiring deeper investigation: > - When you introduce the #assert:equals:, it would be great to show a GT > debugger with the diff pane at the bottom, which gives a hint at what makes > Pharo special > - Capitalized temps in `#digitalComparator:`?! Sacrilege ;-) > - "Grapher" is introduced as if the reader already knows what that is. Is > that assumed to be the case? > > > > - > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >
[Pharo-users] question re. meaning of 'self' in a method used for testing
Hi—I’m a beginner in Pharo and am working my way through Pharo by Example 5.0
(PbE) and Learning OOP and TDD with Pharo (LOTWP).
I’m currently going through 7.4 Designing a test, in LOTWP, which covers
testing whether a string has no repeated characters, adding the method String
>> isIsogramSet.
GramCheckerTest, a class for testing, has the following methods:
—
isograms
"list of isograms; used for testing"
^ #('pharo' 'pathfinder' 'xavier' 'lumberjacks’)
testAllIsogramSet
"using each word in list named 'isograms'"
self isograms do: [ :word | self assert: word isIsogramSet ]
—
Here are my questions:
1) These two methods are defined on the instance side (the Class button is
*not* selected). If so, what is the receiver when they are used?
2) In testAllIsogramSet, why do you need ‘self’? After all ‘isograms’ is a data
structure, and its message is ‘do:’
3) As an add-on to 2), what does ‘self’ refer to? The class GramCheckerTest? If
so, wouldn’t that make testAllIsogramSet a class method? But testAllIsogramSet
doesn’t appear in the class browser when I click the Class button when the
Class pane shows GramCheckerTest.
Thanks for any help you might give/point me to regarding this.
Re: [Pharo-users] Where do we go now ?
--- Begin Message --- >What I find sad is that people spent hours talking instead of doing. >This is why Smalltalk is for them. >Personally I prefer Pharo. Well, I guess I don't belong here anymore since "Pharo is NOT Smalltalk" as you keep saying! And since I've been a Smalltalker for only 25+ years, I guess Smalltalk is really for me as you wrote! Every Smalltalker is a moron as you so often imply (especially in private emails incidentally): only Pharoers "do it right"... So I'll go back to that moronic programming language! P.S. I'll let you handle the questions in #pharo on IRC as I'll no longer be on the channel : you'll see, it'll be really instructive for you! People there have those weird practical problems, it's crazy! - Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)--- End Message ---
Re: [Pharo-users] question re. meaning of 'self' in a method used for testing
On 04/21/2018 08:25 PM, Gregg Williams wrote:
> Hi—I’m a beginner in Pharo
Hi Gregg, welcome!
> and am working my way through Pharo by Example 5.0 (PbE) and Learning OOP and
> TDD with Pharo (LOTWP).
>
> I’m currently going through 7.4 Designing a test, in LOTWP, which covers
> testing whether a string has no repeated characters, adding the method String
> >> isIsogramSet.
>
> GramCheckerTest, a class for testing, has the following methods:
>
> —
> isograms
> "list of isograms; used for testing"
>
> ^ #('pharo' 'pathfinder' 'xavier' 'lumberjacks’)
>
>
> testAllIsogramSet
> "using each word in list named 'isograms'"
>
> self isograms do: [ :word | self assert: word isIsogramSet ]
> —
>
> Here are my questions:
>
> 1) These two methods are defined on the instance side (the Class button is
> *not* selected). If so, what is the receiver when they are used?
The receiver is an instance of the test class, which is most likely a
subclass of TestCase.
>
> 2) In testAllIsogramSet, why do you need ‘self’? After all ‘isograms’ is a
> data structure, and its message is ‘do:’
"isograms" is not, strictly speaking, the name of a data structure. It's
the name (formally, "selector") of a message. The method for responding
to that message is defined by the source code you list above. That
method answers an object of class Array. So in order to get a reference
to that array in the actual test case method, it has to send the message
#isograms (the # indicates a Symbol -- all message selectors are
Symbols), to self. Since the class of the receiver understands messages
with that selector, it evaluates the method, and the method answers the
reference to the Array.
>
> 3) As an add-on to 2), what does ‘self’ refer to? The class GramCheckerTest?
> If so, wouldn’t that make testAllIsogramSet a class method? But
> testAllIsogramSet doesn’t appear in the class browser when I click the Class
> button when the Class pane shows GramCheckerTest.
When these methods are evaluated, self will be bound to the receiver.
The receiver will be an instance of GramCheckerTest. (or possibly a
subclass of GramCheckerTest, if any subclasses exist -- they would
inherit the method unless overridden.) The test framework creates an
instance of the test class to actually run the test. Let's take a look
at the code involved.
One way to run your test would be to evaluate
GramCheckerTest run: #testAllIsogramSet.
GramCheckerTest most likely inherits the method for #run: from TestCase,
and you can see it on the class side of TestCase. It looks like this:
run: aSymbol
"Execute a testcase name, aSymbol, and return a test result."
^(self selector: aSymbol) run
So it sends the message #selector: to self. Note a potentially confusing
point here -- #selector: is a selector. Kind of like if my name were
"Name." Self here is the class GramCheckerTest. As long as
GramCheckerTest doesn't define its own version of #selector:, it
inherits that method from TestCase (class side, still), and that method
looks like this:
selector: aSymbol
"Return a test case with aSymbol as selector but does not execute it."
^self new setTestSelector: aSymbol
This sends #new to self. Self is, once again, the class GramCheckerTest.
A class responds to the message #new by creating a new instance of
itself. So now you've got an *instance* of GramCheckerTest, and any
messages you send to that will be responded to by methods on the
instance side.
Well, I would not be surprised if this explanation has confused you, but
I hope it's enlightened you a bit as well. Please ask more questions
until you understand what's going on here -- if you understand this you
will be well positioned to understand the entire language.
Regards,
-Martin
