September 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo Downloads are sluggish

by Marcus Denker

Hello, We are switching the hosting contract to a more professional one. This should be active soon. This includes a CDN, but it will be active only after we make sure that the files get invalidated when the CI uploads them, so this will be in a week or so. It should improve things even without the CDN active, though. Marcus > On 19 Sep 2018, at 15:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I will have a look how to improve the situation. > > (I hope to be able to do it by next week). > > Marcus > >> On 19 Sep 2018, at 02:10, Esteban Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> >> After sending the previous email I checked the progress and it was aborted due to a network error. >> >> <pharo-cancelled.PNG> >> >> I retried and apparently the speed got to a more reasonable one, with peaks of 300KB/sec. >> >> <pharo-retry.png> >> >> >> My guess is that the bottleneck is at where the files are hosted, and if you attempt to download while maybe there are several CI builds running or something else is using the fileserver bandwidth, then it impacts the overall download speed of those attempting to download just the basic elements. >> >> Regards! >> >> Esteban A. Maringolo >> >> >> El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo (<emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>>) escribiÃ³: >> Is there a reason why the latest version of the builds linked from the website are not hosted in some CDN, Amazon S3 or similar? >> >> Maybe in Europe the speed is fast, but where I am (Argentina) it is really slow, the screenshot shows 3.5KB/s, it averages 10KB/s, with peaks of 40KB/s. >> >> This is an pitiful boarding experience, that will make many cancel it even before getting to open the downloaded launcher. >> >> <node-pharo.png> >> >> The screenshot shows that is not a problem with my home connection, which isn't the fastest but is "normal" for my use cases. >> >> Regards, >> >> Esteban A. Maringolo >> >> ps: When I finished writing this email, this was the progress... >> <image.png> >

Sept. 24, 2018

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

by Esteban Lorenzano

> On 24 Sep 2018, at 09:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Esteban, > >> On 24 Sep 2018, at 08:00, estebanlm(a)gmail.com wrote: >> >> * 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. > > If it was hard for you, how are we supposed to do it ? > Is there a guide/description somewhere ? For what? Migration? There is an option on iceberg (repository/extrasâ¦) that does that and it will work 99% of the cases (there is a known bug with a fix waiting on the iceberg repo who prevents seaside migration). This will migrate without history. Or better: history will be there, just in filetree but since there is no match between one format and another and that will give problems to see the history. The problem here was that I needed to migrate all pharo-ide repositories, and update baselines and make all tests pass and in the middle I exceeding travis ârightâ to see tags (if you are not authenticated, it can happen), etc. So a lot of small problems not directly related with the migration itself :) Esteban > > Sven

Sept. 24, 2018

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

by Sven Van Caekenberghe

Esteban, > On 24 Sep 2018, at 08:00, estebanlm(a)gmail.com wrote: > > * 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. If it was hard for you, how are we supposed to do it ? Is there a guide/description somewhere ? Sven

Sept. 24, 2018

Esteban's ChangeLog week of 17 September 2018

by estebanlm＠gmail.com

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

Sept. 24, 2018

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

by Petr Fischer

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

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