October 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Fossil and Filetree

by Hilaire

Le 22/10/2015 10:47, Thierry Goubier a Ã©crit : > Yes, I guess so. > > Still, with all the people interested by Fossil, I think the > motivation is there. And it would be nice to see a bit of refactoring > to decouple the format from the specific commands used for the > specific VCS. > > Thierry I started to look at it creating abstracted super classes. But RB (refactoring tool I guess) bumped on the middle, try again, then went fine, ouf! Any sandbox where to commit? Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Oct. 24, 2015

Re: [Pharo-users] Pharo family update

by Ferlicot D. Cyril

Le 24/10/2015 09:27, stepharo a Ã©crit : > Superb! Really nice > Margritte -> Magritte > Mondorian -> Mondrian > > to add > > Never heard about PharoLink but you should have Garage (a database > generic API) > > You could add MongoTalk close to Voyage > > GLORP > Relational > Mapper > > Woden 3D > Roassal3D > > Omnibrowser is deprecated > > I would put STON close to Fuel > May be you should move closer the two spots: import/export and data > > Tide is not developed anymore so I would remove it > Add Reef instead (Javascript-enabled Web components) > > About Graphics > > you should have > Athens (Vector graphics API) > Bloc (new generation Morphic) > Brick (new generation widgets) > > Hi, I do not agree to add Reef, Bloc and Brick now if this map is for beginners. If this map is for beginners that need a framework we should wait to have a usable version with documentation. I think Bloc and Brick are not finish yet (I think) and reef lack documentation/tutorial. If a beginner see it on the map and test it he will have a bad first impression. And first impression count. This project should be on a waiting list the time there are stable and documented I think. But this is just my opinion. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 24, 2015

Re: [Pharo-users] #collect:as:Dictionary

by Peter UhnÃ¡k

What is the practical value of creating a dictionary from non-association objects? That seems to me like the programmer made a mistake and forgot something. But maybe you do it regularly, I can only speak for myself. However consider also this: #(a b c) collect: [ :each | each -> each first asciiValue ] as: Dictionary. "a Dictionary(1->#a->97 2->#b->98 3->#c->99 )" (#(a b c) collect: [ :each | each -> each first asciiValue ]) as: Dictionary. "a Dictionary(#a->97 #b->98 #c->99 )" Peter On Sat, Oct 24, 2015 at 12:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2015-10-23 8:33 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> > On 23 Oct 2015, at 07:12, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > >> > Hi, >> > >> > is this intentional behavior? >> > >> > #(a b c) collect: [ :each | each -> each first asciiValue ] as: >> Dictionary. >> > "a Dictionary(1->#a->97 2->#b->98 3->#c->99 )" >> > >> > (#(a b c) collect: [ :each | each -> each first asciiValue ]) >> asDictionary. >> > "a Dictionary(#a->97 #b->98 #c->99 )" >> > >> > I would expect that collect:as: for Dictionaries would act in the same >> way as #asDictionary. >> > >> Yes, I would expect the sameâ¦ asDictionary is fairly recent, though. >> Before that, any kind >> of conversion would have been fine. >> >> Marcus >> >> >> > I would not change this. > The first just collects each entry and builds an association with the > index, > and the second expects a list of assocations. > They have different behaviors if the list does not contains (or does not > only contains) associations: > > { $a -> 1 . $b -> 2. 'not_an_association' } collect:#yourself > as:Dictionary. "works - I would not expect an error" > > { $a -> 1 . $b -> 2. 'not_an_association' } asDictionary "throws an error > - as I would expect it " > > >

Oct. 24, 2015

Re: [Pharo-users] How to programatically select an item in a Spec TreeModel ?

by Ferlicot D. Cyril

Le 24/10/2015 08:11, Peter UhnÃ¡k a Ã©crit : > Waiting for the FT-based rewrite is the thing to do. > > > If by waiting you mean doing FT-based rewrite, then sure. :) > > Unless Cyril is going to do the rewrite himself. > > P > Hi, Create a FTTree should be my next work :) I already begun a FTTree with one sublevel but this is only a first shot. I think it's possible to do cleaner and faster. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 24, 2015

Re: [Pharo-users] How to programatically select an item in a Spec TreeModel ?

by Thierry Goubier

Le 24 oct. 2015 12:07 PM, "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> a Ã©crit : >> >> > Unless Cyril is going to do the rewrite himself. >> Wasn't that the plan? I'm confused :) > > > Oh? I do not remember anyone mentioning on the mailing list that someone will change Spec to use FT. Or was this from some internal discussion at Inria/Synectique? Well, given FT, then Spec will change to use it. You don't want to keep two widly different implementations of the same widget. Now, there was talk of a FT-based tree widget, and, IMO, this is the way to go. Thierry > Peter

Oct. 24, 2015

Re: [Pharo-users] #collect:as:Dictionary

by Nicolai Hess

2015-10-23 8:33 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 23 Oct 2015, at 07:12, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > is this intentional behavior? > > > > #(a b c) collect: [ :each | each -> each first asciiValue ] as: > Dictionary. > > "a Dictionary(1->#a->97 2->#b->98 3->#c->99 )" > > > > (#(a b c) collect: [ :each | each -> each first asciiValue ]) > asDictionary. > > "a Dictionary(#a->97 #b->98 #c->99 )" > > > > I would expect that collect:as: for Dictionaries would act in the same > way as #asDictionary. > > > Yes, I would expect the sameâ¦ asDictionary is fairly recent, though. > Before that, any kind > of conversion would have been fine. > > Marcus > > > I would not change this. The first just collects each entry and builds an association with the index, and the second expects a list of assocations. They have different behaviors if the list does not contains (or does not only contains) associations: { $a -> 1 . $b -> 2. 'not_an_association' } collect:#yourself as:Dictionary. "works - I would not expect an error" { $a -> 1 . $b -> 2. 'not_an_association' } asDictionary "throws an error - as I would expect it "

Oct. 24, 2015

Re: [Pharo-users] How to programatically select an item in a Spec TreeModel ?

by Peter UhnÃ¡k

> > > Unless Cyril is going to do the rewrite himself. > Wasn't that the plan? I'm confused :) Oh? I do not remember anyone mentioning on the mailing list that someone will change Spec to use FT. Or was this from some internal discussion at Inria/Synectique? Peter

Oct. 24, 2015

Re: [Pharo-users] How to programatically select an item in a Spec TreeModel ?

by Edouard KLEIN

Thank you very much ! Le ven. 23 oct. 2015 Ã 21:03, Peter UhnÃ¡k <i.uhnak(a)gmail.com> a Ã©crit : > It's also possible that it is simply bugged. > > PackageRemotesManager doesn't use TreeModel, it uses different widget > (whose API looks cleaner). > > I'll try to look at this tomorrow (unless someone else beats me to it) how > this could be done (and maybe even take a stab at cleaning the API a > bit...). > > Peter > > On Fri, Oct 23, 2015 at 5:17 PM, Edouard KLEIN <edouardklein(a)gmail.com> > wrote: > >> Hi ! >> >> I've been playing with Pharo again. In the application I'm building, I >> need to load a file from disk, and depending on what is inside this >> file, select an item in a tree that is displayed on the main window. >> >> The SearchableTree subclass I use is copied at the end of the email. It >> is nothing fancy, just creating the nodes from a fixed tree structure. >> >> The method selectedItemFRomPathArray (e.g. #('a' 'a1')) is the one that >> should be responsible for selecting the node, but for now it just >> returns the array of TreeNodeModel that correspond to the strings in the >> 'PathArray' given in argument. >> >> I tried the following in a PlayGround : >> >> w := CRPJCategories2 new. w openWithSpec. >> "Taken from packageRemotesManager without understanding it." >> w tree selectedItem:( >> (w roots) first "This line can also be : >> ((w selectedItemFromPathArray:#('a')) last)" >> selected:true; >> takeHighlight; >> yourself). >> >> Which works, but when I try to select something that is not a root node, >> then it does not work, and I've been pulling my hair trying to >> understand why. >> >> w := CRPJCategories2 new. w openWithSpec. >> "Taken from packageRemotesManager without understanding it." >> w tree selectedItem:( >> ((w selectedItemFromPathArray:#('a' 'a1')) last) "<- DOES NOT WORK" >> selected:true; >> takeHighlight; >> yourself). >> >> >> Any pointer would be very much appreciated. >> >> Thenks in advance. >> >> Edouard. >> >> >> >> >> ------------------------------------------------------- >> 'From Pharo4.0 of 18 March 2013 [Latest update: #40623] on 23 October >> 2015 at 4:55:07.823126 pm'! >> SearchableTree subclass: #CRPJCategories2 >> instanceVariableNames: 'structure' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'CRPJ'! >> >> !CRPJCategories2 methodsFor: 'as yet unclassified' stamp: 'EdouardKlein >> 10/23/2015 15:29'! >> nodeFromTreeStructure: anArray >> ^ (anArray collect:[:x| TreeNodeModel new >> content: (x at:1); >> children: [((x size = 1) ifTrue:[#()] ifFalse:[self >> nodeFromTreeStructure:(x at:2)])]; >> hasChildren:[x size > 1]]) asOrderedCollection.! ! >> >> !CRPJCategories2 methodsFor: 'as yet unclassified' stamp: 'EdouardKlein >> 10/23/2015 15:10'! >> initialize >> | | >> super initialize. >> structure := { >> {'a' . { >> {'a1'}. >> {'a2'}}}. >> {'b' . { >> {'b1' . { >> {'b1A'}. >> {'b1B'}}}. >> {'b2'}. >> {'b3' . { >> {'b3A'}. >> {'b3B'}}}}}. >> {'c' . { >> {'c1'}. >> {'c2'}. >> {'c3'}}}}. >> self roots:(self nodeFromTreeStructure: structure).! ! >> >> !CRPJCategories2 methodsFor: 'as yet unclassified' stamp: 'EdouardKlein >> 10/23/2015 16:54'! >> selectedItemFromPathArray:aPathArray >> "a string description of the currently selected item" >> | recurse | >> recurse := [:path :nodes| >> |nextNode| >> nextNode := (nodes select:[:n| n content = path first]) >> first. >> (path size = 1) ifTrue:[{nextNode}] ifFalse:[ >> {nextNode},(recurse value:(path >> allButFirst)value:(nextNode children >> value))]]. >> ^(recurse value: aPathArray value:(self roots)).! ! >> >> !CRPJCategories2 methodsFor: 'as yet unclassified' stamp: 'EdouardKlein >> 10/23/2015 16:53'! >> selectedItemAsPathArray >> "an array of the path to the currently selected item" >> | recurse | >> recurse := [:node| node ifNil:[{}] >> ifNotNil:[(recurse value:(node >> parentNode)),{node}]]. >> ^(recurse value:self selectedItem) collect:[:node| node >> content].! ! >> >> >

Oct. 24, 2015

Re: [Pharo-users] Fossil and Filetree

by Hilaire

I will write you if needed, I am not there yet. Hilaire Le 22/10/2015 22:51, Dale Henrichs a Ã©crit : > Hilaire, if you are interested in contributing, I would be willing to > add you to the FileTree project up on GitHub ... Oops, unless you > don't want to be:) > > Dale > > On 10/22/2015 01:40 AM, Hilaire wrote: >> Le 21/10/2015 22:03, Thierry Goubier a Ã©crit : >>> Just use the ConfigurationOfGitFileTree available in your >>> Configuration browser in the image ;) >>> >>> Or >>> >>> Metacello new >>> configuration: 'GitFileTree'; >>> repository: >>> 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main'; >>> load >>> >>> Thierry >> Okay, thanks. >> Not sure I can handle it right now, there are a lot of know-how about >> git and fossil implicated. >> >> Hilaire >> > > > -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Oct. 24, 2015

Re: [Pharo-users] Pharo family update

by Hilaire

Le 23/10/2015 23:58, Adam a Ã©crit : > I just updated drawing of projects around Pharo. Wow, It is simply M-A-R-V-E-L-L-O-U-S, really. You put in a clear and elegant way the Pharo ecosystem. Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Oct. 24, 2015