September 2020 - Pharo-users

Re: [Pharo-users] Rounding in Floats

by Konrad Hinsen

Hi Esteban, > It is not for printing but for testing. I want to assert that a > certain calculation gives the expected result. > And then it fails because of the difference above when it is > "semantically" correct. If you want reliable precision tests with IEEE floats, you should use rounding to powers of 2, not 10. Round to 1/8 or 1/16, but not to 1/10. The fundamental issue is that 1/10 does not have an exact finite representation in base 2. No matter how I/O libraries handle the conversion between base 2 (in the binary representation of IEEE floats) and base 10 (in the text representation), there will always be bad surprises because the expectations we have from working in base 10 cannot all be met with an internal representation in base 2. So if your goal is not fundamentally related to I/O, forget about I/O and design your code to work the binary level, in particular for testing. However, if your problem specification explicitly requires precision guarantees in base 10 (which seems to be your case, from a quick glance at the Wikipedia page you cite), then it's best to avoid binary floats completely. Rationals (fractions) are one option, scaled integers another one. Konrad.

Sept. 7, 2020

Re: [Pharo-users] Can it do this way ?

by Roelof Wobben

Sept. 7, 2020

Re: [Pharo-users] Getting rid of .sources file for deployment

by Esteban Maringolo

If somebody gets to open the image and loads it with an Smalltalk Emulator to execute it I'll ask him/her to start working together, and even teach me how to do it. I don't want to shield the image from being accessed, just want to make it harder than simply removing the '--headless' parameter to the VM executable. Of course removing sources is a plus (I do for a VW deployed image), but even for this particular piece of software that I'm asking for, I don't need it. If I wanted to make the source public, I'll publish it in Github/Gitlab, otherwise I'd rather keep the code private. Regards, Esteban A. Maringolo On Sun, Sep 6, 2020 at 6:29 PM Davide Grandi <davide.grandi(a)email.it> wrote: > > I mean that with SmalltalkEmulator, the Smalltalk interpreter > written in Smalltalk, one can execute an image looking at > classes, methods and maybe executing code at will. > > And the only practical form of protection I see in Squeak/Pharo > is to obfuscate code. > > Maybe I'm wrong. > > Davide Grandi > > On 06/09/2020 22:27, Esteban Maringolo wrote: > > On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi <davide.grandi(a)email.it> wrote: > >> Does "competition" has SmalltalkEmulator ? > >> A Smalltalk-written VM will defeat any simple obfuscation scheme. > > Sorry, but I don't understand what you mean. > > > > Best regards, > > > -- > Ing. Davide Grandi > email : davide.grandi(a)email.it > mobile : +39 339 7468 778 > linkedin : http://linkedin.com/in/davidegrandi > >

Sept. 6, 2020

Re: [Pharo-users] Getting rid of .sources file for deployment

by Davide Grandi

I mean that with SmalltalkEmulator, the Smalltalk interpreter written in Smalltalk, one can execute an image looking at classes, methods and maybe executing code at will. And the only practical form of protection I see in Squeak/Pharo is to obfuscate code. Maybe I'm wrong. Â Â Â Davide Grandi On 06/09/2020 22:27, Esteban Maringolo wrote: > On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi <davide.grandi(a)email.it> wrote: >> Does "competition" has SmalltalkEmulator ? >> A Smalltalk-written VM will defeat any simple obfuscation scheme. > Sorry, but I don't understand what you mean. > > Best regards, > -- Ing. Davide Grandi email : davide.grandi(a)email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

Sept. 6, 2020

Re: [Pharo-users] Getting rid of .sources file for deployment

by Esteban Maringolo

On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi <davide.grandi(a)email.it> wrote: > > Does "competition" has SmalltalkEmulator ? > A Smalltalk-written VM will defeat any simple obfuscation scheme. Sorry, but I don't understand what you mean. Best regards,

Sept. 6, 2020

Re: [Pharo-users] Rounding in Floats

by Esteban Maringolo

Hi Sven, On Sun, Sep 6, 2020 at 11:57 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 6 Sep 2020, at 16:06, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > (9.1 + (-2.0)) roundTo: 0.1. > > "7.1000000000000005" > > Is this a bug? > > Maybe. > > But I would not approach the problem of rounding like that. > You probably want to control how numbers are printed. It is not for printing but for testing. I want to assert that a certain calculation gives the expected result. And then it fails because of the difference above when it is "semantically" correct. > I would keep the numbers themselves at maximum internal precision and only do something when printing them. I do. I'm implementing the full WHS specification [1], and it mentions that most calculations should preserve the maximum internal precision and even introduces some weird situation where you have an "index" that is rounded and another one that is called the same way but must not be rounded because is going to used to compute some other value. For most calculations it specifies it must round to 1 decimal or even to no decimal, based on a round up if the decimal is greater or equal than zero (e.g. 1.5 becomes 2), except for negative numbers, in which case it rounds "down" (-1.5 becomes 1). > 1 / 3 asFloat printShowingDecimalPlaces: 1. > > Since you like Seaside, the following is even much more powerful (has *many* options): > GRNumberPrinter new precision: 1; print: 1/3 asFloat. I'm already using the GRNumberPrinter and also the Date printer to print these values. Regards! [1] https://en.wikipedia.org/wiki/Handicap_(golf)#World_Handicap_System

Sept. 6, 2020

Re: [Pharo-users] Getting rid of .sources file for deployment

by Davide Grandi

>any simple obfuscation scheme any simple _protection_ scheme, except obfuscation. 0.01 E. ... Â Â Â Davide Grandi On 06/09/2020 17:51, Davide Grandi wrote: > Does "competition" has SmalltalkEmulator ? > A Smalltalk-written VM will defeat any simple obfuscation scheme. > > 0.02 E. > > Â Â Â Davide Grandi > > On 06/09/2020 15:55, Esteban Maringolo wrote: >> Stef, >> >> On Sat, Sep 5, 2020 at 12:49 PM StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> just a question what if a bad guy you want to protect from is just >>> smart >>> and use a default vm. >> You're talking about decompiling and I'm talking about not making it >> trivial to see the code, internals and other things. >> Security is always what you can afford to protect form, with enough >> resources anybody can crack most of the existing software. >> >>> I mean what kind of thieves do you want to protect from? >> Think of it this way... as it is is like saving a six digits password >> in plaintext on a file, what I propose is to have the same file, but >> with the password encrypted with a lousy crypto (still easy to crack >> with a dictionary attack but not as easy as seeing it at plain sight). >> >> I'm not trying to protect from thieves, but from the competition. >> This client part of the software runs in a computer where there is >> also the software it's going to replace (eventually). >> >> I simply want to obfuscate a little so it's not trivial to open it. >> I'm not asking about encrypted image files. :-) >> >>> Because you can let everything and block the menu + the DNU and >>> other exception >>> and nobody even you will be able to access the code. >>> If you remove all the <world menu> menu and toolbar + DNU + >>> exception ... >> I followed most of the guidelines to deploy it obfuscated [1]. >> But if there is a guide for obfuscation, it means that there is some >> need for it, I just want to go one extra step. >> >> Thanks! >> >> [1] >> https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… >> >> Esteban A. Maringolo > -- Ing. Davide Grandi email : davide.grandi(a)email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

Sept. 6, 2020

Re: [Pharo-users] Getting rid of .sources file for deployment

by StÃ©phane Ducasse

So if you remove the code open the worldmenu and the debugger you should get done. After the people could use âeval to open a browser but this is more difficult. > On 6 Sep 2020, at 15:55, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Stef, > > On Sat, Sep 5, 2020 at 12:49 PM StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> just a question what if a bad guy you want to protect from is just smart >> and use a default vm. > > You're talking about decompiling and I'm talking about not making it > trivial to see the code, internals and other things. > Security is always what you can afford to protect form, with enough > resources anybody can crack most of the existing software. > >> I mean what kind of thieves do you want to protect from? > > Think of it this way... as it is is like saving a six digits password > in plaintext on a file, what I propose is to have the same file, but > with the password encrypted with a lousy crypto (still easy to crack > with a dictionary attack but not as easy as seeing it at plain sight). > > I'm not trying to protect from thieves, but from the competition. > This client part of the software runs in a computer where there is > also the software it's going to replace (eventually). > > I simply want to obfuscate a little so it's not trivial to open it. > I'm not asking about encrypted image files. :-) > >> Because you can let everything and block the menu + the DNU and other exception >> and nobody even you will be able to access the code. >> If you remove all the <world menu> menu and toolbar + DNU + exception ... > > I followed most of the guidelines to deploy it obfuscated [1]. > But if there is a guide for obfuscation, it means that there is some > need for it, I just want to go one extra step. > > Thanks! > > [1] https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… > > Esteban A. Maringolo > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 6, 2020

Re: [Pharo-users] Getting rid of .sources file for deployment

by Davide Grandi

Does "competition" has SmalltalkEmulator ? A Smalltalk-written VM will defeat any simple obfuscation scheme. 0.02 E. Â Â Â Davide Grandi On 06/09/2020 15:55, Esteban Maringolo wrote: > Stef, > > On Sat, Sep 5, 2020 at 12:49 PM StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> just a question what if a bad guy you want to protect from is just smart >> and use a default vm. > You're talking about decompiling and I'm talking about not making it > trivial to see the code, internals and other things. > Security is always what you can afford to protect form, with enough > resources anybody can crack most of the existing software. > >> I mean what kind of thieves do you want to protect from? > Think of it this way... as it is is like saving a six digits password > in plaintext on a file, what I propose is to have the same file, but > with the password encrypted with a lousy crypto (still easy to crack > with a dictionary attack but not as easy as seeing it at plain sight). > > I'm not trying to protect from thieves, but from the competition. > This client part of the software runs in a computer where there is > also the software it's going to replace (eventually). > > I simply want to obfuscate a little so it's not trivial to open it. > I'm not asking about encrypted image files. :-) > >> Because you can let everything and block the menu + the DNU and other exception >> and nobody even you will be able to access the code. >> If you remove all the <world menu> menu and toolbar + DNU + exception ... > I followed most of the guidelines to deploy it obfuscated [1]. > But if there is a guide for obfuscation, it means that there is some > need for it, I just want to go one extra step. > > Thanks! > > [1] https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… > > Esteban A. Maringolo -- Ing. Davide Grandi email : davide.grandi(a)email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

Sept. 6, 2020

Re: [Pharo-users] Rounding in Floats

by Sven Van Caekenberghe

> On 6 Sep 2020, at 16:06, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi, > > Continuing with my issues with decimals, I'm having one issue that is > not clear to me why it happens. > > If I do: > (9.1 + (-2.0)) roundTo: 0.1. > "7.1000000000000005" > > I expect to get a single decimal Float (rounded with whatever > precision, but a single decimal). > > Even if I do something like this: > 7.1 roundTo: 0.1 > > It gives the wrong result. > > In VW and VAST it provides the right result. > (9.1 + (-2.0)) roundTo: 0.1 "7.1" > > In Dolphin it also returns the wrong result, it seems to use the same > algorithm to round it. > > Is this a bug? Maybe. But I would not approach the problem of rounding like that. You probably want to control how numbers are printed. I would keep the numbers themselves at maximum internal precision and only do something when printing them. 1 / 3 asFloat printShowingDecimalPlaces: 1. Since you like Seaside, the following is even much more powerful (has *many* options): GRNumberPrinter new precision: 1; print: 1/3 asFloat. Check it out. > > Esteban A. Maringolo >

Sept. 6, 2020