- Pharo-dev - lists.pharo.org

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

by Thierry Goubier

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-double-quotes-inside-… >> >> 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). 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. 29, 2016

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

by Tudor Girba

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. 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. 29, 2016

Re: [Pharo-dev] About Pharo 60

by stepharo

Thanks we are currently brainstorming with esteban on the pharo pro offer and this is nice to have your feedback. Stef Le 28/8/16 Ã 15:33, Torsten Bergmann a Ã©crit : >> what are the points you are working on and that would deserve more focus and help from the community? > I once started with a refactored version of GetText, covered with tests and tools. > Code status I reached so far is here: > > http://www.smalltalkhub.com/#!/~TorstenBergmann/Gettext > > Idea was to be lean, no dependency on Seaside or others and get a well documented easy to use I18N solution. > This would open up the possibility for more internationalized Pharo image and Pharo based apps. Would be nice > if this could be completed and become part of our infrastructure to get a wider audience and globally usable > applications. > > 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 > > - image size management under control (as Philip already suggested) > > - better support for REST based systems (as Philip already suggested) > > - 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. > 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 > - an out of the box Pharo Pi VM + image on the website > > Bye > T. > >

Aug. 29, 2016

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

by stepharo

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-double-quotes-inside-… > > 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. I think that I would use them only when developing. Stef > > Thierry >

Aug. 29, 2016

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

by stepharo

Hi henrik thanks for your analysis. I always wanted to deeply understand the difference between announcements and a simple registry mechanism. Now I'm too tired to think (yes I need to sleep a 9h25 :) but I will reread this mail when my brain is back . stef Le 29/8/16 Ã 00:54, Henrik Nergaard a Ã©crit : > Probably from the use of critical (mutex), the way #subscriptionsHandling: is done, and that Announcer is built for X number of announcers and Y number of subscribers, which means that each announcement the announcer has to filter and find the correct subscribers. > ---- > > | ann a | > > ann := Announcer new. > > ann when: Announcement do: [ :e ]. > a := Announcement new. > [[ ann announce: a ] bench ] timeProfile > > ----- > > Other drawbacks to consider when using announcements: > Memory overhead from the Announcer object and each subscription. > Memory ownership, the announcement subscriptions will strongly reference the announcement target unless the announcement is weakly, which can lead to memory leakage especially if strong and weak subscriptions are mixed in certain situations (see the mailing list from around the release of Pharo 6). This also leads to code where the announcer is the one who owns the target (multiple times if there are different announcements), which makes understanding who references what etc.. much harder to understand. > In many places the control/message flow, and the relationship between the different parts of a bigger object tends to become much more difficult to understand (For example Rubric). > > Announcer usage shines when there is a need for a common place that X objects can communicate Y messages to Z recipients without needing to know who sends what, or who wants to receive what (For example System Announcements). > > Communication when only one Object "A" announces to another Object(s) "B", is better implemented as A referencing B, then B implements the necessary methods needed for this communication. > > Best regards, > Henrik > > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Glenn CavarlÃ© > Sent: Sunday, August 28, 2016 9:11 PM > To: pharo-dev(a)lists.pharo.org > Subject: [Pharo-dev] About the non-use of Announcer in Bloc > > Hi all, > Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. > I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. > The result is that Announcer is at least 5x slower in all tested cases. > Bloc has only specific needs about event dispatching, the first one is the efficiency during event propagation. > It may be interesting to investigate why Announcer is slower and also what are the uncovered cases in BlEventRegistry. > So, i'm interested in continuing our discussion about that. > > Regards, > Glenn. > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 29, 2016

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

by stepharo

Thanks Glenn!!!!!!!!!!!!!!!!!!!!!!! > Hi all, > Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of > Announcer in Bloc. > I made some test cases in Bloc-Tests to compare performances between > Announcer and BlEventRegistry. > The result is that Announcer is at least 5x slower in all tested cases. > Bloc has only specific needs about event dispatching, the first one is the > efficiency during event propagation. > It may be interesting to investigate why Announcer is slower and also what > are the uncovered cases in BlEventRegistry. > So, i'm interested in continuing our discussion about that. > > Regards, > Glenn. > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 29, 2016

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

by Denis Kudriashov

And now question is why SubscriptionRegistry manages subscriptions as IdentitySet instead of OrderedCollection? 2016-08-29 18:36 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 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-th >>> e-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> >

Aug. 29, 2016

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

by Denis Kudriashov

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-th >> e-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

Aug. 29, 2016

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

by Denis Kudriashov

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-tp4913008p4913088.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 29, 2016

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

by Thierry Goubier

2016-08-29 13:24 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > > On Mon, Aug 29, 2016 at 11:42 AM, stepharo <stepharo(a)free.fr> wrote: > >> 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 :) >> > > This would be also consistent with how single quotes are handled in a > string, which would make it doublenice. :) > Implementing it means looking at how strings are scanned :) Thierry > > Peter >

Aug. 29, 2016