Need an Alien-Core-eem.102 update
Locked
Need an Alien-Core-eem.102 update
 
|
Hi Eliot, When you get a chance, can you please commit an update to Alien-Core-eem.101 in http://www.squeaksource.com/Alien in order to make a Alien-Core-eem.102 version that will appear as the latest version for updates? This is needed because the image/BuildSqueakSpurTrunkVMMakerImage.st is loading Alien-Core-TorstenBergmann.101 rather than the intended Alien-Core-eem.101 as the latest Alien-Core version. Thanks, Dave |
Re: Need an Alien-Core-eem.102 update
|
|
Ah, I see, no timestamp thanks to Pharo tools... Maybe we could use a .mcm? or update Metacello ConfigurationOf(Old)Alien? Le dim. 5 janv. 2020 à 01:10, David T. Lewis <[hidden email]> a écrit :
|
Re: Need an Alien-Core-eem.102 update
|
|
Yes the Pharo tools caused the original issue, but here the only problem is that Eliot did not remember to bump the version number up to 102 when he fixed the problem. So the simple solution is to just save it once more with 102 in the version name. I don't have write access to that repo, so that's why I asked Eliot to do it. Yes a .mcm would handle it also (but easier here to just save it one more time). If you are interested in that approach, look at update.oscog in the VMMaker repository. There are a few update maps (totally unofficial and unsupported) that I have been saving from time to time. The 'update.oscog' maps correspond to oscog configurations, as distinct from the 'update' .mcm maps that have been used for many years as the update stream for the traditional interpreter VM. Dave On Wed, Jan 08, 2020 at 04:37:16PM +0100, Nicolas Cellier wrote: > > Ah, I see, no timestamp thanks to Pharo tools... > Maybe we could use a .mcm? or update Metacello ConfigurationOf(Old)Alien? > > Le dim. 5 janv. 2020 ?? 01:10, David T. Lewis <[hidden email]> a ??crit : > > > > > Hi Eliot, > > > > When you get a chance, can you please commit an update to > > Alien-Core-eem.101 > > in http://www.squeaksource.com/Alien in order to make a Alien-Core-eem.102 > > version that will appear as the latest version for updates? > > > > This is needed because the image/BuildSqueakSpurTrunkVMMakerImage.st > > is loading Alien-Core-TorstenBergmann.101 rather than the intended > > Alien-Core-eem.101 as the latest Alien-Core version. > > > > Thanks, > > Dave > > > > |
Re: Need an Alien-Core-eem.102 update
|
|
Hi Dave, there's a simpler solution. We simply delete Alien-Core-TorstenBergmann.101. It lacks time stamps so it doesn't;t belong anyway. I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was unaware of the issue. Torsten is a very nice guy. But the issue of no time stamps intr4oduceing lots of noise into =Monticello repositories is an annoying g piece of passive aggressive B.S. from the Pharo community which we should push back against. On Wed, Jan 8, 2020 at 5:10 PM David T. Lewis <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
Re: Need an Alien-Core-eem.102 update
|
|
In reply to this post by David T. Lewis
Hi Eliot, >there's a simpler solution. We simply delete Alien-Core-TorstenBergmann.101 Yes - no problem with that and thanks for taking care. But a copy might exist still in local Monticello caches on user side. So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest addition to compensate the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a second time). >I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was >unaware of the issue. Yes - for the timestamp I did not notice directly (or even forgot because I guess I just had a newer Pharo image on the machine which was already switched git but still includes MCZ tools). But if you really require the timestamps explicitly on each method for the VMMaker / Alien packages then it means one is only allowed to use Squeak or old Pharo versions to contribute / commit and VM development will never move away from MCZs in all our lifetime. The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file format directly would always mean a change/conflict in the diffs of git anytime - even if there is no real code change on the method or class itself. We all know git is widely accepted in IT shops around the world, really a breeze to work with - now even with and in Smalltalk code. With git one gets timestamps out of the box - but also a lot more like proper branching (which is nearly impossible to handle in MCZs for the Monticello/Metacello approach). Also GIT can version Smalltalk and non-Smalltalk code at the same time and using the same way. In fact one rarely finds a project which is Smalltalk code only - often you have other assets or code in other languages too. And VMMaker is a good example for that. I personally therefore like git much much more than the old more limiting MCZ solutions. Seen from the outside I still fail to understand why - on one side the VM code is maintained with git on GitHub - on the other side the core Smalltalk parts like VMMaker are still versioned as MCZ and hosted on old services like SqueakSource / source.squeak.org Even Squeak might hopefully move forward and use git in the future. Then VMMaker will face the similar issue with the timestamps. If I understood sources like https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi121.pdf correctly then one can already use Git as a backend VCS from Squeak too. >Torsten is a very nice guy. Thanks for the compliment - but like any other human I have a dark side too :) >But the issue of no time stamps intr4oduceing lots of noise into Monticello repositories >is an annoying g piece of passive aggressive B.S. from the Pharo community which we should push back against. What kind of noise exactly are you referring too? No need for a conspiracy theory or blaming of the overall Pharo community - loosing the timestamp is related to the git switch as explained. I know there are sometimes personal differences among members of the various communities - and there is potential for conflicts depending on personality and if the (code) area of work is the same - and when the ideas for the solution(s) differ. But basically in all the communities I assume the individuals are trying to move things and ideas forward. Sometimes we all pull/push into similar direction - sometimes not because goals or ideas differ slightly or even heavily. I assume (and hope) nobody does harmful things willingly just to bug other sides. Anyhow - I hope 2020 will be a good year with good progress for ALL the communities. Thx T. |
Re: Need an Alien-Core-eem.102 update
|
Administrator
|
Torsten Bergmann wrote > But basically in all the communities I assume the individuals are trying > to move things and ideas forward. Sometimes > we all pull/push into similar direction - sometimes not because goals or > ideas differ slightly or even heavily. > I assume (and hope) nobody does harmful things willingly just to bug other > sides. > > Anyhow - I hope 2020 will be a good year with good progress for ALL the > communities. hear! hear! The Smalltalk community is too small and too important (to me anyway ha ha) to fracture into warring tribes. Let's focus all that passion on inventing the future :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-VM-f104410.html
Cheers,
Sean |
Re: Need an Alien-Core-eem.102 update
|
|
On Mon, Jan 13, 2020 at 05:50:50PM -0600, Sean P. DeNigris wrote: > > Torsten Bergmann wrote > > But basically in all the communities I assume the individuals are trying > > to move things and ideas forward. Sometimes > > we all pull/push into similar direction - sometimes not because goals or > > ideas differ slightly or even heavily. > > I assume (and hope) nobody does harmful things willingly just to bug other > > sides. > > > > Anyhow - I hope 2020 will be a good year with good progress for ALL the > > communities. > > hear! hear! > > The Smalltalk community is too small and too important (to me anyway ha ha) > to fracture into warring tribes. Let's focus all that passion on inventing > the future :) > here! here! Thank you Torsten, and thank you Sean. Dave |
Re: Need an Alien-Core-eem.102 update
|
|
In reply to this post by Torsten Bergmann
Hi Torsten On Mon, 13 Jan 2020, Torsten Bergmann wrote: > > Hi Eliot, > >> there's a simpler solution. We simply delete Alien-Core-TorstenBergmann.101 > > Yes - no problem with that and thanks for taking care. But a copy might exist still in local Monticello caches > on user side. > > So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest addition to compensate > the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a second time). > >> I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was >> unaware of the issue. > > Yes - for the timestamp I did not notice directly (or even forgot because I guess I just had a newer Pharo > image on the machine which was already switched git but still includes MCZ tools). > > But if you really require the timestamps explicitly on each method for the VMMaker / Alien packages > then it means one is only allowed to use Squeak or old Pharo versions to contribute / commit and > VM development will never move away from MCZs in all our lifetime. > > The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file > format directly would always mean a change/conflict in the diffs of git anytime - even if there is no real code change > on the method or class itself. Can you explain how keeping the timestamps as they are in Monticello would introduce change/conflict in git? Those are just static strings unless you change the method, aren't they? > > We all know git is widely accepted in IT shops around the world, really a breeze to work with - now even with and in Smalltalk code. > With git one gets timestamps out of the box - but also a lot more like proper branching (which is nearly impossible > to handle in MCZs for the Monticello/Metacello approach). Also GIT can version Smalltalk and non-Smalltalk code > at the same time and using the same way. > > In fact one rarely finds a project which is Smalltalk code only - often you have other assets or code in other languages too. > And VMMaker is a good example for that. > > I personally therefore like git much much more than the old more limiting MCZ solutions. Seen from the outside I still fail to > understand why > > - on one side the VM code is maintained with git on GitHub > - on the other side the core Smalltalk parts like VMMaker are still versioned as MCZ and hosted on old services like > SqueakSource / source.squeak.org > > Even Squeak might hopefully move forward and use git in the future. Then VMMaker will face the similar issue with the > timestamps. If I understood sources like > > https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi121.pdf > > correctly then one can already use Git as a backend VCS from Squeak too. > >> Torsten is a very nice guy. > > Thanks for the compliment - but like any other human I have a dark side too :) > >> But the issue of no time stamps intr4oduceing lots of noise into Monticello repositories >> is an annoying g piece of passive aggressive B.S. from the Pharo community which we should push back against. > > What kind of noise exactly are you referring too? When you create an .mcz file with no timestamps in it, all code will appear as changed in Monticello. The tool you created the .mcz with is therefore broken. Levente > > No need for a conspiracy theory or blaming of the overall Pharo community - loosing the timestamp is related to the > git switch as explained. > > I know there are sometimes personal differences among members of the various communities - and there is potential for > conflicts depending on personality and if the (code) area of work is the same - and when the ideas for the solution(s) differ. > > But basically in all the communities I assume the individuals are trying to move things and ideas forward. Sometimes > we all pull/push into similar direction - sometimes not because goals or ideas differ slightly or even heavily. > I assume (and hope) nobody does harmful things willingly just to bug other sides. > > Anyhow - I hope 2020 will be a good year with good progress for ALL the communities. > > Thx > T. |
|
|
On Tue, 14 Jan 2020 at 20:55, Levente Uzonyi <[hidden email]> wrote:
To simplify things with an analogous example, lets put aside Tonel and Metacello and consider git's treatment of metadata in a basic file-out. # SETUP TEST REPO $ mkdir test & cd test $ git init $ git config --global user.name "Test" $ git config --global user.email "[hidden email]" $ cat > some.st <<EOF Object subclass: #MyClass instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Example'! !MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! method1 self inform: 'line 1 branch master'. self inform: 'line 2 branch master'. self inform: 'line 3 branch master'. self inform: 'line 4 branch master'. ! ! EOF $ git add some.st $ git commit -m "First commit" $ git branch b1 $ git branch b2 $ git branch b3 $ git branch b4 # FIRST EXPERIMENT, BASELINE AN UPDATE & MERGE WITHOUT TIMESTAMPS $ git checkout b1 $ vi some.st - self inform: 'line 1 branch master'. + self inform: 'line 1 branch b1'. $ git commit -am "line 1 branch b1" $ git checkout b2 $ vi some.st - self inform: 'line 3 branch master'. + self inform: 'line 3 branch b3'. $ git commit -am "line 3 branch b3" $ git diff b1 $ git merge b1 $ cat some.st ==> merged worked fine, no conflicts # SECOND EXPERIMENT, UPDATE & MERGE WITH TIMESTAMPS $ git checkout b3 $ vi some.st -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:10'! - self inform: 'line 1 branch master'. + self inform: 'line 1 branch b3'. $ git commit -am "line 1 branch b3" $ git checkout b4 $ vi some.st -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:15'! - self inform: 'line 3 branch master'. + self inform: 'line 3 branch b4'. $ git commit -am "line 3 branch b4" $ git merge --abort So naive question... How does Monticello deal with such a situation between b3 & b4? Left as an exercise is pushing branches b3 & b4 to a git-service-provider, then issue a PR merging b3 into master, followed up a PR merging b4 into master. If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc), in a way compatible with libgit, there may be a better case for calling B.S. on Tonel's lack of timestamps. I do remember watching the Pharo community struggle for many months with the above issue and it was really impeding git uptake by users. I know I got burnt and I didn't transition to using git from within Pharo until it was resolved by Tonel. My memory of mail list discussions was that the decision to drop timestamps wasn't taken lightly, but seemed like the only practical way to move forward into a git world. HTH, cheers -ben |
|
|
On Wed, 15 Jan 2020 at 01:18, Ben Coman <[hidden email]> wrote: > > > > On Tue, 14 Jan 2020 at 20:55, Levente Uzonyi <[hidden email]> wrote: >> >> >> Hi Torsten >> >> On Mon, 13 Jan 2020, Torsten Bergmann wrote: >> >> > >> > Hi Eliot, >> > >> >> there's a simpler solution. We simply delete Alien-Core-TorstenBergmann.101 >> > >> > Yes - no problem with that and thanks for taking care. But a copy might exist still in local Monticello caches >> > on user side. >> > >> > So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest addition to compensate >> > the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a second time). >> > >> >> I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was >> >> unaware of the issue. >> > >> > Yes - for the timestamp I did not notice directly (or even forgot because I guess I just had a newer Pharo >> > image on the machine which was already switched git but still includes MCZ tools). >> > >> > But if you really require the timestamps explicitly on each method for the VMMaker / Alien packages >> > then it means one is only allowed to use Squeak or old Pharo versions to contribute / commit and >> > VM development will never move away from MCZs in all our lifetime. >> > >> > The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file >> > format directly would always mean a change/conflict in the diffs of git anytime - even if there is no real code change >> > on the method or class itself. >> >> Can you explain how keeping the timestamps as they are in Monticello would >> introduce change/conflict in git? >> Those are just static strings unless you change the method, aren't they? > > > To simplify things with an analogous example, lets put aside Tonel and Metacello > and consider git's treatment of metadata in a basic file-out. > > # SETUP TEST REPO > > $ mkdir test & cd test > $ git init > $ git config --global user.name "Test" > $ git config --global user.email "[hidden email]" > $ cat > some.st <<EOF > Object subclass: #MyClass > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Example'! > > !MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! > method1 > self inform: 'line 1 branch master'. > self inform: 'line 2 branch master'. > self inform: 'line 3 branch master'. > self inform: 'line 4 branch master'. > ! ! > EOF > > $ git add some.st > $ git commit -m "First commit" > $ git branch b1 > $ git branch b2 > $ git branch b3 > $ git branch b4 > > # FIRST EXPERIMENT, BASELINE AN UPDATE & MERGE WITHOUT TIMESTAMPS > > $ git checkout b1 > $ vi some.st > - self inform: 'line 1 branch master'. > + self inform: 'line 1 branch b1'. > $ git commit -am "line 1 branch b1" > > $ git checkout b2 > $ vi some.st > - self inform: 'line 1 branch master'. > + self inform: 'line 1 branch b3'. > $ git commit -am "line 1 branch b3" # CORRECTION, of course the moment I hit send I notice a copy-paste error. Obviously it should be... $ git checkout b2 $ vi some.st - self inform: 'line 3 branch master'. + self inform: 'line 3 branch b2'. $ git commit -am "line 3 branch b2" > $ git diff b1 > $ git merge b1 > $ cat some.st > ==> merged worked fine, no conflicts > > # SECOND EXPERIMENT, UPDATE & MERGE WITH TIMESTAMPS > > $ git checkout b3 > $ vi some.st > -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! > +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:10'! > - self inform: 'line 1 branch master'. > + self inform: 'line 1 branch b3'. > $ git commit -am "line 1 branch b3" > > $ git checkout b4 > $ vi some.st > -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! > +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:15'! > - self inform: 'line 3 branch master'. > + self inform: 'line 3 branch b4'. > $ git commit -am "line 3 branch b4" > > $ git diff b1 > $ git merge b1 > $ cat some.st > ==> CONFLICT (content): Merge conflict in some.st > > $ git merge --abort > > > So naive question... How does Monticello deal with such a situation between b3 & b4? > > Left as an exercise is pushing branches b3 & b4 to a git-service-provider, > then issue a PR merging b3 into master, followed up a PR merging b4 into master. > > If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE > on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc), > in a way compatible with libgit, there may be a better case for calling B.S. on Tonel's lack of timestamps. > > I do remember watching the Pharo community struggle for many months with the above issue > and it was really impeding git uptake by users. I know I got burnt and I didn't transition to using git from within Pharo until it was resolved by Tonel. > My memory of mail list discussions was that the decision to drop timestamps wasn't taken lightly, > but seemed like the only practical way to move forward into a git world. > > HTH, > cheers -ben > |
Re: Need an Alien-Core-eem.102 update
|
|
Hi Ben, MC does handle a method as an atom. So 2 branches changing the same method => conflict. git has no idea of what a class or method is. It sort of handle lines of code as atom. This is arbitrary but works with most languages. IMO, it's not a big problem, concurrent changes on one method require human review. Problem of metadata in filetree mostly came from the fact that all-metadata of whole package was in a single line of a single file... Even with that, Thierry Goubier did provide a git hook that did resolve 99% of the false metadata conflicts, it's just that it was never used/integrated. The decision to kill metadata is understandable if in the long term you decide to rely EXCLUSIVELY on VCS metadata. But it means that you EXPLICITELY do not want to support compatibility with MC. That's what Eliot is calling passive aggressive. So I don't buy the conflict argument. In France we say: "quand on veut tuer son chien, on l'accuse de la rage". Le mar. 14 janv. 2020 à 18:23, Ben Coman <[hidden email]> a écrit :
|
Re: Need an Alien-Core-eem.102 update
|
|
> On 2020-01-14, at 1:17 PM, Nicolas Cellier <[hidden email]> wrote: > > In France we say: "quand on veut tuer son chien, on l'accuse de la rage". Sometihng like "when they want to kill our dog we'll claim they hate us"? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- He's not a complete idiot -- some parts are missing. |
Re: Need an Alien-Core-eem.102 update
|
|
> On 14.01.2020, at 22:25, tim Rowledge <[hidden email]> wrote: > > > > >> On 2020-01-14, at 1:17 PM, Nicolas Cellier <[hidden email]> wrote: >> > >> In France we say: "quand on veut tuer son chien, on l'accuse de la rage". > > Sometihng like "when they want to kill our dog we'll claim they hate us"? or so: https://www.deepl.com/translator#fr/en/quand%20on%20veut%20tuer%20son%20chien%2C%20on%20l'accuse%20de%20la%20rage > > tim |
Re: Need an Alien-Core-eem.102 update
|
|
In reply to this post by Ben Coman
Hi Ben! On Wed, 15 Jan 2020, Ben Coman wrote: > > On Wed, 15 Jan 2020 at 01:18, Ben Coman <[hidden email]> wrote: >> >> snip >> >> >> So naive question... How does Monticello deal with such a situation between b3 & b4? >> >> Left as an exercise is pushing branches b3 & b4 to a git-service-provider, >> then issue a PR merging b3 into master, followed up a PR merging b4 into master. >> >> If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE >> on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc), Why do you want these to "AUTO RESOLVE"? If the same method is modified in two different branches, it's a must to check whether those changes are compatible or not, isn't it? Levente >> in a way compatible with libgit, there may be a better case for calling B.S. on Tonel's lack of timestamps. >> >> I do remember watching the Pharo community struggle for many months with the above issue >> and it was really impeding git uptake by users. I know I got burnt and I didn't transition to using git from within Pharo until it was resolved by Tonel. >> My memory of mail list discussions was that the decision to drop timestamps wasn't taken lightly, >> but seemed like the only practical way to move forward into a git world. >> >> HTH, >> cheers -ben >> |
|
|
In reply to this post by Ben Coman
Hi Ben, Thanks for taking the time to explain the issue in more detail. There is one thing I don't understand. When someone is using Git anyway why bother writing MCZs in the first place when the only way to do that causes difficult to spot problems in Squeak? That's an honest question. I am not putting blame on anyone. I use Git almost daily and can see the potential upsides, especially GitHub and PRs. (I convinced Juan to use Git in Cuis for external packages - mainly because there exists no full port of Monticello in Cuis.) Bernhard > Am 14.01.2020 um 18:18 schrieb Ben Coman <[hidden email]>: > > > > On Tue, 14 Jan 2020 at 20:55, Levente Uzonyi <[hidden email]> wrote: > > Hi Torsten > > On Mon, 13 Jan 2020, Torsten Bergmann wrote: > > > > > Hi Eliot, > > > >> there's a simpler solution. We simply delete Alien-Core-TorstenBergmann.101 > > > > Yes - no problem with that and thanks for taking care. But a copy might exist still in local Monticello caches > > on user side. > > > > So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest addition to compensate > > the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a second time). > > > >> I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was > >> unaware of the issue. > > > > Yes - for the timestamp I did not notice directly (or even forgot because I guess I just had a newer Pharo > > image on the machine which was already switched git but still includes MCZ tools). > > > > But if you really require the timestamps explicitly on each method for the VMMaker / Alien packages > > then it means one is only allowed to use Squeak or old Pharo versions to contribute / commit and > > VM development will never move away from MCZs in all our lifetime. > > > > The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file > > format directly would always mean a change/conflict in the diffs of git anytime - even if there is no real code change > > on the method or class itself. > > Can you explain how keeping the timestamps as they are in Monticello would > introduce change/conflict in git? > Those are just static strings unless you change the method, aren't they? > > To simplify things with an analogous example, lets put aside Tonel and Metacello > and consider git's treatment of metadata in a basic file-out. > > # SETUP TEST REPO > > $ mkdir test & cd test > $ git init > $ git config --global user.name "Test" > $ git config --global user.email "[hidden email]" > $ cat > some.st <<EOF > Object subclass: #MyClass > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Example'! > > !MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! > method1 > self inform: 'line 1 branch master'. > self inform: 'line 2 branch master'. > self inform: 'line 3 branch master'. > self inform: 'line 4 branch master'. > ! ! > EOF > > $ git add some.st > $ git commit -m "First commit" > $ git branch b1 > $ git branch b2 > $ git branch b3 > $ git branch b4 > > # FIRST EXPERIMENT, BASELINE AN UPDATE & MERGE WITHOUT TIMESTAMPS > > $ git checkout b1 > $ vi some.st > - self inform: 'line 1 branch master'. > + self inform: 'line 1 branch b1'. > $ git commit -am "line 1 branch b1" > > $ git checkout b2 > $ vi some.st > - self inform: 'line 3 branch master'. > + self inform: 'line 3 branch b3'. > $ git commit -am "line 3 branch b3" > > $ git diff b1 > $ git merge b1 > $ cat some.st > ==> merged worked fine, no conflicts > > # SECOND EXPERIMENT, UPDATE & MERGE WITH TIMESTAMPS > > $ git checkout b3 > $ vi some.st > -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! > +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:10'! > - self inform: 'line 1 branch master'. > + self inform: 'line 1 branch b3'. > $ git commit -am "line 1 branch b3" > > $ git checkout b4 > $ vi some.st > -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'! > +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:15'! > - self inform: 'line 3 branch master'. > + self inform: 'line 3 branch b4'. > $ git commit -am "line 3 branch b4" > > $ git diff b1 > $ git merge b1 > $ cat some.st > ==> CONFLICT (content): Merge conflict in some.st > > $ git merge --abort > > > So naive question... How does Monticello deal with such a situation between b3 & b4? > > Left as an exercise is pushing branches b3 & b4 to a git-service-provider, > then issue a PR merging b3 into master, followed up a PR merging b4 into master. > > If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE > on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc), > in a way compatible with libgit, there may be a better case for calling B.S. on Tonel's lack of timestamps. > > I do remember watching the Pharo community struggle for many months with the above issue > and it was really impeding git uptake by users. I know I got burnt and I didn't transition to using git from within Pharo until it was resolved by Tonel. > My memory of mail list discussions was that the decision to drop timestamps wasn't taken lightly, > but seemed like the only practical way to move forward into a git world. > > HTH, > cheers -ben > |
|
|
In reply to this post by Levente Uzonyi
Hi Levente, > Am 15.01.2020 um 23:46 schrieb Levente Uzonyi <[hidden email]>: > > On Wed, 15 Jan 2020, Ben Coman wrote: >> >> On Wed, 15 Jan 2020 at 01:18, Ben Coman <[hidden email]> wrote: >>> > > snip > >>> >>> So naive question... How does Monticello deal with such a situation between b3 & b4? >>> >>> Left as an exercise is pushing branches b3 & b4 to a git-service-provider, >>> then issue a PR merging b3 into master, followed up a PR merging b4 into master. >>> >>> If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE >>> on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc), > > Why do you want these to "AUTO RESOLVE"? > If the same method is modified in two different branches, it's a must to > check whether those changes are compatible or not, isn't it? Well, when the builds on the CI server running all the tests succeed, you don't necessarily have to. If you have good test coverage. I am not saying that is a good thing. It's just that that is the common practice in all non-Smalltalk projects I worked on for several years now. I guess in other languages this is more important because methods are much longer. Bernhard |
Re: Need an Alien-Core-eem.102 update
|
|
In reply to this post by Torsten Bergmann
Hi Torsten, On Mon, Jan 13, 2020 at 1:54 PM Torsten Bergmann <[hidden email]> wrote:
I disagree with this interpretation. Pharo chose to discard timestamps and did not care about the impact on anyone else. Further. timestamps are not a property of MCZ's but of methods. It would have been simple to retain timestamps in the Tonel format (I'e modified Tonel to preserve these), but Pharo decided not to. I find method timestamps extremely useful in finding out who did what when, and hence who to ask. I don't find Iceberg provides the same convenience, several years after I was told that Pharo/Git integration would be as good as Monticello. Personally I don't find it so. Specifically in the image how do I find out who made the last change to a method? So in staying with timestamps I am simply trying to remain productive and will be coerced by the Pharo community. If it choses to fork the repository, stop collaborating, break compatibility with Squeak that is its choice, but it will live with the consequences, and I will be coerced into losing productivity, or moving to technologies I experience as inferior. The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file Well, it would be easy to write a tool that put them back, and synthesized timestamps for those methods that changed. But for several years it has been the case that timestamps have been screwed up. The solution is not to simply discard them because something useful is too difficult to program. But that seems to be a default position for Pharo. Backwards compatibility, playing nicely with other related communities, are too onerous. We all know git is widely accepted in IT shops around the world, really a breeze to work with - now even with and in Smalltalk code. I use git daily. I find it still has significant bugs, complexities, a truly horrible command vocabulary, an insistence on line feeds, and so on. And unlike Monticello I can't realistically do anything about it. Whereas Monticello belongs to us and we can (and have) evolved it quickly and productively many times. Git, if it has any advantages, does so in the context of GitHub. And I know from personal experience that it is possible to use git as a backend for Monticello. An approach that could have kept everyone happy. With git one gets timestamps out of the box - but also a lot more like proper branching (which is nearly impossible I disagree. We branch with Monticello occasionally (Clément implemented incremental compaction in a branch). What are these impossibilities you mention? And where are these timestamps of which you speak? I use Pharo 7.x in my consulting work and I see no per-method last-commit information in the browser, or in the commit diff tool (Iceberg->Repository->commit to commit comparison). Also GIT can version Smalltalk and non-Smalltalk code
And we have a solution. We use git for the generated C and all non Smalltalk assets. And we use Monticello with timestamps for the Smalltalk code, and it works well. Those of us using this scheme are able to fix bugs that have been long outstanding and not fixed by the Pharo VM engineers. I have just completed a JIT for the ARMv8 in record time while also doing a consulting gig. So I'm not unhappy with my style of work and won't be bullied into changing it because I'm told it's so much better doing it a different way. I use Pharo in my consulting work and I'm amazed by constant quality issues, an editor that gets in my way, an input event system that stops responding to meta key modifiers, still has no accelerator for ifTrue:ifFalse:, uses fixed pitch fonts, and on, and on. I'm very happy where I am. I'm sorry that doesn't suit you. I am not forcing you to change. I would appreciate the same respect. I personally therefore like git much much more than the old more limiting MCZ solutions. Seen from the outside I still fail to I spent at least month last year trying to get Tonel and Git working in Squeak. It didn't work. Esteban refused point blank to allow me to maintain an optional alternative Tonel that preserved time stamps. >Torsten is a very nice guy. What is your intent here Torsten? Are you trying to heal a rift? Anyhow - I hope 2020 will be a good year with good progress for ALL the communities. _,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by Levente Uzonyi
On Thu, 16 Jan 2020 at 06:47, Levente Uzonyi <[hidden email]> wrote: > > > Hi Ben! > > On Wed, 15 Jan 2020, Ben Coman wrote: > > > > > On Wed, 15 Jan 2020 at 01:18, Ben Coman <[hidden email]> wrote: > >> > >> > > snip > > >> > >> > >> So naive question... How does Monticello deal with such a situation between b3 & b4? > >> > >> Left as an exercise is pushing branches b3 & b4 to a git-service-provider, > >> then issue a PR merging b3 into master, followed up a PR merging b4 into master. > >> > >> If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE > >> on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc), > > Why do you want these to "AUTO RESOLVE"? > If the same method is modified in two different branches, it's a must to > check whether those changes are compatible or not, isn't it? Because the merge of PRs is happening on a CI server where there is no human interaction. Tests take care of the issue of compatibility. btw, Did you run through my example on your own system? If not, please do. :) Its easy to skim the text without getting a real feel for it, and indeed, in re-reading my example and my point doesn't leap out at me. My point was that that the FIRST EXPERIMENT demonstrates two branches with "different changes to the same method without updating the times stamp" doesn't cause a merge problem. The result method contains both changes. The SECOND EXPERIMENT makes the identical changes, but this time updates the timestamp. Two updates to the same-line causes a conflict. cheers -ben |
Re: Need an Alien-Core-eem.102 update
|
|
Hi Ben, Le dim. 19 janv. 2020 à 09:43, Ben Coman <[hidden email]> a écrit :
I have to disagree here. Tests do not replace human review, they just complement it btw, Did you run through my example on your own system? Yes, we agree that in some cases line based diff may avoid some conflicts. But as we said, we want human review anyway in case of such concurrent method change. That's true that the non conflicting case would require one more commit or a rebase before merging the PR. But in Smalltalk, methods are rather short, so how often is your crafted example going to happen in real world? |
|
|
On Mon, 20 Jan 2020 at 16:47, Nicolas Cellier <[hidden email]> wrote: > > > Hi Ben, > > > Le dim. 19 janv. 2020 à 09:43, Ben Coman <[hidden email]> a écrit : >> >> >> On Thu, 16 Jan 2020 at 06:47, Levente Uzonyi <[hidden email]> wrote: >> > >> > >> > Hi Ben! >> > >> > On Wed, 15 Jan 2020, Ben Coman wrote: >> > >> > > >> > > On Wed, 15 Jan 2020 at 01:18, Ben Coman <[hidden email]> wrote: >> > >> >> > >> >> > >> > snip >> > >> > >> >> > >> >> > >> So naive question... How does Monticello deal with such a situation between b3 & b4? >> > >> >> > >> Left as an exercise is pushing branches b3 & b4 to a git-service-provider, >> > >> then issue a PR merging b3 into master, followed up a PR merging b4 into master. >> > >> >> > >> If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE >> > >> on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc), >> > >> > Why do you want these to "AUTO RESOLVE"? >> > If the same method is modified in two different branches, it's a must to >> > check whether those changes are compatible or not, isn't it? >> >> Because the merge of PRs is happening on a CI server where there is no >> human interaction. >> Tests take care of the issue of compatibility. >> > I have to disagree here. > Tests do not replace human review, they just complement it A PR does get human review. To review a PR I would merge that PR into my image, then later discuss on github about whether the PR should be changed or merged. When the PR is approved and someone clicks the github <Merge> button. The CI server then bootstraps Pharo from scratch and repeats the same PR merge that I did in my image, at which point conflicts requiring human intervention would be awkward. > >> btw, Did you run through my example on your own system? >> If not, please do. :) Its easy to skim the text without getting a >> real feel for it, >> and indeed, in re-reading my example and my point doesn't leap out at me. >> >> My point was that that the FIRST EXPERIMENT demonstrates two branches >> with "different changes to the same method without updating the times >> stamp" >> doesn't cause a merge problem. The result method contains both changes. >> >> The SECOND EXPERIMENT makes the identical changes, but this time >> updates the timestamp. Two updates to the same-line causes a >> conflict. >> >> cheers -ben > > > Yes, we agree that in some cases line based diff may avoid some conflicts. > But as we said, we want human review anyway in case of such concurrent method change. > That's true that the non conflicting case would require one more commit or a rebase before merging the PR. > But in Smalltalk, methods are rather short, so how often is your crafted example going to happen in real world? I had the same thought about short methods. My example would rarely happen in practice. An explanation was requested for "how timestamps ... introduce change/conflict in git." In the time I had available to answer, my crafted example was just the simplest I could come up with. cheers -ben |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |