- Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] RProjectConnector V1.0

by HernÃ¡n Morales Durand

Hi Vincent, 2014-12-17 6:02 GMT-03:00 Blondeau Vincent <vincent.blondeau(a)worldline.com>: > > Hernan, > > > > I agree that it is a problem. > > > > To detect the R installation path is complicated. > Yes, I am currently working in a NBWin32Registry so we can do: (NBWin32Registry hKeyLocalMachine at: 'Software\R-core\R') values the reason I didn't committed a solution is I am having ERROR_INVALID_FUNCTION with RegEnumValueA apiRegEnumValue: hKey with: dwIndex with: lpValueName with: lpcchValueName with: lpReserved with: lpType with: lpData with: lpcbData " http://msdn.microsoft.com/en-us/library/windows/desktop/ms724865%28v=vs.85%… " <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #( long RegEnumValueA( HKEY hKey, DWORD dwIndex, LPTSTR lpValueName, LPDWORD lpcchValueName, LPDWORD lpReserved, LPDWORD lpType, LPBYTE lpData, LPDWORD lpcbData)) module: 'advapi32.dll' > Under Windows, you should be able to extract a key in the registry to know > where the program is installed. Under linux, as there is x64 and x32 R > versions, and Pharo supports only x32 (but x64 soon), if you have a R x64 > you should reinstall your whole Linux system to have the right libraries (I > tried without successâ¦). > > > Thanks for the advice > I think that to set the libraries available to download on a server is > currently a better idea. Do you know where it can be hosted? > > > An option to upload library files could be http://files.pharo.org/ but I don't have access to. Foy my configurations I am currently using DropBox although not charming it serves well. But AFAIK you cannot link multiple accounts to one DropBox. There are other reliable options? HernÃ¡n

Dec. 18, 2014

Re: [Pharo-users] New Pharo Collections

by Stephan Eggermont

>The goal of my project is to make a new collections for Pharo Smalltalk. >We have a great plans about list of important collections, but we also need your opinion about them. >So, feel free to make your suggestions about collections which you want to be implemented. The most important changes for me with collections have to do with the change from 32 to 64 bit. When we'll be able to access more memory, it doesn't make sense any more to have a backing store that is a single array. The switching to a more advanced backing store can be done transparently based on the size. I'm also interested in hybrid forms of the classic data structures that take less memory. There are several that normally waste much memory on pointers (binary trees, double linked list, tries) And then of course a Judy Array. Stephan

Dec. 17, 2014

Re: [Pharo-users] [ANN] RProjectConnector V1.0

by Blondeau Vincent

Hernan, I agree that it is a problem. To detect the R installation path is complicated. Under Windows, you should be able to extract a key in the registry to know where the program is installed. Under linux, as there is x64 and x32 R versions, and Pharo supports only x32 (but x64 soon), if you have a R x64 you should reinstall your whole Linux system to have the right libraries (I tried without successâ¦). I think that to set the libraries available to download on a server is currently a better idea. Do you know where it can be hosted? Cheers, Vincent De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de HernÃ¡n Morales Durand EnvoyÃ© : mardi 16 dÃ©cembre 2014 20:05 Ã : Any question about pharo is welcome Objet : Re: [Pharo-users] [ANN] RProjectConnector V1.0 Vincent, First of all, thank you for publishing such useful package. This is a very valuable contribution and I would be glad to contribute to the RProjectConnector project. There is one thing which bothers me: Having to manually copy the R library files (.dll or .so) is time-consuming and prevents unattended installation. In BioSmalltalk I am currently downloading library files supporting several URI locations by using Metacello. This is just adding a line in the #baseline: method spec preLoadDoIt: #preLoad. The problem could be incompatibility of versions between the R installed in the user's machine and the .dll/.so versions provided by the RProjectConnector. A better option is to detect the R installation path and copying the libraries to the pharo-vm/ directory. What do you think? Cheers, HernÃ¡n 2014-12-08 11:10 GMT-03:00 Blondeau Vincent <vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>>: Hello everyone, I am glad to announce the first version of the RProjectConnector, a binding between Pharo and R using NativeBoost. You can now call directly your R methods from Pharo: data := (1 to: 1000) collect: #yourself. res := (#acf asRFunctionWith: {data}) eval To use it, you should copy the R libraries near the Pharo VM (see the documentation on SmalltalkHub to see how to proceed) and Gofer it smalltalkhubUser: 'VincentBlondeau' project: 'RProjectConnector'; configuration; loadStable Donât forget to relaunch Pharo after the installation to be able to use the connector. The sources are available on Smalltalkhub: http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector if you want to participate, just ask me! 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. ________________________________ 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.

Dec. 17, 2014

Re: [Pharo-users] New Pharo Collections

by ClÃ©ment Bera

2014-12-17 7:42 GMT+01:00 Damien Cassou <damien.cassou(a)gmail.com>: > > > Le 16 dÃ©c. 2014 22:48, "dboeren" <boerend(a)gmail.com> a Ã©crit :. > > Off the top of my head, I would be interested in support for "slices" > > meaning taking being able to treat a subset of a larger > OrderedCollection as > > its own OrderedCollection rather than using copyFrom:to: to create a > > duplicate object to work with. It seems to me that this would be a more > > efficient method and should not be difficult to implement I think. > > Here is an email I sent about that : > > I see you are working on new collections for Pharo. That's great news, > I'm convinced we can do much better (even if what we already have is > already much better than what can be found in most other languages). > One thing you could work on is the notion of iterator. There are > plenty of ways to iterate over a collection: > > 1/ from the first to the last item > 2/ from the last to the first > 3/ from the 2nd item to the 5th > 4/ only even items (2, 4, 6, ...) > 5/ ... > > Currently, we have to create new collections to iterate in strange > ways. For example, to iterate from the last to the first item, we > create a new collection by sending #reversed to the original > collection. I think that is bad because it creates a copy and that > should not be necessary. > I don't understand that example. #reverseDo: do not create a copy and do not send reversed. To iterate over items from last to first I always do, as recommended in Smalltalk best practice pattern: mySequenceableCollection reverseDo: [:item | .. ]. #reverseDo: is implemented on SequenceableCollection but iterating from last to first item does not make sense in the case of non sequenceable collection. > What we miss is the notion of iterator. An > iterator is an object that is specialized in iterating over any kind > of collection and has methods like #select:, #reject:, #allSatisfy:. > From a collection, you can access different kinds of iterators > (reusing the same ordering as before): > > 1/ aCollection iterator > 2/ aCollection reverseIterator > 3/ aCollection from: 2 to: 5 > 4/ aCollection iterator select: [ :each | each isEven ] --> that > returns an iterator as well, so you can call #select:/#reject: > multiple times without creating any intermediate collection > 5/ ... > That makes sense and would be lovely. What is the syntax for multiple operations ? Have you already think and find something nice about it ? aCollection iterator select: [ :each | each isOdd ]; reject: [ :each | each is isPrime ]; iterate ??? Of course there are backward compatibility issue which needs to be very well adressed here or one would crash every single framework in the system. > Lukas Renggli implemented a prototype that looks really nice but is > unfinished: http://source.lukas-renggli.ch/unsorted/Container-lr.7.mcz. > > I think the notion of Sequences in Clojure is very related as well. > Sequence functions are very generic and can be applied to any kind of > collection. http://clojure.org/sequences >

Dec. 17, 2014

Re: [Pharo-users] New Pharo Collections

by Damien Cassou

Le 16 dÃ©c. 2014 22:48, "dboeren" <boerend(a)gmail.com> a Ã©crit :. > Off the top of my head, I would be interested in support for "slices" > meaning taking being able to treat a subset of a larger OrderedCollection as > its own OrderedCollection rather than using copyFrom:to: to create a > duplicate object to work with. It seems to me that this would be a more > efficient method and should not be difficult to implement I think. Here is an email I sent about that : I see you are working on new collections for Pharo. That's great news, I'm convinced we can do much better (even if what we already have is already much better than what can be found in most other languages). One thing you could work on is the notion of iterator. There are plenty of ways to iterate over a collection: 1/ from the first to the last item 2/ from the last to the first 3/ from the 2nd item to the 5th 4/ only even items (2, 4, 6, ...) 5/ ... Currently, we have to create new collections to iterate in strange ways. For example, to iterate from the last to the first item, we create a new collection by sending #reversed to the original collection. I think that is bad because it creates a copy and that should not be necessary. What we miss is the notion of iterator. An iterator is an object that is specialized in iterating over any kind of collection and has methods like #select:, #reject:, #allSatisfy:. >From a collection, you can access different kinds of iterators (reusing the same ordering as before): 1/ aCollection iterator 2/ aCollection reverseIterator 3/ aCollection from: 2 to: 5 4/ aCollection iterator select: [ :each | each isEven ] --> that returns an iterator as well, so you can call #select:/#reject: multiple times without creating any intermediate collection 5/ ... Lukas Renggli implemented a prototype that looks really nice but is unfinished: http://source.lukas-renggli.ch/unsorted/Container-lr.7.mcz. I think the notion of Sequences in Clojure is very related as well. Sequence functions are very generic and can be applied to any kind of collection. http://clojure.org/sequences

Dec. 17, 2014

Re: [Pharo-users] PetitParser and PPBrowser in Pharo 3.0

by Stephan Eggermont

Jan Kurs wrote: >Anyone experience with Athens can help with the first issue? TRLabelShape>>drawOn: seem to be somehow responsible, but I don't see into this :( Sure. The default fonts you ar easing are bitmap fonts. Roassal2 only works with FreeType fonts. If you open the settings, select appearance and open standard fonts, you'll probably see Bitmap DejaVu Sans. If you select one of the Source Code Fonts Predefined styles you might have better results. (Standard fonts are not updated correctly, you might have to close/open the Standard Font tree element for it to refresh). Stephan

Dec. 16, 2014

Re: [Pharo-users] New Pharo Collections

by dboeren

Sounds like a great idea for a project. Off the top of my head, I would be interested in support for "slices" meaning taking being able to treat a subset of a larger OrderedCollection as its own OrderedCollection rather than using copyFrom:to: to create a duplicate object to work with. It seems to me that this would be a more efficient method and should not be difficult to implement I think. -- View this message in context: http://forum.world.st/New-Pharo-Collections-tp4796132p4796156.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 16, 2014

Re: [Pharo-users] [ANN] RProjectConnector V1.0

by HernÃ¡n Morales Durand

Vincent, First of all, thank you for publishing such useful package. This is a very valuable contribution and I would be glad to contribute to the RProjectConnector project. There is one thing which bothers me: Having to manually copy the R library files (.dll or .so) is time-consuming and prevents unattended installation. In BioSmalltalk I am currently downloading library files supporting several URI locations by using Metacello. This is just adding a line in the #baseline: method spec preLoadDoIt: #preLoad. The problem could be incompatibility of versions between the R installed in the user's machine and the .dll/.so versions provided by the RProjectConnector. A better option is to detect the R installation path and copying the libraries to the pharo-vm/ directory. What do you think? Cheers, HernÃ¡n 2014-12-08 11:10 GMT-03:00 Blondeau Vincent <vincent.blondeau(a)worldline.com> : > > Hello everyone, > > > > I am glad to announce the first version of the RProjectConnector, a > binding between Pharo and R using NativeBoost. > > > > You can now call directly your R methods from Pharo: > > data := (1 to: 1000) collect: #yourself. > > res := (#acf asRFunctionWith: {data}) eval > > > > To use it, you should copy the R libraries near the Pharo VM (see the > documentation on SmalltalkHub to see how to proceed) and > > Gofer it > > smalltalkhubUser: 'VincentBlondeau' project: 'RProjectConnector'; > > configuration; > > loadStable > > Donât forget to relaunch Pharo after the installation to be able to use > the connector. > > > > The sources are available on Smalltalkhub: > > http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector > > > > if you want to participate, just ask me! > > > > 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. >

Dec. 16, 2014

Re: [Pharo-users] PetitParser and PPBrowser in Pharo 3.0

by Jan KurÅ¡

Hi, Anyone experience with Athens can help with the first issue? TRLabelShape>>drawOn: seem to be somehow responsible, but I don't see into this :( Regarding to the second issue, there are some cases, when one really needs a start rule, e.g when computing follow. Yet I updated the code so that it handles missing start rule a bit better. Please, let me know, if you have some other ideas/suggestions/issues. Regards, Jan On 9 December 2014 at 15:17, Hartmut <krasemann(a)acm.org> wrote: > > Hi to all, > > I'm working with PetitParser in a Pharo 3 image. > Until now I had to do without the PPBrowser which I loved in Pharo 2. > > On forum.world.st I now found the hint by Jan Kurs to install all of the > Petit suite: > > > "Configuration should be loaded like this:" > > Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; > > configurationOf: #PetitParser; load. > > > > "All the petit parser suite:" > > ConfigurationOfPetitParser loadDevelopment. > > Apart from the fact that this installed a real lot into my image, I notice > the following problems > in PPBrowser: > > 1. The map of none of the 18 parsers included, is displayed (it becomes > red crossed). > However, this was the most useful part of it > > 2. My interrelated parsers consist of a tree of parsers where each leave > has its own start clause. > They define related languages. It makes no sense to add a *start* > clause to the root. > However, without such a meaningless *start* clause, only the *source* > is displayed, > neither *graph, example, first* or *follow* of any clause. > (this can be reproduced when you move PPJsonGrammar>>start to > PPJsonParser) > > I like the style of having a grammar class above a parser (or compiler) > class. > This is as seen in most of the accompanying parsers. > My preferred petit parser style comprises: > a) keeping grammar rules (without ==>) in the upper classes of the > grammar hierarchy tree, > such that we find the complete grammar there (without the *start* > clause). > b) keeping replacement rules (using ==>) as low as possible the grammar > hierarchy tree > c) writing the start clause to the class that is actually called. (this > gives different entries > in a grammar allowing for different languages with grammar subsets) > > Is there an idea to have 1. and/or 2. resolved? > > Hartmut > > -- > Hartmut Krasemann > KÃ¶nigsberger Str. 41 c > â¨D 22869 Schenefeld > Tel. 040.8307097 > Mobil 0171.6451283â¨krasemann(a)acm.org > >

Dec. 16, 2014

Re: [Pharo-users] [Pharo-dev] how do you use scripts?

by Tudor Girba

Hi, On Tue, Dec 16, 2014 at 1:41 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2014-12-16 13:23 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> Just a clarification: >> Playground is saving after each change, not only after a Go. To some >> extent, it is some sort of duplication with the DoIt actions, but the >> Playground saves the entire code, not just the executed one. >> > > It doesn't make the distinction between a go on a selection or on the full > code? I'd wonder about the correctness of the save, then. > I do not understand what you mean. Playground saves all contents after each edit operation. So, you can open a Playground, type 42, close it without executing anything, and you will have a page with '42' contents. We used to have the saving triggered only on Go, but that was too brittle as sometimes you might close a Playground by mistake before executing anything. Does that make sense now? It saves the contents in a play-cache folder by default, but you can >> configure it to be in a central folder shared by multiple images. >> > > Ok. > > If we have a better log format than the changes, could all this (changes > and those scripts) be unified/integrated? > Indeed, that would be interesting. Cheers, Doru >> The idea is exactly to try to find a mechanism that is transparent and >> let's you play without worrying about save/load. We still have to refine >> the mechanism a bit though. >> >> Please also note that GTSpotter searches through past Playground pages >> which means that discovery is now easier than before. >> > > I expected that feature :) > > Thanks, > > Thierry > > >> >> Cheers, >> Doru >> >> On Tue, Dec 16, 2014 at 1:17 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >>> >>> >>> >>> 2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>> >>>> > On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier(a)gmail.com> >>>> wrote: >>>> > >>>> > >>>> > >>>> > 2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> > >>>> > >>>> > === >>>> > >>>> > We need something very low friction, like automatic >>>> saving/remembering. >>>> > >>>> > >>>> > Why not searching among the doit(s) stored in the changes? >>>> > >>>> > Thierry >>>> >>>> Yes, that combined with Workspace's 'Previous contents' and the new >>>> automatic saving of Playground after Go. >>>> >>> >>> Isn't the Playground saving after go a duplication of the Changes >>> recording of the associated doit? >>> >>> >>>> >>>> It just needs to become a really safe and dependable - so that you just >>>> know you can safely close a workspace/playground with an important script >>>> and always can get it back. >>>> >>> >>> I rebuilt my images regularly, so it could be nice to have that linked >>> to a repository. And yes, simple and dependable. Like in: there is no need >>> to explain how it works... Or that the how is obvious. >>> >>> Saving states of the workspaces / playground in a kind of log and doits >>> as actions on those? Visible in searches? Stored in the package cache? >>> Robust to multiple images use on it? >>> >>> Thierry >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 16, 2014