- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage

by Alistair Grant

Hi Petr, On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> 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

Sept. 23, 2018

iceberg PrimitiveFailed allocateExecutablePage

by Petr Fischer

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

Sept. 23, 2018

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

by Petr Fischer

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… Thanks! pf

Sept. 23, 2018

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

by 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(cccc) for a repeating pattern cccc 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 <grndvd63m06f704u(a)gmail.com> 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 <grndvd63m06f704u(a)gmail.com> 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 <estebanlm(a)gmail.com>: > >> On 18 Sep 2018, at 11:13, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> On Tue, Sep 18, 2018 at 11:06 AM Julien <julien.delplanque(a)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.30000000000000004 0.4 >>> 0.5 0.6000000000000001 0.7000000000000001 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… >>> >>> 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.grandi(a)mclink.it > mobile : +39 339 7468 778 > >

Sept. 23, 2018

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

by 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 <grndvd63m06f704u(a)gmail.com >> <mailto:grndvd63m06f704u@gmail.com>> 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 <estebanlm(a)gmail.com >>> <mailto:estebanlm@gmail.com>>: >>> >>>> On 18 Sep 2018, at 11:13, Guillermo Polito >>>> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> >>>> wrote: >>>> >>>> On Tue, Sep 18, 2018 at 11:06 AM Julien >>>> <julien.delplanque(a)inria.fr >>>> <mailto:julien.delplanque@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.30000000000000004 0.4 0.5 0.6000000000000001 >>>> 0.7000000000000001 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… >>>> <https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by…> >>>> >>>> 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.grandi(a)mclink.it mobile : +39 339 7468 778

Sept. 23, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban Maringolo

I understand, I'm a heavy user of P2P for most of what's possible, even have a , but HTTP CDNs exists for a reason, which is "distributed availability" and low latency. If we add a bitorrent client as a requirement to have reasonable download speed then you're adding one extra step to the whole onboarding experience. Maybe instead of using a CDNs we can think of using mirrors, but then if the mirror can't withstand the load, you end up in the same situation. Regards, Esteban A. Maringolo El sÃ¡b., 22 sept. 2018 a las 2:25, ponyatov (<dponyatov(a)gmail.com>) escribiÃ³: > I say not about size but *distributed availability*. > > Community members can hold many torrent peers let anybody download > minimizing problems with networks, servers etc, see the topic title. > > PS: maybe in 2048 people will have distributed Smalltalk, but not in this > life with the image hell > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Sept. 22, 2018

[Pharo 7.0-dev] Build #1261: Bug fix for bindings to inherited pool dictionaries (issue 22470)

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1261 was: FAILURE. The Pull Request #1816 was integrated: "Bug fix for bindings to inherited pool dictionaries (issue 22470)" Pull request url: https://github.com/pharo-project/pharo/pull/1816 Issue Url: https://pharo.fogbugz.com/f/cases/22470 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 22, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by ponyatov

I say not about size but *distributed availability*. Community members can hold many torrent peers let anybody download minimizing problems with networks, servers etc, see the topic title. PS: maybe in 2048 people will have distributed Smalltalk, but not in this life with the image hell -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 22, 2018

[Pharo 7.0-dev] Build #1260: 22432 New Release test: NoUnusedTemporaryVariablesLeftTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1260 was: FAILURE. The Pull Request #1782 was integrated: "22432 New Release test: NoUnusedTemporaryVariablesLeftTest" Pull request url: https://github.com/pharo-project/pharo/pull/1782 Issue Url: https://pharo.fogbugz.com/f/cases/22432 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 21, 2018

Re: [Pharo-dev] Mailing list Archive - Bandwidth Limit Exceeded

by Marcus Denker

Fixed. > On 21 Sep 2018, at 09:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I will check with support. > >> On 21 Sep 2018, at 09:49, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Hi Marcus, >> >> I receive a "Bandwidth Limit Exceeded - The server is temporarily unable to service your request due to the site owner reaching >> his/her bandwidth limit. Please try again later." message on http://lists.pharo.org >> >> If I remember correctly we already had this one or two years ago. >> >> Thanks >> T. >

Sept. 21, 2018