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

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

by Denis Kudriashov

2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > 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. > > Alternatively we may use OrderedCollection and just check if it includes > the subscription before adding. I think that more events are fired than > clients are subscribed per a period of time > > It looks quite safe to not check anything because subscription items are instances of AnnouncementSubscription which are created internally inside Announcer during subscription

Aug. 29, 2016

wish for Iceberg

by Alexandre Bergel

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

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

by Yuriy Tymchuk

> On 29 Aug 2016, at 21:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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. Alternatively we may use OrderedCollection and just check if it includes the subscription before adding. I think that more events are fired than clients are subscribed per a period of time Uko > > 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] [Moose-dev] [ann] pillar support in gtinspector

by Yuriy Tymchuk

> On 29 Aug 2016, at 21:41, Tudor Girba <tudor(a)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. Uko > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > 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 > https://www.list.inf.unibe.ch/listinfo/moose-dev

Aug. 29, 2016

[ann] pillar support in gtinspector

by Tudor Girba

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: 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. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Aug. 29, 2016

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