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

Re: [Pharo-dev] CRC checks of downloads fail really often

by Norbert Hartl

Yes, this drives me crazy. You cannot do much or invite people to use it because the download does not work. Sometimes it is really ridiculous. Norbert > Am 09.11.2017 um 10:28 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi, > > In the travis jobs of many projects (pillar, ossubprocess), I see often this failure: > > image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be 85ee6276) > > This is happening all the time for large builds, generally in 1 out of 4 jobs: > > https://travis-ci.org/marianopeck/OSSubprocess/builds/299269491 <https://travis-ci.org/marianopeck/OSSubprocess/builds/299269491> > https://travis-ci.org/pillar-markup/pillar/jobs/298538119 <https://travis-ci.org/pillar-markup/pillar/jobs/298538119> > > Of course restarting the job (to retry the download) solves the problem eventually. > > Is this because of the inria infrastructure working funny? > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Nov. 9, 2017

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

by Nicolas Cellier

2017-11-09 18:11 GMT+01:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > On 2017-11-09 15:55, Nicolas Cellier wrote: > >> >> >> 2017-11-09 15:48 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com <mailto: >> tudor(a)tudorgirba.com>>: >> >> Hi, >> >> Thanks for the answer. The example I provided was for convenience. >> >> I still do not understand why it is wrong to expect 0.1 = (1/10) to >> be true. >> >> Doru >> >> >> Because there are infinitely many different Fraction that would be >> "equal" to 0.1 then. >> The first effect is that you have >> >> a = b >> a = c >> b < c >> >> You are breaking the fact that you can sort these Numbers (are they >> Magnitude anymore?) >> You are breaking the fact that you can mix these Numbers as Dictionary >> keys (sometimes the dictionary would have 2 elements, sometimes 3, >> unpredictably). >> >> >> > Fractions are not reliable keys anyway: > (Fraction numerator: 1 denominator: 3) = (Fraction numerator: 2 > denominator: 6) > evaluates to true while > (Fraction numerator: 1 denominator: 3) hash = (Fraction numerator: 2 > denominator: 6) hash > evaluates to false > > > You are violating the invariants described in class comment in this case, and thus missusing Fraction. So it's not anymore the problem of the library

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 17:53 GMT+01:00 Igor Stasenko <siguctua(a)gmail.com>: > > > On 9 November 2017 at 16:28, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > >> >> >> 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*). >> > > Not me. I have nothing to do with libgit bindings.. > > Sorry I answerd to both you and Esteban (and other developpers) But usually, for any who knows C it should be quite simple to follow a > pattern.. it is like > > typedef foo_bar* FooBarObject; > > As long as the names tells, my whole point is that typedef foo_bar* FooBar; Is already a questionable naming per se And having at the same time typedef foo_opt FooOpt; is troublesome so, then you use FooBarObject instead of foo_bar* everywhere. > > 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...) >> >> > IIRC, FFIExternalObject intentionally was not allowing arity more than > one. > So, you can use it for passing it as a return-value argument to function, > but you should not use it where function expecting an array/list of > pointers of given type. > > > 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 >> >> yes, if it using argument as a return-value. > > >> 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))). >> >> ? why? > it should return an object already suitable for use..- an instance of > FooBar. > > mybar := self call: #(FooBar foo_bar_alloc( size_t size). > > self assert: (mybar class == FooBar) > > At least it was like that in NB. > Ah, maybe i was thinking at a much too low level then I will try and understand what happens in UFFI. > >> 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)). >> >> yep > > >> 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? >> >> > i think it expecting a list of options, and if not, then there's a > mistake. i don't know much about libgit.. > > Libgit2 git_options is just another struct like every other ones git_tree etc... The problem is that the API does not alllocate those git_options for us. Instead they just initialize directly from literal values via macro: https://github.com/libgit2/libgit2/search?utf8=%E2%9C%93&q=git_diff_options… #define GIT_DIFF_OPTIONS_INIT \ {GIT_DIFF_OPTIONS_VERSION, 0, GIT_SUBMODULE_IGNORE_UNSPECIFIED, {NULL,0}, NULL, NULL, NULL, 3} So we have to allocate the options in Smalltalk by ourself and can't handle the structure as Opaque unlike the other structures... >> 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-g >>>> it_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_d >>>> iff_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. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

Nov. 9, 2017

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

by Raffaello Giulietti

On 2017-11-09 15:55, Nicolas Cellier wrote: > > > 2017-11-09 15:48 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > Hi, > > Thanks for the answer. The example I provided was for convenience. > > I still do not understand why it is wrong to expect 0.1 = (1/10) to > be true. > > Doru > > > Because there are infinitely many different Fraction that would be > "equal" to 0.1 then. > The first effect is that you have > > a = b > a = c > b < c > > You are breaking the fact that you can sort these Numbers (are they > Magnitude anymore?) > You are breaking the fact that you can mix these Numbers as Dictionary > keys (sometimes the dictionary would have 2 elements, sometimes 3, > unpredictably). > > Fractions are not reliable keys anyway: (Fraction numerator: 1 denominator: 3) = (Fraction numerator: 2 denominator: 6) evaluates to true while (Fraction numerator: 1 denominator: 3) hash = (Fraction numerator: 2 denominator: 6) hash evaluates to false

Nov. 9, 2017

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

by Raffaello Giulietti

On 2017-11-09 15:50, Nicolas Cellier wrote: > This is out of context. > There is no such thing as Fraction type covered by IEEE 754 standard. > Yes, I agree. But we should still strive to model arithmetic embracing the principle of least surprise. That's why in every arithmetic system I'm aware of (with the exception of very old CPUs dating back several decades), for finite x, y the x = y if and only if x - y = 0 property holds. Let's put it in another perspective: what's the usefulness of having x = y evaluate to false just to discover that x - y evaluates to 0, or the other way round? > Anyway relying upon Float equality should allways be subject to extreme > caution and examination > > For example, what do you expect with plain old arithmetic in mind: > > Â Â Â a := 0.1. > Â Â Â b := 0.3 - 0.2. > Â Â Â a = b > > This will lead to (a - b) reciprocal = 3.602879701896397e16 > If it is in a Graphics context, I'm not sure that it's the expected scale... > > a = b evaluates to false in this example, so no wonder (a - b) evaluates to a big number. But the example is not plain old arithmetic. Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest to 0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it seems). Every user of Floats should be fully aware of the implicit loss of precision that using Floats entails. So, using Floats to represent decimal numbers is the real culprit in this example, not the underlying Float arithmetic, which is very well defined from a mathematical point of view. In other words, using Floats to emulate decimal arithmetic will frustrate anybody because Floats work with limited precision binary arithmetic. Users wanting to engage in decimal arithmetic should simply not use Floats. (That's the reason for the addition of limited precision decimal arithmetic and numbers in the IEEE 754-2008 standard.) That said, this does not mean we should give up useful properties like the one discussed above. Since we *can* ensure this property, we also should, in the spirit of the principle of least surprise. What's problematic in Pharo is that comparison works in one way while subtraction works in another way but, mathematically, these operations are essentially the same. So let's be consistent. In the case of mixed-mode Float/Fraction operations, I personally prefer reducing the Fraction to a Float because other commercial Smalltalk implementations do so, so there would be less pain porting code to Pharo, perhaps attracting more Smalltalkers to Pharo. But the main point here, I repeat myself, is to be consistent and to have as much regularity as intrinsically possible.

Nov. 9, 2017

[Pharo 7.0-dev] Build #277: 20582-atat-messages-call-errorKeyNotFound

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

There is a new Pharo build available! The status of the build #277 was: SUCCESS. The Pull Request #454 was integrated: "20582-atat-messages-call-errorKeyNotFound" Pull request url: https://github.com/pharo-project/pharo/pull/454 Issue Url: https://pharo.fogbugz.com/f/cases/20582 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2017

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

by Igor Stasenko

On 9 November 2017 at 16:28, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 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*). > Not me. I have nothing to do with libgit bindings.. But usually, for any who knows C it should be quite simple to follow a pattern.. it is like typedef foo_bar* FooBarObject; so, then you use FooBarObject instead of foo_bar* everywhere. 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...) > > IIRC, FFIExternalObject intentionally was not allowing arity more than one. So, you can use it for passing it as a return-value argument to function, but you should not use it where function expecting an array/list of pointers of given type. 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 > > yes, if it using argument as a return-value. > 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))). > > ? why? it should return an object already suitable for use..- an instance of FooBar. mybar := self call: #(FooBar foo_bar_alloc( size_t size). self assert: (mybar class == FooBar) At least it was like that in NB. > 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)). > > yep > 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? > > i think it expecting a list of options, and if not, then there's a mistake. i don't know much about libgit.. > > 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-g >>> it_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_d >>> iff_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. >> > > -- Best regards, Igor Stasenko.

Nov. 9, 2017

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

by Nicolas Cellier

Note that this started a long time ago and comes up episodically http://forum.world.st/Fraction-equality-and-Float- infinity-problem-td48323.html http://forum.world.st/BUG-Equality-should-be-transitive-tc1404335.html https://lists.gforge.inria.fr/pipermail/pharo-project/2009-July/010496.html A bit like a "marronnier" (in French, a subject that is treated periodically by newspapers and magazines) 2017-11-09 15:55 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-11-09 15:48 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Thanks for the answer. The example I provided was for convenience. >> >> I still do not understand why it is wrong to expect 0.1 = (1/10) to be >> true. >> >> Doru >> >> > Because there are infinitely many different Fraction that would be "equal" > to 0.1 then. > The first effect is that you have > > a = b > a = c > b < c > > You are breaking the fact that you can sort these Numbers (are they > Magnitude anymore?) > You are breaking the fact that you can mix these Numbers as Dictionary > keys (sometimes the dictionary would have 2 elements, sometimes 3, > unpredictably). > > >> > On Nov 9, 2017, at 3:36 PM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > >> > Nope, not a bug. >> > >> > If you use Float, then you have to know that (x -y) isZero and (x = y) >> are two different things. >> > Example; Float infinity >> > >> > In your case you want to protect against (x-y) isZero, so just do that. >> > >> > 2017-11-09 15:15 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > 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-Pharo >> > >> > 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." >> > >> > >> > >> > >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> >> >> >

Nov. 9, 2017

[Pharo 7.0-dev] Build #276: 20664-set-the-display-size-sooner

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

There is a new Pharo build available! The status of the build #276 was: SUCCESS. The Pull Request #458 was integrated: "20664-set-the-display-size-sooner" Pull request url: https://github.com/pharo-project/pharo/pull/458 Issue Url: https://pharo.fogbugz.com/f/cases/20664 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2017

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

by henry

To break down the ASN.1 encoding of 0.1 we have the following: sign * mantissa * (2 raisedTo: scalingFactor) * (base raisedTo: exponent). And in this case the values for 0.1 are as follows: self assert: sign = 1. self assert: mantissa = 3602879701896397. self assert: scalingFactor = 0. self assert: base = 2. self assert: exponent = -55. Just to close it up... - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] float & fraction equality bug > Local Time: November 9, 2017 10:13 AM > UTC Time: November 9, 2017 3:13 PM > From: henry(a)callistohouse.club > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > ASN.1 encoding is a long standing encoding format and includes accepted encoding of Reals and Integers. I read this thread and decided to see what difference that ASN.1 Real encoding may report between this float and the fraction. It turns out it is the same, but not in an equality test with the fraction. That is due to conversion from Fraction to Float before encoding. Here is the results I found: > > ASN1OutputStream encode: (1/10). > ASN1OutputStream encode: (0.1). > bytes := #[9 9 128 201 12 204 204 204 204 204 205] > > This breaks down as in: > ASN1InputStream decodeBytes: bytes. > obj := (3602879701896397/36028797018963968) > > Which equals 0.1, but does not equal (1/10). > > Food for thought regarding ASN.1 encoding of Reals. > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] float & fraction equality bug >> Local Time: November 9, 2017 9:48 AM >> UTC Time: November 9, 2017 2:48 PM >> From: tudor(a)tudorgirba.com >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> Hi, >> >> Thanks for the answer. The example I provided was for convenience. >> >> I still do not understand why it is wrong to expect 0.1 = (1/10) to be true. >> >> Doru >> >>> On Nov 9, 2017, at 3:36 PM, Nicolas Cellier nicolas.cellier.aka.nice(a)gmail.com wrote: >>> Nope, not a bug. >>> If you use Float, then you have to know that (x -y) isZero and (x = y) are two different things. >>> Example; Float infinity >>> In your case you want to protect against (x-y) isZero, so just do that. >>> 2017-11-09 15:15 GMT+01:00 Tudor Girba tudor(a)tudorgirba.com: >>> 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." >> >> www.tudorgirba.com >> www.feenk.com >> >> "We are all great at making mistakes."

Nov. 9, 2017