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

[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
:


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  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

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

[Esteban Maringolo]

Stef,

On Sat, Sep 5, 2020 at 12:49 PM Stéphane Ducasse
 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  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/DeployYourPharoApplication.md#sources-obfuscation

Esteban A. Maringolo

[Pharo-users] Rounding in Floats

[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.1005"

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

Re: [Pharo-users] Rounding in Floats

[Sven Van Caekenberghe]

> On 6 Sep 2020, at 16:06, Esteban Maringolo  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.1005"
> 
> 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
> 

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

[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
 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  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/DeployYourPharoApplication.md#sources-obfuscation

Esteban A. Maringolo


--
Ing. Davide Grandi
email: davide.gra...@email.it
mobile   : +39 339 7468 778
linkedin : http://linkedin.com/in/davidegrandi

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

[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  wrote:
> 
> Stef,
> 
> On Sat, Sep 5, 2020 at 12:49 PM Stéphane Ducasse
>  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  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/DeployYourPharoApplication.md#sources-obfuscation
> 
> 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

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

[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
 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  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/DeployYourPharoApplication.md#sources-obfuscation


Esteban A. Maringolo



--
Ing. Davide Grandi
email: davide.gra...@email.it
mobile   : +39 339 7468 778
linkedin : http://linkedin.com/in/davidegrandi

Re: [Pharo-users] Rounding in Floats

[Esteban Maringolo]

Hi Sven,

On Sun, Sep 6, 2020 at 11:57 AM Sven Van Caekenberghe  wrote:
> > On 6 Sep 2020, at 16:06, Esteban Maringolo  wrote:

> > (9.1 + (-2.0)) roundTo: 0.1.
> > "7.1005"

> > 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

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

[Esteban Maringolo]

On Sun, Sep 6, 2020 at 12:52 PM Davide Grandi  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,

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

[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  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.gra...@email.it
mobile   : +39 339 7468 778
linkedin : http://linkedin.com/in/davidegrandi

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

[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  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  
> > 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.gra...@email.it
> mobile   : +39 339 7468 778
> linkedin : http://linkedin.com/in/davidegrandi
>
>

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

[Roelof Wobben via Pharo-users]

  
  
Hello, 
  
  I solved it but with what I find one big ugly code 
  
  isValidIsbn: aString
      | digits lastDigit acc |
      digits := aString select: [ :each | each ~= $- ].
      digits size = 10
          ifFalse: [ ^ false ].
      lastDigit := digits last.
      digits := aString allButLast asOrderedCollection
          select: [ :each | each isDecimalDigit ]
          thenCollect: [ :each | each digitValue ].
      ((lastDigit = $X or: [ lastDigit isDigit ]) and: [ digits size
  == 9 ])
          ifFalse: [ ^ false ].
      acc := digits
          with: (10 to: 2 by: -1)
          collect: [ :digit :multiplier | digit * multiplier ].
      ^ ((acc sum + (lastDigit digitValue min: 10)) % 11) isZero
  
  Can this be improved some way ? 
  
  Roelof
  
  
  
  Op 4-9-2020 om 07:35 schreef Roelof Wobben via Pharo-users:


  
  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  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