On Mon, 29 Oct 2018 at 03:52, tim Rowledge <[hidden email]> wrote:
Active opposition seems a bit strong. My understanding is that problematic merge conflicts of such version info were difficult to work around. Something similar to this... Here are some historical discussion of merge problems experienced in the move to support git... At one point I thought I might do better and spent a fair it of time trying to crack this. I was experimenting by manually simulated the version info updates using a text editor and merging different branches, but it beat me. However I just now bumped into a novel solution that I never considered which doesn't require merge drivers and wonder how this approach might influence the merge issues we found problematic cheers -ben |
> On 2018-10-28, at 5:15 PM, Ben Coman <[hidden email]> wrote: > > Here are some historical discussion of merge problems experienced in the move to support git... OK, I haven't really paid much attention to this in some time so my opinion, despite having originally written VMMaker, isn't all that important. I do wonder why anyone feels particular need to support git for the Smalltalk source for VMMaker. Sure, for the generated C code, as a way to make it easy for mundane tools to download and build etc, git is as tolerable as anything. But the Smalltalk code is our stuff, in our format, and we already have tools for that. Is it some wish to have everything in a single place, perhaps? I guess I could understand that urge. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: BYEBYE: Store in Write-Only Storage |
On Mon, 29 Oct 2018 at 10:27, tim Rowledge <[hidden email]> wrote:
Is it some wish to have everything in a single place, perhaps? I guess I could understand that urge. I believe that is the main driver. I'm not involved in the decision to do it now, but I've advocated for it in the past. One advantage would be that multiple parties could work on separate feature/experimental branches where the Smalltalk & Generated sources remain in sync on the branch. cheers -ben |
In reply to this post by Tobias Pape
On Fri, 26 Oct 2018, Tobias Pape wrote: > Think I have a method with a very long selector, eg MCClassDefinition: > > > initializeWithName: nameString > superclassName: superclassString > traitComposition: traitCompositionString > classTraitComposition: classTraitCompositionString > category: categoryString > instVarNames: ivarArray > classVarNames: cvarArray > poolDictionaryNames: poolArray > classInstVarNames: civarArray > type: typeSymbol > comment: commentString > commentStamp: stampStringOrNil > name := nameString asSymbol. > superclassName := superclassString ifNil: ['nil'] ifNotNil: [superclassString asSymbol]. > traitComposition := traitCompositionString. > classTraitComposition := classTraitCompositionString. > category := categoryString. > type := typeSymbol. > comment := commentString withSqueakLineEndings. > commentStamp := stampStringOrNil ifNil: [self defaultCommentStamp]. > variables := OrderedCollection new. > self addVariables: ivarArray ofType: MCInstanceVariableDefinition. > self addVariables: cvarArray sorted ofType: MCClassVariableDefinition. > self addVariables: poolArray sorted ofType: MCPoolImportDefinition. > self addVariables: civarArray ofType: MCClassInstanceVariableDefinition > > > Seeing the Tonel format, this formatting of the selector, even if it is uncommon, would not be preserved, right? I just checked, and the formatting is preserved, even comments and white spaces between the selector part and the argument names appear as written. The only nuance is that no parser can optimally separate the method body from its signature, so there are edge cases with unexpected results. E.g.: If you add type information as comments like below, the last comment will appear if it were part of the method body: Object >> foo: foo "Integer" bar: bar "String" ^foo asString, bar will be stored as Object >> foo: foo "Integer" bar: bar [ "String" ^foo asString, bar ] Levente |
> On 29.10.2018, at 20:03, Levente Uzonyi <[hidden email]> wrote: > > On Fri, 26 Oct 2018, Tobias Pape wrote: > >> Think I have a method with a very long selector, eg MCClassDefinition: >> >> >> initializeWithName: nameString >> superclassName: superclassString >> traitComposition: traitCompositionString >> classTraitComposition: classTraitCompositionString >> category: categoryString instVarNames: ivarArray >> classVarNames: cvarArray >> poolDictionaryNames: poolArray >> classInstVarNames: civarArray >> type: typeSymbol >> comment: commentString >> commentStamp: stampStringOrNil >> name := nameString asSymbol. >> superclassName := superclassString ifNil: ['nil'] ifNotNil: [superclassString asSymbol]. >> traitComposition := traitCompositionString. >> classTraitComposition := classTraitCompositionString. >> category := categoryString. >> type := typeSymbol. >> comment := commentString withSqueakLineEndings. >> commentStamp := stampStringOrNil ifNil: [self defaultCommentStamp]. >> variables := OrderedCollection new. >> self addVariables: ivarArray ofType: MCInstanceVariableDefinition. >> self addVariables: cvarArray sorted ofType: MCClassVariableDefinition. >> self addVariables: poolArray sorted ofType: MCPoolImportDefinition. >> self addVariables: civarArray ofType: MCClassInstanceVariableDefinition >> >> >> Seeing the Tonel format, this formatting of the selector, even if it is uncommon, would not be preserved, right? > > I just checked, and the formatting is preserved, even comments and white spaces between the selector part and the argument names appear as written. > The only nuance is that no parser can optimally separate the method body from its signature, so there are edge cases with unexpected results. E.g.: > > If you add type information as comments like below, the last comment will appear if it were part of the method body: > > Object >> foo: foo "Integer" bar: bar "String" > > ^foo asString, bar > > will be stored as > > Object >> foo: foo "Integer" bar: bar [ "String" > > ^foo asString, bar > ] Interesting! |
Free forum by Nabble | Edit this page |