September 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] RE : RPackage, Monticello and the removal of PackageInfo

by GOUBIER Thierry

It's hard to converse with that Exchange webmail. Oh, Ok, here it goes. The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well). The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair. When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ? (RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't) One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system). Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Date d'envoi : vendredi 7 septembre 2012 21:37 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote: > Ok, > > It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way. > > Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(. you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun. > Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ? Yes Ideally we want one MCPackage - one RPackage + tags Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration. So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes. > Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ? You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.

Sept. 7, 2012

Re: [Pharo-project] [Pharo-users] Programmer Day @ Buenos Aires

by StÃ©phane Ducasse

thanks for the effort! Stef On Sep 7, 2012, at 9:22 PM, NicolÃ¡s Paez wrote: > Hello everyone, > > As may know, next Tuesday is the Programmer Day and a non-profit organisation in Buenos Aires in organizing a conference at the City Hall. I was invited to give a presentation in this conference about the any topic I considered relevant for the occasion and I decided to talk about Pharo. Other speakers will be talking about Node.js, Web APIs and Cloud Computing. > > If you are around Buenos Aires and want to attend, just register here, is free. > > Saludos! > NicoPaez >

Sept. 7, 2012

Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo

by StÃ©phane Ducasse

On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote: > Ok, > > It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way. > > Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(. you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun. > Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ? Yes Ideally we want one MCPackage - one RPackage + tags Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration. So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes. > Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ? You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.

Sept. 7, 2012

Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo

by StÃ©phane Ducasse

> > Good thing to have a rationale for where you want to be going and why... > It would be interesting to have it documented.For example: > - A package is holding strong references to class/methods belonging to > it or not? did you read the class comment of RPackage? Because this is explained normally. Now the answer a RPackage does not hold references to class or compiledMethod but to class names and selectors so that it could potentially be used for now working classes. > - Does a class know (directly point to) its package, or is it a > service provided by some helper object? RPackageOrganizer so far we did not modify class but manage the invariant class/package using announcement > - Does a method know (directly point to) its package, or is it a > service provided by some helper object? CompiledMethod package and this is manager by PackageOrganizer > - Are there unpackaged classes/methods (pointing to nil?), is there a > service to discover them? Not that I know. > - What is the relation with st80 classification (class categories and > method protocols)? Is it completely orthogonal? Totally. > - Should class/methods have multi-classification (belong to several > categories protocols)? A class belongs to only one packages Now you can have tags (I implemented it but may be we will not use it) to have virtual categories For methods packages are orthogonal to categories (now we are maintaining for the moment the * notation). > You can call that tags if you want... > pro/cons for each point > > Then it's another thing to tell how you will reach these goals, and > if/how you will maintain compatibility with MC (a vital tool) or other > tools (browsers nautilus RB change list/change sorter etc...) - which > might be possible by faking categories/protocols. the compatibility is first when you load -> * star notation in the mcz -> category announcement -> extension in the repackage saving -> we should check that the package and the categories get the same contents -> saving with * in category So for now we will maintain a compatibility and in the future we will see. > For french: Je dirai qu'on a l'eau Ã la bouche, mais qu'on reste un > peu sur notre faim ;) > >>> So, we rolled back... >>> >>> Attempt 2) Let each Class Category be one RPackage. >>> >>> Ok, this is very simple (and that's the beauty on it)... each tools and >>> conventions will match perfectly. Only problem here is that now, Monticello >>> is not compatible anymore. So, we worked on the concept of RPackageSet, to >>> replace PackageInfo use into Monticelo packages (we need them to load/save >>> packages and stay compatible). RPackageSet is exactly what its name says: a >>> set of RPackage instances (created on the fly, by pattern matching, so, is >>> still some kind of a hack), that is polymorphic with PackageInfo in the >>> monticello context. Thus, everything in the system can remain unchanged (or >>> almost no change, the refactoring engine needs some adjusts). >>> One extra bonus with this approach is that it let us think on more cool >>> refactors in the future: we can for instance replace class categories (now a >>> symbol) with an RPackage... and continue simplifying the system in several >>> ways. >>> >>> ...and that's where we are now. >>> We are working hard on stabilizing the system, but that will take still >>> some days more... after that, we will be really close to the PackageInfo >>> removal. >>> > > Good, if the system was too complex in order to analyze all > implications and completely planify the change path, then trial and > error might be a solution, it's not a shame, but you have to write > your goals to better remind them, and maybe make some amendments to > your rationale because of some unanticipated features (and providing > some degree of compatibility can lead to additional features). Compatibitilty of MC and configurations will be maintain. If we could have got rid of the last one it would have solved a lot of our pain. > >>> PLEASE: PackageInfo users, take this into account: PackageInfo will pass >>> away... and is one of the parts of the system that cannot be deprecated, >>> they has to be completely removed, prepare your tools for the rise of >>> RPackage :) >>> >>> Cheers, >>> Esteban >>> > > Such a change will require a stable and if possible well documented > API (which should be quite straightforward once you have rationalized > your design). Have a look at the RPackage class. It is really nice. The pain is not it, the pain is the system and the pattern matching and event and â¦. and having packages and categories. Stef > > Nicolas > >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Sept. 7, 2012

[Pharo-project] Programmer Day @ Buenos Aires

by NicolÃ¡s Paez

Hello everyone, As may know, next Tuesday is the Programmer Day<http://www.programmerday.info/>and a non-profit organisation in Buenos Aires in organizing a conference at the City Hall. I was invited to give a presentation in this conference about the any topic I considered relevant for the occasion and I decided to talk about Pharo. Other speakers will be talking about Node.js, Web APIs and Cloud Computing. If you are around Buenos Aires and want to attend, just register here<http://www.mug.org.ar/Eventos/3806.aspx>, is free. Saludos! NicoPaez <http://nicopaez.wordpress.com/>

Sept. 7, 2012

Re: [Pharo-project] nil key in last literal in instance side methods (reproducible)

by StÃ©phane Ducasse

On > No, I'm just suggesting a poor man's simple diff in a mailing list, > like squeak trunk. > -1) inbox diff : you open a review to the whole community for comments, > -2) commit phase (whatever the checks you perform now are unchanged, > except you have to take above review into account) > -3) trunk diff : you open a last chance review (or post mortem > analysis) to retract/correct commits > > It's totally informal, and why would it work? You have to answer this > question first: > - how many people have ubiquitous web access to read the code and > qualified enough to emit a useful comment? > - how many people are downloading an image, updating to some version, > opening a MC browser, browsing the diffs? > > You are proposing a much more ellaborated process to review code > before integration. > I agree, this information belongs to issue tracker. > But formalizing and programming this process is involving (think about > concurrent solution, roles, requests/answers timelines etc...) > As you said, who will do it? > > From pragmatic POV, I prefer a light process that provides some help, > than no help at all (which is close to what you get with current state > of issue tracker). > The code producing the diff and sendig the mail already exist, (you'll > have to handle SLICE though)... Bonus: it's Smalltalk code. > > If you prefer to wait for something better, then let's waitâ¦ is there a setting in ss3 that can do that? How this is done in squeak? > > Nicolas >

Sept. 7, 2012

[Pharo-project] RE : RPackage, Monticello and the removal of PackageInfo

by GOUBIER Thierry

Ok, It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way. Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(. Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ? Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ? Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] Date d'envoi : vendredi 7 septembre 2012 18:13 Ã : Pharo-project(a)lists.gforge.inria.fr Development Objet : [Pharo-project] RPackage, Monticello and the removal of PackageInfo Hi, As you know, we want to replace the old PackageInfo structure with RPackage. Last weeks Pharo 2.0 has been really unstable because of this effort, and it will be unstable yet a few days more, so I want to review the actions we are taking, so you know why this happnes and the result we want to obtain. So... first: Why replace PackageInfo and PackageOrganizer? The short answer is: because they suck :) The more or less long answer is: because their existence introduces a lot of penalties in the system, and forces to a lot of workarounds to manage what should be a simple system categories manager... take for instance the match MCPackage-PackageInfo-Class categories. Each MCPackage maps to a unique PackageInfo, but package info contains string pattern matched class categories. Tools uses this and well... performance is frankly disappointing in many case. Like this, there are lots of other reasons. So... RPackage will solve this by keeping a view of the system, not having to calculate it everytime. RPackage will keep also the list of classes, extension, etc. so tools can operate with them in a better/faster way. Question is: How to migrate in the less painful way? Attempt 1) Let each RPackage be one PackageInfo. We first thought this was the best path so, we spend some time moving in that direction. The advantage is that migration from Monticello and PackageInfo is trivial, but then the problems started to happen: PackageInfo (and current RPackage) contains N class categories so, there is an impedance mismatch between what we was seeing and what users/tools expect (they work with class categories, not with RPackage or PackageInfo). To solve that, we added class categories as RPackage tags (yep RPackage allows you to tag classes). But then we need to update in ver annoying ways the tools. And we also has now the fact that class categories are now a tag into an RPackage. Something really obscure and that was causing a lot of pain... So, we rolled back... Attempt 2) Let each Class Category be one RPackage. Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways. ...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal. PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :) Cheers, Esteban

Sept. 7, 2012

Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo

by Nicolas Cellier

2012/9/7 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I am also for the 2 option :) > > > On Fri, Sep 7, 2012 at 6:13 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> Hi, >> >> As you know, we want to replace the old PackageInfo structure with >> RPackage. Last weeks Pharo 2.0 has been really unstable because of this >> effort, and it will be unstable yet a few days more, so I want to review the >> actions we are taking, so you know why this happnes and the result we want >> to obtain. >> So... first: Why replace PackageInfo and PackageOrganizer? The short >> answer is: because they suck :) The more or less long answer is: because >> their existence introduces a lot of penalties in the system, and forces to a >> lot of workarounds to manage what should be a simple system categories >> manager... take for instance the match MCPackage-PackageInfo-Class >> categories. Each MCPackage maps to a unique PackageInfo, but package info >> contains string pattern matched class categories. Tools uses this and >> well... performance is frankly disappointing in many case. Like this, there >> are lots of other reasons. >> So... RPackage will solve this by keeping a view of the system, not having >> to calculate it everytime. RPackage will keep also the list of classes, >> extension, etc. so tools can operate with them in a better/faster way. >> >> Question is: How to migrate in the less painful way? >> >> Attempt 1) Let each RPackage be one PackageInfo. >> >> We first thought this was the best path so, we spend some time moving in >> that direction. The advantage is that migration from Monticello and >> PackageInfo is trivial, but then the problems started to happen: PackageInfo >> (and current RPackage) contains N class categories so, there is an impedance >> mismatch between what we was seeing and what users/tools expect (they work >> with class categories, not with RPackage or PackageInfo). >> To solve that, we added class categories as RPackage tags (yep RPackage >> allows you to tag classes). But then we need to update in ver annoying ways >> the tools. And we also has now the fact that class categories are now a tag >> into an RPackage. Something really obscure and that was causing a lot of >> pain... >> Good thing to have a rationale for where you want to be going and why... It would be interesting to have it documented.For example: - A package is holding strong references to class/methods belonging to it or not? - Does a class know (directly point to) its package, or is it a service provided by some helper object? - Does a method know (directly point to) its package, or is it a service provided by some helper object? - Are there unpackaged classes/methods (pointing to nil?), is there a service to discover them? - What is the relation with st80 classification (class categories and method protocols)? Is it completely orthogonal? - Should class/methods have multi-classification (belong to several categories protocols)? You can call that tags if you want... pro/cons for each point Then it's another thing to tell how you will reach these goals, and if/how you will maintain compatibility with MC (a vital tool) or other tools (browsers nautilus RB change list/change sorter etc...) - which might be possible by faking categories/protocols. For french: Je dirai qu'on a l'eau Ã la bouche, mais qu'on reste un peu sur notre faim ;) >> So, we rolled back... >> >> Attempt 2) Let each Class Category be one RPackage. >> >> Ok, this is very simple (and that's the beauty on it)... each tools and >> conventions will match perfectly. Only problem here is that now, Monticello >> is not compatible anymore. So, we worked on the concept of RPackageSet, to >> replace PackageInfo use into Monticelo packages (we need them to load/save >> packages and stay compatible). RPackageSet is exactly what its name says: a >> set of RPackage instances (created on the fly, by pattern matching, so, is >> still some kind of a hack), that is polymorphic with PackageInfo in the >> monticello context. Thus, everything in the system can remain unchanged (or >> almost no change, the refactoring engine needs some adjusts). >> One extra bonus with this approach is that it let us think on more cool >> refactors in the future: we can for instance replace class categories (now a >> symbol) with an RPackage... and continue simplifying the system in several >> ways. >> >> ...and that's where we are now. >> We are working hard on stabilizing the system, but that will take still >> some days more... after that, we will be really close to the PackageInfo >> removal. >> Good, if the system was too complex in order to analyze all implications and completely planify the change path, then trial and error might be a solution, it's not a shame, but you have to write your goals to better remind them, and maybe make some amendments to your rationale because of some unanticipated features (and providing some degree of compatibility can lead to additional features). >> PLEASE: PackageInfo users, take this into account: PackageInfo will pass >> away... and is one of the parts of the system that cannot be deprecated, >> they has to be completely removed, prepare your tools for the rise of >> RPackage :) >> >> Cheers, >> Esteban >> Such a change will require a stable and if possible well documented API (which should be quite straightforward once you have rationalized your design). Nicolas > > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 7, 2012

Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo

by Mariano Martinez Peck

I am also for the 2 option :) On Fri, Sep 7, 2012 at 6:13 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > As you know, we want to replace the old PackageInfo structure with > RPackage. Last weeks Pharo 2.0 has been really unstable because of this > effort, and it will be unstable yet a few days more, so I want to review > the actions we are taking, so you know why this happnes and the result we > want to obtain. > So... first: Why replace PackageInfo and PackageOrganizer? The short > answer is: because they suck :) The more or less long answer is: because > their existence introduces a lot of penalties in the system, and forces to > a lot of workarounds to manage what should be a simple system categories > manager... take for instance the match MCPackage-PackageInfo-Class > categories. Each MCPackage maps to a unique PackageInfo, but package info > contains string pattern matched class categories. Tools uses this and > well... performance is frankly disappointing in many case. Like this, there > are lots of other reasons. > So... RPackage will solve this by keeping a view of the system, not having > to calculate it everytime. RPackage will keep also the list of classes, > extension, etc. so tools can operate with them in a better/faster way. > > Question is: How to migrate in the less painful way? > > Attempt 1) Let each RPackage be one PackageInfo. > > We first thought this was the best path so, we spend some time moving in > that direction. The advantage is that migration from Monticello and > PackageInfo is trivial, but then the problems started to happen: > PackageInfo (and current RPackage) contains N class categories so, there is > an impedance mismatch between what we was seeing and what users/tools > expect (they work with class categories, not with RPackage or PackageInfo). > To solve that, we added class categories as RPackage tags (yep RPackage > allows you to tag classes). But then we need to update in ver annoying ways > the tools. And we also has now the fact that class categories are now a tag > into an RPackage. Something really obscure and that was causing a lot of > pain... > > So, we rolled back... > > Attempt 2) Let each Class Category be one RPackage. > > Ok, this is very simple (and that's the beauty on it)... each tools and > conventions will match perfectly. Only problem here is that now, Monticello > is not compatible anymore. So, we worked on the concept of RPackageSet, to > replace PackageInfo use into Monticelo packages (we need them to load/save > packages and stay compatible). RPackageSet is exactly what its name says: a > set of RPackage instances (created on the fly, by pattern matching, so, is > still some kind of a hack), that is polymorphic with PackageInfo in the > monticello context. Thus, everything in the system can remain unchanged (or > almost no change, the refactoring engine needs some adjusts). > One extra bonus with this approach is that it let us think on more cool > refactors in the future: we can for instance replace class categories (now > a symbol) with an RPackage... and continue simplifying the system in > several ways. > > ...and that's where we are now. > We are working hard on stabilizing the system, but that will take still > some days more... after that, we will be really close to the PackageInfo > removal. > > PLEASE: PackageInfo users, take this into account: PackageInfo will pass > away... and is one of the parts of the system that cannot be deprecated, > they has to be completely removed, prepare your tools for the rise of > RPackage :) > > Cheers, > Esteban > > -- Mariano http://marianopeck.wordpress.com

Sept. 7, 2012

Re: [Pharo-project] Rounding float question again

by Nicolas Cellier

2012/9/7 Denis Kudriashov <dionisiydk(a)gmail.com>: > Thank's for your answer. > Only one of your solutions works: > (146.015 asMinimalDecimalFraction roundTo: 1/100) asFloat => 146.02 > > Others not works: > > (146.015 * 100.0) rounded / 100.0 => 146.01 > (146.015 asFraction roundTo: 1/100) asFloat => 146.01 > > That's expected, '146.015' asFloat is already smaller than (146015/1000) so if you convert the float value asFraction or asScaledDecimal, it's too late, rounding error is already there. You have to use Fraction, ScaledDecimal or FixedDecimal of Chris right from the beginning, and don't use Float at all. > 2012/9/7 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> >> >> Hi Denis, >> If you decompose the operation performed by round: >> >> (146.015 / 0.01) rounded * 0.01 >> >> '146.015' asFloat is inexact >> '0.01' asFloat is inexact >> / 0.01 operation is inexact >> '0.01' asFloat is inexact (again) >> * 0.01 operation is inexact >> >> That means cumulating 5 inexact operations, how do you say "jouer Ã la >> roulette russe"? >> >> Pharo guys did propose a better scheme >> >> (146.015 * 100.0) rounded / 100.0 >> >> Since '100.0' asFloat is exact, that leave only 2 inexact operations >> and works much better (and we know the last one rounds exactly). >> >> But if (146.015 asFraction < 146.015s3) then you still have a problem >> with inexactness of original value. >> >> I see two solutions for this root problem: >> - don't use Float, but Fraction or ScaledDecimals >> - use a trick, asMinimalDecimalFraction which I proposed in >> http://code.google.com/p/pharo/issues/detail?id=4957 that will convert >> ('146.015' asFloat) to the exact fraction that is printed >> 146015/1000... >> >> (x asMinimalDecimalFraction roundTo: 1/100) asFloat would thus be >> close to your requirements... >> >> Nicolas >> >> 2012/9/7 Denis Kudriashov <dionisiydk(a)gmail.com>: >> > Hello. >> > >> > I know there are many similar questions. >> > >> > Maybe somebody give me fast answer. >> > >> > 146.015 roundTo: 0.01 => 146.01 >> > >> > I guess internal representation of 146.015 is something like >> > 146.014999999999... >> > That's why rounding result is 146.01 >> > >> > But how I can round arbitrary float my math root? >> > How to fix my example to get 146.02? >> > >> > Best regards, >> > Denis >> >

Sept. 7, 2012