[Pharo-dev] Esteban's ChangeLog week of 17 September 2018

[estebanlm]

Hello!

This is my weekly ChangeLog, from 17 September 2018 to 23 September 2018.
You can see it in a better format by going here: 
http://log.smallworks.eu/web/search?from=17/9/2018&to=23/9/2018

ChangeLog
=

19 September 2018:
--

*I migrated all [pharo-ide](https://github.com/pharo-ide) projects to tonel 
format. 

Harder than it seems, it took me a good bunch of hours. But now is working. 

This will enhance work/fixes on Calypso.


18 September 2018:
--

*I just [fixed the CI for 
Calypso](https://github.com/pharo-ide/Calypso/issues/319) (it was failing for 
Pharo 7.0 because of problems when updating).

Now I can start fixing real issues of it :)


17 September 2018:
--

*I backported/promoted a new stable vm for Pharo 6.1. 
This is the one that has been tested for Pharo 7.0alpha already for some 
time, so things should be fine.

Current stable VM is from 2018-07-04 (yeah, eventually we will have a 
decent semver numbering, 
but for now this will have to be enough :P)


cheers! 
Esteban

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - corrected screenshot link

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Ohh sorry - better screenshot link: 





https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy  





pf


> Hi Petr,
> 
> On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev
>  wrote:
> >
> > Hello, I want to propose some small fixes to Pharo, it took me hours just 
> > to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)...
> >
> > Now I am stuck with this Iceberg error:
> > https://app.box.com/file/321243070589
> 
> I was presented with a login box when I tried to view this.
> 
> 
> > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest 
> > CentOS7) - is Iceberg OK on 64bits?
> 
> Yes, I use it all the time (on Ubuntu 16.04 64 bit).
> 
> Cheers,
> Alistair

--- End Message ---

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage

[Alistair Grant]

Hi Petr,

On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev
 wrote:
>
> Hello, I want to propose some small fixes to Pharo, it took me hours just to 
> run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)...
>
> Now I am stuck with this Iceberg error:
> https://app.box.com/file/321243070589

I was presented with a login box when I tried to view this.


> I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest 
> CentOS7) - is Iceberg OK on 64bits?

Yes, I use it all the time (on Ubuntu 16.04 64 bit).

Cheers,
Alistair

[Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello, I want to propose some small fixes to Pharo, it took me hours just to 
run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)...

Now I am stuck with this Iceberg error:
https://app.box.com/file/321243070589

I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest 
CentOS7) - is Iceberg OK on 64bits?

Thanks! pf

--- End Message ---

[Pharo-dev] update linux info page again, please [CentOS/RHEL]

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello,

please, edit CentOS7 installation page:
https://pharo.org/gnu-linux-installation-64

and add workaround for CentOS7 section, wihout this symlink, iceberg is broken:

(do as root)
cd /usr/lib64
ln -s libcurl.so.4 libcurl-gnutls.so.4

Best solution is to put this in the RPM post installation step (I mean RPM from 
official Pharo CentOS repository) - but we will wait for this fix for months, 
maybe years, so, workaround info on that page is necessary and easy to manage.

More details here:
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272624.html

Thanks! pf

--- End Message ---

Re: [Pharo-dev] [rmod] Float should not implement #to:, #to:by:, etc...

[Nicolas Cellier]

Hi Davide,
Using decimals is a possibility which already exists, just add a $s at end
of the literal.
What you suggest is to change the syntax and use decimal as the default,
and another notation (or no literal notation at all, just asFloat message
send) for floating point numbers.

It's worth trying, but IMO, you will encounter these limitations:
- decimals currently are implemented as unlimited precision Fraction. For
long calculations, they will tend to grow in size and slow down the system
(I have developped a symbolic calculation library in Smalltalk 30 yeras ago
and thus used the Fraction extensively, so I know what it can cost).
- decimals currently are not decimals but arbitrary fractions (for example
2.0s / 3 will be represented as Fraction 2/3 internally). But they print as
a rounded decimal representation which can't convert back to the same
number, and thus is not the most convenient for REPL style.
- most decimals operations are slower than floating point operations.

Suggested notations like aaa.bbb() for a repeating pattern  could
be indeed used to deal with REPL problem.
Or we could emulate some limited precision decimals (preferably with
floating point).
But it's hard to address all the issues above together.

For simple geometry problems we soon need Algebraic numbers, and then
transcendental, so the usefulness of unlimited fraction is limited anyway.
In practice, we rapidly need approximations, that's where highly optimized
and carfully thought  floating point shine...
Personnally, if Pharo want to go down that road, I would at least keep a
literal notation for floating point, given the universality and interest of
such numbers.

Le dim. 23 sept. 2018 à 16:31, Davide Grandi  a
écrit :

> > *rational number*
> CORRECT, for any BASE and any string :
> > at worst, repeating decimals (eg [TYPO -->0,1<--] 0.1 in base 3 = 1/3 ~
> 0.333...), that are ultimately fractions.
>
> but for 10, 2 and 5 bases and combinations thereof (Z = 2r, 5r, 10r, 20r,
> ...), any string ZrXXX.YYY will lead to a decimal number with finite and
> precise number of digits.
>
> ... or, maybe, I'm wrong and insisting on wrong premises and conclusions
> in front of all the public...
>
> Davide Grandi
>
> On 19/09/2018 22:54, Julien wrote:
>
> Hello,
>
> Ok, I read all the mails. I see your point about not cancelling the
> possibility to use #to:by: on any Number.
>
> However, the remark from David Grandi seems really relevant to me.
>
> You can NOT write anything else than a *rational number* when writing a
> literal using the XXX.XXX pattern.
>
> I think it would be legit to generate scaled decimal by default from float
> literals and to be able to get Float only by either explicitly specify it
> (#asFloat, etc…) or because of computation that lead to a Float (e.g. the
> need to approach an irrational number ?).
>
> I would be curious to see the impact of such change in the compiler on the
> system.
>
> Maybe a first step is indeed to implement a rule in Renraku to encourage
> people to use ScaledDecimals.
>
> Cheers,
>
> Julien
>
> ---
> Julien Delplanque
> Doctorant à l’Université de Lille
> http://juliendelplanque.be/phd.html
> Equipe Rmod, Inria
> Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
> Numéro de téléphone: +333 59 35 86 40
>
> Le 19 sept. 2018 à 09:22, Davide Grandi  a
> écrit :
>
> > 0.0 to: 1.0 by: 0.1
> Receiver and arguments, lexically (the dot), are float BUT
> are written as decimal number (zero, one, one tenth).
>
> I think that in a text you can ONLY write "decimal" numbers or (in bases
> other than 10 [or with factors other than 2^x and 5 ?]), at worst,
> repeating decimals
> (eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions.
>
> So, may be, if the receiver or an argument is a float the compiler may
> issue a warning and compile to non-float, if receiver or arguments are
> computed ... there should be a default behaviour.
>
> Best regards,
>
> Davide Grandi
> (PS : I work mainly in an ERP that has only integers ... and doubles)
>
> On 18/09/2018 11:52, Guillaume Larcheveque wrote:
>
> Maybe #to:by: should convert its parameters in Fraction to avoid Floats
> problems (not sure, just an idea)
>
> 2018-09-18 11:25 GMT+02:00 Esteban Lorenzano :
>
>> On 18 Sep 2018, at 11:13, Guillermo Polito 
>> wrote:
>>
>> On Tue, Sep 18, 2018 at 11:06 AM Julien 
>> wrote:
>>
>>> Hello,
>>>
>>> I realised that it is possible to create an interval of floats.
>>>
>>> I think this is bad because, since intervals are computed by
>>> successively adding a number, it might result in precision errors.
>>>
>>> (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 0.30004 0.4
>>> 0.5 0.6001 0.7001 0.8 0.9 1.0)
>>>
>>> The correct (precise) way to do it would be to use ScaledDecimal:
>>>
>>> (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 0.3s1 0.4s1
>>> 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1)
>>>
>>> I opened an issue about it:
>>> https://pharo.fo

Re: [Pharo-dev] [rmod] Float should not implement #to:, #to:by:, etc...

[Davide Grandi]

> *rational number*
CORRECT, for any BASE and any string :
> at worst, repeating decimals (eg [TYPO -->0,1<--] 0.1 in base 3 = 1/3 
~ 0.333...), that are ultimately fractions.


but for 10, 2 and 5 bases and combinations thereof (Z = 2r, 5r, 10r, 
20r, ...), any string ZrXXX.YYY will lead to a decimal number with 
finite and precise number of digits.


... or, maybe, I'm wrong and insisting on wrong premises and conclusions 
in front of all the public...


    Davide Grandi

On 19/09/2018 22:54, Julien wrote:

Hello,

Ok, I read all the mails. I see your point about not cancelling the 
possibility to use #to:by: on any Number.


However, the remark from David Grandi seems really relevant to me.

You can NOT write anything else than a *rational number* when writing 
a literal using the XXX.XXX pattern.


I think it would be legit to generate scaled decimal by default from 
float literals and to be able to get Float only by either explicitly 
specify it (#asFloat, etc…) or because of computation that lead to a 
Float (e.g. the need to approach an irrational number ?).


I would be curious to see the impact of such change in the compiler on 
the system.


Maybe a first step is indeed to implement a rule in Renraku to 
encourage people to use ScaledDecimals.


Cheers,

Julien

---
Julien Delplanque
Doctorant à l’Université de Lille
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

Le 19 sept. 2018 à 09:22, Davide Grandi > a écrit :


> 0.0 to: 1.0 by: 0.1
Receiver and arguments, lexically (the dot), are float BUT
are written as decimal number (zero, one, one tenth).

I think that in a text you can ONLY write "decimal" numbers or (in 
bases other than 10 [or with factors other than 2^x and 5 ?]), at 
worst, repeating decimals

(eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions.

So, may be, if the receiver or an argument is a float the compiler 
may issue a warning and compile to non-float, if receiver or 
arguments are computed ... there should be a default behaviour.


Best regards,

    Davide Grandi
(PS : I work mainly in an ERP that has only integers ... and doubles)

On 18/09/2018 11:52, Guillaume Larcheveque wrote:
Maybe #to:by: should convert its parameters in Fraction to avoid 
Floats problems (not sure, just an idea)


2018-09-18 11:25 GMT+02:00 Esteban Lorenzano >:



On 18 Sep 2018, at 11:13, Guillermo Polito
mailto:guillermopol...@gmail.com>>
wrote:

On Tue, Sep 18, 2018 at 11:06 AM Julien
mailto:julien.delplan...@inria.fr>> wrote:

Hello,

I realised that it is possible to create an interval of floats.

I think this is bad because, since intervals are computed
by successively adding a number, it might result in
precision errors.

(0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2
0.30004 0.4 0.5 0.6001
0.7001 0.8 0.9 1.0)

The correct (precise) way to do it would be to use
ScaledDecimal:

(0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1
0.3s1 0.4s1 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1)

I opened an issue about it:

https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by-etc



And I’d like to discuss this with you.

What do you think?


Well, I think it's a matter of balance :)

#to:by: is defined in Number. So we could, for example, cancel
it in Float.
However, people would still be able to do

1 to: 1.0 by: 0.1

Which would still show problems.

Nevertheless, I have seen this a lot of times.

0.0 to: 1.0 by: 0.1

Is a common use case.


And moreover, we could try to do

1 to: 7 by: (Margin fromNumber: 1)

And even worse

1 to: Object new by: (Margin fromNumber: 1)

I think adding type-validations all over the place is not a
good solution, and is kind of opposite to our philosophy...

So we should
 - document the good usages
 - document the bad ones
 - and live with the fact that we have a relaxed type system
that will fail at runtime :)

yup.
But not cancel.

Esteban


Guille


--
*Guillaume Larcheveque*



--
Ing. Davide Grandi
email  : davide.gra...@mclink.it
mobile : +39 339 7468 778