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

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

by raffaello.giulietti＠lifeware.ch

On 2017-11-10 19:45, Martin McClure wrote: > On 11/10/2017 03:59 AM, 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. >> > [...] > > Thanks for the summary, Raffaello. > One can choose to convert Float -> Fraction (because fraction is the > more general format, in that it can represent more of the real numbers) > or to convert Fraction->Float (because a Float is considered an > approximation of a real number). > > But more important, I think, is that whichever choice is made, the > *same* choice must be made in *all* operations that involve both Floats > and Fractions. > > Regards, > -Martin Doing only Fraction->Float conversions in mixed mode won't preserve = as an equivalence relation and won't enable a consistent ordering with <=, which probably most Smalltalkers consider important and enjoyable properties. Nicolas gave some convincing examples on why most programmers might want to rely on them. Also, as I mentioned, most Smalltalkers might prefer keeping away from the complex properties of Floats. Doing automatic, implicit Fraction->Float conversions behind the scenes only exacerbates the probability of encountering Floats and of having to deal with their weird and unfamiliar arithmetic.

Nov. 10, 2017

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

by Tudor Girba

> On Nov 10, 2017, at 7:45 PM, Martin McClure <martin(a)hand2mouse.com> wrote: > > On 11/10/2017 03:59 AM, 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. >> > [...] > > Thanks for the summary, Raffaello. > One can choose to convert Float -> Fraction (because fraction is the more general format, in that it can represent more of the real numbers) or to convert Fraction->Float (because a Float is considered an approximation of a real number). > > But more important, I think, is that whichever choice is made, the *same* choice must be made in *all* operations that involve both Floats and Fractions. Indeed, this was the source of my original confusion. Doru > Regards, > -Martin > -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Nov. 10, 2017

feenk log

by Tudor Girba

Hi, Over the past couple of weeks Alex worked on stabilizing a first beta01 version for Pharo 6.1: https://twitter.com/feenkcom/status/929031849879461889 This is available as a beta01 tag in the pharo61 branch here: https://github.com/pharo-graphics/Bloc/tree/beta01 The main readme was updated with instructions and links: https://github.com/pharo-graphics/Bloc An overview of the improvements: - improved animations support that also works for scaling https://twitter.com/feenkcom/status/927617393194610693 - improved debugging support for transformations https://twitter.com/feenkcom/status/926040946130612224 - support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808 - updated MemoryGame tutorial: http://files.pharo.org/books-pdfs/booklet-Bloc/2017-11-09-memorygame.pdf https://github.com/pharo-graphics/Tutorials - extended examples that offer a 52% coverage - new Bloc world menu for easily accessing Bloc examples and reseting the Universe Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Nov. 10, 2017

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

by Martin McClure

On 11/10/2017 03:59 AM, 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. > [...] Thanks for the summary, Raffaello. One can choose to convert Float -> Fraction (because fraction is the more general format, in that it can represent more of the real numbers) or to convert Fraction->Float (because a Float is considered an approximation of a real number). But more important, I think, is that whichever choice is made, the *same* choice must be made in *all* operations that involve both Floats and Fractions. Regards, -Martin

Nov. 10, 2017

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

by Esteban Lorenzano

none of them, Iâm sorry :) I think we can do a lot better with just a bit of effort. Esteban > On 10 Nov 2017, at 15:26, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I would prefer the last one. > Regularity over exception. > Now the parser should just be good :) > > Stef > > On Fri, Nov 10, 2017 at 7:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 10 Nov 2017, at 19:12, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi sven >>> >>> Do you have an example because I do not understand your doubling. >> >> Sure, >> >> Bla { bla:bla } [ >> self isFoo ifTrue: [ #foo >> ] >> ifFalse: [ [ "block" #bar >> ]] >> ] >> >> would have to become >> >> Bla { bla:bla } [ >> self isFoo ifTrue: [ #foo >> ]] >> ifFalse: [ [ "block" #bar >> ]]] >> ] >> >> but this very rare (because usually code is intended). >> >> Nicolas' latest idea is cool too (use as much ['s as needed to avoid conflict). So the example would then become >> >> Bla { bla:bla } [[[ >> self isFoo ifTrue: [ #foo >> ] >> ifFalse: [ [ "block" #bar >> ]] >> ]]] >> >>> stef >>> >>> >>> On Fri, Nov 10, 2017 at 11:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Hi, >>>> >>>> Right now, TonelParser>>#methodBody looks a bit dangerous (too complex), and Nicolas already found some breaking cases as well a one possible solution. I was thinking a bit along the same lines, so here is a proposal. >>>> >>>> Overall I think we should keep the current readability of Tonel as much as possible (it is very important for diffs), while still being correct - i.e. no method source, even convoluted ones, possibly in different languages should break the encoding. >>>> >>>> The problem is how to quickly scan a stream for the closing $] (which occurs as a single character on a line by its own). Especially in Pharo source code, that situation (a conflict between the proper marker and actual source) is very rare, since code is usually intended. But is can occur and must be dealt with. >>>> >>>> The proposal is to just double the $] but only on lines that could conflict (which are lines consisting of only $]'s). The code itself becomes quite simple and remains fast enough. >>>> >>>> Here is some code to play with (EOL fixed to #cr for demo purposes): >>>> >>>> writer := [ :stream :methodSourceString | >>>> stream nextPut: $[; cr. >>>> methodSourceString linesDo: [ :line | >>>> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >>>> ifTrue: [ stream << $] ]. >>>> stream << line; cr ]. >>>> stream nextPut: $]; cr ]. >>>> >>>> reader := [ :stream | | line | >>>> (stream peekFor: $[) ifTrue: [ stream nextLine ] ifFalse: [ self error ]. >>>> String streamContents: [ :out | >>>> [ (line := stream nextLine) = ']' ] whileFalse: [ >>>> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >>>> ifTrue: [ out << line allButFirst ] >>>> ifFalse: [ out << line ]. >>>> out cr ] ] ]. >>>> >>>> encoded := String streamContents: [ :out | writer value: out value: (Collection>>#inject:into:) sourceCode ]. >>>> >>>> (reader value: encoded readStream) = ((Collection>>#inject:into:) sourceCode, String cr). >>>> >>>> escapedEncoded := String streamContents: [ :out | writer value: out value: 'test >>>> "Make sure there is no whitespace at line start to force an escape" >>>> self isFoo ifTrue: [ #foo >>>> ] >>>> ifFalse: [ [ "block" #bar >>>> ]] >>>> ' ]. >>>> >>>> (reader value: escapedEncoded readStream). >>>> >>>> What do you think ? >>>> Did I miss any special cases ? >>>> Is the price (very occasional insertion of an extra #] in the source code) worth the advantage (a simple, safe scheme). >>>> >>>> Sven >>>> >>>> PS: Note that several tools line syntax highlighting and double-click next to brackets have problems with weird delimiters such as in the above code ;-) >>>> >>>> >>> >> >> >

Nov. 10, 2017

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

by Stephane Ducasse

I would prefer the last one. Regularity over exception. Now the parser should just be good :) Stef On Fri, Nov 10, 2017 at 7:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 10 Nov 2017, at 19:12, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi sven >> >> Do you have an example because I do not understand your doubling. > > Sure, > > Bla { bla:bla } [ > self isFoo ifTrue: [ #foo > ] > ifFalse: [ [ "block" #bar > ]] > ] > > would have to become > > Bla { bla:bla } [ > self isFoo ifTrue: [ #foo > ]] > ifFalse: [ [ "block" #bar > ]]] > ] > > but this very rare (because usually code is intended). > > Nicolas' latest idea is cool too (use as much ['s as needed to avoid conflict). So the example would then become > > Bla { bla:bla } [[[ > self isFoo ifTrue: [ #foo > ] > ifFalse: [ [ "block" #bar > ]] > ]]] > >> stef >> >> >> On Fri, Nov 10, 2017 at 11:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Hi, >>> >>> Right now, TonelParser>>#methodBody looks a bit dangerous (too complex), and Nicolas already found some breaking cases as well a one possible solution. I was thinking a bit along the same lines, so here is a proposal. >>> >>> Overall I think we should keep the current readability of Tonel as much as possible (it is very important for diffs), while still being correct - i.e. no method source, even convoluted ones, possibly in different languages should break the encoding. >>> >>> The problem is how to quickly scan a stream for the closing $] (which occurs as a single character on a line by its own). Especially in Pharo source code, that situation (a conflict between the proper marker and actual source) is very rare, since code is usually intended. But is can occur and must be dealt with. >>> >>> The proposal is to just double the $] but only on lines that could conflict (which are lines consisting of only $]'s). The code itself becomes quite simple and remains fast enough. >>> >>> Here is some code to play with (EOL fixed to #cr for demo purposes): >>> >>> writer := [ :stream :methodSourceString | >>> stream nextPut: $[; cr. >>> methodSourceString linesDo: [ :line | >>> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >>> ifTrue: [ stream << $] ]. >>> stream << line; cr ]. >>> stream nextPut: $]; cr ]. >>> >>> reader := [ :stream | | line | >>> (stream peekFor: $[) ifTrue: [ stream nextLine ] ifFalse: [ self error ]. >>> String streamContents: [ :out | >>> [ (line := stream nextLine) = ']' ] whileFalse: [ >>> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >>> ifTrue: [ out << line allButFirst ] >>> ifFalse: [ out << line ]. >>> out cr ] ] ]. >>> >>> encoded := String streamContents: [ :out | writer value: out value: (Collection>>#inject:into:) sourceCode ]. >>> >>> (reader value: encoded readStream) = ((Collection>>#inject:into:) sourceCode, String cr). >>> >>> escapedEncoded := String streamContents: [ :out | writer value: out value: 'test >>> "Make sure there is no whitespace at line start to force an escape" >>> self isFoo ifTrue: [ #foo >>> ] >>> ifFalse: [ [ "block" #bar >>> ]] >>> ' ]. >>> >>> (reader value: escapedEncoded readStream). >>> >>> What do you think ? >>> Did I miss any special cases ? >>> Is the price (very occasional insertion of an extra #] in the source code) worth the advantage (a simple, safe scheme). >>> >>> Sven >>> >>> PS: Note that several tools line syntax highlighting and double-click next to brackets have problems with weird delimiters such as in the above code ;-) >>> >>> >> > >

Nov. 10, 2017

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

by Sven Van Caekenberghe

> On 10 Nov 2017, at 19:12, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi sven > > Do you have an example because I do not understand your doubling. Sure, Bla { bla:bla } [ self isFoo ifTrue: [ #foo ] ifFalse: [ [ "block" #bar ]] ] would have to become Bla { bla:bla } [ self isFoo ifTrue: [ #foo ]] ifFalse: [ [ "block" #bar ]]] ] but this very rare (because usually code is intended). Nicolas' latest idea is cool too (use as much ['s as needed to avoid conflict). So the example would then become Bla { bla:bla } [[[ self isFoo ifTrue: [ #foo ] ifFalse: [ [ "block" #bar ]] ]]] > stef > > > On Fri, Nov 10, 2017 at 11:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> >> Right now, TonelParser>>#methodBody looks a bit dangerous (too complex), and Nicolas already found some breaking cases as well a one possible solution. I was thinking a bit along the same lines, so here is a proposal. >> >> Overall I think we should keep the current readability of Tonel as much as possible (it is very important for diffs), while still being correct - i.e. no method source, even convoluted ones, possibly in different languages should break the encoding. >> >> The problem is how to quickly scan a stream for the closing $] (which occurs as a single character on a line by its own). Especially in Pharo source code, that situation (a conflict between the proper marker and actual source) is very rare, since code is usually intended. But is can occur and must be dealt with. >> >> The proposal is to just double the $] but only on lines that could conflict (which are lines consisting of only $]'s). The code itself becomes quite simple and remains fast enough. >> >> Here is some code to play with (EOL fixed to #cr for demo purposes): >> >> writer := [ :stream :methodSourceString | >> stream nextPut: $[; cr. >> methodSourceString linesDo: [ :line | >> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >> ifTrue: [ stream << $] ]. >> stream << line; cr ]. >> stream nextPut: $]; cr ]. >> >> reader := [ :stream | | line | >> (stream peekFor: $[) ifTrue: [ stream nextLine ] ifFalse: [ self error ]. >> String streamContents: [ :out | >> [ (line := stream nextLine) = ']' ] whileFalse: [ >> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >> ifTrue: [ out << line allButFirst ] >> ifFalse: [ out << line ]. >> out cr ] ] ]. >> >> encoded := String streamContents: [ :out | writer value: out value: (Collection>>#inject:into:) sourceCode ]. >> >> (reader value: encoded readStream) = ((Collection>>#inject:into:) sourceCode, String cr). >> >> escapedEncoded := String streamContents: [ :out | writer value: out value: 'test >> "Make sure there is no whitespace at line start to force an escape" >> self isFoo ifTrue: [ #foo >> ] >> ifFalse: [ [ "block" #bar >> ]] >> ' ]. >> >> (reader value: escapedEncoded readStream). >> >> What do you think ? >> Did I miss any special cases ? >> Is the price (very occasional insertion of an extra #] in the source code) worth the advantage (a simple, safe scheme). >> >> Sven >> >> PS: Note that several tools line syntax highlighting and double-click next to brackets have problems with weird delimiters such as in the above code ;-) >> >> >

Nov. 10, 2017

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

by Stephane Ducasse

Hi sven Do you have an example because I do not understand your doubling. stef On Fri, Nov 10, 2017 at 11:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Right now, TonelParser>>#methodBody looks a bit dangerous (too complex), and Nicolas already found some breaking cases as well a one possible solution. I was thinking a bit along the same lines, so here is a proposal. > > Overall I think we should keep the current readability of Tonel as much as possible (it is very important for diffs), while still being correct - i.e. no method source, even convoluted ones, possibly in different languages should break the encoding. > > The problem is how to quickly scan a stream for the closing $] (which occurs as a single character on a line by its own). Especially in Pharo source code, that situation (a conflict between the proper marker and actual source) is very rare, since code is usually intended. But is can occur and must be dealt with. > > The proposal is to just double the $] but only on lines that could conflict (which are lines consisting of only $]'s). The code itself becomes quite simple and remains fast enough. > > Here is some code to play with (EOL fixed to #cr for demo purposes): > > writer := [ :stream :methodSourceString | > stream nextPut: $[; cr. > methodSourceString linesDo: [ :line | > (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) > ifTrue: [ stream << $] ]. > stream << line; cr ]. > stream nextPut: $]; cr ]. > > reader := [ :stream | | line | > (stream peekFor: $[) ifTrue: [ stream nextLine ] ifFalse: [ self error ]. > String streamContents: [ :out | > [ (line := stream nextLine) = ']' ] whileFalse: [ > (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) > ifTrue: [ out << line allButFirst ] > ifFalse: [ out << line ]. > out cr ] ] ]. > > encoded := String streamContents: [ :out | writer value: out value: (Collection>>#inject:into:) sourceCode ]. > > (reader value: encoded readStream) = ((Collection>>#inject:into:) sourceCode, String cr). > > escapedEncoded := String streamContents: [ :out | writer value: out value: 'test > "Make sure there is no whitespace at line start to force an escape" > self isFoo ifTrue: [ #foo > ] > ifFalse: [ [ "block" #bar > ]] > ' ]. > > (reader value: escapedEncoded readStream). > > What do you think ? > Did I miss any special cases ? > Is the price (very occasional insertion of an extra #] in the source code) worth the advantage (a simple, safe scheme). > > Sven > > PS: Note that several tools line syntax highlighting and double-click next to brackets have problems with weird delimiters such as in the above code ;-) > >

Nov. 10, 2017

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

by Esteban Lorenzano

Hi Nico, I have a fix for both cases you provided. now, I need to refactor it because is ugly how I solve it :) right now this is super agnostic: the only thing we ensure is to count correctly the brackets to be sure we have a complete method. All the cases you mention it are possible ways where a brackets can appear without being part of a block constructionâ¦ of which I think we can delimit. Esteban > On 10 Nov 2017, at 12:11, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2017-11-10 12:08 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > > > > On 10 Nov 2017, at 11:59, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@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. > > > Indeed, in some well known case, a literal would be modified bewteen Pharo and Tonel which would be rare but weird... > Currently, Tonel does not have to change the syntax at all. > > The first goals are: > - we should prefer a syntax agnostic format for two reasons > * not insulting the future and supporting alternate syntax extensions (compilerClass) > * making the parsing both robust and efficient (not necessary to use a RB parser for a quick scan) > - we don't want too many decorations that would make the Tonel syntax look different from Pharo syntax > > If we also want to support human edited Tonel files: > - we want something resilient (not be too much picky about a missing leading space for example) > - we want the most simple rules and least surprising rules > > The first two goals look really antagonist... > > There are other possibilities: if we don't want to change the methodBody at all, then let's change the opening/closing sequence > > - at write, choose a closing sequence that has no exact match in source code, then use the inverse sequence as the opening sequence > - at read, just scan for the inverse of opening sequence > > opening sequence could be any combination of [{<( > or maybe just a single [ repeated as many times as necessary > > > > > 2017-11-10 11:49 GMT+01:00 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@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 <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> > > > >

Nov. 10, 2017

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

by Esteban Lorenzano

> On 10 Nov 2017, at 13:05, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-11-10 17:03 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > 2017-11-10 16:30 GMT+01:00 Martin McClure <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>>: > Tonel is intended to be, I believe: > * For Smalltalk primarily (although there are other languages) > * Be for any Smalltalk dialect (although the first implementation is for Pharo, it is being ported to GemStone, and we intend to port it to VW and VA) > > Interesting how it will be handled when Pharo will use slots abstraction exclusively. And more simple, when there will be only package and tags instead of class categories. > > To be more clear. Imaging that instead of #instanceVariables field Pharo will use #slots. And instead of #category it will be #package and #tags what does it has to do with this thread? handling that is trivial: once we actually have slots (bah, we have them, but once we *use* them) and once we move to package+tags, we just adapt the descriptions. Thatâs the advantage of using STON to keep them. Esteban > > > * Be human-readable (some people want to be able to use tools like GitHub to look at diffs and such) > * Be human-editable using normal text editors (important for porting -- sometimes you just have to edit the source before it will load, for instance) > > I think that Tonel using [] to enclose the source is a pretty good idea. A proper parser should be able to correctly parse Smalltalk code from any dialect, and it makes it human-readable and human-editable. > > However, as has been noted in this thread, it would also be nice to handle non-Smalltalk code. One way to do this (one that was in an earlier proposal but is not currently in Tonel) is to use pure STON for any source code that does not have standard Smalltalk syntax. A method like this would look something like: > > { 'category' : 'public', > 'source' : 'whatever the source code is, with STON escapes as necessary' } > > Regards, > -Martin > >

Nov. 10, 2017