Re: [Pharo-users] Scaled decimals comparisons

[John Aspinall]

Dolphin shows the same behaviour. I added the following method to ScaledDecimal 
to help:

roundedByScale

| scaleFactor |

scaleFactor := 10 ** scale.

^(ScaledDecimal newFromNumber: (fraction * scaleFactor) rounded scale: 
scale) / scaleFactor


Translating slightly for Pharo:

roundedByScale

| scaleFactor |

scaleFactor := 10 ** scale.

^(ScaledDecimal newFromNumber: (self * scaleFactor) rounded scale: 
scale) / scaleFactor


You can then do:

(82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) roundedByScale = 
9.5s1  "true"


HTH.

John







> On 1 Sep 2020, at 05:17, Esteban Maringolo  wrote:
> 
> 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
> 

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

[Esteban Maringolo]

Hi Stef,

That was the first thing I tried, but PharoADO (it is, PharoCOM) needs
the source in order to do some of its stuff.

But even so, I'd still like to have a VM that is used only for running
the image headless, without any GUI (nor IDE).

Regards!

Esteban A. Maringolo

On Mon, Aug 31, 2020 at 10:20 AM Stéphane Ducasse
 wrote:
>
> 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] mentoring contined I hope

[Richard Sargent]

I recommend against modifying time instances once created. Likewise for
dates and timestamps.You don't know if the time instance has been shared
with another object. It's best to treat them as immutable once created.

Do not make the mistake of trying to avoid creating new objects. It will
lead to contorted code and all sorts of complications. (Of course, be
careful not to create a bazillion objects unnecessarily!)

The same advice applies to creating classes. Some languages have a high
cost to define a new class, usually psychological. This leaves their
programmers "allergic" (or acting as if they were) to creating a new class
that would make a solution better. In Smalltalk, a class is just an object.


In terms of how to model time, you *could* have the time object just store
the count of intervals since the start of the day. But, if you want Times
with microsecond resolution or nanosecond resolution, you would always be
working with a LargeInteger internally.
VA Smalltalk Time has ('hours' 'minutes' 'seconds' 'milliseconds'
'millisecondsFromMidnight')
VisualWorks Time has ('hours' 'minutes' 'seconds' 'milliseconds'
'partialNanosecond')
Pharo (5.0) Time has ('seconds' 'nanos')

It can be useful to trade space efficiency for comprehensibility. Often,
focussing on space efficiency results in convoluted code for little other
benefit. It's a good idea to start by modelling the concepts that we
discuss when describing something. My cookoo clock has an hour hand and a
minute hand. It has no concept of seconds, per se. It has a time tick, but
whether that is exactly one second, I don't know. Probably not. The
pendulum doesn't move that fast. So, if modelling a cookoo clock, modelling
the hours and minutes it shows is a reasonable design.

In some respects, modelling your Time as a number of minutes into the day
would simplify normalizing the arguments to the instance creation methods.
Just compute the requested number of minutes, perform the modulus to limit
the size of a day, and you are done. In the absence of a constraint imposed
by the author of the problem, you are free to implement a solution that
presents the expected results.


On Mon, Aug 31, 2020 at 10:12 PM Roelof Wobben  wrote:

> Op 1-9-2020 om 00:22 schreef Richard Sargent:
>
> On Mon, Aug 31, 2020 at 3:10 PM Roelof Wobben  wrote:
>
>> Op 31-8-2020 om 23:45 schreef 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 au

Re: [Pharo-users] Scaled decimals comparisons

[Esteban Maringolo]

It evaluates to false in VW too.

I guess it is a matter of internal representation, since
ScaledDecimals/FixedPoints are a Fraction after all.

What is weird, and I'd say wrong (at least from the UX perspective) is
that in Pharo (and Dolphin):
((91 - (2 * 35.9) - (0 / 2) * (113/121))  roundTo: 0.1) -> 17.902

While in VW and VAST they round the float properly:
((91 - (2 * 35.9) - (0 / 2) * (113/121))  roundTo: 0.1) -> 17.9

Regards!

Esteban A. Maringolo

On Tue, Sep 1, 2020 at 1:24 AM jtuc...@objektfabrik.de
 wrote:
>
> 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]

Hi John,

I was doing a similar rounding in the test assertion, I think your
method is better and broadly usable (and maybe convenient for an
#equals: implementation).

Thanks!

Esteban A. Maringolo

On Tue, Sep 1, 2020 at 4:33 AM John Aspinall  wrote:
>
> Dolphin shows the same behaviour. I added the following method to 
> ScaledDecimal to help:
>
> roundedByScale
>
> | scaleFactor |
>
> scaleFactor := 10 ** scale.
>
> ^(ScaledDecimal newFromNumber: (fraction * scaleFactor) rounded 
> scale: scale) / scaleFactor
>
>
> Translating slightly for Pharo:
>
> roundedByScale
>
> | scaleFactor |
>
> scaleFactor := 10 ** scale.
>
> ^(ScaledDecimal newFromNumber: (self * scaleFactor) rounded scale: 
> scale) / scaleFactor
>
>
> You can then do:
>
> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) roundedByScale = 
> 9.5s1  "true"
>
>
> HTH.
>
> John
>
>
>
>
>
>
>
> > On 1 Sep 2020, at 05:17, Esteban Maringolo  wrote:
> >
> > 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
> >
>
>

Re: [Pharo-users] Scaled decimals comparisons

[Stéphane Ducasse]

Hi john you can propose for inclusion in pharo. 

- Add a nice comment (with executablecomments would be a plus).
- Possibly some tests
- Send a PR. 

> On 1 Sep 2020, at 09:32, John Aspinall  wrote:
> 
> Dolphin shows the same behaviour. I added the following method to 
> ScaledDecimal to help:
> 
> roundedByScale
> 
>   | scaleFactor |
> 
>   scaleFactor := 10 ** scale.
> 
>   ^(ScaledDecimal newFromNumber: (fraction * scaleFactor) rounded scale: 
> scale) / scaleFactor
> 
> 
> Translating slightly for Pharo:
> 
> roundedByScale
> 
>   | scaleFactor |
> 
>   scaleFactor := 10 ** scale.
> 
>   ^(ScaledDecimal newFromNumber: (self * scaleFactor) rounded scale: 
> scale) / scaleFactor
> 
> 
> You can then do:
> 
> (82 - (2 * 35.9) - (0 / 2) * (113/121) asScaledDecimal: 1) roundedByScale = 
> 9.5s1  "true"
> 
> 
> HTH.
> 
> John
> 
> 
> 
> 
> 
> 
> 
>> On 1 Sep 2020, at 05:17, Esteban Maringolo  wrote:
>> 
>> 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
>> 
> 
> 


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] mentoring contined I hope

[Roelof Wobben via Pharo-users]

--- Begin Message ---

  
  
oke, then I would work with hour and minutes as the challenge
wanted,

  

  
 So still on the class side make code that convert any
  given hour and minute to a valid one ? 

  
  
  
  Yes. Such code would also be used when doing arithmetic
with Times. e.g. if you were to implement an instance method
named #addMinutes:, its implementation would be as simple as
^Time hours: self hours minutes: self minutes + anInteger
(assuming the argument has that name). The instance creation
method would normalize the new requested time, just like
Time hours: 0 minutes: 70 would do.
  
 
  Roelof
  

  

  



On some way I think or I do something wrong or I did misunderstood
you. 

 I did this in Pharo 

Object subclass: #Clock
    instanceVariableNames: 'hour minute'
    classVariableNames: ''
    package: 'Exercise@Clock'

I made a asscesors on the instance side. 

then I did this on the class side : 

hour: anInteger minute: anInteger2
    self hour: anInteger2 % 60 + anInteger;
    self minute: anInteger2 / 60; 
    yourself. 

but I see a message that hour and minutes are not known. 

Roelof

  


--- End Message ---

Re: [Pharo-users] mentoring contined I hope

[Richard Sargent]

What is the value of *self* when the error occurred? The debugger should
show you this.

Another way to determine this is to look at the code and think about where
the sending method is implemented and where the invoked method is
implemented (assuming that there really is one).


On Tue, Sep 1, 2020 at 10:11 AM Roelof Wobben  wrote:

> oke, then I would work with hour and minutes as the challenge wanted,
>
> So still on the class side make code that convert any given hour and
>> minute to a valid one ?
>>
>
> Yes. Such code would also be used when doing arithmetic with Times. e.g.
> if you were to implement an instance method named #addMinutes:, its
> implementation would be as simple as ^Time hours: self hours minutes: self
> minutes + anInteger (assuming the argument has that name). The instance
> creation method would normalize the new requested time, just like Time
> hours: 0 minutes: 70 would do.
>
>>
>> Roelof
>>
>>
>
> On some way I think or I do something wrong or I did misunderstood you.
>
>  I did this in Pharo
>
> Object subclass: #Clock
> instanceVariableNames: 'hour minute'
> classVariableNames: ''
> package: 'Exercise@Clock'
>
> I made a asscesors on the instance side.
>
> then I did this on the class side :
>
> hour: anInteger minute: anInteger2
> self hour: anInteger2 % 60 + anInteger;
> self minute: anInteger2 / 60;
> yourself.
>
> but I see a message that hour and minutes are not known.
>
> Roelof
>
>

Re: [Pharo-users] mentoring contined I hope

[Roelof Wobben via Pharo-users]

--- Begin Message ---

Op 1-9-2020 om 21:11 schreef Richard Sargent:
You will discover an error when you write your tests, but that's fine. 
It's why you write tests. :-)


#validateTime:minute: is a poor name choice for a few reasons.
- there is no validation going on. Validation would report an error 
for invalid data.
- there is nothing to suggest what the first argument is, the 
counterpart to "minute:".

- it doesn't suggest there will be a new Time ("Clock") created.
- it's a "verb phrase" saying it will *do* something rather than 
answer something (I'm being vague here. Sorry.)


I suggest #normalizedForHour:minute:.
It explains that it will normalize the values and that it will answer 
a normalized result (it still isn't great, as it doesn't explain what).

Perhaps better would be #newNormalizedForHour:minute:.





Thanks,

I think I found the error

and solved it

hour: anInteger minute: anInteger2
    ^ self new
        hour: (anInteger2 // 60 + anInteger) % 24;
        minute: anInteger2 % 60;
        yourself

instance side :

printOn: aStream
    ^ aStream
        nextPutAll: self hour asTwoCharacterString;
        nextPut: $:;
        nextPutAll: self minute asTwoCharacterString

and the tests are green

now time to sleep and tomorrow time to figure out how to add and 
substract minutes.
As I remember it right you gave already the answer to me somewhere in 
our conversation


Roelof





I

--- End Message ---

Re: [Pharo-users] mentoring contined I hope

[Roelof Wobben via Pharo-users]

--- Begin Message ---

  
  
Op 1-9-2020 om 21:40 schreef Roelof
  Wobben:

Op
  1-9-2020 om 21:11 schreef Richard Sargent:
  
  You will discover an error when you write
your tests, but that's fine. It's why you write tests. :-)


#validateTime:minute: is a poor name choice for a few reasons.

- there is no validation going on. Validation would report an
error for invalid data.

- there is nothing to suggest what the first argument is, the
counterpart to "minute:".

- it doesn't suggest there will be a new Time ("Clock") created.

- it's a "verb phrase" saying it will *do* something rather than
answer something (I'm being vague here. Sorry.)


I suggest #normalizedForHour:minute:.

It explains that it will normalize the values and that it will
answer a normalized result (it still isn't great, as it doesn't
explain what).

Perhaps better would be #newNormalizedForHour:minute:.



  
  
  
  Thanks,
  
  
  I think I found the error
  
  
  and solved it
  
  
  hour: anInteger minute: anInteger2
  
      ^ self new
  
          hour: (anInteger2 // 60 + anInteger) % 24;
  
          minute: anInteger2 % 60;
  
          yourself
  
  
  instance side :
  
  
  printOn: aStream
  
      ^ aStream
  
          nextPutAll: self hour asTwoCharacterString;
  
          nextPut: $:;
  
          nextPutAll: self minute asTwoCharacterString
  
  
  and the tests are green
  
  
  now time to sleep and tomorrow time to figure out how to add and
  substract minutes.
  
  As I remember it right you gave already the answer to me somewhere
  in our conversation
  
  
  Roelof
  
  


Making it a class method makes things very difficult 


  

--- End Message ---

Re: [Pharo-users] CV/OCR Library

[Tudor Girba]

Hi,

Indeed, we have an integration for OpenCV here:
https://github.com/feenkcom/gt4opencv

Cheers,
Doru



> On Aug 31, 2020, at 4:14 PM, Stéphane Ducasse  
> wrote:
> 
> 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
> 

--
feenk.com

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

Re: [Pharo-users] mentoring continued I hope

[Richard O'Keefe]

I have always found it annoying that the exercism specifications
do not spell things out, so you HAVE to read the tests to find out
what you are supposed to do, which pretty much spoils the point of
them BEING tests.

In this case, we note that there is a test case where the number
of hours is 100, and it is to be accepted as meaning '04'.
There is also a test case where the number of minutes is 160
and it is to be taken as 40 minutes plus 2 hours.

So the only way you can pass the tests is something like
class methods for: 'instance creation'
  hours: h minutes: m
^self new setMinutesSinceMidnight: (h * 60 + m bitOr: 0) \\ 1440

methods for: 'private'
  setMinutesSinceMidnight: m
minutesSinceMidnight := m.

methods for: 'accessing'
  hour
^minutesSinceMidnight // 60

  minute
^minutesSinceMidnight \\ 60

The only *checking* that is involved is that the hour and minute counts
must be integers, which I used " bitOr: 0" to do.  What's the best way to
do thisE?

As for where to do checking in general,
put it as close to the encapsulation boundary as you reasonably can.
If there is a PUBLIC method for changing the time on a Clock,
you need to put the checking in that method.  If (as here) a clock value
is supposed to be immutable, put it in the instance creation method.



On Mon, 31 Aug 2020 at 18:18, 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
> or can I better do this on the instance side.
>
> Regards,
>
> Roelof
>
>
>

Re: [Pharo-users] mentoring continued I hope

[Richard O'Keefe]

Roelof explicitly said that this is for an Exercism exercise.
That exercise defines the API (implicitly) in the test cases.
Roelof has no choice about what the API is, his job is just
to make the tests pass.  Your ideas about how to design an
API are good ones, it's just that Exercism says what to do.


On Tue, 1 Sep 2020 at 05:01, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:

> 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] mentoring contined I hope

[Richard O'Keefe]

Richard Sargent is giving good advice that you cannot use in Exercism.
Your code MUST pass the exercism tests and that means it MUST NOT
limit the hour or minute ranges.


On Tue, 1 Sep 2020 at 08:58, Roelof Wobben via Pharo-users <
pharo-users@lists.pharo.org> 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 send this personal because I cannot send to the mailing list according
> to some spam list
>

[Pharo-users] Can it do this way ?

[Roelof Wobben via Pharo-users]

--- Begin Message ---

Hello,

I have now a challenge where I have to validate a ISBN number.

Can I do something like this on the class side :

(string isEmpty)
   ifTrrue: [ ^ false]
  ifFalse:  [ digits:= something.
   controlDigit := something.
   self validateISBNNumber]

where on the validateISBNNumber I use the instance variables digits and 
controlDigit to validate the ISBN number on the instance side.


Roelof







--- End Message ---

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

[jtuc...@objektfabrik.de]

Roelof,

I don't think so.

A Class cannot access instance variables. Why? because a Class doesn't 
know which of its instances to ask for it.
Ask yourself: who is "self" in a Class method? Is it the Class or is it 
an individual instance of the Class?


(Hint: in a Class, #self is the Class, while in an instance, #self is 
the instance) .



"Who" do you want to validate the ISBN number? An individual instance of 
your Class (like Book)? Or is validating an ISBNNumber a Task that is 
independent of an individual item? If it is independent, then why would 
you want to use semething specific in that method?


You need to understand the differences between Class and Instance 
variables. I suggest reading Chapter 4 of "The Art and Science of 
Smalltalk 
" 
or better: read the whole book. It's easy to read and sparks quite a few 
A-HA's per hour.



HTH

Joachim


Am 02.09.20 um 08:18 schrieb Roelof Wobben:

Hello,

I have now a challenge where I have to validate a ISBN number.

Can I do something like this on the class side :

(string isEmpty)
   ifTrrue: [ ^ false]
  ifFalse:  [ digits:= something.
   controlDigit := something.
   self validateISBNNumber]

where on the validateISBNNumber I use the instance variables digits 
and controlDigit to validate the ISBN number on the instance side.


Roelof










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