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

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

by Eliot Miranda

Oops. No need to add a step method; the increment method already exists: On Wed, Aug 31, 2016 at 9:12 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > 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) >> >> ? ) >> > > Find attached something that works in Squeak 5 > > 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 > -- _,,,^..^,,,_ best, Eliot

Aug. 31, 2016

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) > > ? ) > Find attached something that works in Squeak 5 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] About the non-use of Announcer in Bloc

by Glenn CavarlÃ©

Hi all (I was out for some days), What i see is that Bloc EventRegistry: 1) is not thread safe (no mutex + #select:thenDo:) 2) doesn't allow handler removal from the handler list currently used in the thenDo: loop 3) is used specifically for a one-to-many communication (1 BlElement -> X handlers) The (1) doesn't seem to be a problem in Bloc during UI event processing because a new event handler, even if it is added from another thread, would be taken into account for the next event. I note that it is really not recommended (at all) to update an UI element elsewhere than in the UI thread and it is like that in all other UI frameworks i know. The (2) is a very specific use case and i don't know if it is a real need in Bloc because this implies that an element has 2 handlers for the same event and one of them has to remove the other before it is executed and during the same event processing (maybe more a conception issue than a common use case...). In other cases, no problem for handler removal. But maybe i miss some specific cases in (1) and in (2). To me, Announcer is really usefull and efficient when it is used as an event bus that can be shared between multiple objects. For instance, it seems to be useless to use an Announcer in NewValueHolder because it cannot be shared and it is only used internally to register handlers and to propagate only the same event (ValueChanged) to them. What is the gain of using a full featured Announcer in this case? In Bloc the constraint is to propagate more than 2000 events/second without to decrease fps, so we cannot afford to x4 the time to process events even if Announcer is safer and better tested. Regards, Glenn. ----- 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.

Aug. 31, 2016

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