Smalltalk › Squeak › Squeak VM

reorganizing opensmalltalk-vm

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

Ben Coman

Re: reorganizing opensmalltalk-vm

On Mon, 29 Oct 2018 at 03:52, tim Rowledge <[hidden email]> wrote:

> On 2018-10-28, at 12:37 PM, Eliot Miranda <[hidden email]> wrote:
>
> The only thing I'd like to see in Tonel is per-method timestamps a la
>
[snip]
>
> but I know there is active opposition to this idea.

Why on earth is there any opposition to what appears a perfectly reasonable idea? Within, of course, the context of an idea I find rather daft, that of trying to force Smalltalk source code into a model that seems completely at odds.

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...

[1] http://developers-club.com/posts/244839/

Here are some historical discussion of merge problems experienced in the move to support git...

[3] http://forum.world.st/metadata-less-FileTree-repository-support-part-I-td4906094.html

[4] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html

[5] http://forum.world.st/git-and-author-timestamps-10000-s-of-files-etc-td5063124.html

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

[2] https://stackoverflow.com/questions/33122014/git-conflicts-with-json-files/33262179#33262179

See first answer "Oh, I actually tried this out and encountered some odd problems."

cheers -ben

timrowledge

Re: reorganizing opensmalltalk-vm

> 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

Ben Coman

Re: reorganizing opensmalltalk-vm

On Mon, 29 Oct 2018 at 10:27, tim Rowledge <[hidden email]> wrote:

> 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.

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

Levente Uzonyi

Re: reorganizing opensmalltalk-vm

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

Tobias Pape

Re: reorganizing opensmalltalk-vm

> 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!