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

Re: [Pharo-dev] Never-ending computations and cmd-dot

by Stephane Ducasse

Hi hernan Indeed it would be nice to have a solution for such case. Now we did not look at it. Stef On Tue, Sep 26, 2017 at 5:58 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Tim, > > Yes, I am aware of such menu item. However I would like to know if > someone is working in a more architectural solution. > Because I guess this would imply to hook message sends into the main > feedback loop. > > Cheers, > > HernÃ¡n > > > 2017-09-25 20:08 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: >> Its not quite what you are asking for, but if you right click on one of those windows, someone has helpfully added a âclose all windows to rightâ option, which does let you rapidly get rid of them. >> >> Tim >> >>> On 25 Sep 2017, at 23:16, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>> >>> Hi, >>> >>> Guys I have the situation you will recognize in the attached picture: >>> A never-ending recursive computation which generate zillions of >>> pre-debug windows when cmd-dot key is pressed. >>> >>> Is there any setting, or any way to put a monitor to detect that >>> cmd-dot is creating too many windows so will pop-up just one or two? >>> Maybe someone researched this issue, does it makes sense? >>> >>> Cheers, >>> >>> HernÃ¡n >>> <rw.png> >> >> >

Sept. 27, 2017

Scraping HTML chapter 2 (soon chapter 3 coming)

by Stephane Ducasse

I came with the idea of this booklet thank to Peter Kenny that kindly answered a question on the Pharo mailing-list. To help, Peter showed to a Pharoer how to scrap a web site using XPath. In addition, some years ago I was maintaining Soup a scraping framework because I was scraping magic web sites and I wanted an application to manage my magic cards. Since then I always wanted to try XPath and in addition I wanted to offer this booklet to Peter. Why because I asked Peter if he would like to write something and he told that he was at a great age where he would not take any commitment. I realised that I would like to get as old as him and be able to hack like a mad in Pharo with new technology. So this booklet is a gift to Peter, a great and gentle Pharoer. Stef

Sept. 27, 2017

[Pharo 7.0-dev] Build #159: 20430-Move-kernel-tests-that-use-compiler-to-a-standalone-package

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

There is a new Pharo build available! The status of the build #159 was: SUCCESS. The Pull Request #289 was integrated: "20430-Move-kernel-tests-that-use-compiler-to-a-standalone-package" Pull request url: https://github.com/pharo-project/pharo/pull/289 Issue Url: https://pharo.fogbugz.com/f/cases/20430 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 27, 2017

Call for little tasks for GCI

by Stephane Ducasse

Hi guys We want to compete to a competition for newbies programming. We need to have at least 50 tasks. Right now the tasks are quite difficult to me :) Please help to get some tasks. I can be taken from exercisism.io or other little math problems. - Grab the Pharo logo from url and display it - We can turn some of the mooc challenges into tasks. http://mooc.pharo.org I have some ideas but I need your help because I want to finish the new chapter and book. https://github.com/jigyasa-grover/GCI-2017-with-Pharo Stef

Sept. 26, 2017

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

by Gabriel Cotelli

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. 26, 2017

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

by Stephane Ducasse

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. 26, 2017

Re: [Pharo-dev] XPath chapter...

by Stephane Ducasse

The problem is that people really like when others write documentation. You see I did not know at all what was XPath before starting to write this chapter. Stef On Tue, Sep 26, 2017 at 3:14 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > ghoetker wrote >> Thank you, Stef, for providing this (and all else you do). As a very new >> user, I agree completely with your comment about the importance of >> documentation. > > +100!!! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 26, 2017

[Pharo 7.0-dev] Build #158: 19142-Update-Slots-class-comments-ie-AbstractLayout

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

There is a new Pharo build available! The status of the build #158 was: SUCCESS. The Pull Request #316 was integrated: "19142-Update-Slots-class-comments-ie-AbstractLayout" Pull request url: https://github.com/pharo-project/pharo/pull/316 Issue Url: https://pharo.fogbugz.com/f/cases/19142 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2017

Re: [Pharo-dev] STON question :)

by Stephane Ducasse

On Tue, Sep 26, 2017 at 1:15 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Stef, > >> On 24 Sep 2017, at 12:26, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi Sven >> >> For Moose we are wondering if we can use STON to save/load models >> instead of MSE. >> - I'm sure we can :) >> >> Now my little friends would like to kill two or three birds with the >> same stone :) >> >> Would it be possible to use STON to handle cycles but to generate JSON >> compatible >> in the following sense: >> >> Class { >> "id": 123, >> "name" : "A" >> } >> >> => >> >> { >> "id": 123, >> "type" : "Class", >> "name" : "A" >> } >> >> It means that we could be able to output an extra field and when we >> read that the materialiser >> would create an entity based on the type field for example. >> >> Am I thinking something totally wrong? > > I am not sure how to answer. > > It should be possible to use STON as it is, no ? No because they want to have JSON syntax ie. { "id": 123, "type" : "Class", "name" : "A" } and not Class { "id": 123, "name" : "A" } > JSON is different, as you know. NeoJSON was not designed to work with such dynamic types, its optional mapping mechanism works with a static type map. > STON is a format with an implementation, it is not designed as a general purpose object visitor. To me STON is nearly what we need - handling cycles - nearly JSON But else we will have to redo our own way to handle cycles again so this is why if we could avoid it would be good. > > Sven > >> Stef >

Sept. 26, 2017

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

by Stephane Ducasse

;) 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. 26, 2017