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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60197 Home: https://github.com/pharo-project/pharo-core

Sept. 1, 2016

[pharo-project/pharo-core] 29e0f2: 60197

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 29e0f2580442a1838dc0c84978512f5b73e8c053 https://github.com/pharo-project/pharo-core/commit/29e0f2580442a1838dc0c849… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-01 (Thu, 01 Sep 2016) Changed paths: M Collections-Unordered.package/Dictionary.class/class/instance creation/newFromPairs_.st M FreeType.package/FreeTypeFontProvider.class/instance/file paths/macOSXFolderDirectories.st M FreeType.package/FreeTypeFontProvider.class/instance/file paths/unixFontDirectories.st A FreeType.package/FreeTypeFontProvider.class/instance/file paths/unixUsualDirectories.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60196.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60197.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60196.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60197.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Settings.package/ClassStoredSetting.class/instance/accessing/realValue.st M System-Settings.package/LogicalFontStoredSetting.class/instance/accessing/realValue.st M System-Settings.package/StrikeFontSetStoredSetting.class/instance/accessing/realValue.st M System-Settings.package/StrikeFontStoredSetting.class/instance/accessing/realValue.st M Tool-CriticBrowser.package/CriticBrowser.class/class/instance creation/packagesMenu_.st M Tool-CriticBrowser.package/CriticBrowser.class/class/menu/icon.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/api/onWindowClosed.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/private/allRules.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/private/applyRules.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/private/reapplyAllRules.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/private/reapplyRule_.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/classAdded_.st R Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/classModified_.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/classRemoved_.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/handleClassAdded_.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/handleClassModified_.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/handleClassRemoved_.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/handleMethodAdded_.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/handleMethodModified_.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/handleMethodRemoved_.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/methodAdded_.st R Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/methodModified_.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/methodRemoved_.st M Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/registerToAnnouncements.st A Tool-CriticBrowser.package/CriticBrowser.class/instance/system annoucements/unregisterFromAnnouncements.st M Tool-CriticBrowser.package/CriticsCache.class/instance/add%2Fremove/itemRemoved_.st A Tool-CriticBrowser.package/CriticsCache.class/instance/add%2Fremove/removeRule_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/initializeActionToPerformOnTextModel.st Log Message: ----------- 60197 19019 Inexactitude in Dictionary class>> newFromPairs: comment https://pharo.fogbugz.com/f/cases/19019 18950 CritiqueBrowser: Compiler error when accepting a method with argument https://pharo.fogbugz.com/f/cases/18950 18992 asClass in font related package https://pharo.fogbugz.com/f/cases/18992 18988 FreeTypeFontProvider should calculate correctly the directories where to look for fonts. https://pharo.fogbugz.com/f/cases/18988 http://files.pharo.org/image/60/60197.zip

Sept. 1, 2016

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

by Denis Kudriashov

Hi Thierry. 2016-09-01 10:21 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > (Duration minutes: 1) wait. > Just to mention our nice language: it could be written as: 1 minutes wait

Sept. 1, 2016

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

by Thierry Goubier

Hi Stef, here is the script I use: | c1 c2 c3 n1 n2 n3 l1 l2 l3 | c1 := c2 := c3 := 0. n1 := (Announcer>>#announce:) ast. n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e | (Announcer>>e) ast ]. n3 := #(unsubscribe: removeSubscription:) collect: [ :e | (Announcer>>e) ast ]. l1 := MetaLink new metaObject: [ c1 := c1 + 1 ]; selector: #value. l2 := MetaLink new metaObject: [ c2 := c2 + 1 ]; selector: #value. l3 := MetaLink new metaObject: [ c3 := c3 + 1 ]; selector: #value. [ n1 link: l1. n2 do: [ :e | e link: l2 ]. n3 do: [ :e | e link: l3 ]. (Duration minutes: 1) wait. n1 removeLink: l1. n2 do: [ :e | e removeLink: l2 ]. n3 do: [ :e | e removeLink: l3 ]. { 'announce' -> c1. 'subscribe' -> c2. 'unsubscribe' -> c3 } inspect ] forkAt: Processor userBackgroundPriority [image: Images intÃ©grÃ©es 1] 2016-09-01 9:28 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Stef, > > > 2016-09-01 8:13 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi thierry >> >> I think that if we would have a tool to show us the activity I'm quite >> sure that we would find bugs >> >> or mistaken behavior. >> > > Yes. I did some checks on Morphic and AltBrowser after getting the > numbers, to see if I wasn't > doing something wrong with my code. > > could you send the scripts you did? >> > > Later today. I don't have access now to the laptop where I did it. > > Thierry > > >> >> Stef >> >> >> Le 30/8/16 Ã 22:36, Thierry Goubier a Ã©crit : >> >> 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 >>>> >>>> >>> >>> >>> >> >> >

Sept. 1, 2016

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

by Denis Kudriashov

2016-09-01 9:57 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Really? You lost me on that sentence. SystemAnnouncer current is shared by >> all the tools no? > > > Yes, you are right. I forgot this big monster :). > Now I look at senders of #announcer and there are many places with chain > like "aSomebody announcer when:send:..." or also "aSomebody somebodyElse > announcer when:send:...". So forgot my words :) > But these places are definitely smell.

Sept. 1, 2016

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

by Denis Kudriashov

2016-09-01 8:18 GMT+02:00 stepharo <stepharo(a)free.fr>: > > But in practice we never share any announcer instance. > > Really? You lost me on that sentence. SystemAnnouncer current is shared by > all the tools no? Yes, you are right. I forgot this big monster :). Now I look at senders of #announcer and there are many places with chain like "aSomebody announcer when:send:..." or also "aSomebody somebodyElse announcer when:send:...". So forgot my words :)

Sept. 1, 2016

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

by Thierry Goubier

Hi Stef, 2016-09-01 8:13 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi thierry > > I think that if we would have a tool to show us the activity I'm quite > sure that we would find bugs > > or mistaken behavior. > Yes. I did some checks on Morphic and AltBrowser after getting the numbers, to see if I wasn't doing something wrong with my code. could you send the scripts you did? > Later today. I don't have access now to the laptop where I did it. Thierry > > Stef > > > Le 30/8/16 Ã 22:36, Thierry Goubier a Ã©crit : > > 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 >>> >>> >> >> >> > >

Sept. 1, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by stepharo

Le 31/8/16 Ã 22:10, Tudor Girba a Ã©crit : > Hi, > > The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? > > One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. should protect it with a session check > > As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. > > In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. > > What do you think? > > Cheers, > Doru > > >> On Aug 31, 2016, at 12:00 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> At this point Iâve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose. >> >> In the picture below the code was demonstrably executed and yet itâs not in the history and if I would crash (which happens several times a day in âstableâ pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical codeâ¦ >> >> <F091EED2725D4C679C390F5BC76E1CE3.png> >> >> Peter >> <F091EED2725D4C679C390F5BC76E1CE3.png> > -- > www.tudorgirba.com > www.feenk.com > > "Speaking louder won't make the point worthier." > > >

Sept. 1, 2016

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

by stepharo

Le 31/8/16 Ã 11:23, Denis Kudriashov a Ã©crit : > > 2016-08-31 10:10 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com > <mailto:glenn.cavarle@gmail.com>>: > > Hi all (I was out for some days), > > > Hi Glenn > > > 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. > > > Problem that concurrent modification of OrderedCollection could just > fail. You will got debugger. > > 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. > > > Does it means that I should not subscribe on UI events from different > (not UI) processes? > How to do this if it is needed? > Should I always put subscription code into #defer: message (analogue)? > In that case what to do if I need to be sure that I really subscribe > on event and only after this continue my business logic process? > > > 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. > > > Very simple example: I want one shot handler for MouseMove to > highlight element once to see that my mouse was moved around. > So my handler will highlight target element and unsubscribe it > immediately. > Problem that if you do it on OrderedCollection during iteration you > could skip one of the handlers. And probably some failures are also > possible (debugger again). > > Of course you could say users do not do all of this. But what the > alternative? And if people will do this by "incident" it will be very > difficult to discover reasons. > > > 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? > > > But in practice we never share any announcer instance. Really? You lost me on that sentence. SystemAnnouncer current is shared by all the tools no? > We always hide it inside owner object. ValueHolder is not specific > example. > Also ValueHolder is kind of active model for UI application which > could be shared between different views. And when it will be modified > in one view another view will be updated automatically. > > > 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. > > > I wondering what the source of this constraint? Does Morphic follows > it? I guess not, but all Pharo works quite well with it. >

Sept. 1, 2016

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

by stepharo

> 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? I particularly like these two points and I would really like to have a confirmation because in that case this is really a place for improvements. > 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.

Sept. 1, 2016