- Pharo-users - lists.pharo.org

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

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

by Thierry Goubier

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. I would cry because I remember Pharo going through the RPackage without tags idea and how it was killed and replaced by RPackage + Tags. (It's there somewhere in AltBrowser github history, along with the Spec version of AltBrowser... looked and felt exactly like today's packageName + tags, by the way ) Thierry > > 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] Pharo Video Tutorial: Package Tags

by stepharo

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

collectionDo: vs. collection do:

by Peter UhnÃ¡k

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