November 2017 - Pharo-dev - lists.pharo.org

Catalog problem

by Ben Coman

Today I downloaded Pharo and found Catalog to be empty. http://files.pharo.org/platform/Pharo6.1-64-linux.zip cheers -ben

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by Tudor Girba

Thanks indeed for the summary. I like this. Doru > On Nov 10, 2017, at 12:59 PM, raffaello.giulietti(a)lifeware.ch wrote: > > I would like to summarize my perspective of what emerged from the > discussions in the "float & fraction equality bug" trail. > > The topic is all about mixed operations when both Fractions and Floats > are involved in the mix and can be restated as the question of whether > it is better to automagically convert the Float to a Fraction or the > Fraction to a Float before performing the operation. > > AFAIK, Pharo currently implements a dual-conversion strategy: > (1) it applies Float->Fraction for comparison like =, <=, etc. > (2) it applies Fraction->Float for operations like +, *, etc. > > The reason for (1) is preservation of = as an equivalence and of <= as a > total ordering. This is an important point for most Smalltalkers. > > The reason for (2), however, is dictated by a supposedly better > performance. While it is true that Floats perform better than Fractions, > I'm not sure that it makes a noticeable difference in everyday uses. > Further, the Fraction->Float conversion might even cost more than the > gain of using Floats for the real work, the operation itself. The > conversion Float->Fraction, on the contrary, is easier. > > But the major disadvantage of (2) is that it enters the world of limited > precision computation (e.g., Floats), which is much harder to > understand, less intuitive, more surprising for most of us. > > > > So, it might be worthwhile to suppress (2) and consistently apply > Float->Fraction conversions whenever needed. It won't make daily > computations noticeably slower and helps in preserving more enjoyable > properties than the current dual-conversion regime. > > Also, it won't prevent the numericists or other practitioners to do > floating point computations in mixed contexts: just apply explicit > Fraction->Float conversions when so desired. > > This will be at odd with other Smalltalk implementations but might end > up being a safer environment. > > > > I would like to thank Nicolas in particular for being so quick in > answering back and for the good points he raised. > > Greetings > Raffaello > -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by henry

Good summary. I must add to comparison and operations, Iâd add encoding, where ASN.1 Reals MUST convert to Float before encoding with mantissa, exponent, etc. Here is another Fraction -> Float conversion. As well as ScaledDecimal -> Float conversion. Sent from ProtonMail Mobile On Fri, Nov 10, 2017 at 06:59, <raffaello.giulietti(a)lifeware.ch> wrote: > I would like to summarize my perspective of what emerged from the discussions in the "float & fraction equality bug" trail. The topic is all about mixed operations when both Fractions and Floats are involved in the mix and can be restated as the question of whether it is better to automagically convert the Float to a Fraction or the Fraction to a Float before performing the operation. AFAIK, Pharo currently implements a dual-conversion strategy: (1) it applies Float->Fraction for comparison like =, <=, etc. (2) it applies Fraction->Float for operations like +, *, etc. The reason for (1) is preservation of = as an equivalence and of <= as a total ordering. This is an important point for most Smalltalkers. The reason for (2), however, is dictated by a supposedly better performance. While it is true that Floats perform better than Fractions, I'm not sure that it makes a noticeable difference in everyday uses. Further, the Fraction->Float conversion might even cost more than the gain of using Floats for the real work, the operation itself. The conversion Float->Fraction, on the contrary, is easier. But the major disadvantage of (2) is that it enters the world of limited precision computation (e.g., Floats), which is much harder to understand, less intuitive, more surprising for most of us. So, it might be worthwhile to suppress (2) and consistently apply Float->Fraction conversions whenever needed. It won't make daily computations noticeably slower and helps in preserving more enjoyable properties than the current dual-conversion regime. Also, it won't prevent the numericists or other practitioners to do floating point computations in mixed contexts: just apply explicit Fraction->Float conversions when so desired. This will be at odd with other Smalltalk implementations but might end up being a safer environment. I would like to thank Nicolas in particular for being so quick in answering back and for the good points he raised. Greetings Raffaello

Nov. 10, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by raffaello.giulietti＠lifeware.ch

I would like to summarize my perspective of what emerged from the discussions in the "float & fraction equality bug" trail. The topic is all about mixed operations when both Fractions and Floats are involved in the mix and can be restated as the question of whether it is better to automagically convert the Float to a Fraction or the Fraction to a Float before performing the operation. AFAIK, Pharo currently implements a dual-conversion strategy: (1) it applies Float->Fraction for comparison like =, <=, etc. (2) it applies Fraction->Float for operations like +, *, etc. The reason for (1) is preservation of = as an equivalence and of <= as a total ordering. This is an important point for most Smalltalkers. The reason for (2), however, is dictated by a supposedly better performance. While it is true that Floats perform better than Fractions, I'm not sure that it makes a noticeable difference in everyday uses. Further, the Fraction->Float conversion might even cost more than the gain of using Floats for the real work, the operation itself. The conversion Float->Fraction, on the contrary, is easier. But the major disadvantage of (2) is that it enters the world of limited precision computation (e.g., Floats), which is much harder to understand, less intuitive, more surprising for most of us. So, it might be worthwhile to suppress (2) and consistently apply Float->Fraction conversions whenever needed. It won't make daily computations noticeably slower and helps in preserving more enjoyable properties than the current dual-conversion regime. Also, it won't prevent the numericists or other practitioners to do floating point computations in mixed contexts: just apply explicit Fraction->Float conversions when so desired. This will be at odd with other Smalltalk implementations but might end up being a safer environment. I would like to thank Nicolas in particular for being so quick in answering back and for the good points he raised. Greetings Raffaello

Nov. 10, 2017

Re: [Pharo-dev] Tonel line end convention

by Sven Van Caekenberghe

> On 10 Nov 2017, at 12:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> I am wondering if the current approach regarding the Tonel line end convention is a good idea. >> >> TonelWriter>>#newLine >> ^ OSPlatform current lineEnding >> >> Although it is no problem to write Pharo code that transparently deals with (accepts) any line end convention, not specifying a fixed line end convention is bound to lead to version control problems, in my opinion. >> >> Person 1 on platform A has line end convention #cr. After editing a single method, the .class.st is generated. Now the whole file is using #cr. From the standpoint of the version control system, *every* line is now potentially changed (when the previous line end convention was different). >> >> Or am I missing something that mitigates this ? > > git can handle (ignore) line endings when diffing. > and also git can checkout with platform line endings, which means you can switch between mac/linux and windows *and* you can keep your files readable (which is the purpose of using platform line ending). OK, that's settled then ;-) > Esteban > >> >> Sven

Nov. 10, 2017

Re: [Pharo-dev] Tonel line end convention

by Esteban Lorenzano

> On 10 Nov 2017, at 07:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > I am wondering if the current approach regarding the Tonel line end convention is a good idea. > > TonelWriter>>#newLine > ^ OSPlatform current lineEnding > > Although it is no problem to write Pharo code that transparently deals with (accepts) any line end convention, not specifying a fixed line end convention is bound to lead to version control problems, in my opinion. > > Person 1 on platform A has line end convention #cr. After editing a single method, the .class.st is generated. Now the whole file is using #cr. From the standpoint of the version control system, *every* line is now potentially changed (when the previous line end convention was different). > > Or am I missing something that mitigates this ? git can handle (ignore) line endings when diffing. and also git can checkout with platform line endings, which means you can switch between mac/linux and windows *and* you can keep your files readable (which is the purpose of using platform line ending). Esteban > > Sven > >

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Sven Van Caekenberghe

> On 10 Nov 2017, at 11:59, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > My proposition was to force methodBody closing to be on first column, > and disambiguate potential method conflicts by forcing a more transparent white space. > > Maybe we can force the white space only on conflicting lines that would begin with a ]. > Most methods are indented (and even formatted) so the conflict should be extremely rare. > It could happen though with multiple line literal string > > ^' > [ > something went wrong here > ] > ' > > If first column trick is not acceptable, then we will indeed come up with more visible escape sequences. But don't you think that it would be weird to insert extra whitespace and not remove it (under the assumption that it does not matter), because is string constants like in your example, you would actually change code ! And yes, we are discussing a very rare case. But as you showed, simplifying #methodBody is really important. > 2017-11-10 11:49 GMT+01:00 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > Can a line with a single ] ever at the "right" indentation level? > Forcing autoformat at commit is a bit heavy hand, but maybe inserting a tab > (or 2,3,4 spaces?) would be an ok workaround that doesn't require special > decoding when loading the code? > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Nicolas Cellier

My proposition was to force methodBody closing to be on first column, and disambiguate potential method conflicts by forcing a more transparent white space. Maybe we can force the white space only on conflicting lines that would begin with a ]. Most methods are indented (and even formatted) so the conflict should be extremely rare. It could happen though with multiple line literal string ^' [ something went wrong here ] ' If first column trick is not acceptable, then we will indeed come up with more visible escape sequences. 2017-11-10 11:49 GMT+01:00 Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no>: > Can a line with a single ] ever at the "right" indentation level? > Forcing autoformat at commit is a bit heavy hand, but maybe inserting a tab > (or 2,3,4 spaces?) would be an ok workaround that doesn't require special > decoding when loading the code? > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Sven Van Caekenberghe

> On 10 Nov 2017, at 11:49, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Can a line with a single ] ever at the "right" indentation level? > Forcing autoformat at commit is a bit heavy hand, but maybe inserting a tab > (or 2,3,4 spaces?) would be an ok workaround that doesn't require special > decoding when loading the code? The problem with inserting some whitespace is that you cannot know if you have to remove it (unless you insert whitespace everywhere, which was I believe Nicolas' proposal). Like I said, this is all rare and convoluted. But inside a multiline string constant you can have everything, right ? Foo>#myMethod "Return a help string" ^ 'This is for example help: Never use ] as the single character on a line!' I think the formatter is not good enough to do an auto reformat on every commit (especially for data driven, spec style code). Changing the formatting algorithm (which might be a personal preference) would change all source code. > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Nov. 10, 2017

[Pharo 7.0-dev] Build #279: 20363-ThemeIconsdownloadTo-has-an-argument-which-is-never-referenced-in-code

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

There is a new Pharo build available! The status of the build #279 was: SUCCESS. The Pull Request #453 was integrated: "20363-ThemeIconsdownloadTo-has-an-argument-which-is-never-referenced-in-code" Pull request url: https://github.com/pharo-project/pharo/pull/453 Issue Url: https://pharo.fogbugz.com/f/cases/20363 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 10, 2017