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

Re: [Pharo-users] Protocol selection erratic behaviour

by Sergio Fedi

Let me see if I understand what you are saying. The category "setter" exists, but it's an automatically generated one (as well as others, I suppose). So it doesn't appear in the protocol selection window, because that window only lists protocols created manually. Is that what you where saying?

June 5, 2015

Re: [Pharo-users] loading Coral from SmalltalkHub

by Francisco Garau

Thanks Stefan. I am playing with the Coral image downloaded from the CI site. On 4 June 2015 at 20:08, stepharo <stepharo(a)free.fr> wrote: > Thanks Stefan > > Francisco there is nothing new in Coral we got stalled again because we > focused on pillar. > > Stef > > Le 4/6/15 11:20, Stephan Eggermont a Ã©crit : > > On 04-06-15 01:46, Francisco Garau wrote: >> >>> I've tried loading Coral by following the below instructions in its >>> website <http://rmod.lille.inria.fr/coral/getting-started.html> but they >>> failed when trying to load Readline. >>> >>> Gofer new url: 'http://ss3.gemstone.com/ss/coral'; >>> package: 'ConfigurationOfCoral'; >>> load. >>> >>> ConfigurationOfCoral loadDevelopment. >>> >> >> Yes, that is an old configuration. I've updated it >> on smalltalkhub: PharoExtras/Coral, but that was before >> the release of Pharo4. CDLM, Damien C and Stef have worked >> on it this year. >> >> As PetitParser still uses the >> #stable and #development style of symbolic naming, >> instead of #release5.1, things can break when a new >> version of Moose is released. >> >> It seems the project was moved to Smalltalk Hub >>> (http://smalltalkhub.com/#!/~PharoExtras/Coral/) >>> >>> What expressions should I evaluate in a Pharo5 image to get the latest >>> Coral project loaded. >>> >> >> I've added a Pharo 5 build to >> https://ci.inria.fr/pharo-contribution/job/Coral/ >> The 4 and 5 builds are green >> >> I've also added a Pharo4 and Pharo5 build to OSProcess >> https://ci.inria.fr/pharo-contribution/job/OSProcess/ >> The 4 and 5 builds each have 3 failures >> >> It is possible that some changes to the parser are needed >> due to improvements in PetitParser. I ran into that last >> time I tried, and forgot whether that got fixed. >> >> Stephan >> >> >> >> >> >> > >

June 5, 2015

Re: [Pharo-users] collectionDo: vs. collection do:

by Ben Coman

Considering one of the tenants of OO is information-hiding**, then #linesDo: seems preferable. But I guess the problem is consistently implementing *all* the collection protocols. It might be interesting to have a kind-of Trait that applies to a single instance variable, that prefixes the Trait's method names with the ivar (or custom) name. ** But if the collection is returned to outside the object, its a bit of a mute point - and anyway anyone add an extension method that does this. cheers -ben On Fri, Jun 5, 2015 at 3:39 AM, stepharo <stepharo(a)free.fr> wrote: > Hi peter > > often xxx do: creates an intermediary collection while xxxDo: don't > > Stef > > Le 4/6/15 21:24, Peter UhnÃ¡k a Ã©crit : > >> Hi, >> >> is there some best practice about >> collectionDo: >> versus >> collection do: >> ? >> >> I see many times the first used (e.g. String>>linesDo:); I see a benefit >> if there is no accessor to the collection, but more times than not there >> actually is. >> From my perspective it further pollutes the protocol and as a user of such >> method I will never be sure what to actually use without looking at the >> implementation to see if there is any actual difference. >> >> So is there some consensus on this? >> >> Thanks, >> Peter > > >

June 5, 2015

Re: [Pharo-users] Pharo Video Tutorial: Package Tags

by Dimitris Chloupis

how that would improve Pharo ? On Thu, Jun 4, 2015 at 10:30 PM stepharo <stepharo(a)free.fr> wrote: > Guys > > I would not use sub-packages. Think about newbies please. > We have packages and tags and ideally I would remove tags but we will > not because else people will cry. > > Stef > > Le 3/6/15 12:30, Sergio Fedi a Ã©crit : > > Since Tags have a different behaviour than Packages, I think we should. > > (specially when adding comments, which Packages support and Tags don't) > > > > â > > >

June 4, 2015

Re: [Pharo-users] Visualizing a repository tree

by Alexandre Bergel

> Objects are magical :) Yes, and this is absolutely mind blowing. Understanding that a mouse click is most of the time an action to inspect is absolutely a step forward. I feel we are still at the very beginning. It would be nice to see how this will evolve over the time... Alexandre > > On Thu, Jun 4, 2015 at 10:04 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Yeah, this thing. :) > > <2015-06-04_22:02:31.png> > > I mean I knew I could program it, but I was just surprised that it did it automatically, which is cool :) > > Peter > â > > On Thu, Jun 4, 2015 at 9:54 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > You mean that when you click on a node while you inspecting the view you get a new pane to the right with that object? > > Doru > > On Thu, Jun 4, 2015 at 7:16 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Omg I just found out that if I click on the node representing an McVersionInfo it actually opens it in the inspector and I didn't even needed to implement anything special. > That's really cool! > > Peter > > On Tue, Jun 2, 2015 at 6:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Interesting visualization! Keep going! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jun 2, 2015, at 10:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> On Tue, Jun 2, 2015 at 3:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Interesting. The dominance tree layout is quite interesting for this use case. >> >> There were some upward lines at the bottom of the graph for no apparent reason, not sure what was going on there yet, so I'll look into the layout when I have more time. >> >> Alternatively you could also use Sugiyama, however either due to the choice of heuristics, or some bug it places high priority on last levels which is really bad (since it is no longer at proper hierarchical layers). >> >> Peter >> >> >> Doru >> >> On Tue, Jun 2, 2015 at 12:09 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> HI Offray, >> >> I gave it a quick bash and come up with the following code. It's just a prototype and could be greatly simplified. >> >> - MCVersionInfo ancestors for whatever reason returned empty array down the line (so its cut off at the end), but I didn't investigate the problem >> - edge building and possibly ancestor retrieval could be simplified with builders; I think RTMondrian has methods for it but can't remember exactly (agilevisualization mentioned RTGraphBuilder but that has been removed to my knowledge) >> >> ~~~~~~~~~~~~~~~ >> mc := MCSmalltalkhubRepository allInstances detect: [ :m | m project = 'Roassal2' ]. >> >> root := mc versionInfoFromFileNamed: mc readableFileNames first. >> >> family := Set new. >> retriever := nil. >> retriever := [ :child | >> family add: child. >> child ancestors do: [ :a | retriever value: a ] >> ]. >> retriever value: root. >> obs := family asGroup. >> >> v := RTView new. >> es := RTEllipse new size: 15; color: Color blue; elementsOn: obs. >> v addAll: es. >> >> edges := RTEdge >> buildEdgesFromObjects: obs >> from: #yourself >> toAll: #ancestors >> using: (RTArrowedLine new withShorterDistanceAttachPoint; color: Color red) >> scope: es. >> v addAll: edges. >> >> es @ RTDraggable. >> es @ (RTLabelled new text: [ :m | m nameWithout: 'Roassal2' ]). >> >> v @ RTDraggableView. >> v @ RTZoomableView. >> >> RTDominanceTreeLayout new >> verticalGap: 30; >> horizontalGap: 15; >> on: es. >> >> v open >> ~~~~~~~~~~~~~~~~ >> >> >> <2015-06-02_12:04:32.png> >> >> Cheers, >> Peter >> â >> >> On Tue, Jun 2, 2015 at 5:39 AM, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: >> Hi, >> >> On a closer detail, seems that [1] contains the starting point I'm looking for. I'll keep you posted and of course any other approach will be listened. >> >> [1] https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… >> >> Cheers, >> >> Offray >> >> >> On 01/06/15 22:04, Offray Vladimir Luna CÃ¡rdenas wrote: >> Hi all, >> >> I had asked a similar question before with no much advances, but today I made a discovery that can improve the things a lot: how to export timeline data as structured JSON [1] (and of course this open the possibility to work with it on Pharo). Now I would like to graph the data as a tree with forks, merges and dates and authors of commits. I have seen chronia, but seems overkill for this feature (and is integrated with CVS only). >> >> [1] http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeli… >> >> As usual, any pointer on how to get this going will be greatly appreciated and I will give feedback to the community on how to do it. >> >> Cheers, >> >> Offray >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 4, 2015

Re: [Pharo-users] Visualizing a repository tree

by Tudor Girba

Objects are magical :) Doru On Thu, Jun 4, 2015 at 10:04 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Yeah, this thing. :) > > > I mean I knew I could program it, but I was just surprised that it did it > automatically, which is cool :) > > Peter > â > > On Thu, Jun 4, 2015 at 9:54 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> You mean that when you click on a node while you inspecting the view you >> get a new pane to the right with that object? >> >> Doru >> >> On Thu, Jun 4, 2015 at 7:16 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Omg I just found out that if I click on the node representing an >>> McVersionInfo it actually opens it in the inspector and I didn't even >>> needed to implement anything special. >>> That's really cool! >>> >>> Peter >>> >>> On Tue, Jun 2, 2015 at 6:59 PM, Alexandre Bergel < >>> alexandre.bergel(a)me.com> wrote: >>> >>>> Interesting visualization! Keep going! >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> On Jun 2, 2015, at 10:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>> >>>> On Tue, Jun 2, 2015 at 3:07 PM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>> >>>>> Interesting. The dominance tree layout is quite interesting for this >>>>> use case. >>>>> >>>> >>>> There were some upward lines at the bottom of the graph for no apparent >>>> reason, not sure what was going on there yet, so I'll look into the layout >>>> when I have more time. >>>> >>>> Alternatively you could also use Sugiyama, however either due to the >>>> choice of heuristics, or some bug it places high priority on last levels >>>> which is really bad (since it is no longer at proper hierarchical layers). >>>> >>>> Peter >>>> >>>> >>>>> Doru >>>>> >>>>> On Tue, Jun 2, 2015 at 12:09 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> >>>>> wrote: >>>>> >>>>>> HI Offray, >>>>>> >>>>>> I gave it a quick bash and come up with the following code. It's just >>>>>> a prototype and could be greatly simplified. >>>>>> >>>>>> - MCVersionInfo ancestors for whatever reason returned empty array >>>>>> down the line (so its cut off at the end), but I didn't investigate the >>>>>> problem >>>>>> - edge building and possibly ancestor retrieval could be simplified >>>>>> with builders; I think RTMondrian has methods for it but can't remember >>>>>> exactly (agilevisualization mentioned RTGraphBuilder but that has been >>>>>> removed to my knowledge) >>>>>> >>>>>> ~~~~~~~~~~~~~~~ >>>>>> mc := MCSmalltalkhubRepository allInstances detect: [ :m | m project >>>>>> = 'Roassal2' ]. >>>>>> >>>>>> root := mc versionInfoFromFileNamed: mc readableFileNames first. >>>>>> >>>>>> family := Set new. >>>>>> retriever := nil. >>>>>> retriever := [ :child | >>>>>> family add: child. >>>>>> child ancestors do: [ :a | retriever value: a ] >>>>>> ]. >>>>>> retriever value: root. >>>>>> obs := family asGroup. >>>>>> >>>>>> v := RTView new. >>>>>> es := RTEllipse new size: 15; color: Color blue; elementsOn: obs. >>>>>> v addAll: es. >>>>>> >>>>>> edges := RTEdge >>>>>> buildEdgesFromObjects: obs >>>>>> from: #yourself >>>>>> toAll: #ancestors >>>>>> using: (RTArrowedLine new withShorterDistanceAttachPoint; color: >>>>>> Color red) >>>>>> scope: es. >>>>>> v addAll: edges. >>>>>> >>>>>> es @ RTDraggable. >>>>>> es @ (RTLabelled new text: [ :m | m nameWithout: 'Roassal2' ]). >>>>>> >>>>>> v @ RTDraggableView. >>>>>> v @ RTZoomableView. >>>>>> >>>>>> RTDominanceTreeLayout new >>>>>> verticalGap: 30; >>>>>> horizontalGap: 15; >>>>>> on: es. >>>>>> >>>>>> v open >>>>>> ~~~~~~~~~~~~~~~~ >>>>>> >>>>>> >>>>>> <2015-06-02_12:04:32.png> >>>>>> >>>>>> Cheers, >>>>>> Peter >>>>>> â >>>>>> >>>>>> On Tue, Jun 2, 2015 at 5:39 AM, Offray Vladimir Luna CÃ¡rdenas < >>>>>> offray(a)riseup.net> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On a closer detail, seems that [1] contains the starting point I'm >>>>>>> looking for. I'll keep you posted and of course any other approach will be >>>>>>> listened. >>>>>>> >>>>>>> [1] >>>>>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Offray >>>>>>> >>>>>>> >>>>>>> On 01/06/15 22:04, Offray Vladimir Luna CÃ¡rdenas wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I had asked a similar question before with no much advances, but >>>>>>>> today I made a discovery that can improve the things a lot: how to export >>>>>>>> timeline data as structured JSON [1] (and of course this open the >>>>>>>> possibility to work with it on Pharo). Now I would like to graph the data >>>>>>>> as a tree with forks, merges and dates and authors of commits. I have seen >>>>>>>> chronia, but seems overkill for this feature (and is integrated with CVS >>>>>>>> only). >>>>>>>> >>>>>>>> [1] >>>>>>>> http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeli… >>>>>>>> >>>>>>>> As usual, any pointer on how to get this going will be greatly >>>>>>>> appreciated and I will give feedback to the community on how to do it. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Offray >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

June 4, 2015

Re: [Pharo-users] Visualizing a repository tree

by Peter UhnÃ¡k

Yeah, this thing. :) I mean I knew I could program it, but I was just surprised that it did it automatically, which is cool :) Peter â On Thu, Jun 4, 2015 at 9:54 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > You mean that when you click on a node while you inspecting the view you > get a new pane to the right with that object? > > Doru > > On Thu, Jun 4, 2015 at 7:16 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Omg I just found out that if I click on the node representing an >> McVersionInfo it actually opens it in the inspector and I didn't even >> needed to implement anything special. >> That's really cool! >> >> Peter >> >> On Tue, Jun 2, 2015 at 6:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com >> > wrote: >> >>> Interesting visualization! Keep going! >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> On Jun 2, 2015, at 10:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>> On Tue, Jun 2, 2015 at 3:07 PM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Interesting. The dominance tree layout is quite interesting for this >>>> use case. >>>> >>> >>> There were some upward lines at the bottom of the graph for no apparent >>> reason, not sure what was going on there yet, so I'll look into the layout >>> when I have more time. >>> >>> Alternatively you could also use Sugiyama, however either due to the >>> choice of heuristics, or some bug it places high priority on last levels >>> which is really bad (since it is no longer at proper hierarchical layers). >>> >>> Peter >>> >>> >>>> Doru >>>> >>>> On Tue, Jun 2, 2015 at 12:09 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>> >>>>> HI Offray, >>>>> >>>>> I gave it a quick bash and come up with the following code. It's just >>>>> a prototype and could be greatly simplified. >>>>> >>>>> - MCVersionInfo ancestors for whatever reason returned empty array >>>>> down the line (so its cut off at the end), but I didn't investigate the >>>>> problem >>>>> - edge building and possibly ancestor retrieval could be simplified >>>>> with builders; I think RTMondrian has methods for it but can't remember >>>>> exactly (agilevisualization mentioned RTGraphBuilder but that has been >>>>> removed to my knowledge) >>>>> >>>>> ~~~~~~~~~~~~~~~ >>>>> mc := MCSmalltalkhubRepository allInstances detect: [ :m | m project = >>>>> 'Roassal2' ]. >>>>> >>>>> root := mc versionInfoFromFileNamed: mc readableFileNames first. >>>>> >>>>> family := Set new. >>>>> retriever := nil. >>>>> retriever := [ :child | >>>>> family add: child. >>>>> child ancestors do: [ :a | retriever value: a ] >>>>> ]. >>>>> retriever value: root. >>>>> obs := family asGroup. >>>>> >>>>> v := RTView new. >>>>> es := RTEllipse new size: 15; color: Color blue; elementsOn: obs. >>>>> v addAll: es. >>>>> >>>>> edges := RTEdge >>>>> buildEdgesFromObjects: obs >>>>> from: #yourself >>>>> toAll: #ancestors >>>>> using: (RTArrowedLine new withShorterDistanceAttachPoint; color: Color >>>>> red) >>>>> scope: es. >>>>> v addAll: edges. >>>>> >>>>> es @ RTDraggable. >>>>> es @ (RTLabelled new text: [ :m | m nameWithout: 'Roassal2' ]). >>>>> >>>>> v @ RTDraggableView. >>>>> v @ RTZoomableView. >>>>> >>>>> RTDominanceTreeLayout new >>>>> verticalGap: 30; >>>>> horizontalGap: 15; >>>>> on: es. >>>>> >>>>> v open >>>>> ~~~~~~~~~~~~~~~~ >>>>> >>>>> >>>>> <2015-06-02_12:04:32.png> >>>>> >>>>> Cheers, >>>>> Peter >>>>> â >>>>> >>>>> On Tue, Jun 2, 2015 at 5:39 AM, Offray Vladimir Luna CÃ¡rdenas < >>>>> offray(a)riseup.net> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On a closer detail, seems that [1] contains the starting point I'm >>>>>> looking for. I'll keep you posted and of course any other approach will be >>>>>> listened. >>>>>> >>>>>> [1] >>>>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Offray >>>>>> >>>>>> >>>>>> On 01/06/15 22:04, Offray Vladimir Luna CÃ¡rdenas wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I had asked a similar question before with no much advances, but >>>>>>> today I made a discovery that can improve the things a lot: how to export >>>>>>> timeline data as structured JSON [1] (and of course this open the >>>>>>> possibility to work with it on Pharo). Now I would like to graph the data >>>>>>> as a tree with forks, merges and dates and authors of commits. I have seen >>>>>>> chronia, but seems overkill for this feature (and is integrated with CVS >>>>>>> only). >>>>>>> >>>>>>> [1] >>>>>>> http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeli… >>>>>>> >>>>>>> As usual, any pointer on how to get this going will be greatly >>>>>>> appreciated and I will give feedback to the community on how to do it. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Offray >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 4, 2015

Re: [Pharo-users] Visualizing a repository tree

by Tudor Girba

You mean that when you click on a node while you inspecting the view you get a new pane to the right with that object? Doru On Thu, Jun 4, 2015 at 7:16 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Omg I just found out that if I click on the node representing an > McVersionInfo it actually opens it in the inspector and I didn't even > needed to implement anything special. > That's really cool! > > Peter > > On Tue, Jun 2, 2015 at 6:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >> Interesting visualization! Keep going! >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> On Jun 2, 2015, at 10:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> On Tue, Jun 2, 2015 at 3:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Interesting. The dominance tree layout is quite interesting for this use >>> case. >>> >> >> There were some upward lines at the bottom of the graph for no apparent >> reason, not sure what was going on there yet, so I'll look into the layout >> when I have more time. >> >> Alternatively you could also use Sugiyama, however either due to the >> choice of heuristics, or some bug it places high priority on last levels >> which is really bad (since it is no longer at proper hierarchical layers). >> >> Peter >> >> >>> Doru >>> >>> On Tue, Jun 2, 2015 at 12:09 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>>> HI Offray, >>>> >>>> I gave it a quick bash and come up with the following code. It's just a >>>> prototype and could be greatly simplified. >>>> >>>> - MCVersionInfo ancestors for whatever reason returned empty array down >>>> the line (so its cut off at the end), but I didn't investigate the problem >>>> - edge building and possibly ancestor retrieval could be simplified >>>> with builders; I think RTMondrian has methods for it but can't remember >>>> exactly (agilevisualization mentioned RTGraphBuilder but that has been >>>> removed to my knowledge) >>>> >>>> ~~~~~~~~~~~~~~~ >>>> mc := MCSmalltalkhubRepository allInstances detect: [ :m | m project = >>>> 'Roassal2' ]. >>>> >>>> root := mc versionInfoFromFileNamed: mc readableFileNames first. >>>> >>>> family := Set new. >>>> retriever := nil. >>>> retriever := [ :child | >>>> family add: child. >>>> child ancestors do: [ :a | retriever value: a ] >>>> ]. >>>> retriever value: root. >>>> obs := family asGroup. >>>> >>>> v := RTView new. >>>> es := RTEllipse new size: 15; color: Color blue; elementsOn: obs. >>>> v addAll: es. >>>> >>>> edges := RTEdge >>>> buildEdgesFromObjects: obs >>>> from: #yourself >>>> toAll: #ancestors >>>> using: (RTArrowedLine new withShorterDistanceAttachPoint; color: Color >>>> red) >>>> scope: es. >>>> v addAll: edges. >>>> >>>> es @ RTDraggable. >>>> es @ (RTLabelled new text: [ :m | m nameWithout: 'Roassal2' ]). >>>> >>>> v @ RTDraggableView. >>>> v @ RTZoomableView. >>>> >>>> RTDominanceTreeLayout new >>>> verticalGap: 30; >>>> horizontalGap: 15; >>>> on: es. >>>> >>>> v open >>>> ~~~~~~~~~~~~~~~~ >>>> >>>> >>>> <2015-06-02_12:04:32.png> >>>> >>>> Cheers, >>>> Peter >>>> â >>>> >>>> On Tue, Jun 2, 2015 at 5:39 AM, Offray Vladimir Luna CÃ¡rdenas < >>>> offray(a)riseup.net> wrote: >>>> >>>>> Hi, >>>>> >>>>> On a closer detail, seems that [1] contains the starting point I'm >>>>> looking for. I'll keep you posted and of course any other approach will be >>>>> listened. >>>>> >>>>> [1] >>>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… >>>>> >>>>> Cheers, >>>>> >>>>> Offray >>>>> >>>>> >>>>> On 01/06/15 22:04, Offray Vladimir Luna CÃ¡rdenas wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I had asked a similar question before with no much advances, but >>>>>> today I made a discovery that can improve the things a lot: how to export >>>>>> timeline data as structured JSON [1] (and of course this open the >>>>>> possibility to work with it on Pharo). Now I would like to graph the data >>>>>> as a tree with forks, merges and dates and authors of commits. I have seen >>>>>> chronia, but seems overkill for this feature (and is integrated with CVS >>>>>> only). >>>>>> >>>>>> [1] >>>>>> http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeli… >>>>>> >>>>>> As usual, any pointer on how to get this going will be greatly >>>>>> appreciated and I will give feedback to the community on how to do it. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Offray >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

June 4, 2015

Re: [Pharo-users] Pharo Video Tutorial: Package Tags

by Peter UhnÃ¡k

On Wed, Jun 3, 2015 at 1:19 PM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > If something is a tag, then you should be able to apply multiple tags to > something. > Well you sort-of can do that. Consider how many packages have tag "Tests" in it. They don't need to be globally unique and it makes sense to use the very same tag in different packages... so at least for me tag is perfectly fitting name. On Thu, Jun 4, 2015 at 9:35 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 04/06/2015 21:30, stepharo a Ã©crit : > >> Guys >> >> I would not use sub-packages. Think about newbies please. >> We have packages and tags and ideally I would remove tags but we will >> not because else people will cry. >> > Why would you want to remove them? What is the damage they are incurring? I find them very useful for organization and judging by packages of other people I am not alone. Peter

June 4, 2015

Re: [Pharo-users] collectionDo: vs. collection do:

by stepharo

Hi peter often xxx do: creates an intermediary collection while xxxDo: don't Stef Le 4/6/15 21:24, Peter UhnÃ¡k a Ã©crit : > Hi, > > is there some best practice about > collectionDo: > versus > collection do: > ? > > I see many times the first used (e.g. String>>linesDo:); I see a > benefit if there is no accessor to the collection, but more times than > not there actually is. > From my perspective it further pollutes the protocol and as a user of > such method I will never be sure what to actually use without looking > at the implementation to see if there is any actual difference. > > So is there some consensus on this? > > Thanks, > Peter

June 4, 2015