August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Denis Kudriashov

2016-08-30 10:21 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: > Hi, > > From the top of my head: I would understand that systems where there are > hundreds of thousands of events per second, maybe one does not want to pay > the overhead of announcements... > > But, How many events are produced from a morph per second? One? Two? Five? > Is it really the case of morphs the one that require optimization? > I have similar feeling. But maybe Spec is nice example which could improved by such optimizations

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Guille Polito

Hi, From the top of my head: I would understand that systems where there are hundreds of thousands of events per second, maybe one does not want to pay the overhead of announcements... But, How many events are produced from a morph per second? One? Two? Five? Is it really the case of morphs the one that require optimization? -------- Original Message -------- > > > 2016-08-30 9:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > > I think for the 0 case we should think about instantiating the > SubscriptionRegistry lazily. This would also mitigate the > effect that if a lot of announcers are created they create > only a single object instead of two until used. Of course this > depends on the probability of having a lot of announcers where > only a few are used. > The #announce: method looks like it has been lazy before. > > Announcer>>#announce: anAnnouncement > > | announcement | > announcement := anAnnouncement asAnnouncement. > registry ifNotNil: [ > registry deliver: announcement > ]. > ^ announcement > > checks for #ifNotNil: but registry is created in #initialize. > So #ifNotEmpty: would be right here but #deliver: checks that, > too. > > > We always hide announcer instance inside owner. So it could > instantiate announcer lazily if such optimization really needed. > > > I remember making sure this was the case for Morph instances. If no > subscriber, no announcer and make sure announcing something doesn't > create the announcer lazily. > > Thierry

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Thierry Goubier

2016-08-30 9:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > >> I think for the 0 case we should think about instantiating the >> SubscriptionRegistry lazily. This would also mitigate the effect that if a >> lot of announcers are created they create only a single object instead of >> two until used. Of course this depends on the probability of having a lot >> of announcers where only a few are used. >> The #announce: method looks like it has been lazy before. >> >> Announcer>>#announce: anAnnouncement >> >> | announcement | >> announcement := anAnnouncement asAnnouncement. >> registry ifNotNil: [ >> registry deliver: announcement >> ]. >> ^ announcement >> >> checks for #ifNotNil: but registry is created in #initialize. So >> #ifNotEmpty: would be right here but #deliver: checks that, too. >> > > We always hide announcer instance inside owner. So it could instantiate > announcer lazily if such optimization really needed. > I remember making sure this was the case for Morph instances. If no subscriber, no announcer and make sure announcing something doesn't create the announcer lazily. Thierry

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Denis Kudriashov

2016-08-30 9:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > >> I think for the 0 case we should think about instantiating the >> SubscriptionRegistry lazily. This would also mitigate the effect that if a >> lot of announcers are created they create only a single object instead of >> two until used. Of course this depends on the probability of having a lot >> of announcers where only a few are used. >> The #announce: method looks like it has been lazy before. >> >> Announcer>>#announce: anAnnouncement >> >> | announcement | >> announcement := anAnnouncement asAnnouncement. >> registry ifNotNil: [ >> registry deliver: announcement >> ]. >> ^ announcement >> >> checks for #ifNotNil: but registry is created in #initialize. So >> #ifNotEmpty: would be right here but #deliver: checks that, too. >> > > We always hide announcer instance inside owner. So it could instantiate > announcer lazily if such optimization really needed. Interesting is slots allow to implement such pattern? I imagine AnnouncerSlot which will generate "read code" specifically depending on following message send.

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Denis Kudriashov

Hi 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > I think for the 0 case we should think about instantiating the > SubscriptionRegistry lazily. This would also mitigate the effect that if a > lot of announcers are created they create only a single object instead of > two until used. Of course this depends on the probability of having a lot > of announcers where only a few are used. > The #announce: method looks like it has been lazy before. > > Announcer>>#announce: anAnnouncement > > | announcement | > announcement := anAnnouncement asAnnouncement. > registry ifNotNil: [ > registry deliver: announcement > ]. > ^ announcement > > checks for #ifNotNil: but registry is created in #initialize. So > #ifNotEmpty: would be right here but #deliver: checks that, too. > We always hide announcer instance inside owner. So it could instantiate announcer lazily if such optimization really needed.

Aug. 30, 2016

Re: [Pharo-dev] [Phratch] Re: Phratch on Ubuntu

by jannik laval

Il est possible que le repository ait Ã©tÃ© nettoyÃ© un peu rapidement. Quelqu'un peut confirmer (damien ?) Vous pouvez tÃ©lÃ©charger l'archive sur le site de phratch et l'installer manuellement (http://www.phratch.com/phratch/phratchinstall) Cette version, je suis sÃ»r qu'elle fonctionne. Bien cordialement, Jannik 2016-08-27 18:38 GMT+02:00 Jean Bernard ETIEVE <jb.etieve(a)gmail.com>: > J'ai l'erreur suivante aprÃ¨s avoir fait le 2 premiÃ¨res lignes et lancer > sudo apt-get install phratch > > > > > *Lecture des listes de paquets... FaitConstruction de l'arbre des > dÃ©pendances Lecture des informations d'Ã©tat... FaitE: Impossible de > trouver le paquet phratch* > *Impossible de trouver le paquet phratch* > > Si quelquâun a une idÃ©e, je suis preneur.... > > On Wednesday, March 19, 2014 at 4:57:58 PM UTC+1, Jannik Laval wrote: >> >> Dear Community, >> >> Thanks to Damien Cassou, Phratch can now be installed on Ubuntu using >> apt-get. >> >> If you are an Ubuntu user on 12.10, 13.10 or 14.04, you can very easily >> install Phratch. You have to add the Pharo PPA (ppa:pharo/stable) and >> install Phratch by issuing these commands: >> >> $ sudo add-apt-repository ppa:pharo/stable >> $ sudo apt-get update >> $ sudo apt-get install phratch >> >> Then just run >> >> $ phratch >> >> Thank you again Damien ! >> -- >> >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://car.mines-douai.fr/ >> > -- > You received this message because you are subscribed to the Google Groups > "phratch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to phratch+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- ~~Jannik Laval~~ Enseignant-chercheur Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me d'Information IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re laboratoire DISP http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info

Aug. 30, 2016

Re: [Pharo-dev] [SO] X-509 certificates

by Norbert Hartl

For everyone that does not know what X.509 means just read SSL instead of X.509 where it occurs. I've uploaded a piece of code that is on my disk for too long. The project can be found in http://smalltalkhub.com/#!/~NorbertHartl/X509 <http://smalltalkhub.com/#!/~NorbertHartl/X509> The implementation is pretty basic. It only shows how the ASN.1 suite can be used to read something like a X.509 certificate. If some gets used to the object model beneath reading and creating structures like a X.509 certificate. Reading can be done doing X509 readCertificateFromPEM: '/path/to/pem/file.pem' asFileReference readStream At the moment only PEM/BER format is supported. Others might come in the future. FYI, Norbert > Am 30.08.2016 um 07:00 schrieb Max Leske <maxleske(a)gmail.com>: > > http://stackoverflow.com/questions/39210105/x-509-certificate-operations-wi…

Aug. 30, 2016

Re: [Pharo-dev] Binary selector and special characters

by Nicolai Hess

2016-08-29 21:38 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 29/08/2016 Ã 21:28, stepharo a Ã©crit : > >> >> >> Le 29/8/16 Ã 17:45, Thierry Goubier a Ã©crit : >> >>> Hi Stef, >>> >>> 2016-08-29 11:42 GMT+02:00 stepharo <stepharo(a)free.fr >>> <mailto:stepharo@free.fr>>: >>> >>> Thierry >>> >>> If you have a better editor control even better :) >>> >>>> >>>> Syntax wise, one could consider "" to be inside a comment (i.e. >>>> do not split into two comments if encountered inside a comment, >>>> as it is done now). >>>> >>> This one could be nice too :) >>> >>> >>> https://pharo.fogbugz.com/f/cases/19011/Integrate-two-doubl >>> e-quotes-inside-comments >>> >>> I'll have the slice ready soon. Any comments on what that would mean >>> regarding the Smalltalk commonly accepted syntax if that feature is >>> integrated? >>> >> It will break compatibility for people using it now we should raise the >> topic and lets a chance to people to discuss about it. We could check >> before publishing if code contain nested comments. >> > > Hum. The slice should parse anything legal Smalltalk; just that it may > show less comments intervals (because in fact it will coalesce adjacent > comments). > Yes, I think the change for RBScanner is fine, it does not changes what kind of comments are accepted, only how they are assigned to the AST nodes (one vs. multiple comments). (BTW. do we have a function that would do the coalescing of intervals: (1 to:99) (100 to: 199) -> (1 to:199) ? ) > > For example, standard parse will say that: > > '"this ""test"' is a token with two comments, intervals 1 to: 7 and 8 to: > 13. > > The slice makes that a single comment: > > '"this ""test"' is a token with one comment, interval 1 to: 13. > > Now, this has probably no impact on parsing smalltalk code. But it changes > a bit the language definition, so that's why I'd like comments on it. > > I think that I would use them only when developing. >> > > Up to you :) > > The most interesting is to have the correct comment/uncomment behavior in > an editor... that one works independently and is quite cool. > > Thierry > > Stef >> >> >>> Thierry >>> >>> >> > >

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Norbert Hartl

> Am 30.08.2016 um 06:38 schrieb Stephan Eggermont <stephan(a)stack.nl>: > > On 29/08/16 22:37, Denis Kudriashov wrote: >> It looks quite safe to not check anything because subscription items are >> instances of AnnouncementSubscription which are created internally >> inside Announcer during subscription > > We should probably do something special for 0 and 1 subscriptions. > I think for the 0 case we should think about instantiating the SubscriptionRegistry lazily. This would also mitigate the effect that if a lot of announcers are created they create only a single object instead of two until used. Of course this depends on the probability of having a lot of announcers where only a few are used. The #announce: method looks like it has been lazy before. Announcer>>#announce: anAnnouncement | announcement | announcement := anAnnouncement asAnnouncement. registry ifNotNil: [ registry deliver: announcement ]. ^ announcement checks for #ifNotNil: but registry is created in #initialize. So #ifNotEmpty: would be right here but #deliver: checks that, too. For the 1 case we could store a single subscription in the registry field. Both subscription and registry have the #deliver: method so this would work out of the box. We could just dispatch the method. So without having measured it myself it could be good if - registry is nil if no subscribers are present. With nil checks the Announcer code could go fast - registry is a subscription in case of 1 subscriber. No need for #subscriptionsHandling: because check is directly on the subscription for #handlesAnnouncement: This should save some cycles and the creation of intermediate collections. With not using the SubscriptionRegistry there is also no #critical: section saving the creation of one. - registry is SubscriptionRegistry in case of >1 subscribers my two cents, Norbert

Aug. 30, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by stepharo

Le 29/8/16 Ã 21:37, Tudor Girba a Ã©crit : > Hi Denis, > > Thanks a lot for this analysis! > > In summary, the Bloc events are faster because: > 1. they store the subscriptions in OrderedCollection instead of IdentitySet. This is likely something we can improve in Announcements. > 2. they are unsafe. > > For 1., the only reason I can think of is to prevent the user to register twice the same object by mistake. I think this is an optimization that should be the responsibility of the user. It depends of the contract. Since we want to have a solid architecture then it should not be the responsibility of the client to me. > > For 2. the question is if Bloc really does not need the mutex. > > Cheers, > Doru > > > >> On Aug 29, 2016, at 6:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> And expenses to deliver announcement caused also by protection and usage of IdentitySet. >> Also in announcements we first collect all subscriptions with interest to separate collection and only after we iterate and process given announcement. >> >> But in Bloc you use #select:thenDo: method instead. It is unsafe because event handlers can be modified during delivering (by producing new subscriptions or by unsubscribing inside handlers). >> >> So if you want to address it (and I sure you do) it will lead to same code and performance of announcements. >> >> >> >> >> 2016-08-29 18:05 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> Thank's. >> I try tests for subscribing and what I found is: >> >> Main problem that subscriptions inside SubscriptionRegistry are managed as IdentitySet which of cause much slower for addition then OrderedCollection. We probably could use OrderedCollection here because items are always created on fly and identitySet has no sense. >> >> Another problem is access protection by mutex (semaphore) which make it 3 times slower. >> >> So with OrderedCollection and disabled mutex performance for subscribing is same. >> >> I pretty sure that protection is required for Block handlers too. >> >> 2016-08-29 17:18 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com>: >> Ha... tag doesn't work... >> >> You can load Bloc and show the tests using this script: >> Gofer it >> smalltalkhubUser: 'Pharo' project: 'Bloc'; >> configuration; >> loadDevelopment. >> Gofer it >> smalltalkhubUser: 'Pharo' project: 'Bloc'; >> package: 'Bloc-Tests'; >> load. >> BlAnnouncerVsBlEventRegistryTest browse >> >> >> >> >> ----- >> Glenn CavarlÃ© >> -- >> View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> >> > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > > >

Aug. 30, 2016