May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Inconsistent number comparison?

by Nicolas Cellier

2015-05-27 14:24 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Nicolas Cellier wrote > > Also because it's good to know that 1/10 ~= 0.1 > > Why? It's an implementation detail. #= unlike #== is IIUC supposed to be > logical to the domain, and math doesn't make any distinction about how bits > are stored ;) > > > Nope, it's more than a detail. It's what every engineer should know about floating point. If you think float == real number then you'll be screwed by many unexpected behavior, like why 0.1+0.1+0.1 ~= 0.3 etc... So you have to somehow unlearn what you were teached in math, because it's simply not true with float. And the faster you get this feedback, the better. > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Inconsistent-number-comparison-tp4828795p4828892.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 27, 2015

Re: [Pharo-dev] translateBy: vs translatedBy:

by Ben Coman

On Wed, May 27, 2015 at 8:51 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > There is a discussion of such idioms in the I will present at ESUG. I only > looked at the API of String, but I'm sure most naming idioms apply to any > class. The question is, how do you ensure they are applied and complete? Hard to be perfect but maybe... Extract pairs of past participle (p.p.)[1] and transitive verb (v.t.) [1] from a dictionary like [2], e.g. Merged (imp. & p.p.) of Merge Merge (v.t.) to absorb. and if the method... A. returns same object -- check its method name is (v.t.) form B. returns different object of same species -- check form is (p.p.) C. returns different type of object -- ignore. Actually maybe coverage doesn't need to be perfect. There just needs to be enough consistency that the convention can relied on (and publicised!), and humans can update rules for edges cases as they are arise. cheers -ben [1] http://en.wiktionary.org/wiki/Wiktionary:Abbreviations_in_Webster [2] http://www.mso.anu.edu.au/~ralph/OPTED/v003/wb1913_m.html [3] http://www.mso.anu.edu.au/~ralph/OPTED/ > > On 27 May 2015 at 01:14, Ben Coman <btc(a)openinworld.com> wrote: >> >> > >> > On Tue, May 26, 2015 at 6:14 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Tue, May 26, 2015 at 9:38 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> >> I vote for renaming to Rectangle>>translatedBy:, because it returns >> >> >> a >> >> >> new >> >> >> translated rectangle instance. >> >> > >> >> > >> >> > -1 >> >> > There is no benefit in renaming a single method, apart from creating >> >> > more >> >> > confusion. >> >> >> >> I wouldn't say "no benefit". Consistent conventions are beneficial. >> >> It could be useful to bring these into line with the general "-ed" >> >> convention of returning a new object. I don't see how this would >> >> create confusion, though it might create work. Whether its worth the >> >> work is a slightly different question. >> >> >> >> > If anything, the whole Rectangle API would have to be changed, as >> >> > there >> >> > is >> >> > plethora of similar methods (expandBy:, extendBy:, merge:, etc.) >> >> >> >> For a better feel of the work involved... >> >> >> >> Rectangle methods select: [ :m | m sourceCode includesSubstring: '^ >> >> Rectangle ' ]. >> >> Rectangle>>#intersect: >> >> Rectangle>>#quickMerge: >> >> Rectangle>>#encompass: >> >> Rectangle>>#intersect:ifNone: >> >> >> >> Rectangle methods select: [ :m | m sourceCode includesSubstring: >> >> '^Rectangle ' ]. >> >> Rectangle>>#intersect: >> >> Rectangle>>#translateBy: >> >> Rectangle>>#scaleBy: >> >> Rectangle>>#merge: >> >> Rectangle>>#compressTo: >> >> Rectangle>>#expandTo: >> >> Rectangle>>#roundTo: >> >> Rectangle>>#truncateTo: >> >> >> >> The following already follow the convention... >> >> Rectangle>>#compressed >> >> Rectangle>>#expanded >> >> Rectangle>>#rounded >> >> Rectangle>>#truncated >> >> >> >> > Pretty much all Rectangle messages are immutable and create new >> >> > Rectangle, >> >> > thus I feel it is unnecessary to state it explicitly. >> >> > >> >> > In VW there is plenty of methods (e.g. left:) that mutates it, thus >> >> > unlike >> >> > Pharo a clear distinction is required. >> >> >> >> Still, it is reasonable to consider the impact of inconsistent >> >> conventions on the rest of the system outside of Rectangle. >> >> >> >> cheers -ben >> >> >> > >> >> >> On Wed, May 27, 2015 at 1:16 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > That's not all, many methods return new rectangles via Point's API, >> > namely >> > Point>>{#corner: #extent: #rectangle:} >> > >> > I don't know if I can perform static analysis of the code (are there >> > tools >> > for that in Pharo?) to see which methods exactly return Rectangle >> > >> > rectMethods := #(#corner: #extent: #rectangle:). >> > (Point methods select: [ :m | rectMethods includes: m selector ] >> > thenCollect: [ :m | m senders ]) flattened select: [ :s | s className = >> > #Rectangle ]. "an Array( >> > Rectangle>>#areasOutside: >> > Rectangle>>#withSideOrCorner:setToPoint:minExtent:limit: >> > Rectangle>>#withBottom: >> > Rectangle>>#bottom: >> > Rectangle>>#areasOverlapingOutside: >> > Rectangle>>#floor >> > Rectangle>>#allAreasOutsideList:startingAt:do: >> > Rectangle>>#scaledAndCenteredIn: >> > Rectangle>>#squishedWithin: >> > Rectangle>>#ceiling >> > Rectangle>>#withHeight: >> > Rectangle>>#rectanglesAt:height: >> > Rectangle>>#scaleFrom:to: >> > Rectangle>>#withLeft: >> > Rectangle>>#left: >> > Rectangle>>#withTop: >> > Rectangle>>#right: >> > Rectangle>>#top: >> > Rectangle>>#innerCorners >> > Rectangle>>#interpolateTo:at: >> > Rectangle>>#withWidth: >> > Rectangle>>#quickMergePoint: >> > Rectangle>>#withRight: >> > Rectangle>>#rotateBy:centerAt: >> > Rectangle>>#withSideOrCorner:setToPoint:minExtent:limit: >> > Rectangle>>#flipBy:centerAt:) >> > " >> > >> > This list is maybe a bit excessive (sometimes it returns self, sometimes >> > new >> > rectangle -- e.g. floor). >> > >> >> Good Point ;) >> >> However the "-ed" convention doesn't make sense for many of those... >> #areasdOutside: , #areasedOutside , #areaOutsided: ? >> ... and #areasOutside is obviously a different rectangle than the >> original. >> >> The scope might be restricted to only those where the usual convention >> makes the names misleading, for example: >> #merge >> >> cheers -ben >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

May 27, 2015

[Request]: Review Issue 15399: SmalltalkImage: Thin Proliferation of File Access Messages

by Sean P. DeNigris

https://pharo.fogbugz.com/default.asp?15399 Fix in inbox: SLICE-Issue-15399-SmalltalkImage-Thin-Proliferation-of-File-Access-Messages-SeanDeNigris.2 ### Motivation There was a proliferation of methods in SmalltalkImage for accessing files like sources, changes, and image. The problems were twofold: 1. The interface was complicated with the only benefit being saving a few characters of typing - not worth it! In particular, #vmDirectory instead of "vm directory" seems particularly not-worth-it. 2. It was encouraging strange code, like in ScriptLoader, where the name was taken, and because we were dealing with strings instead of real file objects, #basenameWithoutIndicator was reimplemented `Smalltalk shortImageName copyUpToLast: $.`. And then CodeHolder `sourcesName := Smalltalk sourcesName asFileReference basename.` was using it to reconstruct a real file object which could easily have been gotten via #imageFile. ### Changes #### This version - Deprecate #changesName, #shortImageName, #sourcesName, #vmBinary, and #vmDirectory. Saving a few characters of typing is not worth the complication of interface. - Move all deprecated methods into Deprecated50 package - Update all users - clean up inconsistently named protocols - [OT]: Enhance #basenameWithoutExtension comment #### v. 1 - deprecated SmalltalkImage>>imageName - removed duplicated primitive - changed wrong comment ----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-Review-Issue-15399-SmalltalkImage-Thin-Prolif… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 27, 2015

Re: [Pharo-dev] Parser missing something

by Nicolai Hess

2015-05-27 16:27 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > 50069 > > When the cursor is between the parenthesis, > I get a MNU RBParseErrorNode>>addParenthesis: > when typing anything > > drawOn: aCanvas > |lines| > super drawOn: aCanvas. > lines := segments size - 1. > 1 to: lines do: [:index | |x| > x :=self extent x + ( ) > aCanvas line: self extent x+ (index* to: color: self > defaultBorderColor > > > > Yes, there is already an issue reported 15609 <https://pharo.fogbugz.com/default.asp?15609> dnu RBParserErrorNode addParenthesis

May 27, 2015

Parser missing something

by Stephan Eggermont

50069 When the cursor is between the parenthesis, I get a MNU RBParseErrorNode>>addParenthesis: when typing anything drawOn: aCanvas |lines| super drawOn: aCanvas. lines := segments size - 1. 1 to: lines do: [:index | |x| x :=self extent x + ( ) aCanvas line: self extent x+ (index* to: color: self defaultBorderColor

May 27, 2015

Re: [Pharo-dev] Cross platform key modifiers

by Serge Stinckwich

On Wed, May 27, 2015 at 3:56 PM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > >> I guess we should have a look how Emacs solve this keybinding issue >> regarding multiple platforms. > > Emacs works really well in this regard and should be used as a > reference. If you have any specific question, I can have a look. :-) -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 27, 2015

Re: [Pharo-dev] Cross platform key modifiers

by Damien Cassou

Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > I guess we should have a look how Emacs solve this keybinding issue > regarding multiple platforms. Emacs works really well in this regard and should be used as a reference. If you have any specific question, I can have a look. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

May 27, 2015

Re: [Pharo-dev] Incorrect Class Variable Highlighting?

by Nicolai Hess

2015-05-27 15:22 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Looks like a bug... Shall I open an issue? > <http://forum.world.st/file/n4828900/Screenshot_2015-05-27_09.png> > It is a know issue 15573 <https://pharo.fogbugz.com/default.asp?15573> AST Syntax highlight: Class Vars are coloured wrong > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Incorrect-Class-Variable-Highlighting-tp4828900.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 27, 2015

Incorrect Class Variable Highlighting?

by Sean P. DeNigris

Looks like a bug... Shall I open an issue? <http://forum.world.st/file/n4828900/Screenshot_2015-05-27_09.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/Incorrect-Class-Variable-Highlighting-tp4828900.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 27, 2015

Re: [Pharo-dev] translateBy: vs translatedBy:

by Damien Pollet

There is a discussion of such idioms in the I will present at ESUG. I only looked at the API of String, but I'm sure most naming idioms apply to any class. The question is, how do you ensure they are applied and complete? On 27 May 2015 at 01:14, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Tue, May 26, 2015 at 6:14 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> On Tue, May 26, 2015 at 9:38 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> >> I vote for renaming to Rectangle>>translatedBy:, because it returns a > >> >> new > >> >> translated rectangle instance. > >> > > >> > > >> > -1 > >> > There is no benefit in renaming a single method, apart from creating > >> > more > >> > confusion. > >> > >> I wouldn't say "no benefit". Consistent conventions are beneficial. > >> It could be useful to bring these into line with the general "-ed" > >> convention of returning a new object. I don't see how this would > >> create confusion, though it might create work. Whether its worth the > >> work is a slightly different question. > >> > >> > If anything, the whole Rectangle API would have to be changed, as > there > >> > is > >> > plethora of similar methods (expandBy:, extendBy:, merge:, etc.) > >> > >> For a better feel of the work involved... > >> > >> Rectangle methods select: [ :m | m sourceCode includesSubstring: '^ > >> Rectangle ' ]. > >> Rectangle>>#intersect: > >> Rectangle>>#quickMerge: > >> Rectangle>>#encompass: > >> Rectangle>>#intersect:ifNone: > >> > >> Rectangle methods select: [ :m | m sourceCode includesSubstring: > >> '^Rectangle ' ]. > >> Rectangle>>#intersect: > >> Rectangle>>#translateBy: > >> Rectangle>>#scaleBy: > >> Rectangle>>#merge: > >> Rectangle>>#compressTo: > >> Rectangle>>#expandTo: > >> Rectangle>>#roundTo: > >> Rectangle>>#truncateTo: > >> > >> The following already follow the convention... > >> Rectangle>>#compressed > >> Rectangle>>#expanded > >> Rectangle>>#rounded > >> Rectangle>>#truncated > >> > >> > Pretty much all Rectangle messages are immutable and create new > >> > Rectangle, > >> > thus I feel it is unnecessary to state it explicitly. > >> > > >> > In VW there is plenty of methods (e.g. left:) that mutates it, thus > >> > unlike > >> > Pharo a clear distinction is required. > >> > >> Still, it is reasonable to consider the impact of inconsistent > >> conventions on the rest of the system outside of Rectangle. > >> > >> cheers -ben > >> > > > > > On Wed, May 27, 2015 at 1:16 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > That's not all, many methods return new rectangles via Point's API, > namely > > Point>>{#corner: #extent: #rectangle:} > > > > I don't know if I can perform static analysis of the code (are there > tools > > for that in Pharo?) to see which methods exactly return Rectangle > > > > rectMethods := #(#corner: #extent: #rectangle:). > > (Point methods select: [ :m | rectMethods includes: m selector ] > > thenCollect: [ :m | m senders ]) flattened select: [ :s | s className = > > #Rectangle ]. "an Array( > > Rectangle>>#areasOutside: > > Rectangle>>#withSideOrCorner:setToPoint:minExtent:limit: > > Rectangle>>#withBottom: > > Rectangle>>#bottom: > > Rectangle>>#areasOverlapingOutside: > > Rectangle>>#floor > > Rectangle>>#allAreasOutsideList:startingAt:do: > > Rectangle>>#scaledAndCenteredIn: > > Rectangle>>#squishedWithin: > > Rectangle>>#ceiling > > Rectangle>>#withHeight: > > Rectangle>>#rectanglesAt:height: > > Rectangle>>#scaleFrom:to: > > Rectangle>>#withLeft: > > Rectangle>>#left: > > Rectangle>>#withTop: > > Rectangle>>#right: > > Rectangle>>#top: > > Rectangle>>#innerCorners > > Rectangle>>#interpolateTo:at: > > Rectangle>>#withWidth: > > Rectangle>>#quickMergePoint: > > Rectangle>>#withRight: > > Rectangle>>#rotateBy:centerAt: > > Rectangle>>#withSideOrCorner:setToPoint:minExtent:limit: > > Rectangle>>#flipBy:centerAt:) > > " > > > > This list is maybe a bit excessive (sometimes it returns self, sometimes > new > > rectangle -- e.g. floor). > > > > Good Point ;) > > However the "-ed" convention doesn't make sense for many of those... > #areasdOutside: , #areasedOutside , #areaOutsided: ? > ... and #areasOutside is obviously a different rectangle than the original. > > The scope might be restricted to only those where the usual convention > makes the names misleading, for example: > #merge > > cheers -ben > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 27, 2015