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

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

by Nicolas Cellier

2009/7/8 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > > On 7-Jul-09, at 6:40 PM, Nicolas Cellier wrote: > >> I'm waiting the answer why 1.3*1.3 is different from 169/100. When >> you'll have discovered this, we'll talk about 13/10 = 1.3 on more >> serious bases. >> >> Nicolas > > Well for Fraction I do Â (1.3*1.3 ) asApproximateFraction Â (169/100) > because people have expectations about (1.3*1.3) = 169/100 > the same expectations they likely had for (1/10) = 0.1 > > noting that > (1/10) = 0.1 false > (1/10) = (0.1 asApproximateFraction) true > > > Personally I think here the issue is more what the different smalltalk > think and do for various float to faction conversions > not perhaps what is correct. Unless of course you want to drop any > numerical compatibility? > Hi John, I missed this one, Yes, numerical compatibility is an issue and I'm fighting to restore it. FYI, Smalltalks are just not compatible at very first step: converting literal decimals to Float... This is because conversion algorithms cumulate several rounding errors... ... all with a different algorithm... ... and because of ANSI laxism about implementation. I corrected Integer>>asFloat, Fraction>>asFloat, Number>>readFrom: and maybe a few others to obtain a uniform behaviour: round to the nearest Float (IEEE 754 default mode round to nearest even). I proposed patches to Squeak/Pharo, gst, Dolphin, ST/X and VW, AFAIK they are integrated in Pharo, gst, Dolphin; partially in Squeak. All is MIT, so other dialects just have to cherry pick. Concerning the exact vs inexact comparison, I raised the subject regularly on various mailing list, but yes it would be great to come to an agreement. Its on the pending bugfix list for Squeak 3.11 at least and Paolo has an opened issue for gst i think. Nicolas

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. > > ok, I did so. > > This means that we do not check for this scary selectors anymore on method compile. Yes, that check is totally useless and extremely annoying, if not in e-toy mode. Stef and I removed it from the compiler and the old Squeak browser. As a side-effect when accepting code the parser only runs once over the source, not twice as it did before. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

July 8, 2009

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

by David RÃ¶thlisberger

>> 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. ok, I did so. This means that we do not check for this scary selectors anymore on method compile. David >> 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 >> > > >

July 8, 2009

Re: [Pharo-project] fonts

by Tudor Girba

Done. Doru On 8 Jul 2009, at 14:50, Mariano Martinez Peck wrote: > It would be nice to add this code snippet to here: http://code.google.com/p/pharo/wiki/CodeSnippets > > On Wed, Jul 8, 2009 at 11:46 AM, Tudor Girba <girba(a)iam.unibe.ch> > wrote: > Hi again :), > > Indeed, reinitializing the font system seems to have solved the > problem: > FreeTypeFontProvider current updateFromSystem > > Cheers, > Doru > > ---- font script ---- > menuFont := LogicalFont > familyName: 'Helvetica Neue' > pointSize: 9 > stretchValue: (LogicalFont stretchCondensed) > weightValue: (LogicalFont weightBold) > slantValue: (LogicalFont slantNormal). > titleFont := LogicalFont > familyName: 'Helvetica Neue' > pointSize: 14 > stretchValue: (LogicalFont stretchCondensed) > weightValue: (LogicalFont weightBold) > slantValue: (LogicalFont slantNormal). > codeFont := LogicalFont familyName: 'Monaco' pointSize: 8. > defaultFont := LogicalFont familyName: 'Helvetica Neue' pointSize: > 9. > Preferences setSystemFontTo: defaultFont. > Preferences setListFontTo: defaultFont. > Preferences setFlapsFontTo: menuFont. > Preferences setHaloLabelFontTo: defaultFont. > Preferences setMenuFontTo: menuFont. > Preferences setWindowTitleFontTo: titleFont. > Preferences setBalloonHelpFontTo: defaultFont. > Preferences setCodeFontTo: codeFont. > Preferences setButtonFontTo: defaultFont. > -------- > > > On 8 Jul 2009, at 14:37, Tudor Girba wrote: > > > Hi, > > > > I ran my usual font setting script (see below) on > > pharo0.1-10371dev09.07.1 and the fonts did not get set. I ran the > same > > code on Pharo0.1Core-10371 and it worked. > > > > Any idea what is the difference between the dev and the core images > > regarding this issue? Is it because of some initialization of the > font > > system? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "Problem solving should be concentrated on describing > > the problem in a way that is relevant for the solution." > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > > > _______________________________________________ > 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 -- www.tudorgirba.com "Beauty is where we see it."

July 8, 2009

Re: [Pharo-project] fonts

by Mariano Martinez Peck

It would be nice to add this code snippet to here: http://code.google.com/p/pharo/wiki/CodeSnippets On Wed, Jul 8, 2009 at 11:46 AM, Tudor Girba <girba(a)iam.unibe.ch> wrote: > Hi again :), > > Indeed, reinitializing the font system seems to have solved the problem: > FreeTypeFontProvider current updateFromSystem > > Cheers, > Doru > > ---- font script ---- > menuFont := LogicalFont > familyName: 'Helvetica Neue' > pointSize: 9 > stretchValue: (LogicalFont stretchCondensed) > weightValue: (LogicalFont weightBold) > slantValue: (LogicalFont slantNormal). > titleFont := LogicalFont > familyName: 'Helvetica Neue' > pointSize: 14 > stretchValue: (LogicalFont stretchCondensed) > weightValue: (LogicalFont weightBold) > slantValue: (LogicalFont slantNormal). > codeFont := LogicalFont familyName: 'Monaco' pointSize: 8. > defaultFont := LogicalFont familyName: 'Helvetica Neue' pointSize: > 9. > Preferences setSystemFontTo: defaultFont. > Preferences setListFontTo: defaultFont. > Preferences setFlapsFontTo: menuFont. > Preferences setHaloLabelFontTo: defaultFont. > Preferences setMenuFontTo: menuFont. > Preferences setWindowTitleFontTo: titleFont. > Preferences setBalloonHelpFontTo: defaultFont. > Preferences setCodeFontTo: codeFont. > Preferences setButtonFontTo: defaultFont. > -------- > > > On 8 Jul 2009, at 14:37, Tudor Girba wrote: > > > Hi, > > > > I ran my usual font setting script (see below) on > > pharo0.1-10371dev09.07.1 and the fonts did not get set. I ran the same > > code on Pharo0.1Core-10371 and it worked. > > > > Any idea what is the difference between the dev and the core images > > regarding this issue? Is it because of some initialization of the font > > system? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "Problem solving should be concentrated on describing > > the problem in a way that is relevant for the solution." > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > > > _______________________________________________ > 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] fonts

by Tudor Girba

Hi again :), Indeed, reinitializing the font system seems to have solved the problem: FreeTypeFontProvider current updateFromSystem Cheers, Doru ---- font script ---- menuFont := LogicalFont familyName: 'Helvetica Neue' pointSize: 9 stretchValue: (LogicalFont stretchCondensed) weightValue: (LogicalFont weightBold) slantValue: (LogicalFont slantNormal). titleFont := LogicalFont familyName: 'Helvetica Neue' pointSize: 14 stretchValue: (LogicalFont stretchCondensed) weightValue: (LogicalFont weightBold) slantValue: (LogicalFont slantNormal). codeFont := LogicalFont familyName: 'Monaco' pointSize: 8. defaultFont := LogicalFont familyName: 'Helvetica Neue' pointSize: 9. Preferences setSystemFontTo: defaultFont. Preferences setListFontTo: defaultFont. Preferences setFlapsFontTo: menuFont. Preferences setHaloLabelFontTo: defaultFont. Preferences setMenuFontTo: menuFont. Preferences setWindowTitleFontTo: titleFont. Preferences setBalloonHelpFontTo: defaultFont. Preferences setCodeFontTo: codeFont. Preferences setButtonFontTo: defaultFont. -------- On 8 Jul 2009, at 14:37, Tudor Girba wrote: > Hi, > > I ran my usual font setting script (see below) on > pharo0.1-10371dev09.07.1 and the fonts did not get set. I ran the same > code on Pharo0.1Core-10371 and it worked. > > Any idea what is the difference between the dev and the core images > regarding this issue? Is it because of some initialization of the font > system? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Problem solving should be concentrated on describing > the problem in a way that is relevant for the solution." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

July 8, 2009

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

by StÃ©phane Ducasse

Yes. I have the impression that the representation should give the indication of the fuzzyness of the numbers. Now it would be nice that we are of a kind of fix point around this nice discussion :) From what I heard I would like to give a try to the solution proposed by nicolas and also see if we could improve the user experience. I should reread my scheme Stef > > On Jul 8, 2009, at 1:31 PM, Hernan Wilkinson wrote: >> >> So, I would like my programing language to be aware of this because >> most of the programers do not have such a good skill on numbers as >> you do, and I think programing language should be closer to people >> than to hardware. > > As a counterexample: we readily accept that precedence rules in > smalltalk are different than in mathematical notation, > 1 + 2 * 3 > is interpreted differently in the two notations. > > So IMO we should lean towards writing programming syntax, not shoe- > horning mathematical expectations in there too much. > (Mainly because trying to impose mathematical notation will give > wrinkling and ripping in all kinds of unexpected places in the > system). > > >> [...] and if you write 1.3, the object that represents that number >> is not going to be an instance of float but of scaledecimal or >> fraction or whatever, but not float... > > That only solves the issue of representing literals because: > > >> and all operations are made with exact representation. > > > > cannot be done for all operations: obvious ones like square root, log, > sin, etc and less obvious ones like #squared where you run out of > enough bits to maintain precision (in fixed-width implementations). > > > R > - > > > _______________________________________________ > 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] fonts

by Tudor Girba

Hi, I ran my usual font setting script (see below) on pharo0.1-10371dev09.07.1 and the fonts did not get set. I ran the same code on Pharo0.1Core-10371 and it worked. Any idea what is the difference between the dev and the core images regarding this issue? Is it because of some initialization of the font system? Cheers, Doru -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."

July 8, 2009

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

by Nicolas Cellier

I don't know :( In external world (C) i guess libraries should care of saving/restoring FPU state. For MultiThread, I guess this saving/restoring of FPU state occurs automatically when switching thread... We could mimic this at process switch with Process-bound variables... To limit the overhead, only Process with a declared interest in FPU could perform a Pre-activate, Pre-suspend action. Maybe something like: FPU >> changeFPUstatus: aFPUstatus (Processor activeProcess) saveSuspendedFPUStatus; setActivatedFPUStatus: aFPUstatus FPU setFPUstatus: aFPUstatus. Process >> saveSuspendedFPUStatus suspendedFPUstatus ifNil: [suspendedFPUstatus := FPU currentFPUstatus ]. Process >> suspend suspendedFPUstatus ifNotNil: [FPU setFPUstatus: suspendedFPUstatus ]. self suspendCore. Process >> activate activatedFPUstatus ifNotNil: [FPU changeFPUstatus: activatedFPUstatus]. self activateCore. Process >> restoreSuspendedFPUStatus suspendedFPUstatus ifNotNil: [ FPU setFPUstatus: suspendedFPUstatus. suspendedFPUstatus := activatedFPUstatus := nil]. Or more ellaborated with a statusStack... Nicolas 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Well, that's going to be an issue because the parts of the code will see > different VM behavior. Â Of course, however, the parts of the application > can change the VM's behavior on the fly to do as they like. Â In general, > however, I'd expect that kind of stuff to be rather problematic. Â What > would you do? > > Nicolas Cellier wrote: >> 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >> >>> FWIW... VW has two choices... a) fail the primitives when the answer is >>> INF or NaN, or b) return whatever the FPU says. Â Also, NaN and INF are >>> regular instances of Float and Double... >>> >>> >> >> What if some part of the code rely on signalling an Exception , and >> another part rely on answering exceptional values? >> >> Nicolas >> >> > > _______________________________________________ > 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] problem mixing Traits and Inheritance

by StÃ©phane Ducasse

On Jul 8, 2009, at 11:31 AM, Adrian Lienhard wrote: > 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. yes after our discussion it was clear that requirement was too static for a language like smalltalk. > > 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 > > > _______________________________________________ > 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