<div dir="ltr"><div dir="ltr">Hi Dale, Hi Martin, Hi All,<br><div><br></div><div> find attached changes that allow Tonel to *optionally* support method timestamps. This code formats the category metadata included in a Tonel source file on the same line as a method timestamp, making for something less verbose and IMO more attractive. An example of the format is this:</div><div><br></div><div><div style="color:rgb(0,0,0)">{ #category : #resources, #timeStamp : 'ThierryGoubier 3\/2\/2018 19:24:09' }</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">MCGitTonelTests class >> gitCreateAndInitRepo: dir [</div><div style="color:rgb(0,0,0)"> #(#('init') #('config' 'user.email' '<a href="mailto:you@example.com" target="_blank">you@example.com</a>') #('config' '<a href="http://user.name/" target="_blank">user.name</a>' 'Your Name'))</div><div style="color:rgb(0,0,0)"> do: [ :c | MCTonelGitRepository runGitCommand: c in: dir ]</div><div style="color:rgb(0,0,0)">]</div></div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">I tried to get Esteban to accept these changes *as an option controlled by a preference*, so that Pharo would not have to change its format at all. But when I tried to discuss it with him in mid 2018 and again in early 2019 I was simply rebuffed. Esteban kept on mentioning merge conflicts when</div><div style="color:rgb(0,0,0)">- if Pharo has the preference disabled it will not produce the metadata and hence will not suffer merge conflicts</div><div style="color:rgb(0,0,0)">- a merge conflict would only be experienced had a method actually changed twice independently</div><div style="color:rgb(0,0,0)">Since method timestamps (when correctly implemented) only change when a method actually changes (and a smart system can undo inadvertent changes) Esteban's objection is a straw man.</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">Squeak introduced method timestamps and some of us like them (me very much) as a very convenient way to stamp methods. Any source standard hoping to be widely adopted must be flexible enough to encompass important use cases of the various dialects.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 26, 2020 at 9:41 AM Dale Henrichs <<a href="mailto:dale.henrichs@gemtalksystems.com">dale.henrichs@gemtalksystems.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Eliot,<br>
<br>
When you repost, could you make sure that you include a description of <br>
where the time stamps are stashed ... I'm assuming that you are adding <br>
it to the method properties (where the category is stashed) as I think <br>
that this is the right place, but it's always best not to guess:)<br>
<br>
The current crop of Tonel readers/writers do not necessarily do a good <br>
job of preserving, foreign data (IIRC, the convention is to add a <br>
platform prefix to the property name, which is the same convention used <br>
for class properties ... at GemStone we add a leading `gs_` to our <br>
property names), so until we can get all of the different Tonel <br>
readers/writers to preserve foreign properties (package, class and <br>
method) it will continue to be dicey business for preserving foreign <br>
properties in cross platform projects ...<br>
<br>
Monticello does not explicitly preserve foreign properties as the <br>
definitions get created from the native objects, so it takes some <br>
additional work to arrange to preserve foreign properties for packages, <br>
classes, and methods in the objects themselves. So it is worth <br>
considering what you will do with preserving foreign properties from <br>
other platforms.<br>
<br>
FWIW, I intend to support the preservation of foreign properties in <br>
Rowan (read that as "I haven't done that yet":)<br>
<br>
Finally, Martin McClure has started working on a spec for the next <br>
generation Tonel format ... to add a few missing pieces and tweak the <br>
format to make it possible to continue to evolve the Tonel format into <br>
the future in a somewhat sane way. If there are folks here in the Squeak <br>
community who would like to review, comment and participate in the <br>
creation of the next generation format, send me (or Martin) mail and <br>
we'll get you added to the mailing list.<br>
<br>
Dale<br>
<br>
On 8/26/20 7:15 AM, Eliot Miranda wrote:<br>
> Jakob,<br>
><br>
>> On Aug 26, 2020, at 2:45 AM, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</a>> wrote:<br>
>><br>
>> Hi Eliot,<br>
>><br>
>>> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda<br>
>>> <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:<br>
>>><br>
>>> If we go with Tonel then we must change it to support method timestamps. I have a change set that does this (it is a trivial change). And my changes are controlled by a class variable so that the same code can produce Pharo format or a slightly modified format that includes method timestamps.<br>
>>><br>
>>> What I don’t understand is why Esteban Lorenzano refuses to accept my changes and allow Tonel to be used either with or without method timestamps.<br>
>>><br>
>> Method timestamps produce merge conflicts inevitably.<br>
> a) only when they change, and they change only when methods change<br>
> b) inadvertent method timestamp changes can be undone automatically<br>
> c) Squeak uses method timestamps; we have lots of tools that use them. Dropping them just so that we can use Tonel is an example of the tail wagging the dog. The Tonel interface must instead be made to function with method timestamps<br>
><br>
> If there is a decision not to support method timestamps then I will not support the work. This is a make or break issue for me.<br>
><br>
>> Can you re-post<br>
>> your changeset here?<br>
> I’ll post it later today (reading email in bed right now).<br>
><br>
>> <a href="https://github.com/squeak-smalltalk/squeak-tonel/issues" rel="noreferrer" target="_blank">https://github.com/squeak-smalltalk/squeak-tonel/issues</a><br>
> OK<br>
><br>
>> Then we could<br>
>> discuss whether to include it at least in the Squeak version. As we<br>
>> have heard from Mariano some time ago, VA Smalltalk also puts its<br>
>> dialect-specific metadata in the Tonel format, so Squeak would not be<br>
>> the first to do so.<br>
> Good.<br>
><br>
>> Kind regards,<br>
>> Jakob<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>