November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] float & fraction equality bug

by Sven Van Caekenberghe

Doru, 1/10 cannot be represented as Float without loss of precision. So even though (1/10) asFloat gives you 0.1, the reverse is not possible. Floating point is a binary (as in base 2 representation), not a decimal (base 10) representation. Consider (1/8) asFloat asTrueFraction. which is reversible. x := 0.125. y := (1/8). x = y ifFalse: [ 1 / (x - y) ]. You can see that a bit in the binary representation view: Sven > On 9 Nov 2017, at 15:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I just stumbled across this bug related to the equality between fraction and float: > https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-P… > > In essence, the problem can be seen that by doing this, you get a ZeroDivide: > x := 0.1. > y := (1/10). > x = y ifFalse: [ 1 / (x - y) ] > > The issue seems to come from the Float being turned to a Fraction, rather than the Fraction being turned into a Float: > > Fraction(Number)>>adaptToFloat: rcvr andCompare: selector > "If I am involved in comparison with a Float, convert rcvr to a > Fraction. This way, no bit is lost and comparison is exact." > > rcvr isFinite > ifFalse: [ > selector == #= ifTrue: [^false]. > selector == #~= ifTrue: [^true]. > rcvr isNaN ifTrue: [^ false]. > (selector = #< or: [selector = #'<=']) > ifTrue: [^ rcvr positive not]. > (selector = #> or: [selector = #'>=']) > ifTrue: [^ rcvr positive]. > ^self error: 'unknow comparison selector']. > > ^ rcvr asTrueFraction perform: selector with: self > > Even if the comment says that the comparison is exact, to me this is a bug because it seems to fail doing that. What do you think? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > >

Nov. 9, 2017

Re: [Pharo-dev] float & fraction equality bug

by Martin McClure

On 11/09/2017 06:15 AM, Tudor Girba wrote: > Hi, > > I just stumbled across this bug related to the equality between > fraction and float: > https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-P… > > In essence, the problem can be seen that by doing this, you get a > ZeroDivide: > xÂ :=Â 0.1. > y :=Â (1/10). > x =Â y ifFalse:Â [Â 1Â /Â (xÂ -Â y)Â ] > > The issue seems to come from the Float being turned to a Fraction, > rather than the Fraction being turned into a Float: > > Fraction(Number)>>adaptToFloat: rcvr andCompare: selector > "If I am involved in comparison with a Float, convert rcvr to a > Fraction. This way, no bit is lost and comparison is exact." > > rcvr isFinite > ifFalse: [ > selector == #= ifTrue: [^false]. > selector == #~= ifTrue: [^true]. > rcvr isNaN ifTrue: [^ false]. > (selector = #< or: [selector = #'<=']) > ifTrue: [^ rcvr positive not]. > (selector = #> or: [selector = #'>=']) > ifTrue: [^ rcvr positive]. > ^self error: 'unknow comparison selector']. > > ^ *rcvr asTrueFraction perform: selector with: self* > > Even if the comment says that the comparison is exact, to me this is a > bug because it seems to fail doing that. What do you think? I think exact comparison is the best thing to do here (even though ANSI says otherwise). And an exact comparison will answer false, because there is no float that is exactly equal to 1/10 -- it is an infinitely repeating decimal in binary. For consistency, though, it might be better to compute x - y by converting the Float to a Fraction rather than the other way around (though this would also contravene ANSI) since Fraction is the more general format (every Float can be represented exactly as a Fraction, but the reverse is not true). Regards, -Martin

Nov. 9, 2017

Re: [Pharo-dev] You can cheat in FFI as long as you don't get caught...

by Nicolas Cellier

2017-11-09 12:24 GMT+01:00 Igor Stasenko <siguctua(a)gmail.com>: > > On 9 November 2017 at 12:03, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> yeah, but this is because LGitDiff, LGitRepository and LGitTree (and many >> others) are defined as FFIExternalObjects while they should be >> FFIOpaqueObjects. Then, the problem is that external objects are *already* >> pointers (they have arity 1). >> >> > hmm but the external objects were already designed with thought that it > holding some opaque handle to some external object. it does not neccessary > should be a pointer .. it could be some handle, > that doesn't points directly to some memory location (like in windows api > etc). > they only difference is only in what function(s) expecting, e.g. if it > takes a handle value - you should pass it by value (the handle itself), and > when it asks for pointer to the handle (to fill a return value , for > instance) - you passing a pointer to it. > > > Agree that should not make a difference, a handle can be anything, a pointer, an int, ... Technically, the git_tree are not opaque, they are struct. BUT we don't care at all of their layout/fields from within Pharo and want to treat them as Opaque. - First reason: declaring fields would make the Pharo code fragile versus future evolution of libgit2 because any change in the layout would create a dangerous mismatch. - Second reason: we never have to allocate space for those struct, the library cares for us. - Third reason: libgit2 APi will never deal with a git_tree, only git_tree* or git_tree** So I think that you made a good choice to use a sort-of-handle (git_tree*). I am now certain that it was the exact intention of FFIExternalObject Maybe we could rename superclass to FFIExternalObjectPointer to make explicit that it adds a pointer arity? We must also provide examples in class comment (or link to a Help page...) Example: I have an external object bar from library foo (a foo_bar). C signature: void foo_create_bar(foo_bar **bar); FFIExternalObjectPointer subclass: FooBar. a Smalltalk FooBar now represents a pointer to a foo_bar (a foo_bar *). And the library will be invoked with: self call: #(void foo_create_bar(FooBar *self)) If the library function return a pointer to a foo_bar C signature: foo_bar *foo_bar_alloc(size_t size); then we interface it like that: handle pointerAt: 1 put: (self call: #(FooBar foo_bar_alloc( size_t size))). Note that the handle has one more indirection (it is equivalent to a foo_bar**) And when wanting to use a the foo_bar: C signature: void foo_use_bar(foo_bar *bar); self call: #(void foo_use_bar(FooBar self)). Still it's not obvious to distinguish why LGitTree has different pointer arity than LGitDiffOption at first sight... Naming them LGitTreeHandle or LGitTreePointer is maybe too much? this are remaining of old nativeboost and we created the opaque objects to >> not need this âcheatingââ¦ just, I wanted to change them but is a lot of >> work and I didnât have the time. >> >> I agree it stinks. >> >> Esteban >> >> On 8 Nov 2017, at 19:06, Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com> wrote: >> >> I was trying to inquire about my latest vm crash in libgit2 >> >> https://pharo.fogbugz.com/f/cases/20655/vm-crash-in-libgit- >> git_tree_free-throw-suspiscion-on-potential-double-free-problem >> >> when I found this bizarre prototype: >> >> ^ self >> callUnchecked: >> #(LGitReturnCodeEnum git_diff_tree_to_tree #(LGitDiff * diff >> , LGitRepository repo , LGitTree old_tree , LGitTree new_tree , >> LGitDiffOptions * opts)) >> options: #() >> >> While the libgit2 signature differs in indirection levels: >> https://libgit2.github.com/libgit2/#v0.19.0/group/diff/git_ >> diff_tree_to_tree >> >> int git_diff_tree_to_tree(git_diff_list **diff, git_repository *repo, >> git_tree *old_tree, git_tree *new_tree, const git_diff_options *opts); >> >> The fact that it does not differs for opts, made me think of a bug... >> But no. >> >> opts is allocated on external c heap with: >> >> callUnchecked: #(LGitReturnCodeEnum git_diff_init_options(LGitDiffOptions >> * self, LGitOptionsVersionsEnum version)) >> >> int git_diff_init_options(git_diff_options *opts, unsigned int version); >> >> What you see this time is that signatures match... >> So the LGitDiffOptions handle will be an ExternalAddress that will really >> point on a git_diff_options >> In other words, the handle is a git_diff_options *... >> IOW, our LGitDiffOptions object points to an external it_diff_options so >> it is what it promises to be. >> >> For the other structures not so. >> We are lying on the level of indirection, so our LGitTree handle are not >> really a git_tree *. They are a git_tree **. (an ExternalAddress on a >> pointer). >> >> As long as we lie consistently, it's OK, because it avoids too much >> packToArity: unpackToArity: dance. >> >> That's the "beauty" of C pointers. >> We can cast them to whatever or pretend they are handle_for_anything * in >> the intermediate level, as long as original producer and final consumer >> agree on what it really points to. >> >> But from code quality perspective, it really stinks. Anyone like me >> opening a page to get the exact signature of the function will be >> scratching head and loose precious time. Especially when tracking vm crash >> down. >> >> I'm not sure how well it's documented, I presume it's a well known >> conscious hack from the original developpers, but such practice really >> ought to be discussed here. >> >> >> >> >> > > > -- > Best regards, > Igor Stasenko. >

Nov. 9, 2017

Re: [Pharo-dev] about SortFunctions

by Damien Pollet

Not really, but I'd be interested in understanding why it's overengineering for Ordering but not for Booleanâ¦ On 9 November 2017 at 14:16, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Damien. > > 2017-11-09 14:00 GMT+01:00 Damien Pollet <damien.pollet(a)gmail.com>: > >> >> >> On 7 November 2017 at 14:48, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >>> >>> And we already have VM based String compare: with strange logic >>>> returning 1, 2, 3. So we already can optimize current >>>> String>>threeWayCompareTo:. >>>> >>> >>> Maybe good idea to open ticket and modify image level methods to return >>> standard -1,0,1 values. >>> >> >> If we're modifying core sorting methods, we might as well use proper >> objects instead of magic numbersâ¦ >> >> Ordering >> Lesser >> Equal >> Greater >> (Unordered?) >> > > I also thought about it. But it looks like overengineering to me. These > magic numbers are too well known to be magic. > Do you have real cases where this approach will improve the code? > > >> >> And while I'm on the topic of vocabulary, I'm not convinced by >> SortFunctionâ¦ "to sort" means either to screen, to classify, or to arrange. >> There is a notion of going through all elements and swapping them around or >> putting in specific bins. Think QuickSort, MergeSort, etc >> >> The mathematical term for the thing that determines whether two elements >> a and b are such that a â¤ b is "Order relation". So IMHO Java's Comparator >> fits the purpose much better; OrderFunction or OrderRelation would be nice >> and just Order would have my preference: >> >> Order with: aPredicate >> (Order with: [:a :b | a < b]) value: 1 value 2. â the singleton instance >> of Lesser >> >> Order by: aMappingBlock >> people sorted: (Order by: #name) , (Order by: #age) >> >> Lesser >> #, innerOrder >> ^ self >> >> Equal >> #, innerOrder >> ^ innerOrder >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Nov. 9, 2017

float & fraction equality bug

by Tudor Girba

Hi, I just stumbled across this bug related to the equality between fraction and float: https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-P… In essence, the problem can be seen that by doing this, you get a ZeroDivide: x := 0.1. y := (1/10). x = y ifFalse: [ 1 / (x - y) ] The issue seems to come from the Float being turned to a Fraction, rather than the Fraction being turned into a Float: Fraction(Number)>>adaptToFloat: rcvr andCompare: selector "If I am involved in comparison with a Float, convert rcvr to a Fraction. This way, no bit is lost and comparison is exact." rcvr isFinite ifFalse: [ selector == #= ifTrue: [^false]. selector == #~= ifTrue: [^true]. rcvr isNaN ifTrue: [^ false]. (selector = #< or: [selector = #'<=']) ifTrue: [^ rcvr positive not]. (selector = #> or: [selector = #'>=']) ifTrue: [^ rcvr positive]. ^self error: 'unknow comparison selector']. ^ rcvr asTrueFraction perform: selector with: self Even if the comment says that the comparison is exact, to me this is a bug because it seems to fail doing that. What do you think? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Nov. 9, 2017

[Pharo 7.0-dev] Build #273: 20661-Fixing-test-from-debugger-should-mark-test-as-green-when-proceed-

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #273 was: SUCCESS. The Pull Request #456 was integrated: "20661-Fixing-test-from-debugger-should-mark-test-as-green-when-proceed-" Pull request url: https://github.com/pharo-project/pharo/pull/456 Issue Url: https://pharo.fogbugz.com/f/cases/20661 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

Hi Damien. 2017-11-09 14:00 GMT+01:00 Damien Pollet <damien.pollet(a)gmail.com>: > > > On 7 November 2017 at 14:48, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> >> And we already have VM based String compare: with strange logic returning >>> 1, 2, 3. So we already can optimize current String>>threeWayCompareTo:. >>> >> >> Maybe good idea to open ticket and modify image level methods to return >> standard -1,0,1 values. >> > > If we're modifying core sorting methods, we might as well use proper > objects instead of magic numbersâ¦ > > Ordering > Lesser > Equal > Greater > (Unordered?) > I also thought about it. But it looks like overengineering to me. These magic numbers are too well known to be magic. Do you have real cases where this approach will improve the code? > > And while I'm on the topic of vocabulary, I'm not convinced by > SortFunctionâ¦ "to sort" means either to screen, to classify, or to arrange. > There is a notion of going through all elements and swapping them around or > putting in specific bins. Think QuickSort, MergeSort, etc > > The mathematical term for the thing that determines whether two elements a > and b are such that a â¤ b is "Order relation". So IMHO Java's Comparator > fits the purpose much better; OrderFunction or OrderRelation would be nice > and just Order would have my preference: > > Order with: aPredicate > (Order with: [:a :b | a < b]) value: 1 value 2. â the singleton instance > of Lesser > > Order by: aMappingBlock > people sorted: (Order by: #name) , (Order by: #age) > > Lesser >> #, innerOrder > ^ self > > Equal >> #, innerOrder > ^ innerOrder > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Nov. 9, 2017

Re: [Pharo-dev] about SortFunctions

by Damien Pollet

On 9 November 2017 at 14:00, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Order by: aMappingBlock > people sorted: (Order by: #name) , (Order by: #age) > > Lesser >> #, innerOrder > ^ self > > Equal >> #, innerOrder > ^ innerOrder > oh well, I got the Order composition and the Ordering flattening mixed up, but you get the idea :) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Nov. 9, 2017

Re: [Pharo-dev] about SortFunctions

by Damien Pollet

On 7 November 2017 at 14:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > And we already have VM based String compare: with strange logic returning >> 1, 2, 3. So we already can optimize current String>>threeWayCompareTo:. >> > > Maybe good idea to open ticket and modify image level methods to return > standard -1,0,1 values. > If we're modifying core sorting methods, we might as well use proper objects instead of magic numbersâ¦ Ordering Lesser Equal Greater (Unordered?) And while I'm on the topic of vocabulary, I'm not convinced by SortFunctionâ¦ "to sort" means either to screen, to classify, or to arrange. There is a notion of going through all elements and swapping them around or putting in specific bins. Think QuickSort, MergeSort, etc The mathematical term for the thing that determines whether two elements a and b are such that a â¤ b is "Order relation". So IMHO Java's Comparator fits the purpose much better; OrderFunction or OrderRelation would be nice and just Order would have my preference: Order with: aPredicate (Order with: [:a :b | a < b]) value: 1 value 2. â the singleton instance of Lesser Order by: aMappingBlock people sorted: (Order by: #name) , (Order by: #age) Lesser >> #, innerOrder ^ self Equal >> #, innerOrder ^ innerOrder -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Nov. 9, 2017

[Pharo 7.0-dev] Build #272: 20611-leftover-logCr-debug-logging-in-GLEmptyBrickarea

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #272 was: SUCCESS. The Pull Request #452 was integrated: "20611-leftover-logCr-debug-logging-in-GLEmptyBrickarea" Pull request url: https://github.com/pharo-project/pharo/pull/452 Issue Url: https://pharo.fogbugz.com/f/cases/20611 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2017