- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] git, packages, and package dependencies (also migration from sthub to git)

by Luke Gorrie

On 1 July 2017 at 13:28, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > after many-o-hours spent on my git-migration tool ( > https://github.com/peteruhnak/git-migration ), I've concluded that the > migration cannot be properly done for packages. > Let us hope this effort can be salvaged! > In mcz/monticello, every package has an independent history and can change > independently of each other. > In git, this history is merged into a single hierarchy, therefore: > Git does not strictly require you to put all of your commits into a single hierarchy. You can also have multiple root commits in the same repository i.e. multiple parallel hierarchies of commits. Then you can combine these together with merge commits if/when you want to have them in the same tree (afaik.) See 'git commit --orphan' for introducing a new root commit into the repo. So thinking aloud... Perhaps for each package could you create a dedicated branch (A, B, ...) with its own root commit? This way each package would have a distinct history on its private branch and not be prone to collisions. If you want to combine multiple packages into one tree then you could create a new branch (A+B) that merges the required per-package branches (which remain isolated and pristine.) Just an idea -- sorry if I have misunderstood your use case, and let me know if this idea requires more explanation. Cheers, -Luke

July 1, 2017

Re: [Pharo-dev] Baseline question

by Julien Delplanque

Hello, To do my baselines I do the following: 1. I create a subclass of BaselineOf. 2. I create an instance method #baseline: baseline: spec <baseline> spec for: #common do: [ self defineDependencies: spec; definePackages: spec ] 3. I create the #defineDependencies: instance method (for example in SFDiff): defineDependencies: spec ^ spec project: 'ChangeModel' with: [ spec className: 'ConfigurationOfFamixDiff'; version: #development; repository: 'http://smalltalkhub.com/mc/Moose/FamixDiff/main'; loads: 'ChangeModel' ]; project: 'FamixDiff' with: [ spec className: 'ConfigurationOfFamixDiff'; version: #development; repository: 'http://smalltalkhub.com/mc/Moose/FamixDiff/main'; loads: 'Core' ]; yourself 4. I create the #definePackages: instance method (still for SFDiff): definePackages: spec ^ spec package: 'SimilarityFlooding' with: [ spec requires: #('ChangeModel') ]; package: 'SimilarityFlooding-Tests' with: [ spec requires: #('SimilarityFlooding') ]; package: 'SimilarityFlooding-Diff' with: [ spec requires: #('SimilarityFlooding') ]; package: 'SimilarityFlooding-Diff-Tests' with: [ spec requires: #('SimilarityFlooding-Diff') ]; package: 'SimilarityFlooding-Evaluator' with: [ spec requires: #('SimilarityFlooding' 'FamixDiff') ]; package: 'SimilarityFlooding-DiffOrion' with: [ spec requires: #('SimilarityFlooding-Diff') ]; yourself Separating the dependencies and package definitions allow me to modify it easily. I hope it helps. Julien PS: to make a baseline use on another baseline as dependency I put this kind of source code in #defineDependencies: spec baseline: 'DependenceName' with: [ spec repository: 'github://user/repositoryname/eventualdirectory' ]. On 01/07/17 14:35, Stephane Ducasse wrote: > Hi > > I 'm trying to define a baseline for our project and I defined it as > > baseline: spec > <baseline> > spec for: #common do: [ spec > baseline: 'SmaCC' with: [ spec > repository: 'github://ThierryGoubier/SmaCC'; > loads: 'SmaCC-GLR-Runtime' ]; > > package: 'SmaCC-Solidity' > "we could say that SmaccSolidity depends on Smacc-Runtime but I do not > know how to say it" > ] > > Now I thought that I could try to load it using the following > > Metacello new > baseline: 'SmaccSolidity'; > repository: 'github://RMODINRIA-Blockchain/SmaCC-Solidity'; > load. > > > But I get an error telling me that the baseline constructor does not > understand load ;( > > I read the blog of peter > https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… > > and I'm doing exactly the same so I wonder. > > Stef >

July 1, 2017

Re: [Pharo-dev] git, packages, and package dependencies (also migration from sthub to git)

by Peter Uhnak

On Sat, Jul 01, 2017 at 02:22:53PM +0200, Damien Pollet wrote: > On 1 July 2017 at 13:28, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > In mcz/monticello, every package has an independent history and can change > > independently of each other. > > In git, this history is merged into a single hierarchy, therefore: > > * a specific version of package A mandates specific versions of > > every other package in the project > > * it is not possible to do a 1:1 migration from mcz to git and > > keep this flexibility > > > > Did you ever use that feature (to achieve something precise, not just > because it's here)? Well the implications are more problematic. Imagine you have pkg A, with commits A1,A2,A3. Now you are in A3 and you create a new package (B) and commit it (B1, which has A3 as a parent). Then you move back in history to A2, or you create A4 (as a child of A2) -- package B no longer exists. So you cannot go back in history for any package without affecting the rest of the packages. I think this is a cognitive shift for people switching. And practically speaking if you want to go back for just a single package you have to cherry pick, which is error-prone. (none of this is problem for me, as I've been using git in Pharo for a long time, but more shining light on the impending issues for people now switching) > > > The only solution I see is to either separate every package to a separate > > git project to keep the flexibility or use git subtree/git module... which > > are both complications... > > > > Yes, it's a painâ¦ might be useful in some cases but I think most of the > time versioning each package of a project independently is just cognitive > noise. > > As a git commit specifies the code in the entire project, even across > > packages, then I wonder what is the point of expressing package > > dependencies _within_ the project (whether in BaselineOf or Cargo). > > > > Load order? Ah, right. > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

July 1, 2017

Re: [Pharo-dev] git, packages, and package dependencies (also migration from sthub to git)

by stephan

On 01-07-17 14:22, Damien Pollet wrote: > Yes, it's a painâ¦ might be useful in some cases but I think most of the > time versioning each package of a project independently is just > cognitive noise. No, it is essential complexity in most cases. As soon as independent teams/people make changes you need to split projects up. How to do so to get the least friction is left as an exercise to the reader (see Parnas) Stephan

July 1, 2017

Re: [Pharo-dev] [FT improvements] [GSoC] [guidance needed] move some of the data source responsibilities to the cells

by Stephane Ducasse

Esteban is moving this week-end from another part of France to Lille so I think that he will get back to live wednesday. On Fri, Jun 30, 2017 at 12:14 PM, Elhamer <abdelkhalekdev(a)gmail.com> wrote: > Since there are no response, I am guessing that this design is okay and i > will go for it :D. > > Best, > Elhamer. > > > > -- > View this message in context: http://forum.world.st/FT-improvements-GSoC-guidance-needed-move-some-of-the… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 1, 2017

Baseline question

by Stephane Ducasse

Hi I 'm trying to define a baseline for our project and I defined it as baseline: spec <baseline> spec for: #common do: [ spec baseline: 'SmaCC' with: [ spec repository: 'github://ThierryGoubier/SmaCC'; loads: 'SmaCC-GLR-Runtime' ]; package: 'SmaCC-Solidity' "we could say that SmaccSolidity depends on Smacc-Runtime but I do not know how to say it" ] Now I thought that I could try to load it using the following Metacello new baseline: 'SmaccSolidity'; repository: 'github://RMODINRIA-Blockchain/SmaCC-Solidity'; load. But I get an error telling me that the baseline constructor does not understand load ;( I read the blog of peter https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… and I'm doing exactly the same so I wonder. Stef

July 1, 2017

Re: [Pharo-dev] git, packages, and package dependencies (also migration from sthub to git)

by Damien Pollet

On 1 July 2017 at 13:28, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > In mcz/monticello, every package has an independent history and can change > independently of each other. > In git, this history is merged into a single hierarchy, therefore: > * a specific version of package A mandates specific versions of > every other package in the project > * it is not possible to do a 1:1 migration from mcz to git and > keep this flexibility > Did you ever use that feature (to achieve something precise, not just because it's here)? The only solution I see is to either separate every package to a separate > git project to keep the flexibility or use git subtree/git module... which > are both complications... > Yes, it's a painâ¦ might be useful in some cases but I think most of the time versioning each package of a project independently is just cognitive noise. As a git commit specifies the code in the entire project, even across > packages, then I wonder what is the point of expressing package > dependencies _within_ the project (whether in BaselineOf or Cargo). > Load order? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 1, 2017

git, packages, and package dependencies (also migration from sthub to git)

by Peter Uhnak

Hi, after many-o-hours spent on my git-migration tool ( https://github.com/peteruhnak/git-migration ), I've concluded that the migration cannot be properly done for packages. In mcz/monticello, every package has an independent history and can change independently of each other. In git, this history is merged into a single hierarchy, therefore: * a specific version of package A mandates specific versions of every other package in the project * it is not possible to do a 1:1 migration from mcz to git and keep this flexibility Both ways (mcz and git) have advantages and disadvantages of their own, however as far as I could tell, they are incompatible; so mcz flexibility and some information (history) will be lost during migration. The only solution I see is to either separate every package to a separate git project to keep the flexibility or use git subtree/git module... which are both complications... As a git commit specifies the code in the entire project, even across packages, then I wonder what is the point of expressing package dependencies _within_ the project (whether in BaselineOf or Cargo). Peter

July 1, 2017

Re: [Pharo-dev] [Pharo-users] Custom Glamour browser for Dr. Geo scripting

by Nicolai Hess

2017-06-30 9:55 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > I extended the browser definition with: > > browser transmit > from: #scripts; > from: #categories; > to: #methods; > when: [ :a :b | a isMeta not ]; > andShow: [:a | self methodsIn: a ]. > browser transmit > from: #scripts; > from: #categories; > to: #methods; > when: [ :a | a isMeta ]; > andShow: [:a | self classMethodsIn: a ]. > > > However it does not work as #when: message always receive a class, so > the wrong methods a re list in the method pane. > > I enclosed a Fileout of the browser. It works independently of DrGeo. > When one select class methods, still the instance methods are displayed > in right most pane. > > Any tips? > I don't have a solution. I just want to make more clear what the problem is. See attached screenshot. The question is, is it possible to make the population of the "methods" list dependent of the focused "Instance Methods"/"Class Methods" pane ? I tried to wire a "#focus" port, but I don't think the "categories"-pane exports any port that could be used to distinguish between the selected tabs. > > Thanks > > Hilaire > > > Le 29/06/2017 Ã 14:59, Hilaire a Ã©crit : > > but something is missing to get the listed method right depending on the > > category is instance or class side. I don't how to do it. > > -- > Dr. Geo > http://drgeo.eu > >

July 1, 2017

Re: [Pharo-dev] Epicea feedback

by Stephane Ducasse

Thanks martin for your excellent support. What would be nice is to have some menus on the sessions items because often I try to click on them so see what I can do with them. Stef On Tue, Jun 27, 2017 at 4:17 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hello Jan, thanks for your feedback. I will have a look asap. Feel free to > report it in fogbugz. > > MartÃn > > On Tue, Jun 27, 2017 at 8:26 AM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> > wrote: >> >> Hello >> >> I'd like to thank you for creating the Epicea. It is way more >> user-friendly >> and dependable than previous change-handling tool. Browsing, applying and >> reverting changes is way easier. >> >> Just one note: >> It is not exactly clear from first look how to properly reapply changes >> after an image has been closed without saving. If I select all changes I >> want to apply without using any filter, those changes are reapplied in >> wrong >> order (if I changed a method two times, first the new version is applied >> and >> then the old one). As far as I understood, I have to use filter to show >> only >> latest changes, but I think it could be clearer in the UI that I need to >> do >> so (or something completely different?) for applying changes. >> >> Thank you >> Jan >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Epicea-feedback-tp4952661.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >

July 1, 2017