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

[Pharo 7.0-dev] Build #1257: 22469-Small-cleanup-in-NEC-Model-classes

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

There is a new Pharo build available! The status of the build #1257 was: FAILURE. The Pull Request #1815 was integrated: "22469-Small-cleanup-in-NEC-Model-classes" Pull request url: https://github.com/pharo-project/pharo/pull/1815 Issue Url: https://pharo.fogbugz.com/f/cases/22469 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2018

[Pharo 7.0-dev] Build #1256: 22448 Cleanup ManifestSystemModel and related package

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

There is a new Pharo build available! The status of the build #1256 was: FAILURE. The Pull Request #1796 was integrated: "22448 Cleanup ManifestSystemModel and related package" Pull request url: https://github.com/pharo-project/pharo/pull/1796 Issue Url: https://pharo.fogbugz.com/f/cases/22448 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2018

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

by Julien

Sept. 19, 2018

Re: [Pharo-dev] Platform file encoding for FFI

by Guillermo Polito

On Tue, Sep 18, 2018 at 4:40 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > > I haven't looked at using FFI much, however it is easy to imagine > that > > different file encoding rules on different platforms will make > writing > > FFI calls more difficult, > > > > Well not really (from my point of view :)) > > From the point of view of the FFI call an encoded string is just a bunch > of > > bytes. FFI does not do any interpretation of them. > > Right, but getting the appropriately encoded bunch of bytes is the issue. > :-) > > Yes, the thing is that this would require some new extensions in uFFI to support encodings. The good point of that is that that would have a positive impact in ***ALL** FFI bindings using strings (by making explicit to people that they should care about encodings :)). > > Maybe... Are the OSX routines exposed as C functions (that we can call > through > > FFI) or they are objective-C methods/functions (that are more > complicated to > > map)? > > The OSX routines are exposed as C functions (and available as > Objective-C methods), see convertChars() in > platforms/unix/vm/sqUnixCharConv.c. > Nice! On Tue, Sep 18, 2018 at 11:21:41AM +0200, Esteban Lorenzano wrote: > > > self > > > ffiCall: #(bool saveContentsToFile(String fileName, String > contents)) > > > options: #(+stringEncodings( fileName return , platformAPI contents) > > > > This is cool. > > What I do not like is to rely on primitives to do that encoding. > > This should be in image??? using FFI if needed (this is all because we > > want to rely less and less on plugins :P) > > I realise of course that this could all be done in FFI, and I agree with > all Estaban's arguments in favour of FFI, my main motivation was that > the code is already in the VM, and to avoid code duplication with the > obvious benefit that if a bug is fixed it will apply everywhere. Yeh. At the end it's a matter of debugging cycles. Imagine making the "compile-restart" steps that you're facing while changing the plugin almost negligible in the "change-compile-restart-test" loop :).

Sept. 19, 2018

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

by Davide Grandi

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

Sept. 19, 2018

[Pharo 7.0-dev] Build #1255: 20111-Some-Collection-tests-fail-on-64-bit-because-they-assume-Floats-are-non-immediate

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

There is a new Pharo build available! The status of the build #1255 was: SUCCESS. The Pull Request #1624 was integrated: "20111-Some-Collection-tests-fail-on-64-bit-because-they-assume-Floats-are-non-immediate" Pull request url: https://github.com/pharo-project/pharo/pull/1624 Issue Url: https://pharo.fogbugz.com/f/cases/20111 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2018

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