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

Re: [Pharo-dev] Non-deterministic ombu errors

by Martin Dias

Hi On Tue, Oct 3, 2017 at 11:40 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Yes, please backport the changes to Pharo 6.1 because the travis builds > are failing a lot with this kind of errors when you have a project with > non-ASCII characters. > Ok > > Probably it makes no sense to enable Epicea in the images used by > SmalltalkCI. Is there some way to disable it? > Sure, you can evaluate: EpMonitor reset > > > On Mon, Oct 2, 2017 at 10:18 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Martin >> >> if you publish a fix for 6.1 we will port it back because this is >> important. >> >> Stef >> >> On Fri, Sep 29, 2017 at 3:55 PM, Martin Dias <tinchodias(a)gmail.com> >> wrote: >> > Now I do not know the best way for you to get the new fixed version. >> It's >> > too late to include it in P6.1, I guess, so... either add epicea into >> > metacello configuration or wait until P7. >> > >> > >> > >> > On Fri, Sep 29, 2017 at 5:34 AM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> >> > wrote: >> >> >> >> I'm glad it has known reason then, thank you for looking into it, all I >> >> was >> >> able to find out was that it relates to non-ascii characters and that >> >> build >> >> on our production server fails because of that :) >> >> >> >> Jan >> >> >> >> >> >> tinchodias wrote >> >> > On Sun, Sep 24, 2017 at 5:49 AM, Sven Van Caekenberghe < >> >> >> >> > sven@ >> >> >> >> > > wrote: >> >> > >> >> >> >> >> >> > On 23 Sep 2017, at 22:42, Jan BlizniÄenko < >> >> >> >> > bliznjan@.cvut >> >> >> >> > > wrote: >> >> >> > >> >> >> > Hello >> >> >> > >> >> >> > I am having very similar errors from time to time when manually >> >> >> > loading >> >> >> code >> >> >> > into Pharo from filetree (gitfiletree), but only in one of my >> >> >> > projects >> >> >> which >> >> >> > contains non-ASCII characters like ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©Å¯ÃºÅ¥Ä. For the very >> same >> >> >> reason >> >> >> > (not able to find why sometimes the error is there and sometimes >> is >> >> >> not), I >> >> >> > did not report it yet, but it is quite annoying. Retrying loading >> the >> >> >> > package helps every time. >> >> >> >> >> >> I think was reported before. I believe Ombu somewhere takes an >> >> >> arbitrary >> >> >> chunk of bytes out of an UTF-8 encoded file (like the last 100 of >> >> >> something >> >> >> like that) and then starts reading that. With UTF-8, a variable >> length >> >> >> encoding, that can be dangerous because you could end up in the >> middle >> >> >> of >> >> >> a >> >> >> character, not between encoded character boundaries. This would also >> >> >> explain the randomness, as it is highly dependent on the contents. >> >> >> >> >> >> ZnUTF8Encoder>>#backOnStream: can be used to make sure you are >> really >> >> >> at >> >> >> the start of an encoded character. >> >> >> >> >> > >> >> > >> >> > Hello >> >> > >> >> > This issue was reported as: >> >> > >> >> > >> >> > https://pharo.fogbugz.com/f/cases/20112/Epicea-can-fail-whil >> e-reading-non-ascii-blocks >> >> > >> >> > My apologies for the bug... I introduced that code as an i/o >> >> > optimization >> >> > but wasn't properly tested. >> >> > >> >> > Thnks Sven, but I finally used stream's #basicNext (as Henrik >> suggested >> >> > in >> >> > fogbugz) which skips forward. >> >> > >> >> > >> >> > Martin >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Sent from: http://forum.world.st/Pharo-Sm >> alltalk-Developers-f1294837.html >> >> >> > >> >> >

Oct. 3, 2017

Re: [Pharo-dev] String Interpolation

by Henrik Sperre Johansen

Sven Van Caekenberghe-2 wrote > Nicolas, > >> On 28 Sep 2017, at 23:56, Nicolas Cellier < > nicolas.cellier.aka.nice@ > > wrote: >> >> Hi Sven, >> for now it works because the context into which the block is executed >> still has full access to the variables and receiver of outer context from >> which the block is declared. >> >> But it's not necessarily the case in all dialects. >> In VW for example, I get nil instead of foobar >> #('loop on value 1 in nil' 'loop on value 2 in nil' 'loop on value 3 in >> nil') >> >> This is because the optimized block has its own method (a CompiledBlock) >> and a restricted context (a BlockContext). >> The receiver is the BlockClosure and this closure has no copiedValues >> from the outerContext and an outerContext set to nil because some >> analyzer in the compilation phase thought the closure would never access >> the outerContext (no return to outerContext) nor any of its variable. >> >> Once we'll have clean blocks - depending on the implementation - things >> might change in Pharo too. >> But we must ask Clement on this subject (I add not taken time to check >> the implementation he proposes). > > I think I understand: you basically say that the compiler could > remove/optimise away local/temp variables if it decides they are not used, > hence accessing them dynamically will fail. This could be compiler/dialect > specific. > > That being said, such behaviour would also make the debugger look strange > (assigned local/temp is in the source code but not in the context). > > In Pharo, even the following (currently) works fine: > > [ :x :y | '{x}+{y}={x+y}' interpolate ] value: 7 value: 8. > > Sven Not quite; a clean blocks defining feature is that there's no references to any variables defined in an outer scope. In other words, a block where all variables used are either block params, or defined locally in the block. So the above example is a clean block, and would still work. Removing temps identified as unused, is an orthagonal optimization. It's possible to define even more types of blocks based on the defining scope used (for instance, if a block only uses instance scoped vars/self calls, it's essentially an anonymous method, and could be cached as such), but clean/unclean is the most useful distinction. Like Denis said though, there's really quite a few tools you'd need to update if you want them to function "correctly" with string interpolation. Opinions differ, but at least to me, those tools being (mostly*) reliable is worth more than a less verbose version of format:. If one could have one's cake and eat it too, however... (For reference, I just spent some time writing a translator from a custom application-defined executable string format -> standard blocks for exactly this reason, once you lose reliable senders/implementors/refactorings, it can become hard to evolve an application in a confident manner) Cheers, Henry * We already have things like perform: aPartial, selector of course -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 3, 2017

Re: [Pharo-dev] String Interpolation

by Denis Kudriashov

2017-10-03 17:39 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > While idea looks cool it will require a lot of tool support. Senders, > var/class references, rename refactorings should be aware of it > And I forgot debugger. It should be possible to step over "interpolated expressions" > > 2017-10-03 17:29 GMT+02:00 Damien Pollet <damien.pollet(a)gmail.com>: > >> On 3 October 2017 at 14:07, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >>> Why not having an opal plugin? >>> >>> The opal plugin may read strings in the form: >>> >>> "lalala {some expression} lololo" >>> >>> and replace at compile time that by: >>> >>> "lalala {1} lololo" format { some expression } >>> >> >> If we're going to extend the compiler, we might as avoid parsing at >> runtime by desugaring more like: >> >> String streamContents: [:str | >> str >> nextPutAll: 'lalala '; >> nextPutAll: (some expression) printString; >> nextPutAll: ' lololo' ] >> >> The thing to think about is what is the delimiter for {some expression}. >>> - a too used one may break lots of existing code. >>> >> >> â¦or we could change the string quotes to mean "dynamic string in which >> interpolations can be used" and keep single quotes for literal strings only. >> >> - and we should escape it >>> >> >> indeed >> >> >>> On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> >>>> >>>> >>>> > On 29 Sep 2017, at 08:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> wrote: >>>> > >>>> > This solution will not work for environments without sources too >>>> where names like t1, t2 are used for temporary variables. >>>> >>>> That is true. >>>> >>>> I often wonder why we can't keep at least the variables names, it would >>>> not be that expensive. There was this problem with FFI that needed source >>>> code access as well. It would also help the debugger and make the >>>> decompiler more powerful. >>>> >>>> > Anyway, nice idea. >>>> > >>>> > -- Pavel >>>> > >>>> > Dne Ätvrtek 28. zÃ¡ÅÃ 2017 Sven Van Caekenberghe <sven(a)stfx.eu> >>>> napsal(a): >>>> > Hi, >>>> > >>>> > I got into a little office discussion about string interpolation as >>>> it is done in different programming languages. >>>> > >>>> > In Pharo we have String>>#format: which is pretty nice. It works as >>>> follows: >>>> > >>>> > | x y | >>>> > x := 123. >>>> > y := #foo. >>>> > 'x={1} and y={2}' format: { x. y }. >>>> > >>>> > It is also possible to use a dictionary with keys, like this: >>>> > >>>> > | x y | >>>> > x := 123. >>>> > y := #foo. >>>> > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. >>>> > >>>> > But this is not true string interpolation as described in [ >>>> https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to >>>> write the value generating expressions directly inside the strings. >>>> > >>>> > Since in Pharo we add features not by extending the syntax but by >>>> adding messages I wondered if it could be done for string interpolation. >>>> The goal is to make the following work: >>>> > >>>> > | x y | >>>> > x := 123. >>>> > y := #foo. >>>> > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' >>>> interpolate. >>>> > >>>> > => 'It seems x equals 123 and y equals foo while Pi is still >>>> 3.141592653589793' >>>> > >>>> > Here is the implementation I came up with: >>>> > >>>> > String>>#interpolate >>>> > "Format the receiver by interpolating the evaluation of expressions >>>> > in between curly brackets in the context of the sender as in the >>>> following 3 oneline examples. >>>> > 'Today is {Date today}' interpolate. >>>> > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. >>>> > 'In {#strings} you can escape \{ by prefixing it with \\' >>>> interpolate." >>>> > >>>> > | senderContext | >>>> > senderContext := thisContext sender. >>>> > ^ self class new: self size streamContents: [ :out | | stream | >>>> > stream := self readStream. >>>> > [ stream atEnd ] whileFalse: [ | currentChar | >>>> > (currentChar := stream next) == ${ >>>> > ifTrue: [ | expression result | >>>> > expression := stream upTo: $}. >>>> > result := Compiler new >>>> > evaluate: expression in: senderContext to: nil >>>> notifying: nil ifFail: [ ^ nil ] logged: false. >>>> > out nextPutAll: result asString ] >>>> > ifFalse: [ >>>> > currentChar == $\ >>>> > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream >>>> next ] ] >>>> > ifFalse: [ out nextPut: currentChar ] ] ] ] >>>> > >>>> > It is a hack that could certainly be improved. And there is of course >>>> an obvious security problem. >>>> > >>>> > Thoughts ? >>>> > >>>> > 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 <+33%206%2052%2070%2066%2013> >>> >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > >

Oct. 3, 2017

Re: [Pharo-dev] String Interpolation

by Denis Kudriashov

2017-10-03 17:39 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > While idea looks cool it will require a lot of tool support. Senders, > var/class references, rename refactorings should be aware of it > Language designers do not care about it of course :) > > 2017-10-03 17:29 GMT+02:00 Damien Pollet <damien.pollet(a)gmail.com>: > >> On 3 October 2017 at 14:07, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >>> Why not having an opal plugin? >>> >>> The opal plugin may read strings in the form: >>> >>> "lalala {some expression} lololo" >>> >>> and replace at compile time that by: >>> >>> "lalala {1} lololo" format { some expression } >>> >> >> If we're going to extend the compiler, we might as avoid parsing at >> runtime by desugaring more like: >> >> String streamContents: [:str | >> str >> nextPutAll: 'lalala '; >> nextPutAll: (some expression) printString; >> nextPutAll: ' lololo' ] >> >> The thing to think about is what is the delimiter for {some expression}. >>> - a too used one may break lots of existing code. >>> >> >> â¦or we could change the string quotes to mean "dynamic string in which >> interpolations can be used" and keep single quotes for literal strings only. >> >> - and we should escape it >>> >> >> indeed >> >> >>> On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> >>>> >>>> >>>> > On 29 Sep 2017, at 08:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> wrote: >>>> > >>>> > This solution will not work for environments without sources too >>>> where names like t1, t2 are used for temporary variables. >>>> >>>> That is true. >>>> >>>> I often wonder why we can't keep at least the variables names, it would >>>> not be that expensive. There was this problem with FFI that needed source >>>> code access as well. It would also help the debugger and make the >>>> decompiler more powerful. >>>> >>>> > Anyway, nice idea. >>>> > >>>> > -- Pavel >>>> > >>>> > Dne Ätvrtek 28. zÃ¡ÅÃ 2017 Sven Van Caekenberghe <sven(a)stfx.eu> >>>> napsal(a): >>>> > Hi, >>>> > >>>> > I got into a little office discussion about string interpolation as >>>> it is done in different programming languages. >>>> > >>>> > In Pharo we have String>>#format: which is pretty nice. It works as >>>> follows: >>>> > >>>> > | x y | >>>> > x := 123. >>>> > y := #foo. >>>> > 'x={1} and y={2}' format: { x. y }. >>>> > >>>> > It is also possible to use a dictionary with keys, like this: >>>> > >>>> > | x y | >>>> > x := 123. >>>> > y := #foo. >>>> > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. >>>> > >>>> > But this is not true string interpolation as described in [ >>>> https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to >>>> write the value generating expressions directly inside the strings. >>>> > >>>> > Since in Pharo we add features not by extending the syntax but by >>>> adding messages I wondered if it could be done for string interpolation. >>>> The goal is to make the following work: >>>> > >>>> > | x y | >>>> > x := 123. >>>> > y := #foo. >>>> > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' >>>> interpolate. >>>> > >>>> > => 'It seems x equals 123 and y equals foo while Pi is still >>>> 3.141592653589793' >>>> > >>>> > Here is the implementation I came up with: >>>> > >>>> > String>>#interpolate >>>> > "Format the receiver by interpolating the evaluation of expressions >>>> > in between curly brackets in the context of the sender as in the >>>> following 3 oneline examples. >>>> > 'Today is {Date today}' interpolate. >>>> > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. >>>> > 'In {#strings} you can escape \{ by prefixing it with \\' >>>> interpolate." >>>> > >>>> > | senderContext | >>>> > senderContext := thisContext sender. >>>> > ^ self class new: self size streamContents: [ :out | | stream | >>>> > stream := self readStream. >>>> > [ stream atEnd ] whileFalse: [ | currentChar | >>>> > (currentChar := stream next) == ${ >>>> > ifTrue: [ | expression result | >>>> > expression := stream upTo: $}. >>>> > result := Compiler new >>>> > evaluate: expression in: senderContext to: nil >>>> notifying: nil ifFail: [ ^ nil ] logged: false. >>>> > out nextPutAll: result asString ] >>>> > ifFalse: [ >>>> > currentChar == $\ >>>> > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream >>>> next ] ] >>>> > ifFalse: [ out nextPut: currentChar ] ] ] ] >>>> > >>>> > It is a hack that could certainly be improved. And there is of course >>>> an obvious security problem. >>>> > >>>> > Thoughts ? >>>> > >>>> > 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 <+33%206%2052%2070%2066%2013> >>> >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > >

Oct. 3, 2017

Re: [Pharo-dev] String Interpolation

by Denis Kudriashov

Hi. While idea looks cool it will require a lot of tool support. Senders, var/class references, rename refactorings should be aware of it 2017-10-03 17:29 GMT+02:00 Damien Pollet <damien.pollet(a)gmail.com>: > On 3 October 2017 at 14:07, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Why not having an opal plugin? >> >> The opal plugin may read strings in the form: >> >> "lalala {some expression} lololo" >> >> and replace at compile time that by: >> >> "lalala {1} lololo" format { some expression } >> > > If we're going to extend the compiler, we might as avoid parsing at > runtime by desugaring more like: > > String streamContents: [:str | > str > nextPutAll: 'lalala '; > nextPutAll: (some expression) printString; > nextPutAll: ' lololo' ] > > The thing to think about is what is the delimiter for {some expression}. >> - a too used one may break lots of existing code. >> > > â¦or we could change the string quotes to mean "dynamic string in which > interpolations can be used" and keep single quotes for literal strings only. > > - and we should escape it >> > > indeed > > >> On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> >>> >>> > On 29 Sep 2017, at 08:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> wrote: >>> > >>> > This solution will not work for environments without sources too where >>> names like t1, t2 are used for temporary variables. >>> >>> That is true. >>> >>> I often wonder why we can't keep at least the variables names, it would >>> not be that expensive. There was this problem with FFI that needed source >>> code access as well. It would also help the debugger and make the >>> decompiler more powerful. >>> >>> > Anyway, nice idea. >>> > >>> > -- Pavel >>> > >>> > Dne Ätvrtek 28. zÃ¡ÅÃ 2017 Sven Van Caekenberghe <sven(a)stfx.eu> >>> napsal(a): >>> > Hi, >>> > >>> > I got into a little office discussion about string interpolation as it >>> is done in different programming languages. >>> > >>> > In Pharo we have String>>#format: which is pretty nice. It works as >>> follows: >>> > >>> > | x y | >>> > x := 123. >>> > y := #foo. >>> > 'x={1} and y={2}' format: { x. y }. >>> > >>> > It is also possible to use a dictionary with keys, like this: >>> > >>> > | x y | >>> > x := 123. >>> > y := #foo. >>> > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. >>> > >>> > But this is not true string interpolation as described in [ >>> https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to >>> write the value generating expressions directly inside the strings. >>> > >>> > Since in Pharo we add features not by extending the syntax but by >>> adding messages I wondered if it could be done for string interpolation. >>> The goal is to make the following work: >>> > >>> > | x y | >>> > x := 123. >>> > y := #foo. >>> > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' >>> interpolate. >>> > >>> > => 'It seems x equals 123 and y equals foo while Pi is still >>> 3.141592653589793' >>> > >>> > Here is the implementation I came up with: >>> > >>> > String>>#interpolate >>> > "Format the receiver by interpolating the evaluation of expressions >>> > in between curly brackets in the context of the sender as in the >>> following 3 oneline examples. >>> > 'Today is {Date today}' interpolate. >>> > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. >>> > 'In {#strings} you can escape \{ by prefixing it with \\' >>> interpolate." >>> > >>> > | senderContext | >>> > senderContext := thisContext sender. >>> > ^ self class new: self size streamContents: [ :out | | stream | >>> > stream := self readStream. >>> > [ stream atEnd ] whileFalse: [ | currentChar | >>> > (currentChar := stream next) == ${ >>> > ifTrue: [ | expression result | >>> > expression := stream upTo: $}. >>> > result := Compiler new >>> > evaluate: expression in: senderContext to: nil >>> notifying: nil ifFail: [ ^ nil ] logged: false. >>> > out nextPutAll: result asString ] >>> > ifFalse: [ >>> > currentChar == $\ >>> > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream >>> next ] ] >>> > ifFalse: [ out nextPut: currentChar ] ] ] ] >>> > >>> > It is a hack that could certainly be improved. And there is of course >>> an obvious security problem. >>> > >>> > Thoughts ? >>> > >>> > 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 <+33%206%2052%2070%2066%2013> >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Oct. 3, 2017

Re: [Pharo-dev] String Interpolation

by Damien Pollet

On 3 October 2017 at 14:07, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Why not having an opal plugin? > > The opal plugin may read strings in the form: > > "lalala {some expression} lololo" > > and replace at compile time that by: > > "lalala {1} lololo" format { some expression } > If we're going to extend the compiler, we might as avoid parsing at runtime by desugaring more like: String streamContents: [:str | str nextPutAll: 'lalala '; nextPutAll: (some expression) printString; nextPutAll: ' lololo' ] The thing to think about is what is the delimiter for {some expression}. > - a too used one may break lots of existing code. > â¦or we could change the string quotes to mean "dynamic string in which interpolations can be used" and keep single quotes for literal strings only. - and we should escape it > indeed > On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> >> > On 29 Sep 2017, at 08:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> > >> > This solution will not work for environments without sources too where >> names like t1, t2 are used for temporary variables. >> >> That is true. >> >> I often wonder why we can't keep at least the variables names, it would >> not be that expensive. There was this problem with FFI that needed source >> code access as well. It would also help the debugger and make the >> decompiler more powerful. >> >> > Anyway, nice idea. >> > >> > -- Pavel >> > >> > Dne Ätvrtek 28. zÃ¡ÅÃ 2017 Sven Van Caekenberghe <sven(a)stfx.eu> >> napsal(a): >> > Hi, >> > >> > I got into a little office discussion about string interpolation as it >> is done in different programming languages. >> > >> > In Pharo we have String>>#format: which is pretty nice. It works as >> follows: >> > >> > | x y | >> > x := 123. >> > y := #foo. >> > 'x={1} and y={2}' format: { x. y }. >> > >> > It is also possible to use a dictionary with keys, like this: >> > >> > | x y | >> > x := 123. >> > y := #foo. >> > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. >> > >> > But this is not true string interpolation as described in [ >> https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to >> write the value generating expressions directly inside the strings. >> > >> > Since in Pharo we add features not by extending the syntax but by >> adding messages I wondered if it could be done for string interpolation. >> The goal is to make the following work: >> > >> > | x y | >> > x := 123. >> > y := #foo. >> > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' >> interpolate. >> > >> > => 'It seems x equals 123 and y equals foo while Pi is still >> 3.141592653589793' >> > >> > Here is the implementation I came up with: >> > >> > String>>#interpolate >> > "Format the receiver by interpolating the evaluation of expressions >> > in between curly brackets in the context of the sender as in the >> following 3 oneline examples. >> > 'Today is {Date today}' interpolate. >> > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. >> > 'In {#strings} you can escape \{ by prefixing it with \\' >> interpolate." >> > >> > | senderContext | >> > senderContext := thisContext sender. >> > ^ self class new: self size streamContents: [ :out | | stream | >> > stream := self readStream. >> > [ stream atEnd ] whileFalse: [ | currentChar | >> > (currentChar := stream next) == ${ >> > ifTrue: [ | expression result | >> > expression := stream upTo: $}. >> > result := Compiler new >> > evaluate: expression in: senderContext to: nil notifying: >> nil ifFail: [ ^ nil ] logged: false. >> > out nextPutAll: result asString ] >> > ifFalse: [ >> > currentChar == $\ >> > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream >> next ] ] >> > ifFalse: [ out nextPut: currentChar ] ] ] ] >> > >> > It is a hack that could certainly be improved. And there is of course >> an obvious security problem. >> > >> > Thoughts ? >> > >> > 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 <+33%206%2052%2070%2066%2013> > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 3, 2017

Re: [Pharo-dev] String Interpolation

by Sven Van Caekenberghe

Nicolas, > On 28 Sep 2017, at 23:56, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi Sven, > for now it works because the context into which the block is executed still has full access to the variables and receiver of outer context from which the block is declared. > > But it's not necessarily the case in all dialects. > In VW for example, I get nil instead of foobar > #('loop on value 1 in nil' 'loop on value 2 in nil' 'loop on value 3 in nil') > > This is because the optimized block has its own method (a CompiledBlock) and a restricted context (a BlockContext). > The receiver is the BlockClosure and this closure has no copiedValues from the outerContext and an outerContext set to nil because some analyzer in the compilation phase thought the closure would never access the outerContext (no return to outerContext) nor any of its variable. > > Once we'll have clean blocks - depending on the implementation - things might change in Pharo too. > But we must ask Clement on this subject (I add not taken time to check the implementation he proposes). I think I understand: you basically say that the compiler could remove/optimise away local/temp variables if it decides they are not used, hence accessing them dynamically will fail. This could be compiler/dialect specific. That being said, such behaviour would also make the debugger look strange (assigned local/temp is in the source code but not in the context). In Pharo, even the following (currently) works fine: [ :x :y | '{x}+{y}={x+y}' interpolate ] value: 7 value: 8. Sven > 2017-09-28 19:03 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 28 Sep 2017, at 18:50, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > > > 2017-09-28 16:20 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi, > > > > I got into a little office discussion about string interpolation as it is done in different programming languages. > > > > In Pharo we have String>>#format: which is pretty nice. It works as follows: > > > > | x y | > > x := 123. > > y := #foo. > > 'x={1} and y={2}' format: { x. y }. > > > > It is also possible to use a dictionary with keys, like this: > > > > | x y | > > x := 123. > > y := #foo. > > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. > > > > But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings. > > > > Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work: > > > > | x y | > > x := 123. > > y := #foo. > > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate. > > > > => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793' > > > > Here is the implementation I came up with: > > > > String>>#interpolate > > "Format the receiver by interpolating the evaluation of expressions > > in between curly brackets in the context of the sender as in the following 3 oneline examples. > > 'Today is {Date today}' interpolate. > > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. > > 'In {#strings} you can escape \{ by prefixing it with \\' interpolate." > > > > | senderContext | > > senderContext := thisContext sender. > > ^ self class new: self size streamContents: [ :out | | stream | > > stream := self readStream. > > [ stream atEnd ] whileFalse: [ | currentChar | > > (currentChar := stream next) == ${ > > ifTrue: [ | expression result | > > expression := stream upTo: $}. > > result := Compiler new > > evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false. > > out nextPutAll: result asString ] > > ifFalse: [ > > currentChar == $\ > > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ] > > ifFalse: [ out nextPut: currentChar ] ] ] ] > > > > It is a hack that could certainly be improved. And there is of course an obvious security problem. > > > > Thoughts ? > > > > Sven > > > > > > Nice! > > The only objection I see is that it may fail in blocks if they don't know that they have to refer to outer context, especially once we have clean blocks > > Yes, there are probably some edge cases. Error handling is tricky too. > > > | outer | > > outer := 'foobar'. > > ^#( 1 2 3 ) collect: [:x | 'loop on value {x} in {outer}' interpolate] > > That example works for me in a Playground. How does it fail for you ? >

Oct. 3, 2017

Re: [Pharo-dev] [Ann] Class meta annotations

by Denis Kudriashov

2017-10-03 16:15 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Denis Kudriashov wrote > > I thought I explained it in my blog... But I know that I am a bad writer. > > Ah, sorry I forgot to re-read the blog and was trying to refresh my > understanding just based on this thread. I wouldn't say the post was poorly > written, just seemed to assume a prior familiarity with the inherent value > of class annotations. > > From what I understand, what you're describing sounds very Magritte-like. > Yes, Margitte class side descriptions can be implemented as ClassAnnotations. > What I don't understand is the difference between, for example: > > CmdCommand class>>#activators ^ self classAnnotations select: [ :each | > each isKindOf: CmdCommandActivationStrategy ] > In Commander we need to query all activation strategies which are defined for particular Command. So here we skip any other annotations. But the common case is to query all instances of concrete kind of activation strategy. For example to find shortcut for given keymap: CmdShortcutCommandActivation allAvailableInContext: aToolContext do: [:eachShortcutStrategy | eachShortcutStrategy keyCombination matches: aKey ] > and a <commandActivationStrategy> pragma which signifies a message > returning > an appropriate object. > I also thought that I explained it in the blog :). If you will use method pragma then you will repeat logic of this library: In your code you will need evaluate found pragma methods. You will need to handle broken methods. You will need to implement inheritance, how to correctly query overrides. And if performance is important you will need to implement kind of cache and invalidation logic. So ClassAnnotation solves these problems. All annotations are cached and cheap for queries: CmdShortcutCommandActivation registeredInstances == CmdShortcutCommandActivation registeredInstances. For example I have 187 annotation instances in Calypso. They should not be instantiated during lookup > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Oct. 3, 2017

Re: [Pharo-dev] MetaLink question

by Thierry Goubier

Hi Markus, 2017-10-03 16:45 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > > On 1 Oct 2017, at 14:58, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi, > > > > is there a way to look at a method code once it has been added metalinks? > > You can inspect the method. The best is to turn on # > optionCompileOnLinkInstallation > > (just add > > optionCompileOnLinkInstallation: true; > > to the link definition). > > This way the method is recompiled when installing the link, not on > execution. > > After you can inspect the method and look at the Bytecode / IR. > This is what I ended up doing: looking at the IR, understanding the code that the Metalink was generating (an #ensure:, since it was an after link) rewriting a similar code in smalltalk to check the IR differences, and finding out where it got it wrong. I solved this one by making it a weak after link (adding the weak whatever option). > > > I'm trying to add a metalink after the last statement of a block and it > fails on IR generation with an unknown temporary... > > > > If you have a test I can have a look, too > It was trying to add an after link to the last expression of a [:p | p + ml ] block in a #collect:. The mistake was that when writing the ensure (rewriting as [:p | [ p + ml ] ensure: [ link ] ] ), it would forget to add the temporary :p as a copied temp? into the [ p + ml ] block. The workaround was to ask it not to use an #ensure: block. Then I encountered more errors of that kind (IR generation errors) on very simple links (popping one time too much) and given that it took me a long time to find a workaround for the first one, that I could not find a workaround for the second one (#after, #instead, #before, #after weak wouldn't work), and that I was only at the third type of probes (out of about 20) I needed to do, I stopped there. Thierry > > Marcus >

Oct. 3, 2017

Re: [Pharo-dev] MetaLink question

by Marcus Denker

> On 1 Oct 2017, at 14:58, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi, > > is there a way to look at a method code once it has been added metalinks? You can inspect the method. The best is to turn on #optionCompileOnLinkInstallation (just add optionCompileOnLinkInstallation: true; to the link definition). This way the method is recompiled when installing the link, not on execution. After you can inspect the method and look at the Bytecode / IR. > I'm trying to add a metalink after the last statement of a block and it fails on IR generation with an unknown temporary... > If you have a test I can have a look, too Marcus

Oct. 3, 2017