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

Debugger should step silently over #halt

by Ben Coman

I'll often put several breakpoints in code like this... ``` debug := true. "Somewhere else in application code..." debug ifTrue: [ self halt ]. 1 + 1. "Representing some longer bit of application code" debug ifTrue: [ self halt ]. 2 + 2. "Representing some longer bit of application code" debug ifTrue: [ self halt ]. 3 + 3. "Representing some longer bit of application code" ``` While stepping <Over> code after hitting the first halt, I am used to subsequent halts being silently stepped over. I just confirmed this with http://files.pharo.org/platform/Pharo6.0-win.zip and also build 60541 started from PharoLauncher. However build 71231 and build 60542 do not silently step over a #halt. Each produces slightly different results (pics attached). [image: P01-Double-Halt-Pharo7.png] [image: P02-Double-Halt-Pharo60542.png] I've logged an issue... https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-… cheers -ben

Sept. 20, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban A. Maringolo

On 20/09/2018 02:11, ponyatov wrote: > Just add Torrent as download variant Torrent for a 50mb/file is overkill today. And adds a new requirement to get started. A Torrent based Pharo launcher is a different story :) Regards, -- Esteban A. Maringolo

Sept. 20, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by ponyatov

Just add Torrent as download variant -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 20, 2018

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

by Julien

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

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

by Eliot Miranda

Hi Henry, On Tue, Sep 18, 2018 at 1:43 AM Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Guillermo Polito wrote > > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant < > > > akgrant0710@ > > > > > > wrote: > > > >> Hi Esteban, Guille and Everyone, > >> > >> 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. > > It *would* be pretty handy for adding some auto-conversion into the > marshaller based on parameter encoding options though... (other than > filename, could be done in smalltalk using exisiting encoders) > > self > ffiCall: #(bool saveContentsToFile(String fileName, String contents)) > options: #(+stringEncodings( fileName return , platformAPI contents) > > (And yes, I've probably badly mangled the options syntax) > Why not go for some generic escape sequence that can inject Smalltalk code into the marshaling? Right now e.g. primExport: aName value: aValue ^ self ffiCall: #(void moz_preferences_set_bool (short* aName, bool aValue)) is compiled as primExport: arg1 value: arg2 | tmp1 tmp2 | '<an unprintable nonliteral value>' invokeWithArguments: {(tmp2 := arg1 packToArity: 1). arg2} where '<an unprintable nonliteral value>' is the ExternalFunction object (it could usefully print itself ass a literal and then decompilation would be meaningful; there is already code in the Squeak FFI repository). Let's say one added {}'s as characters that can't ever appear in C parameter lists (of course and alas []'s can because of arrays)â¥ Then you could perhaps write primExport: aName value: aValue ^ self ffiCall: #(void moz_preferences_set_bool ( { short* aName } asUTF8String, bool aValue)) and have that generate a send of asUTF8String to arg1 or tmp2. One could surround the whole thing to apply a coercion to the return value, but there's no need because one can write e.g. primExport: aName value: aValue ^(self ffiCall: #(void moz_preferences_set_bool ( { short* aName } asUTF8String, bool aValue))) fromUTF8String So then there would be a generic mechanism for in jetting Smalltalk code into the marshaling and one could develop the string encoding support independently from the FFI. The options syntax however requires parsing support, more documentation, and constant extension to support new facilities, etc. Is much less verbose than having to manually convert Strings to the proper > platform Unicode encodings before calling. > Depends a bit on whether the primitive argument is > Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and one > has > to convert first anyways. > > It's not like this isn't a pain point, there are plenty of currently used > API's that are broken if you try to use non-ascii. > > Cheers, > Henry > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- _,,,^..^,,,_ best, Eliot

Sept. 19, 2018

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

by Alistair Grant

On Wed, 19 Sep 2018 at 10:26, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > On Tue, Sep 18, 2018 at 4:40 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> 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 :). This is true if the code only resides in the image, but in this case the code won't be going away from the VM any time soon. Anyway, for whoever does implement the code for FFI the option is always there. Thanks to everyone for their replies! Cheers, Alistair

Sept. 19, 2018

[Pharo 7.0-dev] Build #1259: 21660-Changing-the-superclass-of-a-Class-using-superclass-method-does-not-update-instSize-correctly

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

There is a new Pharo build available! The status of the build #1259 was: FAILURE. The Pull Request #1618 was integrated: "21660-Changing-the-superclass-of-a-Class-using-superclass-method-does-not-update-instSize-correctly" Pull request url: https://github.com/pharo-project/pharo/pull/1618 Issue Url: https://pharo.fogbugz.com/f/cases/21660 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2018

[Pharo 7.0-dev] Build #1258: 22457-Provide-a-CalendarPresenter-fully-written-in-Spec

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

There is a new Pharo build available! The status of the build #1258 was: SUCCESS. The Pull Request #1804 was integrated: "22457-Provide-a-CalendarPresenter-fully-written-in-Spec" Pull request url: https://github.com/pharo-project/pharo/pull/1804 Issue Url: https://pharo.fogbugz.com/f/cases/22457 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 A. Maringolo

Hi Marcus, Thank you. Anybody WILLING to use it will wait whatever it takes, but my concern, and rant, is about these that want to give it a try and will abort it even before running it. I'm happily using Pharo in Windows preparing it for a demo I'll be making. Regards! On 19/09/2018 10:06, Marcus Denker 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> >> > -- Esteban A. Maringolo

Sept. 19, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Marcus Denker

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> 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. 19, 2018

[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

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

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

by Alistair Grant

Hi Guille, Esteban and Henry, Thanks for your replies. On Tue, Sep 18, 2018 at 10:09:02AM +0200, Guillermo Polito wrote: > > > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, Guille and Everyone, > > 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. :-) > i.e. some of the different formats are: > > - OSX uses Mac specific decomposed UTF8 encoding > - Windows uses Wide Strings (16 bit Unicode characters) > - Linux allows pretty much anything, but precomposed UTF8 is common > > > > At the image side, we could have an strategy that, depending on the OS, could > encode in one encoding or another, or even not encode at all. > > > Believe it or not, I'm still working on getting the > FileAttributesPlugin working (file name encoding on Windows being the > latest issue - the tests in Pharo need to be extended). > > > I believe you, don't worry ^^. > > > Would it be useful for future FFI work to have primitives available > which convert file names to and from the various platform specific > formats? (Linux is basically a no-op, and Windows could be written > in-image, but OSX requires the platform routines to be called). > > > 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. 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. On Tue, Sep 18, 2018 at 11:23:56AM +0200, Esteban Lorenzano wrote: > > > On 18 Sep 2018, at 11:04, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > On Tue, Sep 18, 2018 at 10:43 AM Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > > It *would* be pretty handy for adding some auto-conversion into the > marshaller based on parameter encoding options though... (other than > filename, could be done in smalltalk using exisiting encoders) > > self > ffiCall: #(bool saveContentsToFile(String fileName, String > contents)) > options: #(+stringEncodings( fileName return , platformAPI > contents) > > > Well, I like this idea. > > > (And yes, I've probably badly mangled the options syntax) > > Is much less verbose than having to manually convert Strings to the > proper > platform Unicode encodings before calling. > Depends a bit on whether the primitive argument is > Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and > one has > to convert first anyways. > > It's not like this isn't a pain point, there are plenty of currently > used > API's that are broken if you try to use non-ascii. > > > Yes, but I think this may be because in general people tend to not know how > encodings work... (even myself I don't feel I know enough :)) > But this makes me think that we should make encoding explicit? > > > Yup, explicit please. Nothing hide behind the carpet :) > > > > Maybe we should force people to specify an encoding if they specify a > callout using a string. > > And then, either they specify it at the level of the callout, or at the > level of the library (like setting a default encoding for all strings). > > > > You can have some global FFI settings (I was thinking on adding some global > options settings for FFI in general, btw) and even ?library based settings?, to > simplify. > > Esteban > > > > Because this raises also the question of what is the default encoding? > And I'd say that in there is no satisfactory default encoding... I'll defer to Sven every time when it comes to character encoding, but my understanding is that the only platform that has consistent encoding rules is OSX, which uses the platform specific decomposed UTF8. Both Windows and Linux use precomposed UTF8, but other character encodings are possible (particularly for older files). So we certainly shouldn't make the encoding hard-coded. UTF8 as the default encoding I think does make sense (this is what FilePlugin currently uses). Cheers, Alistair

Sept. 18, 2018

[Pharo 7.0-dev] Build #1254: 22463 Tag ManifestTextCore and classes in package Text-Core-Manifest

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

There is a new Pharo build available! The status of the build #1254 was: SUCCESS. The Pull Request #1811 was integrated: "22463 Tag ManifestTextCore and classes in package Text-Core-Manifest" Pull request url: https://github.com/pharo-project/pharo/pull/1811 Issue Url: https://pharo.fogbugz.com/f/cases/22463 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 18, 2018

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

by Guillaume Larcheveque

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

Sept. 18, 2018

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

by Esteban Lorenzano

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

Sept. 18, 2018

[Pharo 7.0-dev] Build #1253: 22456 dynamic left to right columns layout generates an additional unneeded row with null presenters

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

There is a new Pharo build available! The status of the build #1253 was: SUCCESS. The Pull Request #1803 was integrated: "22456 dynamic left to right columns layout generates an additional unneeded row with null presenters" Pull request url: https://github.com/pharo-project/pharo/pull/1803 Issue Url: https://pharo.fogbugz.com/f/cases/22456 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 18, 2018

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

by Esteban Lorenzano

> On 18 Sep 2018, at 11:04, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Tue, Sep 18, 2018 at 10:43 AM Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: > Guillermo Polito wrote > > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant < > > > akgrant0710@ > > > > > > wrote: > > > >> Hi Esteban, Guille and Everyone, > >> > >> 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. > > It *would* be pretty handy for adding some auto-conversion into the > marshaller based on parameter encoding options though... (other than > filename, could be done in smalltalk using exisiting encoders) > > self > ffiCall: #(bool saveContentsToFile(String fileName, String contents)) > options: #(+stringEncodings( fileName return , platformAPI contents) > > Well, I like this idea. > > (And yes, I've probably badly mangled the options syntax) > > Is much less verbose than having to manually convert Strings to the proper > platform Unicode encodings before calling. > Depends a bit on whether the primitive argument is > Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and one has > to convert first anyways. > > It's not like this isn't a pain point, there are plenty of currently used > API's that are broken if you try to use non-ascii. > > Yes, but I think this may be because in general people tend to not know how encodings work... (even myself I don't feel I know enough :)) > But this makes me think that we should make encoding explicit? Yup, explicit please. Nothing hide behind the carpet :) > > Maybe we should force people to specify an encoding if they specify a callout using a string. > And then, either they specify it at the level of the callout, or at the level of the library (like setting a default encoding for all strings). You can have some global FFI settings (I was thinking on adding some global options settings for FFI in general, btw) and even âlibrary based settingsâ, to simplify. Esteban > > Because this raises also the question of what is the default encoding? > And I'd say that in there is no satisfactory default encoding...

Sept. 18, 2018

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

by Esteban Lorenzano

> On 18 Sep 2018, at 10:42, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Guillermo Polito wrote >> On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant < > >> akgrant0710@ > >> > >> wrote: >> >>> Hi Esteban, Guille and Everyone, >>> >>> 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. > > It *would* be pretty handy for adding some auto-conversion into the > marshaller based on parameter encoding options though... (other than > filename, could be done in smalltalk using exisiting encoders) > > 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) Esteban > > (And yes, I've probably badly mangled the options syntax) > > Is much less verbose than having to manually convert Strings to the proper > platform Unicode encodings before calling. > Depends a bit on whether the primitive argument is > Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and one has > to convert first anyways. > > It's not like this isn't a pain point, there are plenty of currently used > API's that are broken if you try to use non-ascii. > > Cheers, > Henry > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 18, 2018

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

by Guillermo Polito

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. 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 :) Guille

Sept. 18, 2018

Float should not implement #to:, #to:by:, etc...

by Julien

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

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

by Guillermo Polito

On Tue, Sep 18, 2018 at 10:43 AM Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Guillermo Polito wrote > > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant < > > > akgrant0710@ > > > > > > wrote: > > > >> Hi Esteban, Guille and Everyone, > >> > >> 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. > > It *would* be pretty handy for adding some auto-conversion into the > marshaller based on parameter encoding options though... (other than > filename, could be done in smalltalk using exisiting encoders) > > self > ffiCall: #(bool saveContentsToFile(String fileName, String contents)) > options: #(+stringEncodings( fileName return , platformAPI contents) > Well, I like this idea. (And yes, I've probably badly mangled the options syntax) > > Is much less verbose than having to manually convert Strings to the proper > platform Unicode encodings before calling. > Depends a bit on whether the primitive argument is > Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and one > has > to convert first anyways. > > It's not like this isn't a pain point, there are plenty of currently used > API's that are broken if you try to use non-ascii. > Yes, but I think this may be because in general people tend to not know how encodings work... (even myself I don't feel I know enough :)) But this makes me think that we should make encoding explicit? Maybe we should force people to specify an encoding if they specify a callout using a string. And then, either they specify it at the level of the callout, or at the level of the library (like setting a default encoding for all strings). Because this raises also the question of what is the default encoding? And I'd say that in there is no satisfactory default encoding...

Sept. 18, 2018

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

by Henrik Sperre Johansen

Guillermo Polito wrote > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant < > akgrant0710@ > > > wrote: > > >> Would it be useful for future FFI work to have primitives available >> which convert file names to and from the various platform specific >> formats? (Linux is basically a no-op, and Windows could be written >> in-image, but OSX requires the platform routines to be called). >> > > 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)? > > Thanks Alistair! +1. From the image point of view, the non-standard normal form used on OSX is the biggest issue. If it's available through FFI, the platform-specific String encoding options I mentioned previously could be implemented entirely in the image. If there are extra hoops to jump though, like having to provide utf8 to said FFI function, it might still be worth it for the reduced performance overhead. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 18, 2018

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

by Henrik Sperre Johansen

Guillermo Polito wrote > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant < > akgrant0710@ > > > wrote: > >> Hi Esteban, Guille and Everyone, >> >> 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. It *would* be pretty handy for adding some auto-conversion into the marshaller based on parameter encoding options though... (other than filename, could be done in smalltalk using exisiting encoders) self ffiCall: #(bool saveContentsToFile(String fileName, String contents)) options: #(+stringEncodings( fileName return , platformAPI contents) (And yes, I've probably badly mangled the options syntax) Is much less verbose than having to manually convert Strings to the proper platform Unicode encodings before calling. Depends a bit on whether the primitive argument is Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and one has to convert first anyways. It's not like this isn't a pain point, there are plenty of currently used API's that are broken if you try to use non-ascii. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 18, 2018

Fraction and ScaledDecimal should be not be serialized as Float in STON format

by Julien

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

Re: [Pharo-dev] UndefinedClasses as first class entities for P7

by Guillermo Polito

On Thu, Sep 13, 2018 at 11:07 PM Tim Mackinnon <tim(a)testit.works> wrote: > Kind of related - we did get the ability to save methods with undefined > classes and undeclared variables (vs having to correct this to save). So at > least a nod to that? > Yes, I was following your progress there :) And since you have practical experience with this in excercism, It would be ***really lovely*** if you can check our paper/code and give us some feedback.

Sept. 18, 2018

Re: [Pharo-dev] Confused about FileReference read/write streams

by Guillermo Polito

I've opened an issue https://pharo.fogbugz.com/f/cases/22466/Add-readWriteStream-and-readWriteSt… On Tue, Sep 18, 2018 at 10:14 AM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Sven, > > On Mon, Sep 17, 2018 at 4:14 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi, >> >> Since ever (or as far as I can remember), FileReference made a >> distinction between read and write streams, see #readStream[Do:] and >> #writeStream[Do:] - these return a ZnCharacterReadStream and >> ZnCharacterWriteStream in Pharo 7. >> > > I think so too. > > >> >> Along the same lines, #binaryReadStream and #binaryWriteStream where >> introduced. > > > Well, when I did the stream changes on FileSystem, there was already > support for binary streams. I just exposed it in the API :) > > >> However, the first returns a ZnBufferedReadStream (OK) while the latter >> returns a ZnBufferedReadWriteStream. Why ? >> > > I cannot tell now the details, but there were some parts of the system > where it was assumed that a write-stream is read-write. > IIRC this was related with the changes/sources file handling. > > >> >> I think it would be generally better if a standard ZnBufferedWriteStream >> where returned. >> >> ZnBufferedReadWriteStream is not a very pretty class to say the least, it >> also strikes me as confusing. >> >> What would break if we changed this ? >> >> If necessary there could be something like #readWriteStream[Do:] I guess. >> > > That could be a cleaner way to do this, yes. > And this would isolate strange uses. > > >> >> Sven >> >> >> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 18, 2018

Re: [Pharo-dev] Confused about FileReference read/write streams

by Guillermo Polito

Hi Sven, On Mon, Sep 17, 2018 at 4:14 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Since ever (or as far as I can remember), FileReference made a distinction > between read and write streams, see #readStream[Do:] and #writeStream[Do:] > - these return a ZnCharacterReadStream and ZnCharacterWriteStream in Pharo > 7. > I think so too. > > Along the same lines, #binaryReadStream and #binaryWriteStream where > introduced. Well, when I did the stream changes on FileSystem, there was already support for binary streams. I just exposed it in the API :) > However, the first returns a ZnBufferedReadStream (OK) while the latter > returns a ZnBufferedReadWriteStream. Why ? > I cannot tell now the details, but there were some parts of the system where it was assumed that a write-stream is read-write. IIRC this was related with the changes/sources file handling. > > I think it would be generally better if a standard ZnBufferedWriteStream > where returned. > > ZnBufferedReadWriteStream is not a very pretty class to say the least, it > also strikes me as confusing. > > What would break if we changed this ? > > If necessary there could be something like #readWriteStream[Do:] I guess. > That could be a cleaner way to do this, yes. And this would isolate strange uses. > > Sven > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 18, 2018

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

by Guillermo Polito

On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Esteban, Guille and Everyone, > > 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. > i.e. some of the different formats are: > > - OSX uses Mac specific decomposed UTF8 encoding > - Windows uses Wide Strings (16 bit Unicode characters) > - Linux allows pretty much anything, but precomposed UTF8 is common > > At the image side, we could have an strategy that, depending on the OS, could encode in one encoding or another, or even not encode at all. > Believe it or not, I'm still working on getting the > FileAttributesPlugin working (file name encoding on Windows being the > latest issue - the tests in Pharo need to be extended). > I believe you, don't worry ^^. > Would it be useful for future FFI work to have primitives available > which convert file names to and from the various platform specific > formats? (Linux is basically a no-op, and Windows could be written > in-image, but OSX requires the platform routines to be called). > 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)? Thanks Alistair!

Sept. 18, 2018

Standardized nomenclature for feature requests

by Esteban A. Maringolo

Hi there, Q: Is there a reason why Pharo (as a project) doesn't follow a standardized nomenclature for features/request as other communities does? So for instance something like PFR-005 (Pharo Feature Request) could be "Truly headless images", PFR-006 "Pharo Bootstrapping", etc. I can't really tell whether this would improve to the overall process, but I wanted to know if this was already debated by the board and dismissed, if it is something that wasn't considered at all, of if we have something equivalent and what it is. Regards, Language examples: JSR (Java Specification Requests) https://www.jcp.org/en/jsr/all PEP (Python Enhancement Proposals) https://www.python.org/dev/peps/ RFC (Rust, Request for Comments) https://github.com/rust-lang/rfcs Technologies: BIP (Bitcoin Improvement Proposal) https://github.com/bitcoin/bips EIP (Ethereum Improvement Proposal) https://eips.ethereum.org/ -- Esteban A. Maringolo

Sept. 17, 2018

ZnMimePart Disposition-Content spaces

by Ben Coman

Hi Sven, We encountered a ZnMimePart Content-Disposition header problem with a server expecting a space following the "form-data;" string. The diff here... https://www.diffchecker.com/ETIfCUzx * on the left shows the working request from the default command-line tool * on the right shows the non-working request from Pharo. The specifications are really unclear about the requirement or not for a space, so it may be reasonable to consider the fault lies with the server not being permissive enough, but I notice these examples all have space after semi colons... * https://tools.ietf.org/html/rfc7578 * https://www.ietf.org/rfc/rfc2388.txt so I wonder if this scenario might be widespread (and endemic to Rails apps which this was) and maybe its pragmatic to include the extra spaces to cut off potential issues (it took quite a while to isolate with the live service being HTTPS only.) Steps to reproduce are here... https://github.com/exercism/pharo/issues/96#issuecomment-421224203 In the meantime, once isolated it was simple to work around, but it was almost a show stopper, so I'm interested in your thoughts. cheers -ben

Sept. 17, 2018

Platform file encoding for FFI

by Alistair Grant

Hi Esteban, Guille and Everyone, 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, i.e. some of the different formats are: - OSX uses Mac specific decomposed UTF8 encoding - Windows uses Wide Strings (16 bit Unicode characters) - Linux allows pretty much anything, but precomposed UTF8 is common Believe it or not, I'm still working on getting the FileAttributesPlugin working (file name encoding on Windows being the latest issue - the tests in Pharo need to be extended). Would it be useful for future FFI work to have primitives available which convert file names to and from the various platform specific formats? (Linux is basically a no-op, and Windows could be written in-image, but OSX requires the platform routines to be called). Cheers, Alistair

Sept. 17, 2018

[Pharo 7.0-dev] Build #1252: 22417 Decide about DateAndTimeDosEpochTest>>testToByDo

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

There is a new Pharo build available! The status of the build #1252 was: FAILURE. The Pull Request #1810 was integrated: "22417 Decide about DateAndTimeDosEpochTest>>testToByDo" Pull request url: https://github.com/pharo-project/pharo/pull/1810 Issue Url: https://pharo.fogbugz.com/f/cases/22417 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 17, 2018

[Pharo 7.0-dev] Build #1251: 22459-FileReferencecopyTo-deserves-a-much-better-comment

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

There is a new Pharo build available! The status of the build #1251 was: SUCCESS. The Pull Request #1807 was integrated: "22459-FileReferencecopyTo-deserves-a-much-better-comment" Pull request url: https://github.com/pharo-project/pharo/pull/1807 Issue Url: https://pharo.fogbugz.com/f/cases/22459 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 17, 2018

Confused about FileReference read/write streams

by Sven Van Caekenberghe

Hi, Since ever (or as far as I can remember), FileReference made a distinction between read and write streams, see #readStream[Do:] and #writeStream[Do:] - these return a ZnCharacterReadStream and ZnCharacterWriteStream in Pharo 7. Along the same lines, #binaryReadStream and #binaryWriteStream where introduced. However, the first returns a ZnBufferedReadStream (OK) while the latter returns a ZnBufferedReadWriteStream. Why ? I think it would be generally better if a standard ZnBufferedWriteStream where returned. ZnBufferedReadWriteStream is not a very pretty class to say the least, it also strikes me as confusing. What would break if we changed this ? If necessary there could be something like #readWriteStream[Do:] I guess. Sven

Sept. 17, 2018

[ANN] New Pharo 6.1 stable VM

by Esteban Lorenzano

Hi, Following what I had in my todo list for when coming back from ESUG, I promoted a new stable VM for Pharo 6.1. This is the VM that has been tested during almost two months for Pharo 7.0, so it should be fine, but let me know if there is any problem. Esteban

Sept. 17, 2018