- Pharo-dev - lists.pharo.org

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

by Henrik Sperre Johansen

Denis Kudriashov wrote > 2017-10-04 11:56 GMT+02:00 Henrik Sperre Johansen < > henrik.s.johansen@ >>: > >> Denis Kudriashov wrote >> > Generally it is same like having pragma with parameters. >> > But with annotation you are not restricted by literal objects. So >> > annotation parameters can be anything. >> > >> > And it is important feature for Commander. >> > For example I need instance of KMKeyCombination to define shortcut for >> > command. So I just use normal expression for this: >> > >> > RenamePackageCommand class>>packageBrowserShortcutActivation >> > > <classAnnotation> >> > ^CmdShortcutCommandActivation by: *$r meta* for: >> ClyPackageBrowserContext >> > >> > >> > It will be very complicated to express it with method pragma and it >> will >> > be >> > restricted anyway. >> >> Would it? >> With pure method tags, you'd do something like: >> SomeClass >> #renamePackage: aPackage >> > <command: 'Rename package' >> > category: 'Package' >> order: 25 >> shortcut: #($r meta)> >> ... method renaming package here ... > > Then have different pragma traversers capable of creating the actual menus > / >> commands invoking such methods. >> > > So instead of simple subclassing of ClassAnnotation you would suggest me > to > implement pragma traversal/interpreter? > I would prefer first. It gives me for free the object with any structure > without any tricky literal interpretation logic. > For me annotation is just obviously simpler solution. A traverser doesn't have to be a lot of work; http://forum.world.st/Having-comments-for-pragma-tp4902987p4903058.html Denis Kudriashov wrote > Also try to think how to support blocks in parameters with pragma > approach. > And how fun would be to debug them. > It is for the question about > "restricted anyway". You wouldn't need them. What to do with the tag, is up to the traverser. For instance, #perform'ing one of the literal args on the domain class traverser creates, returning an appropriate block, if strictly necessary. Denis Kudriashov wrote > Really, with annotations you have normal smalltalk > code for annotating classes. No magic. And implementation is really > simple. Same with a traverser; the normal smalltalk code to create your domain objects is simply in a different place; the traverser part of the package defining said domain, rather than as an extension method marked with a tag. I guess it's best to just agree to disagree, and since you're the one implementing... ;) Looking forward to trying it out! Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 4, 2017

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

by Denis Kudriashov

2017-10-04 11:56 GMT+02:00 Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no>: > Denis Kudriashov wrote > > Generally it is same like having pragma with parameters. > > But with annotation you are not restricted by literal objects. So > > annotation parameters can be anything. > > > > And it is important feature for Commander. > > For example I need instance of KMKeyCombination to define shortcut for > > command. So I just use normal expression for this: > > > > RenamePackageCommand class>>packageBrowserShortcutActivation > > <classAnnotation> > > ^CmdShortcutCommandActivation by: *$r meta* for: ClyPackageBrowserContext > > > > > > It will be very complicated to express it with method pragma and it will > > be > > restricted anyway. > > Would it? > With pure method tags, you'd do something like: > SomeClass >> #renamePackage: aPackage > <command: 'Rename package' > category: 'Package' > order: 25 > shortcut: #($r meta)> > ... method renaming package here ... Then have different pragma traversers capable of creating the actual menus / > commands invoking such methods. > So instead of simple subclassing of ClassAnnotation you would suggest me to implement pragma traversal/interpreter? I would prefer first. It gives me for free the object with any structure without any tricky literal interpretation logic. For me annotation is just obviously simpler solution. Also try to think how to support blocks in parameters with pragma approach. And how fun would be to debug them. It is for the question about "restricted anyway". Really, with annotations you have normal smalltalk code for annotating classes. No magic. And implementation is really simple. (And yes, all caching/invalidation would be the responsibility of the > traverser(s) if necessary, as usual) > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Oct. 4, 2017

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

by Henrik Sperre Johansen

Denis Kudriashov wrote > 2017-10-04 9:48 GMT+02:00 Guillermo Polito < > guillermopolito@ > >: > >> I'd even call them First class pragmas from that point of view :P >> > > Yes. > But we decided avoid pragma related names here. Because in future it can > be > possible to add normal pragmas into the class definition. > > >> >> I wonder what are the side-effects of instantiating the annotation >> yourself in a method. >> >> specialAnnotationExample >> > <classAnnotation> >> ^MySpecialAnnotation new >> > > I not understand the question. You supposed to return an *instance* of the > annotation from the "annotating method". > > >> >> I mean, I understand we can use the class state to initialize the >> annotation. But the fact that the annotation is cached after its first >> instantiation means that the annotation will not necessarily evolve as >> the >> class evolves. >> > > Cache is updated after related class changes: method added, removed and so > on (driven by PragmaCollector logic). So outdated annotations should not > exist. > Is it what you ask? > > >> Do we want annotations to be stateless? Or depend only in literals? >> > > I want annotations to be any object with any state inside. Of course you > will be restricted by what is visible from the class side. But in > "annotating method" you can create any complex object (see below). > > >> I wonder then what is the main difference with >> >> specialAnnotationExample >> > <classAnnotation: MySpecialAnnotation> >> >> And what is the impact of having an annotation with parameters. >> > > Generally it is same like having pragma with parameters. > But with annotation you are not restricted by literal objects. So > annotation parameters can be anything. > > And it is important feature for Commander. > For example I need instance of KMKeyCombination to define shortcut for > command. So I just use normal expression for this: > > RenamePackageCommand class>>packageBrowserShortcutActivation > <classAnnotation> > ^CmdShortcutCommandActivation by: *$r meta* for: ClyPackageBrowserContext > > > It will be very complicated to express it with method pragma and it will > be > restricted anyway. Would it? With pure method tags, you'd do something like: SomeClass >> #renamePackage: aPackage <command: 'Rename package' category: 'Package' order: 25 shortcut: #($r meta)> ... method renaming package here ... Then have different pragma traversers capable of creating the actual menus / commands invoking such methods. (And yes, all caching/invalidation would be the responsibility of the traverser(s) if necessary, as usual) Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 4, 2017

Re: [Pharo-dev] String Interpolation

by Denis Kudriashov

Hi Igor. Did you see that we have now #asMethodConstant? DateAndTime now asMethodConst It is not compiled time but behaviour is very close to it. The trick is that first time execution will replace full expression with the result as literal (the receiver of #asMethodConst). So at second time it will be just literal reading. 2017-10-04 11:36 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > IMO, best would be to make it via compiler plugin. > > Same, as i proposed for object literals, > a compiler could detect a pattern <string literal> interpolate > and replace it at compile time to produce/expand it into proper > context-aware semantic, something like this: > > {'a' . x . 'b' . y. 'c' .z } gather: #asString > > That will allow to eliminate run-time security risk(due to #evaluate:), as > well as run-time execution cost, > and allows a nice and convenient and clean syntax. > > Without compiler modification, it's hard to reach best security & > performance & convenience ideals. > > > > On 4 October 2017 at 11:06, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >> >> >> 2017-10-04 9:50 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> if the compiler plugin correctly models such special syntax with special >>> AST nodes, that could be even possible without much effort >>> >> >> Interesting. Would that imply that by having those special ast nodes, we >> would get the decompilation working for the debugger? >> >> Thierry >> >> >> >> >>> >>> On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> >>>> 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 >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> 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> >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

Oct. 4, 2017

Re: [Pharo-dev] String Interpolation

by Sven Van Caekenberghe

> On 4 Oct 2017, at 11:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > > IMO, best would be to make it via compiler plugin. > > Same, as i proposed for object literals, > a compiler could detect a pattern <string literal> interpolate Which means the #interpolate message send is compiled away, right ? So no guessing by the compiler, no new syntax ? Sounds like a good idea. > and replace it at compile time to produce/expand it into proper context-aware semantic, something like this: > > {'a' . x . 'b' . y. 'c' .z } gather: #asString > > That will allow to eliminate run-time security risk(due to #evaluate:), as well as run-time execution cost, > and allows a nice and convenient and clean syntax. > > Without compiler modification, it's hard to reach best security & performance & convenience ideals. > > > > On 4 October 2017 at 11:06, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2017-10-04 9:50 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > if the compiler plugin correctly models such special syntax with special AST nodes, that could be even possible without much effort > > Interesting. Would that imply that by having those special ast nodes, we would get the decompilation working for the debugger? > > Thierry > > > > > On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13 > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > > > > -- > > 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13 > > > > > -- > Best regards, > Igor Stasenko.

Oct. 4, 2017

Re: [Pharo-dev] String Interpolation

by Igor Stasenko

IMO, best would be to make it via compiler plugin. Same, as i proposed for object literals, a compiler could detect a pattern <string literal> interpolate and replace it at compile time to produce/expand it into proper context-aware semantic, something like this: {'a' . x . 'b' . y. 'c' .z } gather: #asString That will allow to eliminate run-time security risk(due to #evaluate:), as well as run-time execution cost, and allows a nice and convenient and clean syntax. Without compiler modification, it's hard to reach best security & performance & convenience ideals. On 4 October 2017 at 11:06, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2017-10-04 9:50 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> if the compiler plugin correctly models such special syntax with special >> AST nodes, that could be even possible without much effort >> > > Interesting. Would that imply that by having those special ast nodes, we > would get the decompilation working for the debugger? > > Thierry > > > > >> >> On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> 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 >>>>> >>>> >>>> >>> >> >> >> -- >> >> >> >> 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> >> > > -- Best regards, Igor Stasenko.

Oct. 4, 2017

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

by Denis Kudriashov

2017-10-04 9:48 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > I'd even call them First class pragmas from that point of view :P > Yes. But we decided avoid pragma related names here. Because in future it can be possible to add normal pragmas into the class definition. > > I wonder what are the side-effects of instantiating the annotation > yourself in a method. > > specialAnnotationExample > <classAnnotation> > ^MySpecialAnnotation new > I not understand the question. You supposed to return an *instance* of the annotation from the "annotating method". > > I mean, I understand we can use the class state to initialize the > annotation. But the fact that the annotation is cached after its first > instantiation means that the annotation will not necessarily evolve as the > class evolves. > Cache is updated after related class changes: method added, removed and so on (driven by PragmaCollector logic). So outdated annotations should not exist. Is it what you ask? > Do we want annotations to be stateless? Or depend only in literals? > I want annotations to be any object with any state inside. Of course you will be restricted by what is visible from the class side. But in "annotating method" you can create any complex object (see below). > I wonder then what is the main difference with > > specialAnnotationExample > <classAnnotation: MySpecialAnnotation> > > And what is the impact of having an annotation with parameters. > Generally it is same like having pragma with parameters. But with annotation you are not restricted by literal objects. So annotation parameters can be anything. And it is important feature for Commander. For example I need instance of KMKeyCombination to define shortcut for command. So I just use normal expression for this: RenamePackageCommand class>>packageBrowserShortcutActivation <classAnnotation> ^CmdShortcutCommandActivation by: *$r meta* for: ClyPackageBrowserContext It will be very complicated to express it with method pragma and it will be restricted anyway. Another important point is that class annotation is first class object which means that you can add behaviour to it. With method pragma you can not. For example shortcut annotation includes method to check given key event and execute command if it is satisfied. Is it now clear? > On Tue, Oct 3, 2017 at 9:02 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Denis Kudriashov wrote >> > If you will use method pragma then you will repeat logic of this >> library: >> > In your code you will need... >> >> So it sounds like it's pragmas++ - the functionality of pragmas plus some >> other stuff you may need that you'd have to roll on your own >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> > > > -- > > > > 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> >

Oct. 4, 2017

Re: [Pharo-dev] String Interpolation

by Thierry Goubier

2017-10-04 9:50 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > if the compiler plugin correctly models such special syntax with special > AST nodes, that could be even possible without much effort > Interesting. Would that imply that by having those special ast nodes, we would get the decompilation working for the debugger? Thierry > > On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 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 >>>> >>> >>> >> > > > -- > > > > 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> >

Oct. 4, 2017

Re: [Pharo-dev] String Interpolation

by Guillermo Polito

if the compiler plugin correctly models such special syntax with special AST nodes, that could be even possible without much effort On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 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 >>> >> >> > -- 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

Oct. 4, 2017

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

by Guillermo Polito

I'd even call them First class pragmas from that point of view :P I wonder what are the side-effects of instantiating the annotation yourself in a method. specialAnnotationExample <classAnnotation> ^MySpecialAnnotation new I mean, I understand we can use the class state to initialize the annotation. But the fact that the annotation is cached after its first instantiation means that the annotation will not necessarily evolve as the class evolves. Do we want annotations to be stateless? Or depend only in literals? I wonder then what is the main difference with specialAnnotationExample <classAnnotation: MySpecialAnnotation> And what is the impact of having an annotation with parameters. On Tue, Oct 3, 2017 at 9:02 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Denis Kudriashov wrote > > If you will use method pragma then you will repeat logic of this library: > > In your code you will need... > > So it sounds like it's pragmas++ - the functionality of pragmas plus some > other stuff you may need that you'd have to roll on your own > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- 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

Oct. 4, 2017