- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] wish for Iceberg

by stepharo

My important wish for Iceberg is managing Pull Request. Now I think that we should let nicolas release a version before bombarding him about features. Le 29/8/16 Ã 22:11, Alexandre Bergel a Ã©crit : > Hi! > > It would be great to be able to save the repositories on the disk, somewhere. And to not have to type them all the time. > > Also, if I install a git repository, I would like to be able to commit / push after modifying it. > > Cheers, > Alexandre > > >

Aug. 30, 2016

Re: [Pharo-dev] [Moose-dev] [ann] pillar support in gtinspector

by stepharo

Le 29/8/16 Ã 21:47, Yuriy Tymchuk a Ã©crit : > >> On 29 Aug 2016, at 21:41, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >> I updated the Pillar support in GTInspector. Some of the extensions >> already exist in the default Pillar #development version. If you want >> to play with the full support, you can load it like this: >> >> Gofer new >> smalltalkhubUser: 'Moose' project: 'PetitParser'; >> package: 'PetitAnalyzer'; >> package: 'PetitIndent'; >> package: 'PetitIslands'; >> smalltalkhubUser: 'Moose' project: 'GToolkit'; >> package: 'GT-InspectorExtensions-Pillar'; >> load >> >> Then you can just inspect a book folder and you get this: >> >> <inspector-pillar.png> > > Cool! > >> >> I did not integrate this in the main Pillar yet because this is an >> older implementation based on a limited island parser. As now Pillar >> has a full parser based on PetitParser, the next step is to move the >> highlighting logic to use this parser instead of the island parser. >> From my measurements, the speed of the two parsers is about the same, >> so from a user perspective there will be not much changes. >> >> It pains me that we are editing Pillar in outside tools, and now we >> should no longer have to do that. Of course, this is not the most >> ideal tool support for Pillar but I think it is a reasonable start. > > To make things sadder: when I need to write some short ârichish" Iâm > using markdown instead for pillar because in ATOM I can open the > rendered version of my document that will update while i type (and > will display images and so on). It could be nice to have the same > functionality in Pharo, but Iâm really busy with improving other > parts. Additionally Iâm not sure that it makes sense to reimplement > rich text editor in Pharo. It does. We want a real editor in Pharo. > > Uko > >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> www.feenk.com <http://www.feenk.com> >> >> "Problem solving should be focused on describing >> the problem in a way that makes the solution obvious." >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> >> https://www.list.inf.unibe.ch/listinfo/moose-dev >

Aug. 30, 2016

Re: [Pharo-dev] About Pharo 60

by stepharo

>> Additionally I would like to see: >> >> - investigation in the Win Pharo VM for being able to run again as >> a Windows Service >> (as it was possible for Squeak) to be able to easily provide, >> deploy and administrate a web >> app on Windows Definitively. Thanks for mentionning it. It will be done by PharoPro :) >> >> - image size management under control (as Philip already suggested) >> >> - better support for REST based systems (as Philip already suggested) Can you be clearer? Because I thought that Seaside-REST was good and you can apply to non Seaside Application. Then there is Teapot. As Pharo core I do not see why Zinc is not enough. Now fr Pharo Pro I could see. >> >> - modern "Material style" UI (as Philip already suggested) but >> additionally with >> better out of the box Spec support and examples for regular widgets >> (Accordion, draggable Toolbars, calendar widget, date/time >> picker, ...) >> >> - clear rules to not accept undocumented classes/packages in the image >> And a clear separation in packages between CORE/BASE stuff and >> TESTS on top. Tests are already separated. Do you have some places where this is not the case? >> Because TEST are usually only for development and for >> production/deployment of an app >> TESTS usually should be thrown out. >> >> Christmas list would include: >> - 64 Bit support This is not a christmas list. It should be threr for September. >> - an out of the box Pharo Pi VM + image on the website >> >> Bye >> T. >> >> > > >

Aug. 30, 2016