November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] roundTo: strange behavior

by Andres Valloud

Hey Martin... I agree on the confusion. > I still recommend not rounding the number itself, but rounding the printing of the number Yes. If "rounding" had well specified behavior that was at least somewhat reasonable (e.g. return the closest floating point value and round to even if tied), I'd accept floating point results that don't print "pretty" in base 10. That's the way things are, there's no point in pretending IEEE-754 is not base 2. If "rounding" is being done in place of "printing", or obtaining a "string representation", I think that won't work as expected because 0.1 not representable etc. For "printing", the algorithms were Dragon4 and Grisu3 last time I checked. For "floating point that works nice in base 10", there's IEEE-854. For those unfamiliar with the spec, it's been implemented in non-exotic hardware already. > you did proof that, as you said "1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1.". As a suggestion for these types of problems, try iterating over a floating point bit range converting each to a true fraction and see which one is closest? > testIfCompletelyBroken [doesn't round to even] I'd agree rounding to even would be better. Guillermo, > And also: I'd argue that you NEVER EVER want to use simple Floats for financial applications Define "financial" applications? In the risk management world, tying down that last $1 difference will likely cost more electricity (and way more time) than the $1 is worth. John, > While ANSI says that the numbers should be converted using the default conversion table, all of the Smalltalkâs that Iâve tried donât follow that. Iâve tried Dolphin, VW, Pharo, & VAST, and all return fractions. I prefer this behavior over the ANSI behavior. I agree that ANSI doesn't always make the best sense. If it were up to me, I'd follow the relevant standard to the letter. That's more important than providing a custom interpretation of an interoperability mechanism just for Smalltalk (or a particular dialect) by default. Nicolas, > printShowingDecimalPlaces: That's quite a long selector. Has anyone considered an approach along the lines of this? 1.2345 %f #'3.2' => ' 1.23' 1.2345 %f #'03.2' => '001.23' A reminder: calling printf() via FFI is undefined behavior. Andres. On 10/26/16 23:31 , Martin McClure wrote: > On 10/26/2016 08:27 AM, stepharo wrote: >> So what is the definition of printShowingMaxDecimalDigit:? >> I have the impression that there is a confusion between the rounding a >> number and the printing of his value in a given format. > > Yes, I see quite a bit of confusion in this thread about that. > >> we can deprecate roundTo: if necessary. > > I think roundTo: is OK. #round: is not, and should be deprecated (at > least for Floats). For Floats, the idea of rounding to a specific number > of decimal digits is a fantasy. Here's why: Floats cannot exactly > represent most common decimal fractions. For example: > > 0.1 -- not representable > > 0.2 -- not representable > > 0.3 -- not representable > > 0.4 -- not representable > > 0.5 -- hey, representable! > > 0.6 -- not representable > > 0.7 -- not representable > > 0.8 -- not representable > > 0.9 -- not representable > > 1.0 -- representable. > > *Printing* a Float to a specific rounded decimal format is a sensible > idea, and should be encouraged. But trying for a "rounded Float" > *number* just can't be done exactly (except by converting to a Fraction). > > Fractions can be rounded to exact decimal fractions, so something like > "myFraction roundTo: 1/100" makes sense. But the current implementation > of round: on Fraction that converts to a Float just gets you the misery > detailed above. > > > On 10/26/2016 01:00 PM, Nicolas Cellier wrote: >> I've put a single slice in the inbox for the 3 issues because they all >> are related. >> See slice comment: >> >> For Float, implement guard to prevent overflow (15471), and use exact >> representation for intermediate results (asFraction) so as to avoid >> double rounding problems (15473) > > The double rounding problem is not the fundamental problem, the > fundamental problem is that what is desired does not exist, because > Floats cannot exactly represent most decimal fractions. So this can't > really fix it. > >> >> For Fraction (15472), choose an exact representation for result rather >> than Float. This is because such method is particularly usefull for >> financial/monetary applications. >> > Yes. Fraction or ScaledDecimal. Not Floats, unless the developer > understands the needs of the financial world and the limitations of > Floats very well. > > > Regards, > > -Martin >

Nov. 26, 2016

Re: [Pharo-dev] About ~= and ~~

by Eliot Miranda

Hi Peter, I'd appreciate it if you used reply to all to keep the conversation thread going. > On Nov 25, 2016, at 10:31 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Out of interest... is the single extra dispatch really that expensive? Yes, in the common case where the send of #== is followed by a jump, as it is in ifNil:ifNotNil: or == foo ifTrue: etc. when #== is inclined the following jump is eliminated and the VM jumps on the condition codes for the comparison. When #== is a real send it answers the true or false objects and the following jump must compare this result against true or false. Note that Sista will be able to perform the inclining optimisation so we will get the performance back once Sista is deployed. > > And speaking of object inequality... I would like to propose "<>" instead of "~=", because I never remember on which side ~ should be.. > > Peter > >> On Wed, Nov 23, 2016 at 05:39:03AM -0800, Aliaksei Syrel wrote: >> Hi >> >> It is been a while... >> So, do we want to replace ~~ with a primitive? :) >> >> Cheers >> Alex >> >> >> >> -- >> View this message in context: http://forum.world.st/About-and-tp3898409p4924391.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

Nov. 26, 2016

Re: [Pharo-dev] About ~= and ~~

by Yuriy Tymchuk

> On 25 Nov 2016, at 19:31, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Out of interest... is the single extra dispatch really that expensive? > > And speaking of object inequality... I would like to propose "<>" instead of "~=", because I never remember on which side ~ should be.. Letâs replace it with ~=~ then :P Y > > Peter > > On Wed, Nov 23, 2016 at 05:39:03AM -0800, Aliaksei Syrel wrote: >> Hi >> >> It is been a while... >> So, do we want to replace ~~ with a primitive? :) >> >> Cheers >> Alex >> >> >> >> -- >> View this message in context: http://forum.world.st/About-and-tp3898409p4924391.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

Nov. 25, 2016

Re: [Pharo-dev] About ~= and ~~

by Peter Uhnak

Out of interest... is the single extra dispatch really that expensive? And speaking of object inequality... I would like to propose "<>" instead of "~=", because I never remember on which side ~ should be.. Peter On Wed, Nov 23, 2016 at 05:39:03AM -0800, Aliaksei Syrel wrote: > Hi > > It is been a while... > So, do we want to replace ~~ with a primitive? :) > > Cheers > Alex > > > > -- > View this message in context: http://forum.world.st/About-and-tp3898409p4924391.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 25, 2016

Re: [Pharo-dev] [Vm-dev] About ~= and ~~

by Eliot Miranda

Hi ClÃ©ment, Hi All, On Thu, Nov 24, 2016 at 5:09 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hi, > > Support for primitive 169 for Object>>#~~ has been in the VM for a while. > The default implementation in Squeak 5 uses this primitive for example. > > I've just added today (VMMaker commit 2003) support for inlined #~~ like > #== (including JIT support, branch pipelining, etc.). If one puts #~~ in > the specialObjectsArray at the location of #blockCopy:, the bytecode > compiler generates the special send bytecode for #~~ leading to improved > performance and consistency between #== and #~~. > > With today's update, the VM supports 3 inlined operations without any type > checks: #==, #~~ and #class. It is possible to disable such optimisations > in the bytecode compiler (In Pharo #class inlining is disabled there for > example). Eliot would like to add support to disable these operations at VM > level as a VM command line parameter too, and we may do it in the future. > > Now this is for the VM support. It's up to the Pharo/Squeak/other > community to decide what behavior they want in their runtime for these 3 > selectors. > > In my opinion, I believe that #~~ should be consistent with #==, hence > they should be both inlined or both sends to primitives. I don't like the > current situation in Pharo nor in Squeak. > > Now when we look for solutions, we see that one of #== and #~~ needs to be > a primitive (it's essential), hence it makes sense to have both Object>>#== > and Object>>#~~ as primitives (with the primitive pragma in the method > body). The inlining of #== and #~~ is arguable and I let the community > decide what they believe is best for their runtime, though I would rather > have the same behavior for both selectors. > In addition, for proxies, it makes sense to allow the system to not inline the primitives. Let me explain. The primitives for #== and #~~, just like any other primitives, are found by message sends. However, a set of 32 "special" selectors, which comprise some arithmetic selectors (#+, #- etc) and comparison selectors (#< #<= etc) and some frequent selectors #(at: #next #value #== etc) are subject to inlining with no sends (see Smalltalk specialSelectoers for the full set). The first sixteen are arithmetic and comparison, and the interpreter gains performance by implementing these byte codes to test for SmallIntegers and Floats, and performing the arithmetic directly without a send, and for the comparisons, performing the comparison and any immediately following conditional branch. The JIT performs these optimisations too. But these short-cuts (static type prediction in the official terminology) are safe because they apply only to SmallInteger and Float. Of the next sixteen most are there only to save space in a method's literal frame. Since the byte code encodes the selector directly there is no need to store the selector in the method's literals. The implementation of all but two (three if we add #~~ to replace #blockCopy: as mentioned above) of these bytecodes is to fetch the selector from the specialSelectors array and do a normal send. #== and #class are handled specially. These are inlined without doing a send. The current Opal compiler in Pharo avoids the inlining of #class by not generating the #class special selector bytecode. Squeak's compiler still issues the special selector bytecode. Both generate #== by issuing the #== special selector bytecode, and so #== is never sent. This is not what's desired for applications that use proxies. It is fine for simple applications that prefer speed. One simple thing one can do is prevent inlining for anything other than the arithmetic and comparison operators. A simple command-line switch, or perhaps better, a flag in the image header, can control whether the VM inlines #class, #== & #~~. This then allows the compilers to generate the more compact special selector byte codes for these sends, but causes the VM to treat them like the other 13 non-arithmetic special selectors. Hence they become true sends. I did this for VisualWorks several years ago and it works well, expect for needing a command-line switch. The flag in the image header is much more reliable; whether an image should be run with inlining or not is a property of the image, not of a particular VM invocation. So I suggest that a) I implement the switch as an image header flag, allowing the inlining of #class, #== and #~~ to be turned off (but keeping inlining on by default) b) Pharo changes Opal to start issuing the #class special selector send byte code again and turns off inlining of #class, #== and #~~ c) applications that use proxies (in Cuis, Pharo or Squeak) experiment with the setting and see if logic is improved and report back; Squeak and other dialects can then decide what they want as the default, and indeed certain packages could try and set the flag or at least check that the flag is in the desired state > Cheers > > On Wed, Nov 23, 2016 at 2:39 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> Hi >> >> It is been a while... >> So, do we want to replace ~~ with a primitive? :) >> >> Cheers >> Alex >> >> >> >> -- >> View this message in context: http://forum.world.st/About-an >> d-tp3898409p4924391.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > -- _,,,^..^,,,_ best, Eliot

Nov. 25, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50764 Home: https://github.com/pharo-project/pharo-core

Nov. 25, 2016

[pharo-project/pharo-core] e13d19: 50764

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e13d19f8de0c20da4ae9607cb5b0164a5e4c9e11 https://github.com/pharo-project/pharo-core/commit/e13d19f8de0c20da4ae9607c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-25 (Fri, 25 Nov 2016) Changed paths: M Morphic-Base.package/MorphicEventHandler.class/instance/access/methodRefList.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50763.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50764.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50763.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50764.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50764 19361 Morph>>#showActions broken https://pharo.fogbugz.com/f/cases/19361 http://files.pharo.org/image/50/50764.zip

Nov. 25, 2016

[pharo-project/pharo-core] 69f0be: 60307

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 69f0be0ef4bcb176b97acaaee6f6751d7b8ab580 https://github.com/pharo-project/pharo-core/commit/69f0be0ef4bcb176b97acaae… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-25 (Fri, 25 Nov 2016) Changed paths: R FuelPlatform-Core.package/FLPlatform.class/class/class initialization/initialize.st R FuelPlatform-Core.package/FLPlatform.class/class/operations/checkForUpdates.st R FuelPlatform-Core.package/FLPlatform.class/class/private/getConfigurationVersion.st R FuelPlatform-Core.package/FLPlatform.class/class/private/updateConfigurationVersion.st M Morphic-Base.package/MorphicEventHandler.class/instance/access/methodRefList.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60306.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60307.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60306.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60307.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Announcements.package/MethodAnnouncement.class/definition.st A System-Announcements.package/MethodAnnouncement.class/instance/accessing/methodPackage.st M System-Announcements.package/MethodAnnouncement.class/instance/accessing/method_.st A System-Announcements.package/MethodAnnouncement.class/instance/accessing/packagesAffected.st A System-Announcements.package/MethodAnnouncement.class/instance/accessing/protocolsAffected.st A System-Announcements.package/MethodRecategorized.class/instance/accessing/protocolsAffected.st A Tests.package/AbstractObjectsAsMethod.class/instance/compatibility/package.st Log Message: ----------- 60307 19377 Pharo 6 Morph>>#showActions broken https://pharo.fogbugz.com/f/cases/19377 19339 MethodAnnouncement should has methodPackage information and provide packagesAffected and protocolsAffected https://pharo.fogbugz.com/f/cases/19339 19391 FuelPlatform-Core https://pharo.fogbugz.com/f/cases/19391 http://files.pharo.org/image/60/60307.zip

Nov. 25, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60307 Home: https://github.com/pharo-project/pharo-core

Nov. 25, 2016

Re: [Pharo-dev] Removing most of the windowing code

by phil＠highoctane.be

I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x under Mingw). If you have a GCC5 instead of the old 4.6, I am interested in your config. It is great that you are giving a solid kick in this. Do not get burned out. Peace. Phil On Thu, Nov 24, 2016 at 11:48 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Need help with the VM cleaning? >> > Not for now. Now I will try to make this working on Windows. Once I manage > to isolate the most of the stubbed dependencies on Window(heartbeat, time, > asynchronous I/O), we will have a more unified core VM in a single static > library. When we have this unified VM, I will need help for testing, and > defining a definitive build system where the community also agrees. For now > I will just keep working on my private branch. > > 2016-11-24 17:29 GMT-03:00 philippe.back(a)highoctane.be < > philippe.back(a)gmail.com>: > >> Need help with the VM cleaning? >> >> Le 24 nov. 2016 08:13, "Ronie Salgado" <roniesalg(a)gmail.com> a Ã©crit : >> >>> Hello, >>> >>> I am working on removing most of windowing code from the VM, and in >>> trying to unify the platform specific code of the VM. In the >>> MinimalistHeadless branch of https://github.com/ronsaldo/op >>> ensmalltalk-vm I made the following changes: >>> >>> - Unified standard CMake building scripts for Unixes. I hate autoconf. I >>> want to use them in Windows too. >>> - Refactoring the Unix entry points. I am trying to remove a lot of code >>> for simplfying stuff. >>> - Null window driver for true headless. >>> - Optional SDL2 based traditional display backend for compatibility >>> reasons, and because the extra Morphic worlds using OSWindow are a bit >>> unstable. >>> >>> So far I managed to run a standard Pharo 6 image using this custom VM in >>> Linux. Windows and Mac are coming next. Hopefully this is going to fix the >>> problems with duplicated events when using OSWindow in Windows. >>> >>> I am also planning on making a standard interface for embedding the VM >>> in an application, at least as a static library. With this new building >>> system, this seems to be easy to do. >>> >>> BTW. When I tried the minimalistic Pharo image, in a completely headless >>> VM, I got the following error: >>> >>> [ "Ugh .... now this is a biggie - a system that does not support >>> any of the display depths at all." >>> Smalltalk >>> logError: >>> 'Fatal error: This system has no support for any display depth >>> at all.' >>> inContext: thisContext. >>> Smalltalk quitPrimitive "There is no way to continue from here" ] in >>> DisplayScreen>>findAnyDisplayDepth >>> DisplayScreen>>findAnyDisplayDepthIfNone: >>> DisplayScreen>>findAnyDisplayDepth >>> DisplayScreen>>setExtent:depth: >>> DisplayScreen class>>startUp >>> >>> As a workaround, I am doing the following for ioHasDisplayDepth with the >>> null driver: >>> >>> sqInt ioHasDisplayDepth(sqInt depth) >>> { >>> return true; >>> } >>> >>> In DisplayScreen class >> startUp we have the following: >>> startUp "DisplayScreen startUp" >>> Display setExtent: self actualScreenSize depth: Display nativeDepth. >>> Display beDisplay >>> >>> Does it make sense, to always trying to create a display in startup time? >>> >>> Best regards, >>> Ronie >>> >> >

Nov. 24, 2016