- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban Maringolo

After sending the previous email I checked the progress and it was aborted due to a network error. [image: pharo-cancelled.PNG] I retried and apparently the speed got to a more reasonable one, with peaks of 300KB/sec. [image: 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>) 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. > > [image: 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: image.png] >

Sept. 19, 2018

Pharo Downloads are sluggish

by Esteban Maringolo

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. [image: 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: image.png]

Sept. 19, 2018

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

by Nicolas Cellier

Le mar. 18 sept. 2018 Ã 22:40, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > > > Le mar. 18 sept. 2018 Ã 11:53, Guillaume Larcheveque < > guillaume.larcheveque(a)gmail.com> a Ã©crit : > >> Maybe #to:by: should convert its parameters in Fraction to avoid Floats >> problems (not sure, just an idea) >> >> > Hi Guillaume, > Yes possibly... > But if the author explicitely requested a loop on Float, why not honour > the request, as bad as it can be? > If the answer is, well, it could be legitimate in some cases, but we just > don't know how to recognize theses legitimate cases, then it's better to > not alter the resquest at all, and let the author deal with the > responsibility (and all the possible consequences). > > You could argue for an intermediate solution: > maybe we could perform the increment arithmetic with Fraction but convert > back asFloat just before evaluating the block ... > But in this case, (0 to: 1 by: 0.1 asFraction) collect: #asFloat would be > probably more surprising than (0 to: 1 by: 0.1 ) asArray w.r.t. naive > expectations: > #(0.0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6000000000000001 > 0.7000000000000001 0.8 0.9) > #(0.0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6000000000000001 > 0.7000000000000001 0.8 0.9 1.0) > > And I forgot also the inlined or not inlined, to:by:do: which currently agree with each other (but not with Interval do:) Array new: 11 streamContents: [:s | 0 to: 1 by: 0.1 do: [:e|s nextPut: e]]. Array new: 11 streamContents: [:s | 0 to: 1 by: 0.1 do: [:e|s nextPut: e] yourself]. #(0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6 0.7 0.7999999999999999 0.8999999999999999 0.9999999999999999) We could try to workaround by converting start/step > asMinialDecimalFraction, just as a wild guess of author's intentions... > But then again, if we are not sure of the intentions, it's better to not > alter the request at all. > > We have Renraku in Pharo, so we could use Renraku for trivial cases (usage > of literal Float as start/step). > And with Instruction Reified capability of Pharo Compiler, we could even > instrument some code and implement runtime checks when the static analysis > cannot infer the types like the cases submitted by Guillermo, if it really > matters. > It would be very much like the undefined behavior runtime checks of clang > for example, and a nice subject for an advanced student. > > 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* >> >>

Sept. 18, 2018

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

by Nicolas Cellier

Le mar. 18 sept. 2018 Ã 11:53, Guillaume Larcheveque < guillaume.larcheveque(a)gmail.com> a Ã©crit : > Maybe #to:by: should convert its parameters in Fraction to avoid Floats > problems (not sure, just an idea) > > Hi Guillaume, Yes possibly... But if the author explicitely requested a loop on Float, why not honour the request, as bad as it can be? If the answer is, well, it could be legitimate in some cases, but we just don't know how to recognize theses legitimate cases, then it's better to not alter the resquest at all, and let the author deal with the responsibility (and all the possible consequences). You could argue for an intermediate solution: maybe we could perform the increment arithmetic with Fraction but convert back asFloat just before evaluating the block ... But in this case, (0 to: 1 by: 0.1 asFraction) collect: #asFloat would be probably more surprising than (0 to: 1 by: 0.1 ) asArray w.r.t. naive expectations: #(0.0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6000000000000001 0.7000000000000001 0.8 0.9) #(0.0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6000000000000001 0.7000000000000001 0.8 0.9 1.0) We could try to workaround by converting start/step asMinialDecimalFraction, just as a wild guess of author's intentions... But then again, if we are not sure of the intentions, it's better to not alter the request at all. We have Renraku in Pharo, so we could use Renraku for trivial cases (usage of literal Float as start/step). And with Instruction Reified capability of Pharo Compiler, we could even instrument some code and implement runtime checks when the static analysis cannot infer the types like the cases submitted by Guillermo, if it really matters. It would be very much like the undefined behavior runtime checks of clang for example, and a nice subject for an advanced student. 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* > >

Sept. 18, 2018

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

by Nicolas Cellier

Hi Julien, You are right, Float intervals are not to be encouraged! But if a knowledgeable person wants to use it, why forbid it? Why not forbid Float alltogether then? In the same vein, I saw C compiler warning me about using Float = (== in C). Great! Now I cannot use -Wall -Werror, though I perfectly know where I can use == and where I cannot... I understand the intentions, but in french, don't we say that hell is paved with good intentions? Warning about = and not warning about < <= > >= != is kind of stupid common knowledge not very well assimilated... Like telling me that I should use a tolerance (a-b) abs < eps, as kind of miraculous workaround. Err... The problem is now to choose eps and deal with false positive/negative, and bad news, there's no such thing as a universal eps. So in this spirit, I would restrain from forbiding anything. Rather, you could add a rule checking for that construct for the purpose of educating. And please, if activating the rule on some continuous integration Cerberus bot, then provide a way to explicitely bypass it in exceptional conditions! Last thing, Interval enumeration is not performed via cumulative additions start + step + step + step + .... But rather with a multiplication which performs well better wrt loss of accuracy: start + (index - 1 * step) See Interval>>do: since http://bugs.squeak.org/view.php?id=6456 Unfortunately, #to:do: #to:by:do: and their inlined versions do not follow this pattern, but use cumulative additions (at least in Squeak, to be confirmed in Pharo...) If I would change something, that would be that. Remember, "You can cheat as long as you don't get caught", I think I caught the inliner with this snippet: | eps count | eps := 1.0 timesTwoPower: -52. count := 0. 1 + eps to: 2 do: [:x | count := count + 1]. (1 + eps to: 2) do: [:x | count := count - 1]. ^count = 0 Beware, most loops are for Integer and should not be de-optimized too much (cheating can be a tough problem)... Le mar. 18 sept. 2018 Ã 17:18, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > > On Sep 18, 2018, at 2:52 AM, Guillaume Larcheveque < > guillaume.larcheveque(a)gmail.com> wrote: > > Maybe #to:by: should convert its parameters in Fraction to avoid Floats > problems (not sure, just an idea) > > > There is no need to convert. One can simply write > > 0 to: 1 by: 1/10 > > The issue with 0 to: 1 by: 0.1 is a problem with floating point > arithmetic, not with intervals, and one does not cure disease by putting > band aids on symptoms. Instead we should teach the pitfalls of floating > point arithmetic representations so that people are not astonished by > 1/10.0*10. Avoid simplifying language. Teach literacy. > > > 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* > >

Sept. 18, 2018

Roassal2 crashing when drawing TRLabelShape

by Oleksandr Zaytsev

Hello, Roassal2 has recently been crashing on my image on every example that includes text. Peter Uhnak helped me discover that it crashes when drawing a TRLabelShape and maybe Cairo doesn't like the new FT plugin. Some experiments: 1. Inspecting an empty view (RTView new inspect) doesn't crash. 2. Everything works well on Pharo 7. My image and crash.dmp can be found in this folder: https://drive.google.com/drive/folders/1lypWVL6VwYfHCqRuXZfnAcA4qZGulDal?us… Oleks

Sept. 18, 2018

Re: [Pharo-dev] [squeak-dev] _: in selectors

by Eliot Miranda

On Tue, Sep 18, 2018 at 10:38 AM Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > Hi Eliot, > > That's clearly a bug as the compiler accepts this: > > method: p __: q __: r > ^'cool' > ROTFL > > Levente > > On Tue, 18 Sep 2018, Eliot Miranda wrote: > > > Hi All, > > Pharo accepts > > > > method: p _: q _: r > > ^'cool' > > > > Squeak does not. I have an urgent compelling use case in VMMaker. > Would there be any strong objections to me modifying the Squeak compiler to > accept the above when the allowUnderscoresInSelectors > > preference is in effect? > > _,,,^..^,,,_ > > best, Eliot > > > > > -- _,,,^..^,,,_ best, Eliot

Sept. 18, 2018

_: in selectors

by Eliot Miranda

Hi All, Pharo accepts method: p _: q _: r ^'cool' Squeak does not. I have an urgent compelling use case in VMMaker. Would there be any strong objections to me modifying the Squeak compiler to accept the above when the allowUnderscoresInSelectors preference is in effect? _,,,^..^,,,_ best, Eliot

Sept. 18, 2018

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

by Eliot Miranda

> On Sep 18, 2018, at 2:52 AM, Guillaume Larcheveque <guillaume.larcheveque(a)gmail.com> wrote: > > Maybe #to:by: should convert its parameters in Fraction to avoid Floats problems (not sure, just an idea) There is no need to convert. One can simply write 0 to: 1 by: 1/10 The issue with 0 to: 1 by: 0.1 is a problem with floating point arithmetic, not with intervals, and one does not cure disease by putting band aids on symptoms. Instead we should teach the pitfalls of floating point arithmetic representations so that people are not astonished by 1/10.0*10. Avoid simplifying language. Teach literacy. > > 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 >

Sept. 18, 2018

Re: [Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format

by Sven Van Caekenberghe

Hi Julien, Good and interesting point. Your summary is correct: STON, inheriting from JSON so to speak, only knowns about integer and float numbers. All other Smalltalk numbers get converted, which results in a loss of type and precision. That might not be a perfect situation, but nobody complained so far. If we would change it, efficiency has to be taken into account: speed/memory efficiency as well as human typing efficiency/complexity. Compatibility, especially between different Smalltalk and other object languages, is also an aspect. Apart from the current approach, the full STON approach could be, for example for 1/3 and 1.5s2 Fraction { #numerator:1, #denominator:3 } ScaledDecimal { #numerator:3, #denominator:2, #scale:2} For some types, STON uses shorter notations, either using positional arguments Point [ 1, 2 ] Fraction [ 1, 3 ] ScaledFraction [ 3, 2, 2 ] Or a string argument, when there is a clear external representation DateAndTime [ '2018-09-18T16:39:10.325129+02:00' ] Fraction [ '1/3' ] ScaledFraction [ '3/2s2' ] Of course, we could also extend the basic number parser and allow the native (stored) notation 1/3 3/2s2 Note how that last one should use the more exact #storeOn: notation, not the #printOn: I'll have to think about this a bit more, as I can really not choose right now. Sven > On 18 Sep 2018, at 10:34, Julien <julien.delplanque(a)inria.fr> wrote: > > Hello, > > I realised that in the current implementation, when a number is serialised by STON it is either as an integer literal or as a float literal. > > There is a risk to loose precision, especially if what you serialise is a ScaledDecimal or a fraction. > > I propose a simple change to fix this: > > 1. Add STONWriter>>#isInJsonMode method which returns true if the STONWriter wants to write JSON > > 2. Add: > > Fraction>>#stonOn: stonWriter > stonWriter isInJsonMode > ifTrue: [ ^ super stonOn: stonWriter ]. > > stonWriter writeObject: self streamMap: [ :dictionary | > dictionary at: #numerator put: numerator. > dictionary at: #denominator put: denominator ] > > 3. Add: > > ScaledDecimal>>#stonOn: stonWriter > stonWriter isInJsonMode > ifTrue: [ ^ super stonOn: stonWriter ]. > > stonWriter writeObject: self streamMap: [ :dictionary | > dictionary at: #numerator put: numerator. > dictionary at: #denominator put: denominator. > dictionary at: #scale put: scale ] > > > This change has a main drawback, storing fractions and scaled decimal will result in a huge overhead. > > Maybe for ScaledDecimal we can use Pharoâs literal (e.g. 1.12s2). > > For fractions I donât know what literal could be used? > > Or maybe the overhead is fine? > > 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 >

Sept. 18, 2018