September 2020 - Pharo-users

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

by Roelof Wobben

See here for all the tests : https://github.com/exercism/pharo-smalltalk/blob/master/exercises/isbn-veri… Roelof

Sept. 7, 2020

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

by Esteban Maringolo

Hi Davide, Thanks for the thorough response, but I think you're over dimensioning, and to some extent missing, my initial purpose and intention. I don't want to protect from somebody attempting to reverse engineer my application, that's impossible (more so given your references). I simply want to disable the option to open the IDE, even with all tool menus disabled. In Java if I deliver a .jar or .war anybody could reverse engineer it, but launching it won't open the development environment. For comparison with other Smalltalks I've used: * VisualWorks enables the distribution of a "headless" IMAGE (and parcels) without sources, if you revert that image to be headful all source code will be decompiled using meaningless variables. * Dolphin has the concept of SessionManager that is the entry point to the image startup, if you save your image with a Headless Session manager, then no GUI loop will start, same thing if you deploy as a COM component. * VAST produces its own ICX file where you can choose what to include in it, it's not simply saving the image but building a new one from within the development image, it's one step further. * VSE had the SLL (similar to DLLs), if you don't bind the IDE's SLLs then there is no way to start the IDE (I never built a headless VSE app though). So what I'd like is an always Pharo headless image or Pharo headless vm, instead of being controlled by a parameter in the VM. Regards, Esteban A. Maringolo On Mon, Sep 7, 2020 at 12:04 PM Davide Grandi <davide.grandi(a)email.it> wrote: > > Ok, I'll give you a result, meanwhile fixing some imprecisions. > > The "class" is CogVmSimulator but it's use is very far from my knowlegde, > I recalled having seen a picture of Pharo-in-Pharo (or Squeak-in-Squeak) > running under this simulator. > It lives near the Cog side (or the OpenVM side) of Squeak/Pharo > (If I'm not wrong Squeak ran into an emulator, before walking on his > legs-his VM). > > There are many of these simulator, for other Smalltalk : > - Hobbes and others for Xerox (thanks to files of Mario Molczko and/or > Bitsavers > - Dan Ingalls Apda Smalltalk + old Smalltalk -72 /-76 > and maybe others I don't yet know about > > The reason is quite simple : the object memory is written to disk > and the spec of executing Smalltalk are known either from the books > or by the source. > > The root is Xerox's SystemTracer, a class that wrote a running image > to disk, optionally changing object format (see the Green Book). > > So : > - if you can read the image > - you can run into a simulator > - or decode it without to much effort (5 emulators for Xerox V2 image, > so far). > (try to open an image with a text editor : intriguing !) > > I don't know how Cincom or Instantiations protect the released st code, > but for Pharo and Squeak this is not a point : they are all open. > > So, as if you wanna "protect" names and methods of a running image ... > ... you have to (IMHO) : > - encrypt executable and image (and modify the VM) > - or obfuscate your classes and methods renaming it to > C1, C2, ..., m1:p1:p2: and so on (keeping a map for debugging) > > Sorry to be imprecise about names and locations > apart from suggest to see 4 emulators 4 running in a squeak image > running ... in javascript in your browser (so total is 5) at : > https://smalltalkzoo.thechm.org/HOPL-Squeak.html?earlyst80 > (thanks to Vanessa Freudemberg & Dan Ingalls). > > Sorry again & best regards, > > Davide Grandi > > On 06/09/2020 23:51, Esteban Maringolo wrote: > > 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 > > -- > Ing. Davide Grandi > email : davide.grandi(a)email.it > mobile : +39 339 7468 778 > linkedin : http://linkedin.com/in/davidegrandi > >

Sept. 7, 2020

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

by Davide Grandi

Ok, I'll give you a result, meanwhile fixing some imprecisions. The "class" is CogVmSimulator but it's use is very far from my knowlegde, I recalled having seen a picture of Pharo-in-Pharo (or Squeak-in-Squeak) running under this simulator. It lives near the Cog side (or the OpenVM side) of Squeak/Pharo (If I'm not wrong Squeak ran into an emulator, before walking on his legs-his VM). There are many of these simulator, for other Smalltalk : - Hobbes and others for Xerox (thanks to files of Mario Molczko and/or Â Bitsavers - Dan Ingalls Apda Smalltalk + old Smalltalk -72 /-76 and maybe others I don't yet know about The reason is quite simple : the object memory is written to disk and the spec of executing Smalltalk are known either from the books or by the source. The root is Xerox's SystemTracer, a class that wrote a running image to disk, optionally changing object format (see the Green Book). So : - if you can read the image - you can run into a simulator - or decode it without to much effort (5 emulators for Xerox V2 image, so far). (try to open an image with a text editor : intriguing !) I don't know how Cincom or Instantiations protect the released st code, but for Pharo and Squeak this is not a point : they are all open. So, as if you wanna "protect" names and methods of a running image ... ... you have to (IMHO) : - encrypt executable and image (and modify the VM) - or obfuscate your classes and methods renaming it to Â C1, C2, ..., m1:p1:p2: and so on (keeping a map for debugging) Sorry to be imprecise about names and locations apart from suggest to see 4 emulators 4 running in a squeak image running ... in javascript in your browser (so total is 5) at : https://smalltalkzoo.thechm.org/HOPL-Squeak.html?earlyst80 (thanks to Vanessa Freudemberg & Dan Ingalls). Sorry again & best regards, Â Â Â Davide Grandi On 06/09/2020 23:51, Esteban Maringolo wrote: > 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 -- Ing. Davide Grandi email : davide.grandi(a)email.it mobile : +39 339 7468 778 linkedin : http://linkedin.com/in/davidegrandi

Sept. 7, 2020

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

by Steffen MÃ¤rcker

No problem. I am not knowledgeable about isbn numbers. At which places may a dash occur? Kind regards, Steffen 07.09.2020 16:18:22 Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org>: > Op 6-9-2020 om 10:07 schreef 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 nder if the code will not be too big. I learned that it is good >> > Sorry to respond not earlier but your respons seems to be in the spam folder of my provider. > > I could do that but if very bad in regex so I do not know a regex which van validate 123456789 or 123-456-78-9 > > Roelof >

Sept. 7, 2020

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

by Roelof Wobben

Op 6-9-2020 om 10:07 schreef 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 nder if the code will not be too big. I learned that it is good > Sorry to respond not earlier but your respons seems to be in the spam folder of my provider. I could do that but if very bad in regex so I do not know a regex which van validate 123456789 or 123-456-78-9 Roelof

Sept. 7, 2020

Re: [Pharo-users] Rounding in Floats

by Esteban Maringolo

Hi Tomohiro, Thanks, that certainly is the simplest solution that does exactly what I need. Maybe roundTo: should be considered harmful when using Floats. (and it is very unlikely anybody is going to round to something other than a power of 10) Best regards! Esteban A. Maringolo On Mon, Sep 7, 2020 at 9:51 AM Tomohiro Oda <tomohiro.tomo.oda(a)gmail.com> wrote: > > Esteban, > > You can instead use `7.1 round: 1` to get 7.1. > It's not the problem of the rounding algorithm. > It's because IEEE float can't express the exact value of 0.1. > --- > tomo > > 2020å¹´9æ7æ¥(æ) 21:28 Esteban Maringolo <emaringolo(a)gmail.com>: > > > > Hi Sven, > > > > On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > On 6 Sep 2020, at 22:21, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > > > > > It is not for printing but for testing. I want to assert that a > > > > certain calculation gives the expected result. > > > > > > Then you should use #assert:closeTo: and friends. > > > (9.1 + (-2.0)) closeTo: 7.1 precision: 0.1. > > > > I remembered about it, and implemented my own > > #assertDifferential:equals: which I first did convert to > > ScaledDecimals and then compares with #roundedByScale. > > > > > Floats should always be compared using an epsilon (precision) value in tests, not using equality. > > > > Sure, but 7.1 roundTo: 0.1 should return 7.1. Shouldn't it? > > > > Regards! > > > > Esteban A. Maringolo > > >

Sept. 7, 2020

Re: [Pharo-users] Rounding in Floats

by Tomohiro Oda

Esteban, You can instead use `7.1 round: 1` to get 7.1. It's not the problem of the rounding algorithm. It's because IEEE float can't express the exact value of 0.1. --- tomo 2020å¹´9æ7æ¥(æ) 21:28 Esteban Maringolo <emaringolo(a)gmail.com>: > > Hi Sven, > > On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 6 Sep 2020, at 22:21, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > > > It is not for printing but for testing. I want to assert that a > > > certain calculation gives the expected result. > > > > Then you should use #assert:closeTo: and friends. > > (9.1 + (-2.0)) closeTo: 7.1 precision: 0.1. > > I remembered about it, and implemented my own > #assertDifferential:equals: which I first did convert to > ScaledDecimals and then compares with #roundedByScale. > > > Floats should always be compared using an epsilon (precision) value in tests, not using equality. > > Sure, but 7.1 roundTo: 0.1 should return 7.1. Shouldn't it? > > Regards! > > Esteban A. Maringolo >

Sept. 7, 2020

Re: [Pharo-users] Rounding in Floats

by Esteban Maringolo

Hi Sven, On Mon, Sep 7, 2020 at 9:10 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 6 Sep 2020, at 22:21, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > It is not for printing but for testing. I want to assert that a > > certain calculation gives the expected result. > > Then you should use #assert:closeTo: and friends. > (9.1 + (-2.0)) closeTo: 7.1 precision: 0.1. I remembered about it, and implemented my own #assertDifferential:equals: which I first did convert to ScaledDecimals and then compares with #roundedByScale. > Floats should always be compared using an epsilon (precision) value in tests, not using equality. Sure, but 7.1 roundTo: 0.1 should return 7.1. Shouldn't it? Regards! Esteban A. Maringolo

Sept. 7, 2020

Re: [Pharo-users] Rounding in Floats

by serge.stinckwich＠gmail.com

BTW why closeTo: is initialized by default with a value of 0.0001 ? https://github.com/pharo-project/pharo/issues/3067 Sent from my iPhone > On 7 Sep 2020, at 20:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > ï»¿ > >> On 6 Sep 2020, at 22:21, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> It is not for printing but for testing. I want to assert that a >> certain calculation gives the expected result. > > Then you should use #assert:closeTo: and friends. > > (9.1 + (-2.0)) closeTo: 7.1 precision: 0.00001. > > Floats should always be compared using an epsilon (precision) value in tests, not using equality. > >

Sept. 7, 2020

Re: [Pharo-users] Rounding in Floats

by Sven Van Caekenberghe

> On 6 Sep 2020, at 22:21, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > It is not for printing but for testing. I want to assert that a > certain calculation gives the expected result. Then you should use #assert:closeTo: and friends. (9.1 + (-2.0)) closeTo: 7.1 precision: 0.00001. Floats should always be compared using an epsilon (precision) value in tests, not using equality.

Sept. 7, 2020