[Vm-dev] [squeak-dev] Squeak and Tonel

[Jakob Reschke]

Hi Eliot,

Am Mo., 18. Feb. 2019 um 18:34 Uhr schrieb Eliot Miranda <
eliot.miranda at gmail.com>:

> Esteban,
>
> On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
>
>>
>> Thing is,  putting timestamps it will generate conflicts massively when
>> there is no reason to it.
>>
>
> How can this be true? Since a method's time stamp changes only when it is
> modified it will only produce a change where a method is changed.  I see no
> problem with this.
>

When two people's changes to the same method are merged with Git (or on
GitHub for that matter) there will be a conflict at the line that contains
the timestamp. Even if the method source could be merged conflict-free.
Moreover, none of the two original timestamps will be accurate for the
merged version of the method, so in fact there *must* be a conflict. This
is only alleviated by performing the merge in the IDE where a new timestamp
could be generated for the merged method. For otherwise clean merges, this
is probably unacceptable for people that just want to press the "merge"
button on a pull request.


>
>> And Pharo can read that format but it will ignore all extensions.
>> Now, another problem is to WRITE: Pharo would write those packages in
>> “pharo format” and that information would be lost. And in the case of
>> VMMaker, if the idea is to be able to work on both sides, then Pharo needs
>> to “honour” that format, it cannot just read it and ignore it later. So
>> this creates an incompatibility that needs to be handled.
>>
>
This is the reason why Pharo cannot just "not use" timestamps and yet
support them. Every Pharo user on the team would eliminate the timestamps
that the Squeak team members committed. Except if Pharo would allow to
carry the existing timestamps around in the code model for Squeak, but it
sounds like they are not willing to do that, are they?


>> Anyway, as you can see my answer was not “not under any circumstances”.
>> Was “no, because is not convenient”.
>>
>
> It was still no.  And my request was clear.  I asked if you would allow
> Tonel to support timestamps, not that Pharo would use timestamps.  This
> avoids forking Tonel, which I see as essential (it is essential that Tonel
> *not* fork) for Tonel to be a format that can serve as an interchange
> between Squeak and Pharo.
>

Kind regards,
Jakob

PS. Note that I am not on pharo-dev and do not wish to subscribe for just
one thread, so I had to omit them from CC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190218/24c6333d/attachment.html>