Re: [Pharo-users] Scaled decimals comparisons

[jtuc...@objektfabrik.de]

Interesting. Your expression evaluates to true in VA Smalltalk.


Am 01.09.20 um 06:17 schrieb Esteban Maringolo:

As a follow up to this, adding a roundTo: before converting into a
ScaledDecimal does not work.

(((91 - (2 * 35.9) - (0 / 2) * (113/121))  roundTo: 0.1)
asScaledDecimal: 1) = 17.9s1

So how do you compare two ScaledDecimals that _should_ be the same?

Regards!

Esteban A. Maringolo

On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo  wrote:

Hi,

I was doing some basic calculations based on a formula, and I wanted
to convert the result to a scaled decimal in order to avoid having
these "loose" decimals in 10th position or something similar.

So I did the following:
82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1

But When I do this in a test:
(82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1

It fails because the comparison returns false.

I guess this is the proper behavior, but I'd expected that the
conversion from a Float to a scaled decimal would have eliminated the
extra precision from the formula.

I can do a roundTo: 0.1 before converting, but I'd like to know what
would be the proper way of dealing with this.

Thanks!

Esteban A. Maringolo




--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Scaled decimals comparisons

[Esteban Maringolo]

As a follow up to this, adding a roundTo: before converting into a
ScaledDecimal does not work.

(((91 - (2 * 35.9) - (0 / 2) * (113/121))  roundTo: 0.1)
asScaledDecimal: 1) = 17.9s1

So how do you compare two ScaledDecimals that _should_ be the same?

Regards!

Esteban A. Maringolo

On Tue, Sep 1, 2020 at 1:07 AM Esteban Maringolo  wrote:
>
> Hi,
>
> I was doing some basic calculations based on a formula, and I wanted
> to convert the result to a scaled decimal in order to avoid having
> these "loose" decimals in 10th position or something similar.
>
> So I did the following:
> 82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1
>
> But When I do this in a test:
> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1
>
> It fails because the comparison returns false.
>
> I guess this is the proper behavior, but I'd expected that the
> conversion from a Float to a scaled decimal would have eliminated the
> extra precision from the formula.
>
> I can do a roundTo: 0.1 before converting, but I'd like to know what
> would be the proper way of dealing with this.
>
> Thanks!
>
> Esteban A. Maringolo

[Pharo-users] Scaled decimals comparisons

[Esteban Maringolo]

Hi,

I was doing some basic calculations based on a formula, and I wanted
to convert the result to a scaled decimal in order to avoid having
these "loose" decimals in 10th position or something similar.

So I did the following:
82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1 -> 9.5s1

But When I do this in a test:
(82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) = 9.5s1

It fails because the comparison returns false.

I guess this is the proper behavior, but I'd expected that the
conversion from a Float to a scaled decimal would have eliminated the
extra precision from the formula.

I can do a roundTo: 0.1 before converting, but I'd like to know what
would be the proper way of dealing with this.

Thanks!

Esteban A. Maringolo

Re: [Pharo-users] mentoring contined I hope

[Richard Sargent]

On Mon, Aug 31, 2020 at 1:57 PM Roelof Wobben  wrote:

>
> I would argue against that approach. Make it a requirement that a given
> API must be used with correct values.
> e.g. #hours:minutes: requires hours between 00 and 23 and minutes between
> 00 and 59.
>
> If you want to convert equivalent time values, use a specific API. For
> example, many time implementations publicly define a seconds-based API,
> such as Time class>>#fromSeconds:. You can do the same with your
> implementation with a class-side #fromMinutes: method. (The corresponding
> instance methods would be #asSeconds and #asMinutes or something similar.)
>
>
>
> Moment, I do not know if I understand you right.
>
> so I would use the given method and use on the instance another function
> that takes care of the converting to or a valid time object or for example
> convert it to minutes and on display take care that a valid time is shown.
>
> Do I understand you right ?
>

I don't think you do, but it's a little difficult to determine.

*Time hours: 0 minutes: 70* should throw an out of range exception on the
second argument.
Time fromMinutes: 70 "should" answer an instance equivalent to 01:00. (I
say should in quotes, because Time is a point in time. Duration is
something that makes more sense to have *Duration minutes: 70* be
acceptable.)

This discussion assumes *your* model of time uses just hours and minutes.
Normally, Time includes seconds, and often fractions of seconds. But, you
are working on an exercise, so a reduced scope Time may be appropriate.

Rather than talking about Time class>>#fromMinutes:, let's go a little more
extreme and discuss a hypothetical Time class>>#fromHours: method. We
understand and agree that Time can represent hours from 0 through 23. There
is no 24 o'clock. So, if you wrote *Time fromHours: 25*, what would you
expect to get for a result? What would someone who comes along later and
uses your code expect to get? It's not well defined. So extrapolate from
that case to the other cases. 70 minutes is not a time. "I'll meet you *at*
70 minutes" said no one ever. :-) ["*in* 70 minutes" is a duration from the
present moment, implying a time 70 minutes in the future.]

I have come across a lot of code in my life. The hardest code to work with
and to enhance is code that says it will try to accept whatever it's given.
If it wants a number, it will accept a string of digits and "figure out"
what number was meant. Life is so much easier when the author says "That's
rubbish. Give me a proper number." or "That's too big. Give me a proper
number of hours.", etc.

In general, make your APIs precise and predictable. Range check the passed
values and complain when they aren't proper. If the clock you are modelling
has a precision of minutes, your API is #hours:minutes: and maybe just
#hours: for convenience. (In general, I wouldn't do so.) And it's
reasonable to have methods to answer the number of increments from the
start of the day of your clock's precision and to create a new instance
from that number. So, with a precision of minutes, you can have an instance
method named e.g. #asMinutes or perhaps #totalMinutes or even
#minutesSinceMidnight, and to have a corresponding *class* method
#fromMinutes: or #minutesFromMidnight: which answers the corresponding
instance of Time. If your clock has a precision of seconds, which is more
normal for us, those "minutes" methods would actually be similarly named
"seconds" methods instead. (If your clock has a precision finer than
seconds, I would expect to see corresponding methods for the finer
gradations of time that would be common, *in addition to* the various
"seconds" methods. e.g. milliseconds or microseconds since midnight. And
likely both if the clock resolution was microseconds, just because we do
tend to think of milliseconds or microseconds when we talk of more precise
times.)


Just as the advice I gave you some months ago was to be unambiguous and
precise when naming things, be unambiguous and precise about your APIs (all
your methods, really!). People who end up using your code will thank you.





> I send this personal because I cannot send to the mailing list according
> to some spam list
>

[Pharo-users] mentoring contined I hope

[Roelof Wobben via Pharo-users]

--- Begin Message ---

  
  

  

  I would argue against that approach. Make it a
requirement that a given API must be used with correct
values.
  e.g. #hours:minutes: requires hours between 00 and 23 and
minutes between 00 and 59.
  
  
  If you want to convert equivalent time values, use a
specific API. For example, many time implementations
publicly define a seconds-based API, such as Time
class>>#fromSeconds:. You can do the same with your
implementation with a class-side #fromMinutes: method. (The
corresponding instance methods would be #asSeconds and
#asMinutes or something similar.)
  
  
  

  


Moment, I do not know if I understand you right. 

so I would use the given method and use on the instance another
function that takes care of the converting to or a valid time object
or for example convert it to minutes and on display take care that a
valid time is shown. 

Do I understand you right ? 

I send this personal because I cannot send to the mailing list
according to some spam list
  


--- End Message ---

Re: [Pharo-users] mentoring continued I hope

[Richard Sargent]

On Sun, Aug 30, 2020 at 10:04 PM Roelof Wobben via Pharo-users <
pharo-users@lists.pharo.org> wrote:

> Hello,
>
> I have this challenge from exercism :
> https://github.com/exercism/pharo-smalltalk/tree/master/exercises/clock
>
> and this function is given :
>
> hour: anInteger minute: anInteger2
>  self shouldBeImplemented
>
>
> Schould I make it on this class method work that the minutes will not
> exceed the 59 minutes
> So when for example when 70 min are given so hour:0  minute:70 it will
> be converted to hour: 1 minutes: 10
>

I would argue against that approach. Make it a requirement that a given API
must be used with correct values.
e.g. #hours:minutes: requires hours between 00 and 23 and minutes between
00 and 59.

If you want to convert equivalent time values, use a specific API. For
example, many time implementations publicly define a seconds-based API,
such as Time class>>#fromSeconds:. You can do the same with your
implementation with a class-side #fromMinutes: method. (The corresponding
instance methods would be #asSeconds and #asMinutes or something similar.)


or can I better do this on the instance side.
>
> Regards,
>
> Roelof
>
>
>

Re: [Pharo-users] ported and refreshed Crypto-Nacl to GitHub (from StH)

[Torsten Bergmann]

Hi Jonathan,
 
nice, thanks for investing time and effort into this. Such utilities are needed 
for serious applications. Some thoughts and questions:

 1. What is the mid-term or long-term plan regarding collaboration? Will you be 
able to step in as maintainer?

 2. As it already seems to be authored by several people and contains 
functionality of general interest it should be considered to move it to 
     a central community place like 
https://github.com/pharo-contributions[https://github.com/pharo-contributions/Cryptography]/
 where several people from community have already
     access. It would then be in alignment with 
https://github.com/pharo-contributions/Cryptography[https://github.com/pharo-contributions/Cryptography]
 too and maintenance of
 contributions as well as releases could be done from different sides and 
more centrally.
 
     You and anyone can then regulary fork from the community repo to an own 
(customized) repo like https://github.com/objectguild/Crypto-Nacl

     I guess Esteban can add you as contributor to "pharo-contribution" 
organization if you follow that path.

 3. I guess LICENSE file need to be updated to give additionall credit to the 
original authors or mention more general "Pharo community" 
     (currently it mentions Object Guild solely)
 
 4. Can it be changed to use "NaCl" instead of "Nacl" which is more suitable 
name for Sodium  (a similar name fixing was done in the Cuis port too)

 5. Would it be possible to add some expressions/samples or docu in the README 
for end users on how to use it. This would give people a quick guide 
on how to do things.
    
 6. Any plans for making it work on Windows too?

Thanks
Torsten
 

Gesendet: Montag, 31. August 2020 um 09:52 Uhr
Von: "Jonathan van Alteren" 
An: "Any question about pharo is welcome" 
Betreff: [Pharo-users] ported and refreshed Crypto-Nacl to GitHub (from StH)

Hi all,

I wanted to let you know that I ported the Crypto-Nacl library from 
SmalltalkHub to GitHub here: 
https://github.com/objectguild/Crypto-Nacl[https://github.com/objectguild/Crypto-Nacl]

The original author is Tony Garnock-Jones, with contributions from Hernán 
Morales Durand. See the README for more details.

Libsodium has evolved a lot over time, which means that there is plenty of 
additional functionality that can be unlocked through this library. I don't 
have a need for it at the moment, but that might change in the near future. My 
interest is in using the cryptographic features to enhance security of business 
applications.

Oh, and thanks to the Buenos Aires Smalltalk team 
(https://github.com/ba-st/[https://github.com/ba-st/]) for inspiration on using 
GitHub Actions with smalltalkCI :-)
 

Cheers,

Jonathan van Alteren

Founding Member | Object Guild B.V.
Sustainable Software for Purpose-Driven Organizations

jvalte...@objectguild.com

Re: [Pharo-users] CV/OCR Library

[Stéphane Ducasse]

I know that there is an openCV binding by https://twitter.com/DmitryMatveev 
You have a binding in GT too. 


> On 31 Aug 2020, at 14:40, Esteban Maringolo  wrote:
> 
> Hi,
> 
> Does anybody know if there is an OCR or some CV library available for Pharo?
> 
> I would like to make an experiment with recognizing the content of
> some fixed size form, and of course I prefer to do it with Smalltalk
> whenever possible.
> 
> Regards!
> 
> 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] CV/OCR Library

[Esteban Maringolo]

Hi Eric,

Thanks for the reference. I'll look into it!

Regards!

Esteban A. Maringolo

On Mon, Aug 31, 2020 at 10:06 AM Eric Gade  wrote:
>
> Hi Esteban,
>
> I know that Sean D has wrapped the Tesseract OCR library:
> https://github.com/seandenigris/Tesseract-St
>
> On Mon, Aug 31, 2020 at 8:42 AM Esteban Maringolo  
> wrote:
>>
>> Hi,
>>
>> Does anybody know if there is an OCR or some CV library available for Pharo?
>>
>> I would like to make an experiment with recognizing the content of
>> some fixed size form, and of course I prefer to do it with Smalltalk
>> whenever possible.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>
>
> --
> Eric

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

[Stéphane Ducasse]

If this is for obsfucation why not simply providing an empty source/changes 
file?
And you can remove the decompiler (but then after you will never debug anymore 
your application). 

S

> Hi Stef,
> 
> Thanks for the support.
> 
> I don't know if there is a way to do that for FFI except if you
> somehow modify the methods during execution to include the arguments
> in the method itself instead of relying on the source code for
> reflection.
> 
> What would help in the meantime is to have a VM that is headless all
> the time (something like a forced --headless parameter), otherwise it
> is really easy for somebody to remove the --headless parameter and
> fire your image and navigate your code with all the power a Smalltalk
> IDE provides.
> 
> Is there a way to compile a VM with such an option? (basically a
> HeadlessPharoConsole.exe).
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> On Sat, Aug 29, 2020 at 2:46 AM Stéphane Ducasse
>  wrote:
>> 
>> Hi
>> 
>> I’m really interested in this.
>> Because we should be able to ship without the sources.
>> FFI needs the source at some point but I guess that this is the first time
>> and that the information could be stored in the compiledMethod.
>> But I do not remember.
>> 
>> Now may be esteban or pablo can give you some hints
>> but frankly we are super super super busy
>> but if you have a way and that Pharo should be changed to support this 
>> scenario let
>> us know we will support you.
>> 
>> S
>> 
>> On 29 Aug 2020, at 04:49, Esteban Maringolo  wrote:
>> 
>> Hi,
>> 
>> Is there a way to get rid the .sources file in a deployment scenario?
>> 
>> I followed this guide [1], but I cannot get rid of the .sources files,
>> because I'm using PharoADO (which uses PharoCOM) and it uses some
>> reflection for FFI and for some reason that implies using the .sources
>> file. I installed the FFICompilerPlugin as per the instructions, but I
>> don't have a way to tell whether I did in the right place/moment, nor
>> how to assess its proper installation.
>> 
>> If such [2] .sources file cannot be removed, what is the criteria for
>> the lookup, can it be renamed or modified via some parameter/config?
>> 
>> Thanks!
>> 
>> [1] 
>> https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/DeployYourPharoApplication.md#sources-obfuscation
>> [2] Pharo8.0-32bit-0932da8.sources in my case
>> 
>> 
>> 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
>> 
> 


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] CV/OCR Library

[Eric Gade]

Hi Esteban,

I know that Sean D has wrapped the Tesseract OCR library:
https://github.com/seandenigris/Tesseract-St

On Mon, Aug 31, 2020 at 8:42 AM Esteban Maringolo 
wrote:

> Hi,
>
> Does anybody know if there is an OCR or some CV library available for
> Pharo?
>
> I would like to make an experiment with recognizing the content of
> some fixed size form, and of course I prefer to do it with Smalltalk
> whenever possible.
>
> Regards!
>
> Esteban A. Maringolo
>
>

-- 
Eric

[Pharo-users] CV/OCR Library

[Esteban Maringolo]

Hi,

Does anybody know if there is an OCR or some CV library available for Pharo?

I would like to make an experiment with recognizing the content of
some fixed size form, and of course I prefer to do it with Smalltalk
whenever possible.

Regards!

Esteban A. Maringolo

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

[Esteban Maringolo]

Hi Stef,

Thanks for the support.

I don't know if there is a way to do that for FFI except if you
somehow modify the methods during execution to include the arguments
in the method itself instead of relying on the source code for
reflection.

What would help in the meantime is to have a VM that is headless all
the time (something like a forced --headless parameter), otherwise it
is really easy for somebody to remove the --headless parameter and
fire your image and navigate your code with all the power a Smalltalk
IDE provides.

Is there a way to compile a VM with such an option? (basically a
HeadlessPharoConsole.exe).

Regards!

Esteban A. Maringolo

On Sat, Aug 29, 2020 at 2:46 AM Stéphane Ducasse
 wrote:
>
> Hi
>
> I’m really interested in this.
> Because we should be able to ship without the sources.
>  FFI needs the source at some point but I guess that this is the first time
> and that the information could be stored in the compiledMethod.
> But I do not remember.
>
> Now may be esteban or pablo can give you some hints
> but frankly we are super super super busy
> but if you have a way and that Pharo should be changed to support this 
> scenario let
> us know we will support you.
>
> S
>
> On 29 Aug 2020, at 04:49, Esteban Maringolo  wrote:
>
> Hi,
>
> Is there a way to get rid the .sources file in a deployment scenario?
>
> I followed this guide [1], but I cannot get rid of the .sources files,
> because I'm using PharoADO (which uses PharoCOM) and it uses some
> reflection for FFI and for some reason that implies using the .sources
> file. I installed the FFICompilerPlugin as per the instructions, but I
> don't have a way to tell whether I did in the right place/moment, nor
> how to assess its proper installation.
>
> If such [2] .sources file cannot be removed, what is the criteria for
> the lookup, can it be renamed or modified via some parameter/config?
>
> Thanks!
>
> [1] 
> https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/DeployYourPharoApplication.md#sources-obfuscation
> [2] Pharo8.0-32bit-0932da8.sources in my case
>
>
> 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] ported and refreshed Crypto-Nacl to GitHub (from StH)

[Stéphane Ducasse]

tx!


> On 31 Aug 2020, at 09:52, Jonathan van Alteren  
> wrote:
> 
> Hi all,
> 
> I wanted to let you know that I ported the Crypto-Nacl library from 
> SmalltalkHub to GitHub here: https://github.com/objectguild/Crypto-Nacl 
> 
> 
> The original author is Tony Garnock-Jones, with contributions from Hernán 
> Morales Durand. See the README for more details.
> 
> Libsodium has evolved a lot over time, which means that there is plenty of 
> additional functionality that can be unlocked through this library. I don't 
> have a need for it at the moment, but that might change in the near future. 
> My interest is in using the cryptographic features to enhance security of 
> business applications.
> 
> Oh, and thanks to the Buenos Aires Smalltalk team (https://github.com/ba-st/ 
> ) for inspiration on using GitHub Actions with 
> smalltalkCI :-)
> 
> Cheers,
> 
> Jonathan van Alteren
> 
> Founding Member | Object Guild B.V.
> Sustainable Software for Purpose-Driven Organizations
> 
> jvalte...@objectguild.com


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] Image crashed, how can I restore the Playground?

[Davide Varvello via Pharo-users]

--- Begin Message ---
Thanks Offray,
I'll give a glance to Grafoscopio
Cheers
Davide



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--- End Message ---

[Pharo-users] ported and refreshed Crypto-Nacl to GitHub (from StH)

[Jonathan van Alteren]

Hi all,

I wanted to let you know that I ported the Crypto-Nacl library from 
SmalltalkHub to GitHub here: https://github.com/objectguild/Crypto-Nacl

The original author is Tony Garnock-Jones, with contributions from Hernán 
Morales Durand. See the README for more details.

Libsodium has evolved a lot over time, which means that there is plenty of 
additional functionality that can be unlocked through this library. I don't 
have a need for it at the moment, but that might change in the near future. My 
interest is in using the cryptographic features to enhance security of business 
applications.

Oh, and thanks to the Buenos Aires Smalltalk team (https://github.com/ba-st/) 
for inspiration on using GitHub Actions with smalltalkCI :-)

Cheers,

Jonathan van Alteren

Founding Member | Object Guild B.V.
Sustainable Software for Purpose-Driven Organizations

jvalte...@objectguild.com