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

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

whatâs your libgit2 version? (LGitLibrary uniqueInstance version) because is weird you are the only one getting that error. Esteban > On 9 Nov 2017, at 21:10, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Using iceberg tool now I get > > Invalid verion 0 on git_remote_callbacks > >> On Nov 9, 2017, at 2:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> oops. >> that was my bad (I put .properties in the wrong place). >> >> please, pull again and retry :) >> >> >>> On 9 Nov 2017, at 18:49, Todd Blanchard <tblanchard(a)mac.com> wrote: >>> >>> I just downloaded the latest Pharo 6.1-64. >>> >>> Now I want to load repository git@github.com:estebanlm/libclang-pharo-bindings.git >>> >>> I have tried.... >>> >>> Opening an iceberg window and clicking +clone and pasting this in there. It fails either with a walkback or vm crash. >>> >>> Also tried >>> >>> Metacello new >>> repository: 'github://estebanlm/libclang-pharo-bindings/src'; (incidentally why are these a different format from what github uses?) >> >> because they are used to indicate repository/subdir/tag/branch, etc. >> but I agree it is far from perfect. >> >> Esteban >> >>> baseline: 'LibClang'; >>> load. >>> >>> Walkback with 'Could not resolve BaselineOfLibClang' >>> >>> Not having much fun here. I definitely do not understand the new code management tools. >>> >>> -Todd Blanchard >> >> > >

Nov. 10, 2017

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

by raffaello.giulietti＠lifeware.ch

On 2017-11-10 00:02, Henrik Sperre Johansen wrote: > raffaello.giulietti wrote >> On 2017-11-09 21:49, Stephane Ducasse wrote: >>> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier >>> < > >> nicolas.cellier.aka.nice@ > >> > wrote: >>>> Note that this started a long time ago and comes up episodically >>>> http://forum.world.st/Fraction-equality-and-Float-infinity-problem-td48323.… >>>> 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) >>> >>> Hi nicolas except that now we could a chapter describing some of the >>> answers :) >>> >> >> It's easy to make = behave as an equivalence if the two objects it >> operates on are of the same class. >> >> But it is well-known that it's hard when their classes are different, >> short of implementing = trivially in this case. >> >> This is to say that there's no real hope to make = an equivalence if the >> wish is to make it useful in the presence of different kind of objects. >> >> In the context of numeric computations, luckily, there is some hope when >> conversions, if possible at all, are all performed consistently. But the >> same conversions should then be applied for all operations, whether >> comparisons or subtractions, etc., to ensure more familiar properties. >> This is not currently the case in Pharo. >> >> >> >> Raffaello > > Personally, I rather like = being transitive across different types of > objects, which is the case with the current implementation.* > It would not be if, like you suggest, multiple Fractions = the same Float. > Take a moment to also reflect on what it would mean if, as the implication > goes, a float represents a range of numbers on the rational number line, > rather than a single point. > Taken to its logical conclusion, it follows you'd need to also redefine the > other mathematical operators to reflect this, as well as conversion to exact > numbers like Integers and Fractions being lossy, rather than the other way > around. > You could certainly build an interesting system of floats with such a > property (I can swear I've read a paper on one somewhere...), but it > wouldn't be the world of IEEE754 Floats we live in. > > Other properties one might deem beneficial, such as > a + b > a if b > 0, > or > (a + b) + c = a + (b + c) > are not true in the context of floats. Does that mean we need to fix them > too? > My 2c: It feels like you are asking Floats to be something they're not, and > the answer simply isn't to try and paint over issues and try and make them > look like something they're not. > > Cheers, > Henry > > Personally, I could live without mixed arithmetic between unlimited and limited precision numbers: I would always be explicit in the conversions. They are so different in nature, like apples and oranges are. This also entails that I would accept that 1 = 1.0 evaluates to false, that 1 <= 1.0 throws an exception and all consequences of this. But this would be unacceptable for most Smalltalkers for many good reasons. And, as you point out, = and total ordering are easily preserved if Floats are converted to Fractions. But then please convert Floats to Fractions even when adding, multiplying, etc. To me a Float does not stand for an interval. It's just a real number that happens to have strange, unfamiliar operations that resemble the pure ones. Some familiar properties also hold for these strange operations, others do not.

Nov. 10, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Todd Blanchard

Using iceberg tool now I get Invalid verion 0 on git_remote_callbacks > On Nov 9, 2017, at 2:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > oops. > that was my bad (I put .properties in the wrong place). > > please, pull again and retry :) > > >> On 9 Nov 2017, at 18:49, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> I just downloaded the latest Pharo 6.1-64. >> >> Now I want to load repository git@github.com:estebanlm/libclang-pharo-bindings.git >> >> I have tried.... >> >> Opening an iceberg window and clicking +clone and pasting this in there. It fails either with a walkback or vm crash. >> >> Also tried >> >> Metacello new >> repository: 'github://estebanlm/libclang-pharo-bindings/src'; (incidentally why are these a different format from what github uses?) > > because they are used to indicate repository/subdir/tag/branch, etc. > but I agree it is far from perfect. > > Esteban > >> baseline: 'LibClang'; >> load. >> >> Walkback with 'Could not resolve BaselineOfLibClang' >> >> Not having much fun here. I definitely do not understand the new code management tools. >> >> -Todd Blanchard > >

Nov. 10, 2017

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

by raffaello.giulietti＠lifeware.ch

On 2017-11-09 22:11, Nicolas Cellier wrote: > > > > I think we have as much as possible already. > Non equality resolve more surprising behavior than it creates. > It makes the implementation more mathematically consistent > (understand preserving more properties). > Tell me how you are going to sort these 3 numbers: > > {1.0 . 1<<60+1/(1<<60).Â 1<<61+1/(1<<61)} sort. > > tell me the expectation of: > > {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size. > > > A clearly stated rule, consistently applied and known to > everybody, helps. > > In presence of heterogeneous numbers, the rule should state the > common denominator, so to say. Hence, the numbers involved in > mixed-mode arithmetic are either all converted to one > representation or all to the other: whether they are compared or > added, subtracted or divided, etc. One rule for mixed-mode > conversions, not two. > > > Having an economy of rules is allways a good idea. > If you can obtain a consistent system with 1 single rule rather than > 2 then go. > But if it's at the price of sacrificing higher expectations, that's > another matter. > > Languages that have a simpler arithmetic model, bounded integer, no > Fraction, may stick to a single rule. > More sofisticated models like you'll find in Lisp and Scheme have > exact same logic as Squeak/Pharo. > > sophisticated... (i'm on my way copying/pasting that one a thousand times) > > We don't have 2 rules gratuitously as already explained. > - Total relation order of non nan values so as to be a good > Magnitude citizen imply non equality > - Producing Float in case of mixed arithmetic is for practicle > purpose: speed > Â (What are those damn Float for otherwise?) > Â it's also justified a posteriori by (exact op: inexact) -> inexact > > What are you ready to sacrifice/trade? > > Let me check if I correctly understand the reason for the dual rule regime for mixed computations: (1) preservation of = as an equivalence and of total ordering. This is ensured by converting Floats to Fractions. (2) performance in case of the 4 basic operations, which is the reason for the second conversion rule from Fractions to Floats. Now, the gain in speed by exercising (2) really depends on how the numbers "mix" in a long chain of operations. I guess for most uses of mixed arithmetic it doesn't make any noticeable difference with respect to a pure Fraction computation. Besides, correctly converting a Fraction to a Float requires more computation than the opposite. So, to answer your question, if preservation of total order and = is worthwhile even in case of mixed numbers, I would sacrifice speed for the sake of the principle of least surprise. One rule, Float->Fraction, slightly less speed. But for those cases where the gain in speed from using Floats would make a noticeable difference, we are entering the hard, counter-intuitive realm of limited precision arithmetic anyway. We better be experts in the first place. And as experts we will find a way out of the one-rule regime by performing explicit Fraction->Float conversions where needed and won't face surprises. The only reason to prefer the opposite one-rule, that would always convert Fractions to Floats in mixed computations, is compatibility with the commercial Smalltalk implementations. Granted, it's not a sound reason but a pragmatic one.

Nov. 9, 2017

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

by Nicolas Cellier

2017-11-09 23:50 GMT+01:00 <raffaello.giulietti(a)lifeware.ch>: > On 2017-11-09 22:11, Nicolas Cellier wrote: > > > > Something like exact difference like Martin suggested, then > > converting to nearest Float because result is inexact: > > ((1/10) - 0.1 asFraction) asFloat > > > > This way, you would have a less surprising result in most > cases. > > But i could craft a fraction such that the difference > > underflows, and the assertion a ~= b ==> (a - b) isZero not > > would still not hold. > > Is it really worth it? > > Will it be adopted in other dialects? > > > > > > > > As an alternative, the Float>>asFraction method could return the > > Fraction with the smallest denominator that would convert to the > > receiver by the Fraction>>asFloat method. > > > > So, 0.1 asFraction would return 1/10 rather than the beefy > > Fraction it currently returns. To return the beast, one would > > have to intentionally invoke asExactFraction or something > similar. > > > > This might cause less surprising behavior. But I have to think > more. > > > > > > No the goal here was to have a non null difference because we need > > to preserve inequality for other features. > > > > Answering anything but a Float at a high computation price goes > > against primary purpose of Float (speed, efficiency) > > If that's what we want, then we shall not use Float in the first > place. > > That's why I don't believe in such proposal > > > > The minimal Fraction algorithm is an intersting challenge though. > > Not sure how to find it... > > I'm thinking of a continuous fraction expansion of the exact fraction > until the partial fraction falls inside the rounding interval of the Float. > > Heavy, but doable. > > Not sure, however, if it always meets the stated criterion. > > > then look at asApproximateFraction and change the termination condition

Nov. 9, 2017

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

by Henrik Sperre Johansen

raffaello.giulietti wrote > On 2017-11-09 21:49, Stephane Ducasse wrote: >> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier >> < > nicolas.cellier.aka.nice@ > > wrote: >>> Note that this started a long time ago and comes up episodically >>> http://forum.world.st/Fraction-equality-and-Float-infinity-problem-td48323.… >>> 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) >> >> Hi nicolas except that now we could a chapter describing some of the >> answers :) >> > > It's easy to make = behave as an equivalence if the two objects it > operates on are of the same class. > > But it is well-known that it's hard when their classes are different, > short of implementing = trivially in this case. > > This is to say that there's no real hope to make = an equivalence if the > wish is to make it useful in the presence of different kind of objects. > > In the context of numeric computations, luckily, there is some hope when > conversions, if possible at all, are all performed consistently. But the > same conversions should then be applied for all operations, whether > comparisons or subtractions, etc., to ensure more familiar properties. > This is not currently the case in Pharo. > > > > Raffaello Personally, I rather like = being transitive across different types of objects, which is the case with the current implementation.* It would not be if, like you suggest, multiple Fractions = the same Float. Take a moment to also reflect on what it would mean if, as the implication goes, a float represents a range of numbers on the rational number line, rather than a single point. Taken to its logical conclusion, it follows you'd need to also redefine the other mathematical operators to reflect this, as well as conversion to exact numbers like Integers and Fractions being lossy, rather than the other way around. You could certainly build an interesting system of floats with such a property (I can swear I've read a paper on one somewhere...), but it wouldn't be the world of IEEE754 Floats we live in. Other properties one might deem beneficial, such as a + b > a if b > 0, or (a + b) + c = a + (b + c) are not true in the context of floats. Does that mean we need to fix them too? My 2c: It feels like you are asking Floats to be something they're not, and the answer simply isn't to try and paint over issues and try and make them look like something they're not. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 9, 2017

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

by raffaello.giulietti＠lifeware.ch

On 2017-11-09 22:11, Nicolas Cellier wrote: > Something like exact difference like Martin suggested, then > converting to nearest Float because result is inexact: > Â Â Â Â ((1/10) - 0.1 asFraction) asFloat > > This way, you would have a less surprising result in most cases. > But i could craft a fraction such that the difference > underflows, and the assertion a ~= b ==> (a - b) isZero not > would still not hold. > Is it really worth it? > Will it be adopted in other dialects? > > > > As an alternative, the Float>>asFraction method could return the > Fraction with the smallest denominator that would convert to the > receiver by the Fraction>>asFloat method. > > So, 0.1 asFraction would return 1/10 rather than the beefy > Fraction it currently returns. To return the beast, one would > have to intentionally invoke asExactFraction or something similar. > > This might cause less surprising behavior. But I have to think more. > > > No the goal here was to have a non null difference because we need > to preserve inequality for other features. > > Answering anything but a Float at a high computation price goes > against primary purpose of Float (speed, efficiency) > If that's what we want, then we shall not use Float in the first place. > That's why I don't believe in such proposal > > The minimal Fraction algorithm is an intersting challenge though. > Not sure how to find it... I'm thinking of a continuous fraction expansion of the exact fraction until the partial fraction falls inside the rounding interval of the Float. Heavy, but doable. Not sure, however, if it always meets the stated criterion.

Nov. 9, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

oops. that was my bad (I put .properties in the wrong place). please, pull again and retry :) > On 9 Nov 2017, at 18:49, Todd Blanchard <tblanchard(a)mac.com> wrote: > > I just downloaded the latest Pharo 6.1-64. > > Now I want to load repository git@github.com:estebanlm/libclang-pharo-bindings.git > > I have tried.... > > Opening an iceberg window and clicking +clone and pasting this in there. It fails either with a walkback or vm crash. > > Also tried > > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src'; (incidentally why are these a different format from what github uses?) because they are used to indicate repository/subdir/tag/branch, etc. but I agree it is far from perfect. Esteban > baseline: 'LibClang'; > load. > > Walkback with 'Could not resolve BaselineOfLibClang' > > Not having much fun here. I definitely do not understand the new code management tools. > > -Todd Blanchard

Nov. 9, 2017

Re: [Pharo-dev] Metacello we need automated conflict resolution between Baselines and Configurations

by Dale Henrichs

Peter, Metacello locks are supposed to address this kind of problem ... at this point in time, any project that is loaded from a git project should be 'locked' using a Metacello lock. The lock means that any request to load that project will use the locked version instead of the version specified in the configuration/baseline. A lock can be applied to a project without actually loading the project ... Presuming that you have a preference towards using the local git repository for project X, then you can lock project X with a reference to the local git repository: Â Metacello new Â Â Â project: 'X'; Â Â Â repository: '......'; Â Â Â lock. ... and from this point on any attempt by Metacello to load project X will load from the local git repository ... Once you have a local clone of a project it is very likely that you will want to share that repository amongst many of your local pharo projects and to do that with Metacallo you need to lock those projects in each of your images, including new images ... This can lead to a lot of locking ... I talk about the approach that I use in tODE to address this problem in two Smalltalks talks [1] and [2]... Dale [1] https://www.youtube.com/watch?v=Ejmqs0xLvSk&list=PLCGAAdUizzH06AkHg6_UxZ6QZ… [2] https://www.youtube.com/watch?v=QshDlH1ADZQ On 11/9/17 12:21 PM, Peter UhnÃ¡k wrote: > Hi, > > as people are increasingly starting to move to git and baselines, it > is becoming more and more common that there are loading issues: > > A depends on B and C > > B depends on ConfigurationOfX > > C depends on BaselineOfX > > and then loading fails on > > MetacelloConflictingProjectError: Load Conflict between existing > BaselineOfStateSpecs [baseline] from > github://dionisiydk/StateSpecs:v2.4.x and ConfigurationOfStateSpecs > stable from http://www.smalltalkhub.com/mc/dionisiy/StateSpecs/main > > I imagine that this will become more and more common. > > Can this be resolved in some automated fashion? > > Thanks, > Peter

Nov. 9, 2017

[Pharo 7.0-dev] Build #278: 20667-Be-able-to-install-breakpoints-by-clicking-on-segment-icons-area

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

There is a new Pharo build available! The status of the build #278 was: SUCCESS. The Pull Request #459 was integrated: "20667-Be-able-to-install-breakpoints-by-clicking-on-segment-icons-area" Pull request url: https://github.com/pharo-project/pharo/pull/459 Issue Url: https://pharo.fogbugz.com/f/cases/20667 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2017