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

Re: [Pharo-project] Initial PetitC parser

by StÃ©phane Ducasse

in that case you have also cil in oCaml used by Frama-C. But I do not think that this is necessary to read all the ressources of earth. Javier contact nick because he started (I guess to implement a parser for C using PP). Stef On Apr 8, 2011, at 8:25 PM, Alexandre Bergel wrote: > A good source of ideas: http://www.sdml.info/projects/srcml/ > > Alexandre > > > On 8 Apr 2011, at 12:57, Javier PimÃ¡s wrote: > >> >> >> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 9, 2011

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

by Andres Valloud

At the end of the day, we still insist on expecting there won't be loss of information just because we wrote a decimal print string for a binary floating point number. One can get offended or irritated all one wants, but the reality of the situation won't change. I think the real solution to these "problems" is to implement decimal floating point as per IEEE-754/2008. Then you can write something like 1.2345 and know for a fact the number represented is *exactly* 1.2345. At least one VisualWorks platform already supports decimal floating point in hardware (IBM's POWER line). C99 extensions exist at least in draft form to extend C so that it supports decimal floating point. IBM has released a GPL library in ANSI C that implements the feature. I am not sure what is the deal with the license and if you can e.g.: interface to it without making your whole Smalltalk GPL. Food for thought... On 4/8/11 12:53 , Marcus Denker wrote: > > On Apr 8, 2011, at 7:48 PM, Hilaire Fernandes wrote: > >> Well, whatever the underneath representation, one can expect roundedTo: >> 2 to return a float with two decimals. >> > Sometimes I think we should use the resources that these amazing machines > give us these days to move programming languages closer to humans... > > There are better Float models than the ones that are implemented in hardware. > E.g. another INRIA Project is this GNU MPFR: > > "The MPFR library is a C library for multiple-precision floating-point computations with correct rounding." > > http://www.mpfr.org/ > > Why don't we make our language better at "real" math? The power in the machine is definitly there... > I am quite convincd that if there are normal programming languages in 50 years, the math part of them > will be closer to Mathematica then to C... > > Marcus > > > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

April 9, 2011

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

by StÃ©phane Ducasse

>> > I played with my own modest Smalltalk implementation relying on > LargeInteger arithmetic > http://www.squeaksource.com/ArbitraryPrecisionFl.html > It implements correct rounding to (if correct is round to nearest even). Nicolas would it be a path for you and us so that we use your library? Ok it will put pressure on you but like that we move one the next age. Stef

April 9, 2011

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

by StÃ©phane Ducasse

Nicolas would not you like the write (I can help) a two three 5 pages document for the next book on this topics? :) I would be gorgeous and everybody would love that Stef On Apr 8, 2011, at 7:18 PM, Nicolas Cellier wrote: > Yes nice example to exhibit in school > > This again happens even if performed exactly (then rounded to nearest Float) > (2.8 asTrueFraction roundTo: 0.01 asTrueFraction) asFloat > > As soon as you write 0.01 instead of (1/100) or (0.01s2), the worm is > in the fruit. > > Nicolas > > 2011/4/8 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: >> 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 9, 2011

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

by StÃ©phane Ducasse

On Apr 8, 2011, at 7:14 PM, Nicolas Cellier wrote: > 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. we should update the comment if it does not reflect that. > 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. Yes! > > 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 9, 2011

Re: [Pharo-project] Issue 3662 in pharo: build of 1.3 Full fails on Hudson

by StÃ©phane Ducasse

We should probably learn not to pop up information all the time. So I would remove it and wrtie the Transcript. Stef On Apr 8, 2011, at 3:29 PM, Igor Stasenko wrote: > On 6 February 2011 10:46, <pharo(a)googlecode.com> wrote: >> Status: Accepted >> Owner: marcus.d...(a)gmail.com >> Labels: Milestone-1.3 >> >> New issue 3662 by marcus.d...(a)gmail.com: build of 1.3 Full fails on Hudson >> http://code.google.com/p/pharo/issues/detail?id=3662 >> >> Related to OCompletion: >> >> An attempt to use interactive tools detected, while in non-interactive mode >> 6 February 2011 10:16:11 am >> >> VM: unix - i686 - linux - Squeak3.10.2 of '5 June 2008' [latest update: >> #7179] >> Image: Pharo1.3a [Latest update: #13038] >> >> SecurityManager state: >> Restricted: false >> FileAccess: true >> SocketAccess: true >> Working Dir /builds/workspace/Pharo 1.3/Pharo-1.3 >> Trusted Dir /builds/workspace/Pharo 1.3/Pharo-1.3/secure >> Untrusted Dir /builds/workspace/Pharo 1.3/Pharo-1.3/My Squeak >> >> NonInteractiveUIManager>>nonInteractive >> Receiver: a NonInteractiveUIManager >> Arguments and temporary variables: >> >> Receiver's instance variables: >> uiManager: a MorphicUIManager >> doNotQuitOnRestart: false >> >> >> NonInteractiveUIManager>>request:initialAnswer: >> Receiver: a NonInteractiveUIManager >> Arguments and temporary variables: >> queryString: ' > > > >>> Thanks for installing OCompletion! > > hehe.. what a joke :) > > So, what is solution? Remove thanks from OCompletion? > or just check if image is in interactive mode and don't thank to mr. > Hudson for installing it? :))) > > > > -- > Best regards, > Igor Stasenko AKA sig. >

April 9, 2011

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

by Schwab,Wilhelm K

Levente, I follow on why my shell script did not work. Your instructions got me going, but we still don't have an answer. The vm is running, but I cannot attach: http://lists.squeakfoundation.org/pipermail/vm-dev/2008-March/001840.html >From what I read, one answer is the get the image loaded and then attach - my problem is that the vm never gets far enough to actually load the image. Any ideas? Bill

April 8, 2011

Re: [Pharo-project] squeakdbx and Pharo 1.2

by Mariano Martinez Peck

On Fri, Apr 8, 2011 at 5:52 PM, Olivier Auverlot <olivier.auverlot(a)gmail.com > wrote: > Hi, > > I have used squeakdbx at work wednesday with Pharo 1.2.1 and a mysql > server. No problems :-) > > It makes me very happy when I hear about people using SqueakDBX that didn't even send one single email asking about help. It means that not only they succed with the Smalltalk part but also the OpenDBX :) Did you read the website as a help? Cheers Mariano Best regards > Olivier ;-) > > www.auverlot.fr > > What is state of squeakdbx in conjunction with Pharo 1.2? > Is anyone using it? Which backends are know to successfully > work? > > Thx > T. > > > > > > -- Mariano http://marianopeck.wordpress.com

April 8, 2011

Re: [Pharo-project] Initial PetitC parser

by Alexandre Bergel

> Can't macros and preprocessor directives be represented as just another nodes in the AST? In some cases yes, in some other no. The preprocessor allows you to completely change the syntax of C. This makes it very hard to parse. Consider the following valid C program: #define LEFTPARENT ( #define RIGHTPARENT ) int main LEFTPARENT void RIGHTPARENT { return 0; } 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 8, 2011

Re: [Pharo-project] Issue 3975 in pharo: References to ivars shortcut

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3975 by marcus.d...(a)gmail.com: References to ivars shortcut http://code.google.com/p/pharo/issues/detail?id=3975 in 13137

April 8, 2011