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

Re: [Pharo-dev] Call for little tasks for GCI

by Stephane Ducasse

Hernan What we should see is that students will barely know how to program. So any solution is good. I think that we should ask really simple task. Stef On Fri, Sep 29, 2017 at 7:19 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Jigyasa, > > Thank you for the invitation. I read the letter, it looks interesting > for me to participate. > > However I have a question about how the students can solve the exercises. > Are they allowed to use any library or just limited to the packages > distributed in the standard Pharo image? > > Cheers, > > HernÃ¡n > > > > > 2017-09-28 14:41 GMT-03:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: >> Hello hernanmd, >> >> Please check out the link to the repository >> (github.com/jigyasa-grover/GCI-2017-with-Pharo) it should work for you, I >> added you as a collaborator. >> >> For more details on the contest and type of tasks to be created, please >> refer: >> 1. Resources in the repository >> 2. Invitation Letter >> (http://forum.world.st/Let-s-prepare-for-Google-Code-In-2017-with-Pharo-Cons…) >> >> Looking forward to significant contributions from your side ! >> >> Best Regrads >> Jigyasa Grover >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >

Sept. 29, 2017

Re: [Pharo-dev] Call for little tasks for GCI

by HernÃ¡n Morales Durand

Hi Jigyasa, Thank you for the invitation. I read the letter, it looks interesting for me to participate. However I have a question about how the students can solve the exercises. Are they allowed to use any library or just limited to the packages distributed in the standard Pharo image? Cheers, HernÃ¡n 2017-09-28 14:41 GMT-03:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: > Hello hernanmd, > > Please check out the link to the repository > (github.com/jigyasa-grover/GCI-2017-with-Pharo) it should work for you, I > added you as a collaborator. > > For more details on the contest and type of tasks to be created, please > refer: > 1. Resources in the repository > 2. Invitation Letter > (http://forum.world.st/Let-s-prepare-for-Google-Code-In-2017-with-Pharo-Cons…) > > Looking forward to significant contributions from your side ! > > Best Regrads > Jigyasa Grover > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 29, 2017

Re: [Pharo-dev] String Interpolation

by HernÃ¡n Morales Durand

Hi Sven, Is this one the similar to the #evaluate in http://www.squeaksource.com/evaluablestrings ? Cheers, HernÃ¡n 2017-09-28 11:20 GMT-03: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 > >

Sept. 29, 2017

Re: [Pharo-dev] String Interpolation

by Nicolas Cellier

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). 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@ > 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 ? >

Sept. 28, 2017

Re: [Pharo-dev] Iceberg Contribution Barrier

by Sean P. DeNigris

EstebanLM wrote > you do not need to update Iceberg Aha! After I successfully navigate your other instructions I'll update the readme EstebanLM wrote > I didnât submit the change because I donât know how to fork the wiki :P If it's the "official" way, should we just move it somewhere under the team? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 28, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Stephane Ducasse

Indeed we could. Coudl you add an issue? On Thu, Sep 28, 2017 at 12:43 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Why not make a backport to Pharo 6.1 with the new pinned message and provide it in a 60511 (last update is 60510 as of today). > I know it is effort but that way you can be compatible and use the new methods. > > Thanks > T. > > > Gesendet: Donnerstag, 28. September 2017 um 10:19 Uhr > Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo]) > > > > On 28 Sep 2017, at 10:01, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote: > > So it is integrated it Pharo 7 > > 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: > I did pull request for issue 20426[https://pharo.fogbugz.com/f/cases/20426/Better-pin-messages]. > > Interesting that Iceberg uses pinning in couple of places. I not touch it because it would not be single commit. And I have no idea how contribute in that case. I thing we are still in process to decide it. > Anyway old messages are deprecated and users will continue work with auto transformation. > > and we cannot just change it right now because for the moment we want iceberg to be loadable in Pharo 6.1. > so we will continue using deprecated messages until we drop compatibility. > > Esteban > > > 2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: > > > On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote: > > > > > Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: > > > Hello. > I guess we are agree to rename. I will prepare pull request for Pharo. And Squeak is up to you. > > Here is the new messages: > > - pinInMemory > - unpinInMemory > - isPinnedInMemory > - setPinnedInMemory: > > What was decision about #pinInMemoryDuring: ? Do we need it? > I understand Eliot in a way that there is no real point in unpinning objects. Hence pinDuring: is basically never useful and therefor adding a selectir has rather a negative impact > +1 > > > > > Norbert > > 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com[mailto:hannes.hirzel@gmail.com]>:+1 for pinInMemory > > It explains what it does. > > On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]> wrote: >> Hi Norbert, >> >>> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote: >>> >>> >>>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: >>>> >>>> Hi Denis, >>>> >>>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> >>>> wrote: >>>>> Hi Eliot. >>>>> >>>>> I know and I only talk about new messages. I am not trying to rethink >>>>> full meta model of Smalltalk. >>>>> By the way #class is very common message and it is handy to use short >>>>> name. But pinning messages will be used rarely in very specific >>>>> applications. So no much sense to preserve them in short version. >>>> >>>> Agreed. So we have to decide whether to go with pinInMemory or >>>> pinObject, pinObject being suggested by Norbert because it matched >>>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel >>>> strongly about pinObject et al? >>>> >>> No I don't. It feels only good to me if there is a requirement not to >>> implement selectors that are likely to be used in user code. I'm ok with >>> pinInMemory although I asked myself where can it be pinned elsewhere if >>> not in memory. So the suffix in memory doesn't add anything but also moves >>> the selector out of user space. >> >> Well I think Denis' point is that pinInMemory removes ambiguity with pin for >> other uses and I agree. So I for one am happy to change it to pinInMemory >> et al. >> >>> >>> Norbert >>> >>>>> >>>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: >>>>>> Hi Denis, >>>>>> >>>>>> >>>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> >>>>>>> wrote: >>>>>>> >>>>>>> I am really wonder guys. I thought you are not big funs of Object >>>>>>> protocol. >>>>>>> Current pinning messages are a new set of very generic messages in the >>>>>>> Object. >>>>>> >>>>>> Yes, and that's because this is a fundamental property of all >>>>>> non-immediate objects. Do you object to the #class message? Should it >>>>>> be #classObject because it might conflict with #class used in an >>>>>> educational or socioeconomic model? All objects other than immediates >>>>>> can move. Pinning stops that movement. It applies generally. So the >>>>>> protocol belongs in Object. >>>>>> >>>>>> >>>>>>> >>>>>>> About Norbert idea. >>>>>>> - bePinnedObject is not bad convention. But I would prefer the memory >>>>>>> suffix because it reflects the low level behaviour. >>>>>>> >>>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com[mailto:estebanlm@gmail.com]>: >>>>>>>> yes, me :) >>>>>>>> >>>>>>>> I do not see a reason to change them, tbh. >>>>>>>> for me they are comprensible as they are now and it does not adds >>>>>>>> more information pinInMemory or pinMemory. >>>>>>>> >>>>>>>> Esteban >>>>>>>> >>>>>>>> >>>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Anybody else? >>>>>>>>> >>>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >>>>>>>>> <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >>>>>>>>>> <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: >>>>>>>>>>> Hi. >>>>>>>>>>> >>>>>>>>>>> We now have very generic message names: >>>>>>>>>>> - pin >>>>>>>>>>> - unpin >>>>>>>>>>> - setPinned: >>>>>>>>>>> - isPinned >>>>>>>>>>> >>>>>>>>>>> Problem that they collide with possible domain related names. >>>>>>>>>>> For example I implemented pinning of tabs in Calypso and I found >>>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it with >>>>>>>>>>> different names. >>>>>>>>>>> Probably menus also uses pin word but without overrides >>>>>>>>>>> >>>>>>>>>>> What you think about renaming pinning messages? Something like: >>>>>>>>>>> - pinMemory >>>>>>>>>> >>>>>>>>>> I would use pinInMemory >>>>>>>>>> >>>>>>>>>> -- Pavel >>>>>>>>>> >>>>>>>>>>> - unpinMemory >>>>>>>>>>> - isMemoryPinned >>>>>>>>>>> - setPinnedMemory: >>>>>>>>>>> - pinMemoryDuring: (if we will introduce it) >>>>>>>>>>> >>>>>>>>>>> I think it is easy to do now because not much code uses pinning >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot >>> >> > >

Sept. 28, 2017

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

by Stephane Ducasse

Thanks On Thu, Sep 28, 2017 at 6:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-09-28 18:17 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 2017-09-25 17:57 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> 2017-09-25 17:38 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>>> I agree with guille. We should just called them class annotations. >>>> >>>> Denis what is a declared instance (is it an object returned by the >>>> method having the annotation) >>>> but can we find a better name. >>>> >>> >>> My idea that the method with pragma #classMetaAnnotation is the >>> declaration of annotation. Internally this declaration creates instance of >>> specified annotation which cached by system. And users access all these >>> declared instances for reflection purposes. >>> >>> >> Maybe #registeredInstances would be better? >> > > So I rename these messages too. I think it's better. > > >> >>> Also annotation has inst var declarationSelector. >>> >> >>> >>>> may be effectiveInstances? >>>> >>> >>> I don't like this name. I not understand "effective" in that context. >>> >>> >>>> >>>> >>>> On Mon, Sep 25, 2017 at 5:09 PM, Guillermo Polito < >>>> guillermopolito(a)gmail.com> wrote: >>>> >>>>> Why calling them meta-annotation and not just annotation? Annotations >>>>> are in general already meta :) >>>>> >>>>> On Mon, Sep 25, 2017 at 5:01 PM, Denis Kudriashov < >>>>> dionisiydk(a)gmail.com> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> I glad to present one class package which introduces reusable >>>>>> mechanism for first class annotations. >>>>>> >>>>>> The project can be found on github https://github.com/dion >>>>>> isiydk/ClassMetaAnnotation. >>>>>> And I tried to describe why it is needed in my blog >>>>>> http://dionisiydk.blogspot.fr/2017/09/class-meta-annotations.html. >>>>>> >>>>>> And here is overview: >>>>>> >>>>>> Every annotation should be subclass of ClassMetaAnnotation. To attach >>>>>> it to class you create new class side method which will return an instance >>>>>> of the annotation. Method should be marked with pragma #classMetaAnnotation: >>>>>> >>>>>> >>>>>> MyClass class>>specialAnnotation >>>>>> >>>>>> <classMetaAnnotation> >>>>>> >>>>>> ^MySpecialAnnotation new >>>>>> >>>>>> >>>>>> To query annotations from system there are two methods: >>>>>> >>>>>> 1) You can ask concrete annotation class for all declared instances: >>>>>> >>>>>> MySpecialAnnotation declaredInstances >>>>>> >>>>>> 2) You can ask given class for all attached annotations: >>>>>> >>>>>> MyClass metaAnnotations >>>>>> >>>>>> Every annotation includes information about annotated class and the >>>>>> selector of declaring method. >>>>>> All annotations are cached. So it is cheap to query them. There are >>>>>> extra messages to enumerate annotations using block. >>>>>> >>>>>> Now let's discuss it. I think it can be good addition for the Pharo >>>>>> 7. Especially that it is very small code. >>>>>> >>>>>> Also I would like to thank Marcus who helps me realize this concept >>>>>> in Commander and Calypso which I start simplify with this library. >>>>>> >>>>>> Best regards, >>>>>> Denis >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> 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> >>>>> >>>> >>>> >>> >> >

Sept. 28, 2017

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

by Stephane Ducasse

Yes. On Thu, Sep 28, 2017 at 6:17 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-09-25 17:57 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 2017-09-25 17:38 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> I agree with guille. We should just called them class annotations. >>> >>> Denis what is a declared instance (is it an object returned by the >>> method having the annotation) >>> but can we find a better name. >>> >> >> My idea that the method with pragma #classMetaAnnotation is the >> declaration of annotation. Internally this declaration creates instance of >> specified annotation which cached by system. And users access all these >> declared instances for reflection purposes. >> >> > Maybe #registeredInstances would be better? > > >> Also annotation has inst var declarationSelector. >> > >> >>> may be effectiveInstances? >>> >> >> I don't like this name. I not understand "effective" in that context. >> >> >>> >>> >>> On Mon, Sep 25, 2017 at 5:09 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Why calling them meta-annotation and not just annotation? Annotations >>>> are in general already meta :) >>>> >>>> On Mon, Sep 25, 2017 at 5:01 PM, Denis Kudriashov <dionisiydk(a)gmail.com >>>> > wrote: >>>> >>>>> Hi. >>>>> >>>>> I glad to present one class package which introduces reusable >>>>> mechanism for first class annotations. >>>>> >>>>> The project can be found on github https://github.com/dion >>>>> isiydk/ClassMetaAnnotation. >>>>> And I tried to describe why it is needed in my blog >>>>> http://dionisiydk.blogspot.fr/2017/09/class-meta-annotations.html. >>>>> >>>>> And here is overview: >>>>> >>>>> Every annotation should be subclass of ClassMetaAnnotation. To attach >>>>> it to class you create new class side method which will return an instance >>>>> of the annotation. Method should be marked with pragma #classMetaAnnotation: >>>>> >>>>> >>>>> MyClass class>>specialAnnotation >>>>> >>>>> <classMetaAnnotation> >>>>> >>>>> ^MySpecialAnnotation new >>>>> >>>>> >>>>> To query annotations from system there are two methods: >>>>> >>>>> 1) You can ask concrete annotation class for all declared instances: >>>>> >>>>> MySpecialAnnotation declaredInstances >>>>> >>>>> 2) You can ask given class for all attached annotations: >>>>> >>>>> MyClass metaAnnotations >>>>> >>>>> Every annotation includes information about annotated class and the >>>>> selector of declaring method. >>>>> All annotations are cached. So it is cheap to query them. There are >>>>> extra messages to enumerate annotations using block. >>>>> >>>>> Now let's discuss it. I think it can be good addition for the Pharo 7. >>>>> Especially that it is very small code. >>>>> >>>>> Also I would like to thank Marcus who helps me realize this concept in >>>>> Commander and Calypso which I start simplify with this library. >>>>> >>>>> Best regards, >>>>> Denis >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> 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> >>>> >>> >>> >> >

Sept. 28, 2017

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

by Stephane Ducasse

I would not use meta because you would not write annotationAnnotations :) and annotations is meta by its name. classAnnotation is much better than metaAnnotation Stef On Thu, Sep 28, 2017 at 5:40 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > So I renamed it to ClassAnnotation with all related names. > > But I keep meta prefix in #metaAnnotations Class extension to avoid > general name: > > MyClass metaAnnotations > > You can check updated readme for details https://github.com/ > dionisiydk/ClassAnnotation > > 2017-09-26 17:31 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> ;) >> >> On Tue, Sep 26, 2017 at 1:28 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> Shhh... The first rule of meta-club is we don't talk about meta-club. >>> >>> >>> cheers -ben >>> >>> >>> On Mon, Sep 25, 2017 at 11:09 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Why calling them meta-annotation and not just annotation? Annotations >>>> are in general already meta :) >>>> >>>> On Mon, Sep 25, 2017 at 5:01 PM, Denis Kudriashov <dionisiydk(a)gmail.com >>>> > wrote: >>>> >>>>> Hi. >>>>> >>>>> I glad to present one class package which introduces reusable >>>>> mechanism for first class annotations. >>>>> >>>>> The project can be found on github https://github.com/dion >>>>> isiydk/ClassMetaAnnotation. >>>>> And I tried to describe why it is needed in my blog >>>>> http://dionisiydk.blogspot.fr/2017/09/class-meta-annotations.html. >>>>> >>>>> And here is overview: >>>>> >>>>> Every annotation should be subclass of ClassMetaAnnotation. To attach >>>>> it to class you create new class side method which will return an instance >>>>> of the annotation. Method should be marked with pragma #classMetaAnnotation: >>>>> >>>>> >>>>> MyClass class>>specialAnnotation >>>>> >>>>> <classMetaAnnotation> >>>>> >>>>> ^MySpecialAnnotation new >>>>> >>>>> >>>>> To query annotations from system there are two methods: >>>>> >>>>> 1) You can ask concrete annotation class for all declared instances: >>>>> >>>>> MySpecialAnnotation declaredInstances >>>>> >>>>> 2) You can ask given class for all attached annotations: >>>>> >>>>> MyClass metaAnnotations >>>>> >>>>> Every annotation includes information about annotated class and the >>>>> selector of declaring method. >>>>> All annotations are cached. So it is cheap to query them. There are >>>>> extra messages to enumerate annotations using block. >>>>> >>>>> Now let's discuss it. I think it can be good addition for the Pharo 7. >>>>> Especially that it is very small code. >>>>> >>>>> Also I would like to thank Marcus who helps me realize this concept in >>>>> Commander and Calypso which I start simplify with this library. >>>>> >>>>> Best regards, >>>>> Denis >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> 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> >>>> >>> >>> >> >

Sept. 28, 2017

Re: [Pharo-dev] slow Pharo downloading and Travis

by Stephane Ducasse

We opened a new ticket. On Tue, Sep 26, 2017 at 8:45 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > I'm willing to do some other specific tests if needed. Just let me know. > > On Tue, Sep 26, 2017 at 3:36 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Thanks Gabriel I forwarded this to christophe. >> >> On Tue, Sep 26, 2017 at 12:01 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> >> wrote: >> > Still really slow from Argentina. >> > >> > In case it helps >> > >> > traceroute files.pharo.org >> > traceroute to files.pharo.org (128.93.162.72), 30 hops max, 60 byte >> > packets >> > 1 192.168.1.1 (192.168.1.1) 0.574 ms 0.968 ms 1.538 ms >> > 2 192.168.0.1 (192.168.0.1) 2.048 ms 2.499 ms 2.847 ms >> > 3 10.33.32.1 (10.33.32.1) 12.264 ms 14.160 ms 14.336 ms >> > 4 10.242.2.161 (10.242.2.161) 14.522 ms 14.643 ms 16.497 ms >> > 5 telecentro.baires3.bai.seabone.net (195.22.220.33) 18.936 ms >> > 19.575 ms >> > 18.843 ms >> > 6 ae0.baires3.bai.seabone.net (195.22.220.32) 19.554 ms 10.675 ms >> > 13.028 ms >> > 7 et10-1-0.miami15.mia.seabone.net (89.221.41.175) 246.284 ms >> > et9-3-0.miami15.mia.seabone.net (195.22.199.179) 246.214 ms >> > et4-3-0.miami15.mia.seabone.net (195.22.199.177) 246.137 ms >> > 8 gtt.miami15.mia.seabone.net (89.221.41.197) 245.909 ms 245.924 ms >> > 245.870 ms >> > 9 xe-3-1-2.cr0-par7.ip4.gtt.net (141.136.109.18) 251.632 ms 274.447 >> > ms >> > 250.097 ms >> > 10 renater-gw-ix1.gtt.net (77.67.123.206) 281.025 ms 259.509 ms >> > 261.717 >> > ms >> > 11 * * * >> > 12 inria-rocquencourt-te1-4-inria-rtr-021.noc.renater.fr >> > (193.51.184.177) >> > 271.263 ms 307.011 ms 306.876 ms >> > 13 * * * >> > 14 * * * >> > 15 * * * >> > 16 * * * >> > 17 * * * >> > 18 * * * >> > 19 * * * >> > 20 * * * >> > 21 * * * >> > 22 * * * >> > 23 * * * >> > 24 * * * >> > 25 * * * >> > 26 * * * >> > 27 * * * >> > 28 * * * >> > 29 * * * >> > 30 * * * >> > >> > httping -g http://files.pharo.org/get-files/61/pharo64.zip -c 20 >> > PING files.pharo.org:80 (/get-files/61/pharo64.zip): >> > connected to 128.93.162.72:80 (256 bytes), seq=0 time=625,90 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=1 time=842,02 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=2 time=638,83 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=3 time=637,63 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=4 time=637,85 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=5 time=580,27 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=6 time=1207,98 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=7 time=638,13 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=8 time=637,74 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=9 time=582,59 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=10 time=658,11 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=11 time=673,84 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=12 time=584,44 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=13 time=691,84 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=14 time=637,20 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=15 time=861,84 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=16 time=619,45 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=17 time=638,03 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=18 time=638,11 ms >> > connected to 128.93.162.72:80 (256 bytes), seq=19 time=741,01 ms >> > --- http://files.pharo.org/get-files/61/pharo64.zip ping statistics --- >> > 20 connects, 20 ok, 0,00% failed, time 33781ms >> > round-trip min/avg/max = 580,3/688,6/1208,0 ms >> > >> > >> > On Thu, Sep 21, 2017 at 12:13 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> Still seems a bit slow... >> >> http://files.pharo.org/get-files/70/pharo64.zip >> >> 16MB ==> 10 minutes (and actually it stalled after 3.4MB downloaded) >> >> Local speed test: 40Mb/s down, 20Mb/s up >> >> >> >> but then I'm a long way across the internet, the cause could be >> >> anywhere... >> >> $ traceroute files.pharo.org >> >> traceroute to files.pharo.org (128.93.162.72), 30 hops max, 60 byte >> >> packets >> >> 1 192.168.43.1 (192.168.43.1) 2.040 ms 2.403 ms 4.222 ms >> >> 2 * * * >> >> 3 * * * >> >> 4 Bundle-Ether14.wel-edge901.perth.telstra.net (139.130.16.49) >> >> 67.741 >> >> ms 67.739 ms 67.730 ms >> >> 5 bundle-ether6.wel-core3.perth.telstra.net (203.50.6.214) 67.696 ms >> >> 67.697 ms 67.697 ms >> >> 6 bundle-ether7.fli-core1.adelaide.telstra.net (203.50.11.18) 95.723 >> >> ms >> >> 91.753 ms 100.574 ms >> >> 7 bundle-ether9.win-core10.melbourne.telstra.net (203.50.11.91) >> >> 106.550 >> >> ms 108.849 ms 108.851 ms >> >> 8 bundle-ether12.ken-core10.sydney.telstra.net (203.50.11.122) >> >> 117.770 >> >> ms 117.767 ms 117.751 ms >> >> 9 bundle-ether1.pad-gw11.sydney.telstra.net (203.50.6.61) 117.720 ms >> >> 103.603 ms 102.171 ms >> >> 10 bundle-ether1.sydp-core04.sydney.reach.com (203.50.13.90) 93.276 >> >> ms >> >> 95.822 ms 102.577 ms >> >> 11 i-52.tlot-core02.bx.telstraglobal.net (202.84.137.101) 330.128 ms >> >> 321.231 ms 322.522 ms >> >> 12 i-0-4-0-10.tlot-core01.bi.telstraglobal.net (202.84.253.21) >> >> 321.187 >> >> ms i-0-2-0-10.tlot-core01.bi.telstraglobal.net (202.40.149.181) >> >> 321.181 ms >> >> i-0-2-0-9.tlot-core01.bi.telstraglobal.net (202.40.149.177) 308.786 ms >> >> 13 gtt-peer.tlot02.pr.telstraglobal.net (134.159.63.182) 273.784 ms >> >> 283.530 ms 281.079 ms >> >> 14 xe-1-2-0.cr0-par7.ip4.gtt.net (89.149.185.53) 466.648 ms 479.910 >> >> ms >> >> 481.254 ms >> >> 15 renater-gw-ix1.gtt.net (77.67.123.206) 479.900 ms 479.882 ms >> >> 478.641 ms >> >> 16 * * * >> >> 17 inria-rocquencourt-te1-4-inria-rtr-021.noc.renater.fr >> >> (193.51.184.177) >> >> 436.776 ms 479.819 ms 478.907 ms >> >> 18 * * * >> >> 19 * * * >> >> >> >> $ httping -h files.pharo.org >> >> PING files.pharo.org:80 (http://files.pharo.org:80/) >> >> connected to 128.93.162.72:80 (169 bytes), seq=0 time=970.27 ms >> >> connected to 128.93.162.72:80 (169 bytes), seq=1 time=928.26 ms >> >> connected to 128.93.162.72:80 (169 bytes), seq=2 time=860.06 ms >> >> connected to 128.93.162.72:80 (169 bytes), seq=3 time=976.04 ms >> >> connected to 128.93.162.72:80 (169 bytes), seq=4 time=1238.72 ms >> >> connected to 128.93.162.72:80 (169 bytes), seq=5 time=1239.65 ms >> >> connected to 128.93.162.72:80 (169 bytes), seq=6 time=918.06 ms >> >> >> >> >> >> cheers -ben >> >> >> >> On Thu, Sep 21, 2017 at 5:43 PM, Marcus Denker <marcus.denker(a)inria.fr> >> >> wrote: >> >>> >> >>> >> >>> > On 18 Sep 2017, at 08:37, Marcus Denker <marcus.denker(a)inria.fr> >> >>> > wrote: >> >>> > >> >>> > >> >>> >> On 16 Sep 2017, at 09:40, Stephane Ducasse >> >>> >> <stepharo.self(a)gmail.com> >> >>> >> wrote: >> >>> >> >> >>> >> Hi marcus >> >>> >> >> >>> >> I do not see why they could not find it. >> >>> >> Can you tell me how you ask because we should reask? >> >>> >> >> >>> >> >> >>> > >> >>> > I spend a ticket and they wanted to close it last week. I have told >> >>> > them to not close it >> >>> > >> >>> The problems seems to be fixed now. >> >>> >> >>> If someone sees any slowness -> send me a mail. >> >>> >> >>> Marcus >> >>> >> >>> >> >> >> > >> >

Sept. 28, 2017