- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Performance difference between Pharo 32bits and 64bits

by ClÃ©ment Bera

Hi Thierry, On the speed center you can compare 32 bits and 64 bits linux VMs: http://squeak.org/codespeed/ Normally Pharo 64 should be overall slightly slower than Pharo 32 because 70% of the memory is used for pointers, implying twice more data to process by the processor for pointer operations. Specific things, for example SmallFloat arithmetic, should however be faster on 64 bits. For numerical code, benchs can be faster for two main reasons: - the bench uses SmallFloat instead of BoxedFloat for most floats it uses in 64 bits - the bench overflows the 31bits signed integer range for SmallIntegers, leading to the usage of LargeInteger in 32 bits, while it does not overflow the 61 bits signed integer range in 64 bits. This is typically the case for int32 benchs. Other numerical benchs may be faster on 32 bits. On Mon, Nov 14, 2016 at 4:04 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Has anybody seen performance differences between the 32bits and the 64bits > versions of Pharo 6 ? > > I'm seeing a speedup greater than 2 on some intensive numerical code. > > Note that, on that code, Pharo 64bits is slower than R, by around 30%. The > code overall is memory bound. > > Thierry > > >

Nov. 14, 2016

Performance difference between Pharo 32bits and 64bits

by Thierry Goubier

Has anybody seen performance differences between the 32bits and the 64bits versions of Pharo 6 ? I'm seeing a speedup greater than 2 on some intensive numerical code. Note that, on that code, Pharo 64bits is slower than R, by around 30%. The code overall is memory bound. Thierry

Nov. 14, 2016

Re: [Pharo-dev] #printShowingMaxDecimalPlaces: What do you think?

by Brad

I vote for the NumberFormatter. It adds another layer, which can be a pain, but gives you much more flexibility. Plus it decouples the formatting from all of the number classes. VA Smalltalk has something like this. Brad Selfridge 913-269-2385 > On Nov 14, 2016, at 8:38 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I am voting against because both methods are very similar while we are trying to clean. > > Also, if I would have to present a number I would personally always prefer the .00 for uniformity. > > But I understand what you want. I think a NumberFormatter object would be better -- what about thousands separators, negative and/or positive sign, different scientific notations, ... ? > > Anyway, just my opinion. > >> On 14 Nov 2016, at 14:56, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >> >> Hi! >> >> I have a problem in an application, I need to print some numbers with 2 >> decimals max. The numbers can be an Integer, Float or Fraction. I >> checked and found Number>>#printShowingDecimalPlaces:. This is cool but >> this is not what I want because when I get "10", I want to print "10" >> and not "10.00". >> >> So I created a method Number>>#printShowingMaxDecimalPlaces: to do so. >> At first I made a mistake and I was not the only one. To avoid this kind >> of mistakes I think this method should be in Pharo by default. This is >> really useful when building a GUI. >> >> This method already exists in Squeak. >> >> I want to ask to the list, do you think this method should make it in >> the image? I think this is important but I also know that people do not >> want to have too much things in the kernel. >> >> So, do you think this is important enough or not? >> >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> > >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Esteban A. Maringolo

2016-11-14 11:50 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> >> Breaking Metacello in any version = Not good. >> >> Metacello is very backward compatible but breaking pragma semantics >> would require a rewrite of many configurations that work okay today > Why? ConfigurationOf~ not collect any pragmas by themselves. They only > declare versions by pragmas. You're right. > And we only need to fix Pharo version of Metacello which is already fork. Which is not there yet. Quoting myself: "... and would require a new version of Metacello that contemplates the new selectors based on some criteria." Criteria being pharo version, or anything else that identifies the new pragma semantics. Regards!

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Denis Kudriashov

2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Breaking Metacello in any version = Not good. > > Metacello is very backward compatible but breaking pragma semantics > would require a rewrite of many configurations that work okay today > Why? ConfigurationOf~ not collect any pragmas by themselves. They only declare versions by pragmas. And we only need to fix Pharo version of Metacello which is already fork.

Nov. 14, 2016

Re: [Pharo-dev] #printShowingMaxDecimalPlaces: What do you think?

by Sven Van Caekenberghe

I am voting against because both methods are very similar while we are trying to clean. Also, if I would have to present a number I would personally always prefer the .00 for uniformity. But I understand what you want. I think a NumberFormatter object would be better -- what about thousands separators, negative and/or positive sign, different scientific notations, ... ? Anyway, just my opinion. > On 14 Nov 2016, at 14:56, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Hi! > > I have a problem in an application, I need to print some numbers with 2 > decimals max. The numbers can be an Integer, Float or Fraction. I > checked and found Number>>#printShowingDecimalPlaces:. This is cool but > this is not what I want because when I get "10", I want to print "10" > and not "10.00". > > So I created a method Number>>#printShowingMaxDecimalPlaces: to do so. > At first I made a mistake and I was not the only one. To avoid this kind > of mistakes I think this method should be in Pharo by default. This is > really useful when building a GUI. > > This method already exists in Squeak. > > I want to ask to the list, do you think this method should make it in > the image? I think this is important but I also know that people do not > want to have too much things in the kernel. > > So, do you think this is important enough or not? > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Esteban A. Maringolo

2016-11-14 11:27 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Breaking Metacello in Pharo 6: Not good. Revert: +1 Breaking Metacello in any version = Not good. Metacello is very backward compatible but breaking pragma semantics would require a rewrite of many configurations that work okay today and would require a new version of Metacello that contemplates the new selectors based on some criteria. Regards! Esteban A. Maringolo

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by phil＠highoctane.be

Breaking Metacello in Pharo 6: Not good. Revert: +1 On Mon, Nov 14, 2016 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > we need to revert. > this is a huge mess in a very inappropriate moment :) > > Esteban > > > On 14 Nov 2016, at 13:56, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > Indeed, I forgot that #selector is doing something else. This is a bit > of a mess. Either we revert it today, or we leave it. Otherwise, more > projects will adopt the new API only to break again afterwards. > > > > Doru > > > >> On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. < > cyril.ferlicot(a)gmail.com> wrote: > >> > >> On 14/11/2016 13:44, Tudor Girba wrote: > >>> Hi, > >>> > >>> Please do not revert the API. Just comment out the deprecation. The > code in Moose was already updated to the new API and I presume other > projects might be in the same situation. > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Be rather willing to give than demanding to get." > >>> > >>> > >>> > >> > >> Changing the API without a deprecation phase is bad. This kind of > >> breaking change without warning is something companies can fear. This is > >> even more important when there is such a dangerous change. #selector is > >> still here but do something differentâ¦ This is bad to just change it in > >> one go. > >> > >> Maybe some projects updated but most companies do not follow the > >> development version of Pharo. > >> > >> -- > >> Cyril Ferlicot > >> > >> http://www.synectique.eu > >> > >> 2 rue Jacques PrÃ©vert 01, > >> 59650 Villeneuve d'ascq France > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "It's not how it is, it is how we see it." > > > > > > >

Nov. 14, 2016

Re: [Pharo-dev] macOS Sierra support

by MartinW

If I try to start the Pharo from the Download page e.g. from my Desktop I get the following information: ----- Pharo cannot write to the changes file named /private/var/folders/9p/h6h_ntqs2gs9kztvdp9mrm1m0000gn/T/AppTranslocation/1CA39D30-C5A9-4599-82F0-8FFA46606D5B/d/Pharo5.0.app/Contents/Resources/Pharo5.0.changes. Please check that you have write permission for this file. You won't be able to save this image correctly until you fix this. ----- And Pharo does not work at all, because it tries to write to changes all the time, of course. The hint on the Website looks good. kilon.alios wrote > This is weird but I have never experienced this "sandbox" thing > > I have Sierra, updated to the latest and when I download this zip to my > downloads folder, I uncompress it and double click the application without > moving to the application folder it works without doing anything > additionally or complaining about it. > > I am almost always do this with applications I download because I like to > test them before copying them to the application folder. Never had any > issues. > > So apparently my Sierra loves me :D -- View this message in context: http://forum.world.st/macOS-Sierra-support-tp4917181p4922953.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 14, 2016

#printShowingMaxDecimalPlaces: What do you think?

by Cyril Ferlicot D.

Hi! I have a problem in an application, I need to print some numbers with 2 decimals max. The numbers can be an Integer, Float or Fraction. I checked and found Number>>#printShowingDecimalPlaces:. This is cool but this is not what I want because when I get "10", I want to print "10" and not "10.00". So I created a method Number>>#printShowingMaxDecimalPlaces: to do so. At first I made a mistake and I was not the only one. To avoid this kind of mistakes I think this method should be in Pharo by default. This is really useful when building a GUI. This method already exists in Squeak. I want to ask to the list, do you think this method should make it in the image? I think this is important but I also know that people do not want to have too much things in the kernel. So, do you think this is important enough or not? -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 14, 2016