- Pharo-dev - lists.pharo.org

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

by Eliot Miranda

On Tue, Aug 30, 2016 at 8:14 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 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) > > ? ) > Specialize #, in Interval to check. Right now #, will answer an Array, but it would be easy to special-case. > > > >> >> 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 >>>> >>>> >>> >> >> > -- _,,,^..^,,,_ best, Eliot

Aug. 31, 2016

Re: [Pharo-dev] Examples accessible within the World Menu?

by Tudor Girba

Indeed, GTExamples offer ways to get examples from the World menu: Doru > On Aug 30, 2016, at 2:51 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > Is there a way to easily have some examples accessible within a world menu? That would be so much convenientâ¦ > > Does GTExample do something in that direction? > > Cheers, > Alexandre > > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Aug. 30, 2016

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

by Thierry Goubier

Numbers for the discussion: No activity, empty desktop: announcements 608/minute subscribe add/remove 9/minute Activity, AltBrowser: announcements 1109/minute subscribe add/remove 207/minute Activity, Nautilus: announcements 2488/minute subscribe add/remove 716/minute Empirically the same processus in both environments: open two system browser, in one, find the Announcer class, browse through a few of the methods, select basicSubscribe: and ask for senders. Tracing done with Metalinks during one minute. Not exactly what I would have expected, especially the ratio subscribe add/remove and announcements. Thierry Le 30/08/2016 Ã 17:36, Henrik Johansen a Ã©crit : > >> On 30 Aug 2016, at 5:16 , Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> >> I have the same concern with an Announcer optimized for certain use >> cases, in the fact that the announcer creator is the one choosing >> the 'kind of' optimisation it would target, hoping that the >> listeners will conform to that use case... > > > There simply is no silver bullet that will give unbeatable > performance in all scenarios; and focusing on improving one facet of > the default implementation will inevitably lead to either - the loss > of some important property (general thread-safety if removing the > mutex protection, ability to unsubscribe in handler if removing the > copy operation and extending the delivery mutex protection, etc.) - > greatly degenerated performance for another facet (like #remove for > OC's). > > That said, the current implementation is very geared towards decent, > balanced subscribe/unsubscribe performance, at the expense of > delivery speed. I've said it before, and still think, that offering > at least one other implementation emphasizing delivery speed over > subscription/unsubscription performance, in the same way the original > implementation did (and/or changing the default Announcer to switch > between the two dynamically based on heuristics) *would* be a > valuable addition to the general library. > > Cheers, Henry >

Aug. 30, 2016

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

by Thierry Goubier

2016-08-30 17:36 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > > On 30 Aug 2016, at 5:16 , Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > > I have the same concern with an Announcer optimized for certain use > cases, in the fact that the announcer creator is the one choosing the 'kind > of' optimisation it would target, hoping that the listeners will conform to > that use case... > > > There simply is no silver bullet that will give unbeatable performance in > all scenarios; and focusing on improving one facet of the default > implementation will inevitably lead to either > - the loss of some important property (general thread-safety if removing > the mutex protection, ability to unsubscribe in handler if removing the > copy operation and extending the delivery mutex protection, etc.) > - greatly degenerated performance for another facet (like #remove for > OC's). > > That said, the current implementation is very geared towards decent, > balanced subscribe/unsubscribe performance, at the expense of delivery > speed. > I've said it before, and still think, that offering at least one other > implementation emphasizing delivery speed over subscription/unsubscription > performance, in the same way the original implementation did (and/or > changing the default Announcer to switch between the two dynamically based > on heuristics) *would* be a valuable addition to the general library. > Intuitively, I would say that delivery speed would be more important. But I wonder what would be a way to ensure we optimise for the correct usual use. Either way, I agree with you about the interest of another implementation targetting faster delivery. Regards, Thierry > Cheers, > Henry > >

Aug. 30, 2016

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

by Henrik Johansen

> On 30 Aug 2016, at 5:16 , Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > I have the same concern with an Announcer optimized for certain use cases, in the fact that the announcer creator is the one choosing the 'kind of' optimisation it would target, hoping that the listeners will conform to that use case... There simply is no silver bullet that will give unbeatable performance in all scenarios; and focusing on improving one facet of the default implementation will inevitably lead to either - the loss of some important property (general thread-safety if removing the mutex protection, ability to unsubscribe in handler if removing the copy operation and extending the delivery mutex protection, etc.) - greatly degenerated performance for another facet (like #remove for OC's). That said, the current implementation is very geared towards decent, balanced subscribe/unsubscribe performance, at the expense of delivery speed. I've said it before, and still think, that offering at least one other implementation emphasizing delivery speed over subscription/unsubscription performance, in the same way the original implementation did (and/or changing the default Announcer to switch between the two dynamically based on heuristics) *would* be a valuable addition to the general library. Cheers, Henry

Aug. 30, 2016

Re: [Pharo-dev] wish for Iceberg

by Serge Stinckwich

I start to move some of my projects on github as a small experiment: https://github.com/UMMISCO/kendrick https://github.com/SergeStinckwich/PlayerST https://github.com/SergeStinckwich/Actalk All with SmalltalkCI jobs ! Everything is working perfectly until now but still very tricky sometimes. On Tue, Aug 30, 2016 at 4:32 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > So in the meantime I can build a tool to convert a git metacello-downloaded > MCRepository to an Iceberg repository in a simple way. Do you think it would > be useful? > > > No idea. It looks interesting! > > Anyway, keep pushing! This is so exciting to see this happening! > > Alexandre > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 30, 2016

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

by Thierry Goubier

2016-08-30 16:01 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 29 Aug 2016, at 6:39 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > And now question is why SubscriptionRegistry manages subscriptions as > IdentitySet instead of OrderedCollection? > > > 1) Performance of remove operation is the main reason. Sure, registration > has a larger constant overhead than using an OrderedCollection, but it's > still a theta(1) operation.Removal however, is theta(1)'ish, while with > OrderedCollection, it would be theta(n/2). So for a general implementation > where the usage pattern is unknown, it gives more balanced performance > considering all use cases. * > 2) Lessen chance of user relying on delivery order implied by registration > order. > > And yes, it's possible to create much better performing announcers for > specific use patterns, such as a (short-lived) announcer where there's a > period of registration, followed by a period of delivery, before eventual > garbage collection of the announcer rather than explicit deregistration. > Personally, I think the (original) announcer pattern, where subscription > collection is copied at registration, then replaced atomically, would be a > better alternative. > You'd still need a mutex for the copy->add part to keep it thread-safe, > but delivery would have much less overhead (no copy needed to avoid mutex > guarding against mutation) > > I'd be *very* wary of adding announcers that do not have thread-safe > interaction between registration and delivery, though one suited for > registration limited to a single thread may be a valid scenario. > The problem I see with that scenario is the risk of code evolution and the fact one must be aware, in the announcement listener, that single threading is to be maintained... and this is out of the scope of the Announcer code itself (or even the object creating the announcer instance). I have the same concern with an Announcer optimized for certain use cases, in the fact that the announcer creator is the one choosing the 'kind of' optimisation it would target, hoping that the listeners will conform to that use case... Regards, Thierry > > Cheers, > Henry >

Aug. 30, 2016

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

by Alexandre Bergel

Hi! Having a spell checker would be fantasticâ¦ Any chance to have this? Alexandre > On Aug 29, 2016, at 4:41 PM, 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> > > 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 <http://www.tudorgirba.com/> > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > >

Aug. 30, 2016

Re: [Pharo-dev] wish for Iceberg

by Alexandre Bergel

> So in the meantime I can build a tool to convert a git metacello-downloaded MCRepository to an Iceberg repository in a simple way. Do you think it would be useful? No idea. It looks interesting! Anyway, keep pushing! This is so exciting to see this happening! Alexandre

Aug. 30, 2016

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

by Henrik Johansen

> On 29 Aug 2016, at 6:39 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > And now question is why SubscriptionRegistry manages subscriptions as IdentitySet instead of OrderedCollection? 1) Performance of remove operation is the main reason. Sure, registration has a larger constant overhead than using an OrderedCollection, but it's still a theta(1) operation.Removal however, is theta(1)'ish, while with OrderedCollection, it would be theta(n/2). So for a general implementation where the usage pattern is unknown, it gives more balanced performance considering all use cases. * 2) Lessen chance of user relying on delivery order implied by registration order. And yes, it's possible to create much better performing announcers for specific use patterns, such as a (short-lived) announcer where there's a period of registration, followed by a period of delivery, before eventual garbage collection of the announcer rather than explicit deregistration. Personally, I think the (original) announcer pattern, where subscription collection is copied at registration, then replaced atomically, would be a better alternative. You'd still need a mutex for the copy->add part to keep it thread-safe, but delivery would have much less overhead (no copy needed to avoid mutex guarding against mutation) I'd be *very* wary of adding announcers that do not have thread-safe interaction between registration and delivery, though one suited for registration limited to a single thread may be a valid scenario. Cheers, Henry

Aug. 30, 2016