- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1

by Alexandre Bergel

I wanted to try, but there is no installation instruction for OS X :-( Can you produce some on OS X? It would be great Anyway, this is great Vincent! Keep pushing! Alexandre > On Sep 1, 2016, at 12:42 PM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Hello everyone, > > I am glad to announce the release of version 2.1 of the RProjectConnector. > The binding between Pharo and R (https://www.r-project.org/ <https://www.r-project.org/>) is now translated to UFFI and so to Pharo 6.0. > > You can call directly your R methods from Pharo. For example, with the famous iris clustering example: > > iris := 'eval' asREval: {RObject findVar: 'iris'}. > 'plot' > asREval: > {(iris at: 'Petal.Length'). > (iris at: 'Petal.Width'). > (#pch -> 21). > (#xlab -> 'length'). > (#ylab -> 'Width'). > (#bg ->((iris at: 'Species') collect: [ :value | {'red'. 'green3'. 'blue'} at: value ])). > (#main -> 'Edgar Anderson''s Iris Data')}. > iris inspect. > > To use it, you should install R and copy the R libraries near the Pharo VM (see the documentation on SmalltalkHub (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector <http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector>) for how to proceed). > > Donât forget to relaunch Pharo after the installation to be able to use the connector. > > Only basic features are implemented yet, but you can participate to its extension! > > Cheers, > Vincent Blondeau > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

Sept. 1, 2016

[ANN] RProjectConnector V2.1

by Blondeau Vincent

Hello everyone, I am glad to announce the release of version 2.1 of the RProjectConnector. The binding between Pharo and R (https://www.r-project.org/) is now translated to UFFI and so to Pharo 6.0. You can call directly your R methods from Pharo. For example, with the famous iris clustering example: iris := 'eval' asREval: {RObject findVar: 'iris'}. 'plot' asREval: {(iris at: 'Petal.Length'). (iris at: 'Petal.Width'). (#pch -> 21). (#xlab -> 'length'). (#ylab -> 'Width'). (#bg ->((iris at: 'Species') collect: [ :value | {'red'. 'green3'. 'blue'} at: value ])). (#main -> 'Edgar Anderson''s Iris Data')}. iris inspect. To use it, you should install R and copy the R libraries near the Pharo VM (see the documentation on SmalltalkHub (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector) for how to proceed). Don't forget to relaunch Pharo after the installation to be able to use the connector. Only basic features are implemented yet, but you can participate to its extension! Cheers, Vincent Blondeau !!!************************************************************************************* "Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

Sept. 1, 2016

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