September 2016 - Pharo-users

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

by Ben Coman

On Wed, Sep 14, 2016 at 4:21 PM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: >> > >> >> >> >> I try to move the R dll close to my Pharo VM and also inside the >> >> Plugins directory but without success ... >> > >> > It should be at the same location that libcairo.2.dylib >> > >> >> Is there a way to say where are the R dll instead of copying them ? >> >> Are you using the system to do the library path resolution? Or finding the >> library file in Pharo and then passing an absolute path to FFI? > > I think that the system that do the resolution: > I defined in a trait: > ffiLibraryName > ^ #R > And the library is named R.dll (under windows). > > Maybe I should do like CairoLibrary? My limited understanding is that #ffiLibraryName should return a class rather than a symbol. Thus... MyClass class >> ffiLibraryName ^ R R >> win32ModuleName ^ 'libr.N.dll'. "or whatever is the actual dll filename" cheers -ben

Sept. 14, 2016

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

by Blondeau Vincent

> > > >> > >> I try to move the R dll close to my Pharo VM and also inside the > >> Plugins directory but without success ... > > > > It should be at the same location that libcairo.2.dylib > > > >> Is there a way to say where are the R dll instead of copying them ? > > Are you using the system to do the library path resolution? Or finding the > library file in Pharo and then passing an absolute path to FFI? I think that the system that do the resolution: I defined in a trait: ffiLibraryName ^ #R And the library is named R.dll (under windows). Maybe I should do like CairoLibrary? Cheers, Vincent > > cheers -ben > !!!************************************************************************************* "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. 14, 2016

Re: [Pharo-users] Class shown in _UnpackagedPackage but belongs to package

by Ben Coman

Thought-0.0.2... What does Monticello > Browse show? Thought-0.0.3... Have a look at RPackageOrganizer class >> initialize cheers -ben On Wed, Sep 14, 2016 at 1:05 PM, Ben Coman <btc(a)openinworld.com> wrote: > Very first thought... > 1. Close all Nautilus windows. > 2. Smalltalk recompileAll. > > ?? > cheers -ben > > On Wed, Sep 14, 2016 at 11:58 AM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: >> Hi, >> >> After renaming, promoting as tag, moving to package and other >> non-secuential operations in Nautilus which screwed up the packaging, >> now all classes are shown in _UnpackagedPackage but when browsed via >> Spotter they show the right package in the class template. >> >> SequenceableCollection subclass: #OrderedCollection >> instanceVariableNames: 'array firstIndex lastIndex' >> classVariableNames: '' >> package: 'Collections-Sequenceable' >> >> Any pointers on how to fix/rebuild whatever is needed? >> It took me two classes and less than 5 minutes to screw it, I guess >> it's a new record. :) >> >> Regards! >> >> ps: this happens with the latest 5.0 image and vm version. >> >> Esteban A. Maringolo >>

Sept. 14, 2016

Re: [Pharo-users] Class shown in _UnpackagedPackage but belongs to package

by Ben Coman

Very first thought... 1. Close all Nautilus windows. 2. Smalltalk recompileAll. ?? cheers -ben On Wed, Sep 14, 2016 at 11:58 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi, > > After renaming, promoting as tag, moving to package and other > non-secuential operations in Nautilus which screwed up the packaging, > now all classes are shown in _UnpackagedPackage but when browsed via > Spotter they show the right package in the class template. > > SequenceableCollection subclass: #OrderedCollection > instanceVariableNames: 'array firstIndex lastIndex' > classVariableNames: '' > package: 'Collections-Sequenceable' > > Any pointers on how to fix/rebuild whatever is needed? > It took me two classes and less than 5 minutes to screw it, I guess > it's a new record. :) > > Regards! > > ps: this happens with the latest 5.0 image and vm version. > > Esteban A. Maringolo >

Sept. 14, 2016

Class shown in _UnpackagedPackage but belongs to package

by Esteban A. Maringolo

Hi, After renaming, promoting as tag, moving to package and other non-secuential operations in Nautilus which screwed up the packaging, now all classes are shown in _UnpackagedPackage but when browsed via Spotter they show the right package in the class template. SequenceableCollection subclass: #OrderedCollection instanceVariableNames: 'array firstIndex lastIndex' classVariableNames: '' package: 'Collections-Sequenceable' Any pointers on how to fix/rebuild whatever is needed? It took me two classes and less than 5 minutes to screw it, I guess it's a new record. :) Regards! ps: this happens with the latest 5.0 image and vm version. Esteban A. Maringolo

Sept. 14, 2016

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

by Ben Coman

On Wed, Sep 14, 2016 at 12:25 AM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > > >> -----Message d'origine----- >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Serge Stinckwich >> EnvoyÃ© : vendredi 2 septembre 2016 16:44 >> Ã : Pharo Development List >> Cc : scismalltalk(a)googlegroups.com; Any question about pharo is welcome >> Objet : Re: [Pharo-dev] [ANN] RProjectConnector V2.1 >> >> Great job Vincent ! >> > It will be great when it will work on OS X ;) > >> There is some problems on Mac OS X: >> - when I try to load in a fresh Pharo 5.0 image, I got a DNU on: >> RObjectArray class>>initElementType: >> I was able to load the package after a while by loading directly the package >> with the Monticello Browser > > Strange, I deleted these methods... Please ensure you are using a Pharo 6.0 image (it should work under Pharo 5.0 too) and that version 14 of ConfigurationOfRProjectConnector and version 71 of the RConnector packages are loaded. > >> - Apparently there is still some methods using NB like: RSession >> class>>checkSession or RSession class>>initEmbeddedR: > > Should not, it is modified ... > >> >> I try to move the R dll close to my Pharo VM and also inside the Plugins >> directory but without success ... > > It should be at the same location that libcairo.2.dylib > >> Is there a way to say where are the R dll instead of copying them ? Are you using the system to do the library path resolution? Or finding the library file in Pharo and then passing an absolute path to FFI? cheers -ben >> > Didn't think so .. Maybe the VM developers knows ? > > > Thanks! > > Vincent > > >> Thank you. >> >> >> >> >> On Thu, Sep 1, 2016 at 5: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/) 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 >> >

Sept. 13, 2016

Re: [Pharo-users] double dispatch example

by Denis Kudriashov

2016-09-13 20:56 GMT+02:00 stepharo <stepharo(a)free.fr>: > > I was thinking about the code in Pharo. > > Plenty of examples: > >> - Converting money >> > > can you tell me more about this one? Probably most known and beautiful case is arithmetic operations. Look at #adaptToInteger:andSend: and friends.

Sept. 13, 2016

Re: [Pharo-users] double dispatch example

by stepharo

Thanks Alex I was thinking about the code in Pharo. Plenty of examples: > - Converting money can you tell me more about this one? > - Paper, Stone, Scissor > - A canvas containing triangle, circle, box has to be printed, on an html canvas or PDF. (Very close to the Visitor design pattern, but simpler) > > Here are the lectures I use: > https://dl.dropboxusercontent.com/u/31543901/TMP/DoubleDispatch.zip TX here is what I wrote today > > (One of them is highly inspired from a lecture from Oscar) I will have a look now > > Hope it helps! > > Cheers, > Alexandre > >> On Sep 13, 2016, at 7:33 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> If you happen to know a double dispatch situation in Pharo, I'm interested since I'm revisiting my lecture. >> >> >> Stef >> >> > >

Sept. 13, 2016

Re: [Pharo-users] Problem cleaning up image

by Marcus Denker

> On 13 Sep 2016, at 18:54, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > I understand. I thought it did more stuff, like remove necessary development tools or executing processes, It does call #cleanUpForRelease, but this we call at *every* update on the CI, too. This calls the #cleanUp method of all classes and does some more (rehashing all dictionaries, restarting all? methods holding on to blocksâ¦). > I don't know, but considering its implementation it should affect only the image size, right? > Yes. Of course right now Cog is not compacting the somewhat empty allocated memory regions, so e.g. the 47 MB image should be around 15 MB empty space and the cleanup will not shrink it. But when this is fixed, you should see a change. A saved image is too a large extend methods and literals they point to (especially for things like Tutorials). In the past the normal image was ca. 25MB, while the shrieked one after cleanup for deployment maybe 15? I do not remember. But that was already a bit of âmoored lawâ time ago ;-) Marcus

Sept. 13, 2016

Re: [Pharo-users] Problem cleaning up image

by Vitor Medina Cruz

I understand. I thought it did more stuff, like remove necessary development tools or executing processes, I don't know, but considering its implementation it should affect only the image size, right? Thanks, Vitor On Tue, Sep 13, 2016 at 8:30 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 13 Sep 2016, at 13:15, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > > > > Humm, why not? When I load the configuration it loads several other > packages, wouldn't that need a cleanup too? When I first see that I could > cleanup an image my first thought was to put it in a production state with > my code, then I would cleanup to leave it as lean as possible. Isn't that > correct? > > > > If I should not clean after load my packages why provide the > functionality? Why not provide clean images to be used in production so > that people could download and load it's ready to production code? > > > > No, the #cleanUpForProduction just unloads tests, examples and things like > thatâ¦ it only touches loaded code in the sense that it > unloads all packages named -Tests and -Examples. > > But if the external package happens to be structured in a way that this is > bad, it would brake. > > I never expected this to be run *after* more packages are loaded, just > *before*. > > What it does right now it this (you can see that it could be simpler if > our packages are better structured): > > cleanUpForProduction > "self new cleanUpForProduction" > "delete logo" > PolymorphSystemSettings showDesktopLogo: false. > > self packagesForCleanUpInProduction do: [ :each | (MCPackage > named: each) unload ]. > self helpPackages do: [ :each | (MCPackage named: each) unload ]. > self testPackages do: [ :each | (MCPackage named: each) unload ]. > self examplePackages do: [ :each | (MCPackage named: each) unload > ]. > (MCPackage named: 'ScriptLoader40') unload. > > > (MCPackage named: 'MonticelloMocks') unload. > (MCPackage named: 'ToolsTest') unload. > (MCPackage named: 'Announcements-Tests-Core') unload. > (MCPackage named: 'AST-Tests-Core') unload. > (MCPackage named: 'AST-Interpreter-Test') unload. > (MCPackage named: 'Ring-Tests-Containers') unload. > (MCPackage named: 'Ring-Tests-Kernel') unload. > (MCPackage named: 'Ring-Tests-Monticello') unload. > (MCPackage named: 'Regex-Tests-Core') unload. > (MCPackage named: 'Refactoring-Tests-Changes') unload. > (MCPackage named: 'Refactoring-Tests-Core') unload. > (MCPackage named: 'Refactoring-Tests-Critics') unload. > (MCPackage named: 'Refactoring-Tests-Environment') unload. > (MCPackage named: 'FileSystem-Tests-Core') unload. > (MCPackage named: 'FileSystem-Tests-Disk') unload. > (MCPackage named: 'FileSystem-Tests-Memory') unload. > > (MCPackage named: 'GT-Tests-Inspector') unload. > (MCPackage named: 'Glamour-Tests-Core') unload. > (MCPackage named: 'Glamour-Tests-Morphic') unload. > (MCPackage named: 'Glamour-Tests-Resources') unload. > (MCPackage named: 'Glamour-Tests-Rubric') unload. > > (MCPackage named: 'Versionner-Core-Model') unload. > (MCPackage named: 'Versionner-Core-DependenciesModel') unload. > (MCPackage named: 'Versionner-Core-Announcements') unload. > (MCPackage named: 'Versionner-Core-Commands') unload. > (MCPackage named: 'Versionner-Spec-Browser') unload. > (MCPackage named: 'Versionner-Tests-Core-Commands') unload. > (MCPackage named: 'Versionner-Tests-Core-DependenciesModel') > unload. > (MCPackage named: 'Versionner-Tests-Core-Model') unload. > (MCPackage named: 'Versionner-Tests-Resources') unload. > > self cleanUpForRelease. > > > Marcus > > >

Sept. 13, 2016