- Pharo-dev - lists.pharo.org

FFIIntegerTypes inheritance hierarchy

by Ben Coman

I'm looking through the keyhole at something new to me, so maybe this is off base, but looking at the inheritance hierarchy... FFIIntegerType FFIUint16 FFIUint16 FFIUInt32 FFIInt32 FFIUint64 FFIInt64 FFIUint8 FFIInt8 I'm curious... why the all the Ints inherit from the UInts? Each of those classes has the same two methods #basicHandle:at: and #basicHandle:at:put. So the Int subclasses fully override the superclass methods. So there in no inherited behaviour on the instance side. On the class side, I see #externalTypeSize is inherited by the Ints, but evaluating... FFIIntegerType allSubclasses collect: [ :class | class externalType byteSize -> class externalTypeSize ] produces... 4->4 2->2 4->4 8->8 1->1 2->2 4->4 8->8 1->1 So naively the extra inheritance level seems unnecessary and perhaps having... FFIIntegerType class >> externalTypeSize ^ self externalType byteSize would allow the hierarchy to be flattened. Maybe not a great benefit, except to avoid the next person wondering the same thing :P Also, it is surprising that that FFUInt64 uses #signedLongLongAt: rather than #unsignedLongLongAt: . This seems on-purpose rather than accidental since its inherited by FFIInt64, so it seems there is something interesting to learn here that would benefit a method comment. cheers -ben

Sept. 1, 2016

Engineer position at Lille (France) about Moose FAMIX

by Anne Etien

Hi, We have an engineer position at Lille (France) in the RMOD team to modernize FAME, FAMIX and software analysis tools. The position is for two years starting in November or December. Conditions to apply are to have a master with 2 to 10 years of experience. Industrial applications of Moose have shown some limits: (1) problem to scale, (2) modularity and extensibility and (3) user syntax. To overtake these limits, it becomes essential to modernize Moose heart. This project has three major objectives: (i) reduce the memory print to enable a better scaling, (ii) modernize Moose heart to introduce more modularity and extensibility and (iii) simplify the use and extension of Moose. This project aims to develop a new version of Moose (Moose 2.0) more modular, less memory consumer and easier to use. Advantages of Platypus (PL)(http://dossen.univ-brest.fr/apl/index.php/Platypus <http://dossen.univ-brest.fr/apl/index.php/Platypus>) a research prototype developed in Pharo to analyse software systems as models will be combined to those of the current Moose (M) version and the new features of Pharo (P). Moose 2.0 = flexible metamodel (M) supporting multiple inheritance and union of types (PL) + user syntaxto simplify model specifications (PL) + lot of analysis and visualization tools (M) + tool infrastructure (M) + model generator (PL) + compatibility with industrial and academic standard (PL) + low memory print (P) + access to method details (M) on demand (P) Mission description (in French) and application form are available here (https://www.inria.fr/institut/recrutement-metiers/offres/ingenieurs-r-d-con… <https://www.inria.fr/institut/recrutement-metiers/offres/ingenieurs-r-d-con…>). French is not mandatory whereas English is ;o) If you have questions, donât hesitate to ask. Sincerely, Anne Etien

Sept. 1, 2016

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

by Thierry Goubier

2016-09-01 10:29 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 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 > > > Thanks. Didn't find that one when searching through the code. Recovering the userBackgroundPriority message by code browsing and search wasn't too obvious either. Thierry

Sept. 1, 2016

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

by Sven Van Caekenberghe

> On 01 Sep 2016, at 10:21, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > 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 Well, this is really cool code ! > <image.png> > > 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

[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