July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] problem mixing Traits and Inheritance

by Adrian Lienhard

We had a discussion about this on this mailing list some time ago. The conclusion, as far as I remember, was that yes, ideally it should detect that the method exists in a superclass and hence should not add the atEnd method to the subclass in your example. This is not that easy to implement, though (if you think through the different cases of structural changes that would need to be captured to correctly update classes using traits). The simplest solution is to not implement atEnd in the trait. Anyway, the information that this method is a requirement should be automatically provided by a tool rather than being hardcoded by the developer. Cheers, Adrian On Jul 8, 2009, at 11:08 , Cyrille Delaunay wrote: > Hi, > Here's my problem : > - I have the class NSCollectionStream which define ( for example ) > #atEnd > - I have the class NSSubclassOfCollectionStream ( which is a suclass > of > NSCollectionStream). > > When I use a trait in NSSubclassOfCollectionStream that required the > method > #atEnd, the defintion in NSCollectionStream is not used and the method > #atEnd is overridden with : > atEnd > self explicitRequirement. > > I think we should take care about definitions in superclass, no? > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 8, 2009

Re: [Pharo-project] Fwd: issue 348

by StÃ©phane Ducasse

Yes. I think that it would be great to have a smart student working on a SummerTalk Project on that. Stef On Jul 8, 2009, at 1:22 AM, Igor Stasenko wrote: > 2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Your cents are valuable! >> > Thanks. > Then 1 more cent: > > No doubt , this will require deep refactoring/rethinking the Compiler > & requestor roles. > But it would help greatly in cleaning the Compiler/Parser code from > things which related to handle uncertainties, like > non-existing selector(s), undefined identifiers, unused temps and so > on.. > >> 2009/7/8 Igor Stasenko <siguctua(a)gmail.com>: >>> My 2 cents: >>> >>> compiler should always work together with requestor: >>> >>> Compiler compile: some thing requestor: aRequestor. >>> >>> Then it could always ask, aRequestor if its interactive, or not, >>> but i think, Compiler could live just well without such knowledge at >>> all - each time it needs some extra data - it can simply ask the >>> requestor to handle such particular situation, in a fashion like >>> following: >>> >>> Compiler>>compileError: error >>> ^ requestor handleError: error ifUnhandled: [ error signal ] >>> >>> all we need is just carefully establish protocol between Compiler >>> and >>> requestor object, so then making interactive/non-interactive/partly >>> interactive will be completely independant from Compiler. >>> >>> 2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> Hi Pavel >>>> >>>>> Hi, >>>>> >>>>> every UIManager may have its own preference about this behaviour >>>>> (for example the dummy ui manager has no user input). It is >>>>> cleaner >>>>> solution than to set interactivity for every Compiler instance or >>>>> for the Compiler class. >>>> >>>> In fact I have the impression that this is the same pattern than >>>> with >>>> preference class. >>>> We are now making sure that the Preference layer can be remove by >>>> removing references from within the package to the Preference >>>> class and we turn into a flow from the preference class to push >>>> value >>>> to the tools default value. >>>> >>>> Similarly we prefer that the UIManager pushes information to the >>>> compiler and not that the compiler rely on >>>> UIManager. I would like to think about a Compiler been able to run >>>> standalone without UI. >>>> >>>> Now we could have >>>> >>>> UIManager>> setUpForNonInteraction >>>> >>>> Compiler setInNonInteractiveMode >>>> ,... >>>> other class >>>> >>>> and Compiler code >>>> referring to itself (its value for non interaction) >>>> >>>> This way we could even remove completely the UIManager. >>>> >>>> Else I think that UIManager will become another huge facade that we >>>> cannot remove. >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> -- Pavel >>>>> >>>>> >>>>> On Tue, Jul 7, 2009 at 7:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >>>>>> wrote: >>>>> pavel I was wondering why you want to have interactiveParserFor: >>>>> in >>>>> UIManager and not in Compiler? >>>>> >>>>> May be I missed something but I'm ready to learn. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> On Jul 7, 2009, at 7:18 PM, StÃ©phane Ducasse wrote: >>>>> >>>>>> >>>>>> From: Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>>> Date: July 6, 2009 2:26:56 PM CEDT >>>>>> To: stephane ducasse <stephane.ducasse(a)free.fr> >>>>>> Subject: issue 348 >>>>>> >>>>>> Hi Stef, >>>>>> >>>>>> I updated the issue http://code.google.com/p/pharo/issues/detail? >>>>>> id=348 >>>>>> >>>>>> Cheers, >>>>>> -- Pavel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 8, 2009

[Pharo-project] problem mixing Traits and Inheritance

by Cyrille Delaunay

Hi, Here's my problem : - I have the class NSCollectionStream which define ( for example ) #atEnd - I have the class NSSubclassOfCollectionStream ( which is a suclass of NSCollectionStream). When I use a trait in NSSubclassOfCollectionStream that required the method #atEnd, the defintion in NSCollectionStream is not used and the method #atEnd is overridden with : atEnd self explicitRequirement. I think we should take care about definitions in superclass, no?

July 8, 2009

Re: [Pharo-project] Issue 941: adding class methods fails

by Lukas Renggli

> Lukas fixed OB too. So may be you should load the latest code. I did that in the category based browser only, David probably has to merge these changes into the package browser. Lukas > > Stef > > On Jul 8, 2009, at 12:47 AM, Johan Brichau wrote: > >> that's issue 941 (not 942) >> >> sorry >> >> On 08 Jul 2009, at 00:46, Johan Brichau wrote: >> >>> Hi, >>> >>> Adding (new) class methods fails in latest image. >>> I described the problem and proposed a fix attached to issue 942 >>> >>> ---------------------------- >>> Johan Brichau >>> johan.brichau(a)uclouvain.be >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ---------------------------- >> Johan Brichau >> johan.brichau(a)uclouvain.be >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

July 8, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by danil osipchuk

>> >> I repeat here my arguments: >> Anyone depending on (13/10) = 1.3 is plain wrong... >> > +1. > I dealt with 3D rendering/linear algebra using floats in the past , > and i can say just one: > - never write the code which compares the floats to be equal to some > exact value. > It makes no sense in practice, because of inexact nature of floats. +1 me too Code like '(13/10) = 1.3' just jumps at you if you have been bitten by this before. In languages of APL branch (which are traditionally used for intensive calculations) the comparison of real numbers is 'tolerant': that is two numbers are considered equal if their relative difference is less than some predefined small value: a = b isTrue if: |a-b|/max(a,b) < Epsilon http://www.jsoftware.com/help/primer/tolerance.htm http://jsoftware.com/help/dictionary/d000.htm Creators of these languages put a lot of considiration into this and it I think they got it right. It may be too radical to redefine comparison of real values in Smalltalk (although it still makes sense to do so in practical terms) but the discussed test is just a blind shot into a sky. The user should be discouraged to rely on a such comparison. regards, Danil > As we know, if two vectors is perpendicular, then their dot product is zero. > But it is almost always non-zero on hardware, especially when you > transform vectors or compute them using data, which already contains a > degree of precision error! > So, i learned that comparing dot product with zero makes no sense, > instead you'd better test it with something like: > > abs(float) < epsilon > where epsilon is very small number. > > So, i don't understand, why its so important for such kind of equality > tests to work right at all - because you hardly will use such tests in > practice. > >> Either you want fast and inexact floating point operation and should >> not rely on exact equality (use #closeTo:). >> Or you want (13/10) = 1.3 EXACTLY, and then should better use ScaledDecimal. >> That's the deal, and it's quite independant from the language. >> >> The false assertions that people are trying to push does not matter: >> it's high time to educate. >> My proposition has at least the merit to put a light on these >> dangerous floating point strict equality tests >> (I saw so many bugs like testing cos(pi/2) == 0). >> >> And I'm still waiting for the hypothetical application that would >> break because of this change. >> That's the main point of interest. >> In this case, we'll see if patching is necessary and easy. >> >> Nicolas >> >> P.S. concerning behaviour of conversion binary<->decimal >> representation, I'm rather the one trying to unify Smalltalk. >> Dolphin, gst and Pharo adopted some of my changes to behave as exactly >> as we can, and thus behave the same. >> Try this in your prefered dialect, I guess you will have some surprise. >> 123.4567890123d3 = (1234567890123/10000000). >> 123.4567890123d3 = (1234567890123/10000000) asFloat. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 8, 2009

Re: [Pharo-project] Issue 941: adding class methods fails

by StÃ©phane Ducasse

Hi Johan Lukas fixed OB too. So may be you should load the latest code. Stef On Jul 8, 2009, at 12:47 AM, Johan Brichau wrote: > that's issue 941 (not 942) > > sorry > > On 08 Jul 2009, at 00:46, Johan Brichau wrote: > >> Hi, >> >> Adding (new) class methods fails in latest image. >> I described the problem and proposed a fix attached to issue 942 >> >> ---------------------------- >> Johan Brichau >> johan.brichau(a)uclouvain.be >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 8, 2009

Re: [Pharo-project] Issue 941: adding class methods fails

by StÃ©phane Ducasse

oops! Stef On Jul 8, 2009, at 12:47 AM, Johan Brichau wrote: > that's issue 941 (not 942) > > sorry > > On 08 Jul 2009, at 00:46, Johan Brichau wrote: > >> Hi, >> >> Adding (new) class methods fails in latest image. >> I described the problem and proposed a fix attached to issue 942 >> >> ---------------------------- >> Johan Brichau >> johan.brichau(a)uclouvain.be >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 8, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Reinout Heeck

> I have given enough arguments and should let other people express > their opinion without fearing an agressive response :) In my opinion the behavior should exactly match the underlying binary representation of floats, otherwise I get results where I feel the system is 'fuzzing' while I didn't tell it to do so and I start to feel uneasy. So where VisualWorks does (13/10) = 1.3 "true" it makes me cringe, OTOH where it does 1.3 = 1.3d "false" it makes me feel right at home. At the heart of the matter is that we use /decimal/ floating point notation to represent /binary/ floats, and the issues (surprises for some people) of approximation should be put at exactly that conversion place and not compensated elsewhere -- this way we get a system with the least surprises. I am too new at Squeak to know how well separated #displayString (application behavior) and #printString (tools behavior) are, but it might help if the tools clearly show when the #printString of a float is approximate by prepending a ~ for example: 1.3 printString "~1.3" 1.0 printString "1.0" Regarding #asExactFraction I'd say that is an ugly pleonasm but more importantly it is confusing (it suggests that #asFraction is fuzzing), hence it should be deprecated; #asFraction should do an exact conversion IMO. R -

July 8, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by StÃ©phane Ducasse

On Jul 8, 2009, at 4:07 AM, Hernan Wilkinson wrote: > ok, let me start again. > 1) I created the issue because 13/10 = 1.3 works different in the > new pharo image that in vw, va, dolphin, squeak and the previous > pharo version, so I thought it was a bug > 2) I understand that comparing floats is not good and I also > understand the representation problems of floats > 3) I'm in favor of making changes. Changes are needed to make > progress although not all changes make progress > > But, Nicolas when you say > > Anyone depending on (13/10) = 1.3 is plain wrong... > I do not completely agree. You say that because you are thinking > like a programmer and you know that 1.3 is a float, but if you ask > the same question to an accountant, engineering, etc. they will say > that 13/10 is equal to 1.3. So, outside computers, 13/10 is equal to > 1.3, the same as 1/2 equals to 0.5 and so on. > Dan Ingalls followed a good design principle: to hide as much as > possible implementation details from the user and that is why > Smalltalk has such a great Number model that I did not see in > another language. > From my point of view, the implementation you are providing is not > quite following this principle or at least is making the float > representation problem more evident. If the last is the intention, I > think it should be consistent (i.e. 1/2 = 0.5 should return false > also) and provide specific messages to handle that decision too. > Or maybe the change has to be more profound, maybe changes like the > one suggested by Michael van der Gulik > are necessary, maybe we have to print ScaledDecimals as float are > printed now and print floats with a special representation to make > evident that is not a "normal" number... May be this would be good in fact. I was wondering why we could not have = comparison always been false? Stef > Anyway, as I said before, I'm not sure this change is a good > decision, time will tell I guess, those are my two cents. > Bye, > Hernan > > > > > On Tue, Jul 7, 2009 at 7:37 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com > > wrote: > 2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > > On Jul 7, 2009, at 11:21 PM, Hernan Wilkinson wrote: > > > >> ok, but can you be sure that your objects are not handling floats? > >> maybe the same code handles floats when you want speed and > fractions > >> when you want precision, I remember we did that once but I don't > >> remember if we had to compare the numbers... > >> I understand your point and I agree with you that erratic behavior > >> should be avoided as much as possible, new programmers always get > >> confused when two floats print the same but return false when > >> compared, but do you agree with me that this new behavior make > >> floats "less polymorphic" with numbers? and code more odd?... you > >> see, people will have the same question as me, why (13/10) = 1.3 > >> returns false but (1/2) = 0.5 returns true? > >> Maybe the solution has to be more drastic, and if we want to avoid > >> people for comparing floats for equality, just not let them or > >> return false always... or take the other road as Smalltalk had > after > >> now, that is: make the implementation detail as hide as possible, > >> and if the programmer really cares about representation problems > let > >> him compare the numbers with a difference... > >> Smalltalk has almost 30 years old and I have not seen any big > >> problem related to comparing numbers, so why changing that? what do > >> we gain with the change?... I'm still not sure that this change is > >> for the better :-) > > > > :-) > > yes I understand that point too :) > > So please continue to discuss that we understand the deep pros and > > cons. I think this is extremely healthy > > > > Stef > > > > Except the polymorphism argument, this is more a principle of inertia. > "Why did you change the browser, I want it back..." > > IMO, Smalltalk had not so many problems because it is not used for > number crunching. > Financial apps use ScaledDecimal where due and avoid the problem. > I used it for crunching numbers, but I feel a bit alone :) > > Concerning polymorphism, I hope I demonstrated this is a false > polymorphism because you get non transitive equality and numbers not > well ordered. > > Anyway: > | a b | > a = 13/10. > b= a asFloat. > self assert: (a = b) ==> (a squared = b squared). > self assert: (a = b) ==> (a fractionPart = b fractionPart). > etc... > They behave differently, really. > > Concerning (0.5) ~= (1/2) that might be a good idea. > What stopped me was the implications it would have on inequality > tests... > 0.5 < (1/2). -> false > 0.5 = (1/2). -> false > 0.5 > (1/2). -> false > So they are unordered... I prefer 0.5 = (1/2). -> true strategy mainly > for this reason. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 8, 2009

Re: [Pharo-project] SUnit assert:equals:

by Oscar Nierstrasz

OK, got it. I should have closer look at http://squeaksource.com/Testing/ too. Cheers, - on On 8 Jul 2009, at 00:05, Michael Roberts wrote: > No you understand certainly, I wasn't clear. If we provide a nice api > for comparing things are equal it would be a shame to not provide the > convenience for doubles. Newcomers to the environment would not > necessarily understand the pitfalls of testing equality on doubles. > Thus providing convenience in one area could look very attractive in > the general case if there are no other methods hinting their > appropriate use. I'm sure such a method has already been written in a > repository somewhere . I just thought it would be good to put them in > together. That make sense? > > Mike > > On Tuesday, July 7, 2009, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: >> >> Hi Mike, >> >> I don't understand. assert:equals: should only be used for exact >> equality tests, not for comparing doubles. >> >> Doubles should never go through this method. >> >> Existing tests won't know about assert:equals: >> >> Did I misunderstand you? >> >> - on >> >> On 7 Jul 2009, at 19:24, Michael Roberts wrote: >> >>> If you are adding this it would be good to either add or review >>> existing implementation that checks the comparison is within a >>> tolerance. This would be for asserting double values are close but >>> not >>> necessarily exact. I would rather we didn't get double comparison >>> going through this method you describe which would be easy to do. >>> >>> Thanks >>> mike >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 8, 2009