June 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Confused about Floats on 64-bit Pharo 6

by Sven Van Caekenberghe

> On 1 Jun 2017, at 15:29, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi Sven, > SmallFloat64 consumes 3bits taken from exponent for tagging immediate value. > So very small values and very large values don't fit in SmallFloat64 and require a BoxedFloat64. > > I don't think we should change emin and emax though. > The reason is that emin and emax are public methods for accessing the underlying floating point model. > Small/Boxed Float are implementation details, they both implement the same float model with different levels of optimization. If I am on 64-bit and SmallFloat64 is used (the default, right ?), then I have a smaller exponent range (right ?), so I should be able to access meta info about the currently applying limits, no ? I recently added that to NeoJSON to protect against overly large/small exponents when reading floats, like 1e1231231231. I understand about this being an implementation detail, but if the choice of implementation changes the range, it seems important to be able to know this, one way or another. > For the rest of the report, it's a bug we will have to track catch and fix ASAP Thanks! > 2017-06-01 14:53 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I am working in Pharo 6 RC, 64-bit on macOS 10.12.5 > > One of the tests of STON fails, #testFloat and I got confused about Floats on 64-bit Pharo 6. > > Is there a write-up that explains the new/changed situation ? > > Because, what I see is the following: > > Float pi. > 1.3. > > Both the above give me SmallFloat64 instances. > > (10 raisedTo: 100) asFloat. > 1.0e100. > 10.0 raisedTo: 100. > > All 3 above give me BoxedFloat64 instance. > But the first 2 give wrong results (correct answer is 1.0e100) ! > > (10 raisedTo: 100) asFloat. > "5.15323791002091e91" > > 1.0e100. > "5.15323791002091e91" > > Why ? > > BoxedFloat64 allInstances. > SmallFloat64 allInstances. > > The first is not-empty, the second is (logical since these are immediate values). > I thought BoxedFloat64 should not be used in 64-bit ? > > Also, should #emin, #emax and friends not be different for SmallFloat64 ? > > Sven >

June 1, 2017

Re: [Pharo-dev] Confused about Floats on 64-bit Pharo 6

by Nicolas Cellier

Can't reproduce in Squeak trunk 64bits with latest opensmalltalk-VM, So for me it should'nt be a VM problem, (or it's fixed already). 2017-06-01 15:31 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-06-01 15:29 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> Hi Sven, >> SmallFloat64 consumes 3bits taken from exponent for tagging immediate >> value. >> So very small values and very large values don't fit in SmallFloat64 and >> require a BoxedFloat64. >> >> I don't think we should change emin and emax though. >> The reason is that emin and emax are public methods for accessing the >> underlying floating point model. >> Small/Boxed Float are implementation details, they both implement the >> same float model with different levels of optimization. >> >> For the rest of the report, it's a bug we will have to track catch and >> fix ASAP >> >> (is looks like a shift of 1 bit) > > >> 2017-06-01 14:53 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> I am working in Pharo 6 RC, 64-bit on macOS 10.12.5 >>> >>> One of the tests of STON fails, #testFloat and I got confused about >>> Floats on 64-bit Pharo 6. >>> >>> Is there a write-up that explains the new/changed situation ? >>> >>> Because, what I see is the following: >>> >>> Float pi. >>> 1.3. >>> >>> Both the above give me SmallFloat64 instances. >>> >>> (10 raisedTo: 100) asFloat. >>> 1.0e100. >>> 10.0 raisedTo: 100. >>> >>> All 3 above give me BoxedFloat64 instance. >>> But the first 2 give wrong results (correct answer is 1.0e100) ! >>> >>> (10 raisedTo: 100) asFloat. >>> "5.15323791002091e91" >>> >>> 1.0e100. >>> "5.15323791002091e91" >>> >>> Why ? >>> >>> BoxedFloat64 allInstances. >>> SmallFloat64 allInstances. >>> >>> The first is not-empty, the second is (logical since these are immediate >>> values). >>> I thought BoxedFloat64 should not be used in 64-bit ? >>> >>> Also, should #emin, #emax and friends not be different for SmallFloat64 ? >>> >>> Sven >>> >> >> >

June 1, 2017

Re: [Pharo-dev] Confused about Floats on 64-bit Pharo 6

by Nicolas Cellier

2017-06-01 15:29 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi Sven, > SmallFloat64 consumes 3bits taken from exponent for tagging immediate > value. > So very small values and very large values don't fit in SmallFloat64 and > require a BoxedFloat64. > > I don't think we should change emin and emax though. > The reason is that emin and emax are public methods for accessing the > underlying floating point model. > Small/Boxed Float are implementation details, they both implement the same > float model with different levels of optimization. > > For the rest of the report, it's a bug we will have to track catch and fix > ASAP > > (is looks like a shift of 1 bit) > 2017-06-01 14:53 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> I am working in Pharo 6 RC, 64-bit on macOS 10.12.5 >> >> One of the tests of STON fails, #testFloat and I got confused about >> Floats on 64-bit Pharo 6. >> >> Is there a write-up that explains the new/changed situation ? >> >> Because, what I see is the following: >> >> Float pi. >> 1.3. >> >> Both the above give me SmallFloat64 instances. >> >> (10 raisedTo: 100) asFloat. >> 1.0e100. >> 10.0 raisedTo: 100. >> >> All 3 above give me BoxedFloat64 instance. >> But the first 2 give wrong results (correct answer is 1.0e100) ! >> >> (10 raisedTo: 100) asFloat. >> "5.15323791002091e91" >> >> 1.0e100. >> "5.15323791002091e91" >> >> Why ? >> >> BoxedFloat64 allInstances. >> SmallFloat64 allInstances. >> >> The first is not-empty, the second is (logical since these are immediate >> values). >> I thought BoxedFloat64 should not be used in 64-bit ? >> >> Also, should #emin, #emax and friends not be different for SmallFloat64 ? >> >> Sven >> > >

June 1, 2017

Re: [Pharo-dev] Confused about Floats on 64-bit Pharo 6

by Nicolas Cellier

Hi Sven, SmallFloat64 consumes 3bits taken from exponent for tagging immediate value. So very small values and very large values don't fit in SmallFloat64 and require a BoxedFloat64. I don't think we should change emin and emax though. The reason is that emin and emax are public methods for accessing the underlying floating point model. Small/Boxed Float are implementation details, they both implement the same float model with different levels of optimization. For the rest of the report, it's a bug we will have to track catch and fix ASAP 2017-06-01 14:53 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I am working in Pharo 6 RC, 64-bit on macOS 10.12.5 > > One of the tests of STON fails, #testFloat and I got confused about Floats > on 64-bit Pharo 6. > > Is there a write-up that explains the new/changed situation ? > > Because, what I see is the following: > > Float pi. > 1.3. > > Both the above give me SmallFloat64 instances. > > (10 raisedTo: 100) asFloat. > 1.0e100. > 10.0 raisedTo: 100. > > All 3 above give me BoxedFloat64 instance. > But the first 2 give wrong results (correct answer is 1.0e100) ! > > (10 raisedTo: 100) asFloat. > "5.15323791002091e91" > > 1.0e100. > "5.15323791002091e91" > > Why ? > > BoxedFloat64 allInstances. > SmallFloat64 allInstances. > > The first is not-empty, the second is (logical since these are immediate > values). > I thought BoxedFloat64 should not be used in 64-bit ? > > Also, should #emin, #emax and friends not be different for SmallFloat64 ? > > Sven >

June 1, 2017

Release deferred to next Tuesday :(

by Esteban Lorenzano

Hi list, yes, this release is being a pain. anyway, yesterday after asking for testI found two blocking issues and one ânice to haveâ and I needed to work on them. Blocking issues were: 1) Athens (with Fonts ) was not working on 64bits and because of that, Roassal was not either. 2) There is a problem in VM packaging which packages as files what should be symlinks.\ The nice to have: It seems there are english problems in the welcome browser (and in the STAGE pages). It would be nice if some native speaker takes a look :) I already fixed (1) and Iâm working on (2), but the release is deferred to Tuesday because: a) we want to test. b) you never release on friday c) monday is holiday here :) So well, that. Iâm sorry. Esteban

June 1, 2017

Confused about Floats on 64-bit Pharo 6

by Sven Van Caekenberghe

I am working in Pharo 6 RC, 64-bit on macOS 10.12.5 One of the tests of STON fails, #testFloat and I got confused about Floats on 64-bit Pharo 6. Is there a write-up that explains the new/changed situation ? Because, what I see is the following: Float pi. 1.3. Both the above give me SmallFloat64 instances. (10 raisedTo: 100) asFloat. 1.0e100. 10.0 raisedTo: 100. All 3 above give me BoxedFloat64 instance. But the first 2 give wrong results (correct answer is 1.0e100) ! (10 raisedTo: 100) asFloat. "5.15323791002091e91" 1.0e100. "5.15323791002091e91" Why ? BoxedFloat64 allInstances. SmallFloat64 allInstances. The first is not-empty, the second is (logical since these are immediate values). I thought BoxedFloat64 should not be used in 64-bit ? Also, should #emin, #emax and friends not be different for SmallFloat64 ? Sven

June 1, 2017

Minor glitch in source code diff tool

by Sven Van Caekenberghe

It seems there is a minor glitch in the source code diff tool: The first difference is marked (coloured) OK, each next one is one character position more off. This is in the latest 6.0 RC image. Should I create an issue ? Sven

June 1, 2017

Re: [Pharo-dev] please test download for Pharo 6.0

by Marcus Denker

> On 31 May 2017, at 17:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > OK, I quickly tested the Mac 32 and 64 bit versions, installing some code, running unit tests, clicking around. Both are working perfectly. > > The Pharo Welcome window with the clickable coloured links and the tabs is particularly nice. > > The need to move to /Applications is just one thing, you also have to allow the app to actually run (with my settings, by right clicking on it, and giving permission; but even then it stops the first time and only runs the second time; no big deal for me but it might be confusing for others). > I am looking into signingâ¦ but as we did not have it for Pharo5, it should not hold up the release. The /Applications thing is related to signing, too. (the container, we should ship it with a signed .dmg). I will look into it for next week, but this is a bit independend of the release.. Marcus

June 1, 2017

GSoC Week 3 update - Enhancing Pharo Command Line

by Rajula Vineet

Hi all, It has been about three weeks, I started working on my GSoC project. The first task I am working on is the new implementation for Current Working Directory. I have written the new implementation. Currently, I am testing the new code. Will soon share the work here. Meanwhile, for the week three, I have written a blog post <https://vineetreddy.wordpress.com/2017/05/29/cross-platform-with-pharo/> on OSPlatfrom. Please do take a look and give your feedback. Thanks, Rajula -- View this message in context: http://forum.world.st/GSoC-Week-3-update-Enhancing-Pharo-Command-Line-tp494… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 1, 2017

Re: [Pharo-dev] please test download for Pharo 6.0

by K K Subbu

On Wednesday 31 May 2017 07:48 PM, Esteban Lorenzano wrote: > Hello, > > we are getting ready for release. > please take a minute to review: > > http://pharo.org/STAGE.download Quick feedback on Pharo linux/x86_64 on Ubuntu 16.04/64b. I feel the Welcome page should point to HelpBrowser open instead of referring pharo.org because Pharo has a built-in help browser but not a WWW browser. The very first page should not lead to people to switch to a different app for help. Using help keeps people within the env and also leads them to learn how to create tutorials etc. In Welcome/changelog/second item, Epicea is misspelled as Epica. Same doc, suggest renaming section heading for consistency - s/Tools/Tools related/ and s/Network/Network related/ "Learn Pharo Smalltalk" and "Explore Pharo Environment" dups references to books. The former could be merged into the latter to drive home the point that language and env are tightly coupled. Also, merge "More Documentation" into "Getting help" and keep all web references together. I can send in a pull request for these changes if it helps. I tried to run: $ ./pharo-vm/pharo --nodisplay pharo-vm/shared/Pharo*.image eval 3+4 and got a usage error. The problem is that the pharo-vm/pharo script does not take into account option arguments and has other issues too. This works: $ ./pharo/bin/pharo --nodisplay pharo-vm/shared/Pharo*.image eval 3+4 HTH .. Subbu

June 1, 2017