December 2014 - Pharo-users

Question about Morphic in Pharo 4

by nacho

Hi folks, I'm doing some project in Morphic in Pharo 3. I was wondering if big changes are expected in Moprhic in Pharo 4 or if it will remain relatively unchanged. Thanks in advance. Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 18, 2014

Re: [Pharo-users] PetitParser problem with plus

by Jan KurÅ¡

Exactly... This happens so often that we should add some warning somewhere in these cases.... Cheers, Jan On 18 December 2014 at 08:36, Guillaume Larcheveque < guillaume.larcheveque(a)gmail.com> wrote: > > So you just have to remove the #star in notA or replace it by #plus to > makes it succeed only when it consume at least one character > > 2014-12-18 7:54 GMT+01:00 Guillaume Larcheveque < > guillaume.larcheveque(a)gmail.com>: >> >> With x, x it will only go to 2 level deep. >> >> With the plus you allow to go as far as the x rule succeed and your x >> rule always succeed because notA always succeed due to the star without >> consuming anything so you fall into infinite loop. >> >> 2014-12-18 6:47 GMT+01:00 James Foster <Smalltalk(a)jgfoster.net>: >>> >>> There is something about plus that I donât understand. In the following >>> code if I parse for (x , x) then I get what I expect. If I parse for (x >>> plus) then the image hangs. What am I doing wrong? >>> >>> James >>> >>> | a notA x y | >>> a := $a asParser. >>> notA := $a asParser negate star flatten. >>> x := a / notA. >>> y := x , x. âworks fineâ >>> y := x plus. ânever finishesâ >>> ^y end parse: 'abâ. >>> >>> >>> >> >> -- >> *Guillaume Larcheveque* >> >> > > -- > *Guillaume Larcheveque* > >

Dec. 18, 2014

Re: [Pharo-users] PetitParser problem with plus

by Guillaume Larcheveque

So you just have to remove the #star in notA or replace it by #plus to makes it succeed only when it consume at least one character 2014-12-18 7:54 GMT+01:00 Guillaume Larcheveque < guillaume.larcheveque(a)gmail.com>: > > With x, x it will only go to 2 level deep. > > With the plus you allow to go as far as the x rule succeed and your x rule > always succeed because notA always succeed due to the star without > consuming anything so you fall into infinite loop. > > 2014-12-18 6:47 GMT+01:00 James Foster <Smalltalk(a)jgfoster.net>: >> >> There is something about plus that I donât understand. In the following >> code if I parse for (x , x) then I get what I expect. If I parse for (x >> plus) then the image hangs. What am I doing wrong? >> >> James >> >> | a notA x y | >> a := $a asParser. >> notA := $a asParser negate star flatten. >> x := a / notA. >> y := x , x. âworks fineâ >> y := x plus. ânever finishesâ >> ^y end parse: 'abâ. >> >> >> > > -- > *Guillaume Larcheveque* > > -- *Guillaume Larcheveque*

Dec. 18, 2014

Re: [Pharo-users] PetitParser problem with plus

by Guillaume Larcheveque

With x, x it will only go to 2 level deep. With the plus you allow to go as far as the x rule succeed and your x rule always succeed because notA always succeed due to the star without consuming anything so you fall into infinite loop. 2014-12-18 6:47 GMT+01:00 James Foster <Smalltalk(a)jgfoster.net>: > > There is something about plus that I donât understand. In the following > code if I parse for (x , x) then I get what I expect. If I parse for (x > plus) then the image hangs. What am I doing wrong? > > James > > | a notA x y | > a := $a asParser. > notA := $a asParser negate star flatten. > x := a / notA. > y := x , x. âworks fineâ > y := x plus. ânever finishesâ > ^y end parse: 'abâ. > > > -- *Guillaume Larcheveque*

Dec. 18, 2014

PetitParser problem with plus

by James Foster

There is something about plus that I donât understand. In the following code if I parse for (x , x) then I get what I expect. If I parse for (x plus) then the image hangs. What am I doing wrong? James | a notA x y | a := $a asParser. notA := $a asParser negate star flatten. x := a / notA. y := x , x. âworks fineâ y := x plus. ânever finishesâ ^y end parse: 'abâ.

Dec. 18, 2014

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