April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Unexpected behavior of roundTo:

by Schwab,Wilhelm K

+1. This seems like an extension of "never test equality on floats." ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Friday, April 08, 2011 1:14 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Unexpected behavior of roundTo: Once more, Floats are inexact. 0.01 ~= 0.01s2 The name #absPrintExactlyOn:base: is lying, it does not print exactly, but it prints the shortest decimal representation than will be rounded to the same Float when read back. To print it exactly, you need to use #printShowingDecimalPlaces: indeed. As every finite Float is a represented internally as a Fraction with a denominator being a power of 2, every finite Float has a decimal representation with a finite number of decimals digits (just multiply numerator and denominator with adequate power of 5, and you'll get the digits). So try: 0.01 printShowingDecimalPlaces: 59 -> 0.01000000000000000020816681711721685132943093776702880859375 You see that even if you try to execute the operation without rounding error, then convert it back to Float, you get the error: (2.8011416510246336 asTrueFraction roundTo: 0.01 asTrueFraction) asFloat -> 2.8000000000000003 When you perform the #roundTo: operations in Float inexact arithmetic, you may accumulate more rounding errors, so the result may vary. If you want to round to an exact hundredth, then use exact arithmetic and try: 2.8011416510246336 roundTo: 0.01s2 Hope it helps to consider Float for what they are, inexact but fast. Don't put too much expectations on them. Nicolas 2011/4/8 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > It looks like a known issue: > > printShowingDecimalPlaces: placesDesired > "This implementation avoids any rounding error caused by rounded or > roundTo: " > ^ self asTrueFraction printShowingDecimalPlaces: placesDesired > > > > Le 08/04/2011 18:47, Hilaire Fernandes a Ã©crit : >> 2.8011416510246336 roundTo: 0.01 >> >> returns >> >> 2.8000000000000003 >> >> >> Tested with 1.2 >> >> >> Should I fill a ticket, I don't see anythings similar? >> >> Hilaire >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > >

April 8, 2011

Re: [Pharo-project] [Vm-dev] FW: Debugging Cog crash

by Schwab,Wilhelm K

"You still didn't answer where you got the VM." http://gforge.inria.fr/frs/download.php/28439/Pharo-1.2.1-CogOneClick.zip ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Friday, April 08, 2011 11:56 AM To: Pharo-project(a)lists.gforge.inria.fr; Squeak Virtual Machine Development Discussion Subject: Re: [Pharo-project] [Vm-dev] FW: Debugging Cog crash Levente, The image will not load at all. It simply dies with "Segmentation fault" - NOTHING else happens. gdb is maybe a possibility, but it is not an approach I ordinarily take, so some guidance would be helpful. I have a reproducible crash, but poor access to the affected box. Bill On Fri, 8 Apr 2011, Schwab,Wilhelm K wrote: > > Gratuitous default recipient... > > If there is a verbose dump option or other diagnostic efforts that will help, I will do my best to run them and report the results. I am fairly certain the vm is 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54]' (can verify later today), but this happened with an earlier Cog one-click too. There is something about the machine (UUID again?) that is different. I do not have root access to it, but I can get to a terminal. Ubuntu 10.10. Where did you download the VM? Does it crash when you're trying to evaluate [UUID new]? Did you try gdb? Levente ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Friday, April 08, 2011 11:42 AM To: Pharo-project(a)lists.gforge.inria.fr; Squeak Virtual Machine Development Discussion Subject: Re: [Pharo-project] [Vm-dev] FW: Debugging Cog crash Dave, It was, I did :) No help :( What else can I try? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] Sent: Friday, April 08, 2011 10:32 AM To: Squeak Virtual Machine Development Discussion Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] FW: Debugging Cog crash Yes, the libuuid.so bug would be a likely suspect. If the UUIDPlugin was built as an external library, just delete it and you will probably be good to go. If you need further info, look here: http://bugs.squeak.org/view.php?id=7358 Dave On Fri, Apr 08, 2011 at 07:58:39AM -0400, Schwab,Wilhelm K wrote: > > Gratuitous default recipient... > > If there is a verbose dump option or other diagnostic efforts that will help, I will do my best to run them and report the results. I am fairly certain the vm is 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54]' (can verify later today), but this happened with an earlier Cog one-click too. There is something about the machine (UUID again?) that is different. I do not have root access to it, but I can get to a terminal. Ubuntu 10.10. > > > ________________________________________ > From: Schwab,Wilhelm K > Sent: Friday, April 08, 2011 7:44 AM > To: Mariano Martinez Peck > Subject: RE: [Pharo-project] Debugging Cog crash > > Mariano, > > I first identified this problem/opportunity a while ago. At the time, there was no log - the vm just died. I can sniff around again as there might be one this time. My question at the time was whether there was something that I could enable to perhaps get more info. > > The output from the vm is, and I quote<g> "Segmentation fault". There is no other output. Perhaps it does not get far enough to have a call stack?? > > Bill > > > > ________________________________________ > From: Mariano Martinez Peck [marianopeck(a)gmail.com] > Sent: Friday, April 08, 2011 3:42 AM > To: Squeak Development Discussion Virtual Machine; Pharo Development > Cc: Schwab,Wilhelm K > Subject: Re: [Pharo-project] Debugging Cog crash > > also...shouldn't be a crash/dump file somewhere? > > can you write the output of the console where you invoke the VM into a file ? (using > to redirect) > > Cheers > > Mariano > > On Thu, Apr 7, 2011 at 11:10 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: > Hello all, > > I have an account on an Ubuntu terminal server (at least I think that's what it would be called) running 10.10. The Cog one-click image crashes with "Segmentation fault" (if run from a terminal); the legacy VM seems to run the image nicely on the box. Any ideas? I will happily collect any facts that will be of help, but I need some > direction. > > Bill > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

April 8, 2011

Re: [Pharo-project] Unexpected behavior of roundTo:

by Nicolas Cellier

Once more, Floats are inexact. 0.01 ~= 0.01s2 The name #absPrintExactlyOn:base: is lying, it does not print exactly, but it prints the shortest decimal representation than will be rounded to the same Float when read back. To print it exactly, you need to use #printShowingDecimalPlaces: indeed. As every finite Float is a represented internally as a Fraction with a denominator being a power of 2, every finite Float has a decimal representation with a finite number of decimals digits (just multiply numerator and denominator with adequate power of 5, and you'll get the digits). So try: 0.01 printShowingDecimalPlaces: 59 -> 0.01000000000000000020816681711721685132943093776702880859375 You see that even if you try to execute the operation without rounding error, then convert it back to Float, you get the error: (2.8011416510246336 asTrueFraction roundTo: 0.01 asTrueFraction) asFloat -> 2.8000000000000003 When you perform the #roundTo: operations in Float inexact arithmetic, you may accumulate more rounding errors, so the result may vary. If you want to round to an exact hundredth, then use exact arithmetic and try: 2.8011416510246336 roundTo: 0.01s2 Hope it helps to consider Float for what they are, inexact but fast. Don't put too much expectations on them. Nicolas 2011/4/8 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > It looks like a known issue: > > printShowingDecimalPlaces: placesDesired > Â Â Â Â "This implementation avoids any rounding error caused by rounded or > roundTo: " > Â Â Â Â ^ self asTrueFraction printShowingDecimalPlaces: placesDesired > > > > Le 08/04/2011 18:47, Hilaire Fernandes a Ã©crit : >> 2.8011416510246336 roundTo: 0.01 >> >> returns >> >> Â 2.8000000000000003 >> >> >> Tested with 1.2 >> >> >> Should I fill a ticket, I don't see anythings similar? >> >> Hilaire >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > >

April 8, 2011

Re: [Pharo-project] Unexpected behavior of roundTo:

by Hilaire Fernandes

Even better: 2.8 truncateTo: 0.01 -> 2.8000000000000003 Le 08/04/2011 18:52, Hilaire Fernandes a Ã©crit : > It looks like a known issue: > > printShowingDecimalPlaces: placesDesired > "This implementation avoids any rounding error caused by rounded or > roundTo: " > ^ self asTrueFraction printShowingDecimalPlaces: placesDesired > > > > Le 08/04/2011 18:47, Hilaire Fernandes a Ã©crit : >> 2.8011416510246336 roundTo: 0.01 >> >> returns >> >> 2.8000000000000003 >> >> >> Tested with 1.2 >> >> >> Should I fill a ticket, I don't see anythings similar? >> >> Hilaire >> > > -- Education 0.2 -- http://blog.ofset.org/hilaire

April 8, 2011

Re: [Pharo-project] Initial PetitC parser

by Javier PimÃ¡s

On Fri, Apr 8, 2011 at 1:08 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > What is tricky with analyzing C are macros and preprocessors directive. > srcML does a satisfactory job. But indeed, having a solution based on > PetitParser is indeed promising. Yes, and I don't know what to do, and would like to know if you or someone else have any idea of how to solve it. I will think some approach, but if you have some idea to share it would be better so I go directly to a good solution. I'm thinking that to feed the parser I'll have to preprocess the string with another parser, and make a string to string conversion by having a set of defines and paths so that #includes and #ifdefs work. But probably I'll need a cache because the generated string will be huge. What do you think? Regards, Javier. > > Cheers, > Alexandre > > > On 7 Apr 2011, at 23:53, Javier PimÃ¡s wrote: > > > by the way, the grammar is based on > > > > http://www.quut.com/c/ANSI-C-grammar-l-1998.html > > > > and > > > > http://www.quut.com/c/ANSI-C-grammar-y.html > > > > I'd be very grateful if you contribute to cover the full extent of it! > > > > > > On Fri, Apr 8, 2011 at 12:37 AM, Javier PimÃ¡s < > elpochodelagente(a)gmail.com> wrote: > > Hi, > > I took some time to start developing a C parser with PetitParser. I > used the slides of the smalltalk school, they were pretty useful, and after > some hours I have a very basic tokens scanner. The idea of this work is to > be able to feed the parser with C headers and automagically get the C > bindings done in smalltalk. > > > > Now I have to actually start doing something with the scanned code. How > should I do that, all in the same class? What if I want to generate bindings > for different kinds of FFIs? Other question, how should I handle > preprocessing? (now there isn't any kind of preprocessing) > > > > You can see the code, download it and commit improvements to the repo at > www.squeaksource.com/Bindings > > > > Anybody who is interested is welcomed to help in the development! > > > > Regards, > > Javier. > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > > > > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Javier PimÃ¡s Ciudad de Buenos Aires

April 8, 2011

Re: [Pharo-project] Unexpected behavior of roundTo:

by Hilaire Fernandes

It looks like a known issue: printShowingDecimalPlaces: placesDesired "This implementation avoids any rounding error caused by rounded or roundTo: " ^ self asTrueFraction printShowingDecimalPlaces: placesDesired Le 08/04/2011 18:47, Hilaire Fernandes a Ã©crit : > 2.8011416510246336 roundTo: 0.01 > > returns > > 2.8000000000000003 > > > Tested with 1.2 > > > Should I fill a ticket, I don't see anythings similar? > > Hilaire > -- Education 0.2 -- http://blog.ofset.org/hilaire

April 8, 2011

Re: [Pharo-project] Initial PetitC parser

by Javier PimÃ¡s

On Fri, Apr 8, 2011 at 3:41 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Javier, > > On 8 Apr 2011, at 05:37, Javier PimÃ¡s wrote: > > > Hi, > > I took some time to start developing a C parser with PetitParser. I > used the slides of the smalltalk school, they were pretty useful, and after > some hours I have a very basic tokens scanner. The idea of this work is to > be able to feed the parser with C headers and automagically get the C > bindings done in smalltalk. > > > Nice. I took a quick look. If you want to scale, please write tests (one > small example per test). Grammars become complex and if you do not have > close to 100% coverage, you will get stuck. > > OK, I'll try. One question regarding PP: I started coding by looking at PPArithmeticParser, and noticed that for each sub-grammar you have a method and an instance named the same way, is that a requirement? If I don't add the instances this sub-grammars are not shown in the PPBrowser. Regards, Javier. Cheers, > Doru > > > > > Now I have to actually start doing something with the scanned code. How > should I do that, all in the same class? What if I want to generate bindings > for different kinds of FFIs? Other question, how should I handle > preprocessing? (now there isn't any kind of preprocessing) > > > > You can see the code, download it and commit improvements to the repo at > www.squeaksource.com/Bindings > > > > Anybody who is interested is welcomed to help in the development! > > > > Regards, > > Javier. > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > > > -- Javier PimÃ¡s Ciudad de Buenos Aires

April 8, 2011

[Pharo-project] Unexpected behavior of roundTo:

by Hilaire Fernandes

2.8011416510246336 roundTo: 0.01 returns 2.8000000000000003 Tested with 1.2 Should I fill a ticket, I don't see anythings similar? Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

April 8, 2011

Re: [Pharo-project] Initial PetitC parser

by Javier PimÃ¡s

On Fri, Apr 8, 2011 at 2:05 AM, Ricardo Moran <richi.moran(a)gmail.com> wrote: > > On Fri, Apr 8, 2011 at 12:37 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > >> Hi, >> I took some time to start developing a C parser with PetitParser. I >> used the slides of the smalltalk school, they were pretty useful, and after >> some hours I have a very basic tokens scanner. The idea of this work is to >> be able to feed the parser with C headers and automagically get the C >> bindings done in smalltalk. >> >> > Hi Javier, > > That's a great project and I'm highly interested in it. I'm not experienced > in PetitParser so I won't be a lot of help, but I'll give it a try. > excelent > > >> Now I have to actually start doing something with the scanned code. How >> should I do that, all in the same class? What if I want to generate bindings >> for different kinds of FFIs? Other question, how should I handle >> preprocessing? (now there isn't any kind of preprocessing) >> > > Maybe you already thought of this but what if you make your parser build > some simple C AST and then you make specific visitors for each kind of FFI? > I didn't think of it because I never did a parser before and have no experience with PP. Is it the clean way to do it? How is that implented? maybe have for each expression in the bnf a class that represents it, and make PP create the instances? > Cheers > Richo > > >> >> You can see the code, download it and commit improvements to the repo at >> www.squeaksource.com/Bindings >> >> Anybody who is interested is welcomed to help in the development! >> >> Regards, >> Javier. >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > -- Javier PimÃ¡s Ciudad de Buenos Aires

April 8, 2011

Re: [Pharo-project] Initial PetitC parser

by Alexandre Bergel

What is tricky with analyzing C are macros and preprocessors directive. srcML does a satisfactory job. But indeed, having a solution based on PetitParser is indeed promising. Cheers, Alexandre On 7 Apr 2011, at 23:53, Javier PimÃ¡s wrote: > by the way, the grammar is based on > > http://www.quut.com/c/ANSI-C-grammar-l-1998.html > > and > > http://www.quut.com/c/ANSI-C-grammar-y.html > > I'd be very grateful if you contribute to cover the full extent of it! > > > On Fri, Apr 8, 2011 at 12:37 AM, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > Hi, > I took some time to start developing a C parser with PetitParser. I used the slides of the smalltalk school, they were pretty useful, and after some hours I have a very basic tokens scanner. The idea of this work is to be able to feed the parser with C headers and automagically get the C bindings done in smalltalk. > > Now I have to actually start doing something with the scanned code. How should I do that, all in the same class? What if I want to generate bindings for different kinds of FFIs? Other question, how should I handle preprocessing? (now there isn't any kind of preprocessing) > > You can see the code, download it and commit improvements to the repo at www.squeaksource.com/Bindings > > Anybody who is interested is welcomed to help in the development! > > Regards, > Javier. > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 8, 2011