- Pharo-users - lists.pharo.org

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

Rounding in Floats

by Esteban Maringolo

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? Esteban A. Maringolo

Sept. 6, 2020

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

by Esteban Maringolo

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

Sept. 6, 2020

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

by Steffen MÃ¤rcker

Maybe this is a naive question, but can you just split the task into the following two? 1. Check whether whether the string is syntactically an ISBN number. This can be done, e.g., using a regex. 2. Check the the check character. Calculate the check character from the (now to be known) syntactically valid string. ISBNValidator>>isValidISBN: aString ^(self isSyntacticallyValid: aString) and: [self isCheckCharacterValid: aString] Kind regards, Steffen Am .09.2020, 07:35 Uhr, schrieb Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org>: > Nope, with your idea I cannot make this part work : > > he ISBN-10 format is 9 digits (0 to 9) plus one check character (either > a digit > or an X only). In the case the check character is an X, this represents > the > value '10'. These may be communicated with or without hyphens, and can be > checked for their validity by the following formula: > > (x1 * 10 + x2 * 9 + x3 * 8 + x4 * 7 + x5 * 6 + x6 * 5 + x7 * 4 + x8 * 3 > + x9 * 2 + > > so I mean the calculation. > > > Roelof > > > Op 4-9-2020 om 06:45 schreef Roelof Wobben: > > oke, then I could use your idea but then I have to make the code for > calculating > if its a valid number. > and I wonder if the code will not be too big. I learned that it is good > that a > method does only 1 thing and this one seems to be doing more then 1 > thing. > > Roelof > > > > Op 4-9-2020 om 05:24 schreef Richard O'Keefe: > > What part of "return false if there are not exactly 10 characters > > left after discarding dashes" fails to handle the empty string? > > A test case for the empty string is is only valuable if the > > empty string is NOT a special case. > > > > On Wed, 2 Sep 2020 at 22:52, Roelof Wobben <r.wobben(a)home.nl> wrote: > > Op 2-9-2020 om 12:38 schreef Richard O'Keefe: > > There is simply no point in "taking the first nine numbers out". > > And there shouldn't BE a test for the string being empty, anywhere. > > '' '-' '---' and so on should all be handled the same way. > > > Oh well, what stops you doing > > > digits := aString select: [:each | each ~= $-]. > > digits size = 10 ifFalse: [^false]. > > lastDigit := digits la ost. > > digits := digits copyFrom: 1 to: 9. > > ( (lastDigit = $X or: [lastDigit isDigit]) and: [ > > digits allSatisfy: #isDigit] > > ) ifFalse: [^false]. > > > Now my code does not do this, but it is just 16 lines of code with > > nothing that it would make sense to extract. > > > > Nothing only that I could not think of this one for myself. > If I do it the TDD way I come more on the way Im currently thinking > > but does this case then be covered > > test14_EmptyIsbn > | result | > result := isbnVerifierCalculator isValidIsbn: ''. > self assert: result equals: false > > and still I have to do the calcualation to see if it's valid. > If I understand the code well I can use the digits variable ? > > > Roelof > > >

Sept. 6, 2020

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

by StÃ©phane Ducasse

just a question what if a bad guy you want to protect from is just smart and use a default vm. I mean what kind of thieves do you want to protect from? 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 ... S. > On 4 Sep 2020, at 22:05, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > My compromise would be to disable the GUI version of the VM. > > How can I compile a VM with the --headless setting hardcoded? Where to start? > > Esteban A. Maringolo > > On Fri, Sep 4, 2020 at 2:39 PM StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Thanks James >> >> This is pretty much the right questions :) >> And I would love to have money to solve the problems the way I would like but life is a compromise. >> >> S >> >> On 3 Sep 2020, at 20:50, Smalltalk(a)jgfoster.net <Smalltalk(a)JGFoster.net> wrote: >> >> >> On Sep 3, 2020, at 9:49 AM, Trygve Reenskaug <trygver(a)ifi.uio.no> wrote: >> >> The .sources file has been optional for as long as I can remember. >> Is it OK for list that somebody breaks this tradition? >> Trygve >> >> >> Hi Trygve, >> >> Iâm not sure what you mean by this question. >> >> Are you asking, âIs it acceptable to have code that relies on reflection in order to operate properly?â To this question I would answer âyesâ since some things are easier to do using reflection. >> >> Or are you asking, âWould it be better to not have FFI at all until it can be implemented without reflection?â To this question I would answer ânoâ since people that donât want reflection can choose to forego features that require it. >> >> Or are you asking, âWould it be nice if someone could do the work to implement FFI without reflection?â To this question I would answer âyes.â Unfortunately, there is a cost involved. >> >> So were you asking one of those questions or something else? >> >> James >> >> >> -------------------------------------------- >> 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 >> > -------------------------------------------- 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. 5, 2020