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

Ben Coman btc at openinworld.com
Mon Feb 18 13:33:40 EST 2019

On Tue, 19 Feb 2019 at 01:34, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Esteban,
> On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
>> Hi,
>> I’m so not wanting to be part of this discussion, but here I am.
>> Just because it was mentioned my name in a way I consider inaccurate.
>> On 17 Feb 2019, at 21:27, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> Hi All, Hi Torsten, Hi Jakob,
>> On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares at gmx.de> wrote:
>>> Hi,
>>> as some of you might already know "Tonel" is a file-per-class format for
>>> monticello repositories [1].
>>> In Pharo land many projects are already converted to it - as regular
>>> "file tree" solution faces issues
>>> with git handling due to very long file names / deep file hierarchy
>>> (often leading to trouble on Windows).
>>> Dales's Rowan (a new project/package manager for Smalltalk) supports
>>> FileTree and also Tonel
>>> repositories [2]. There is also a tool to convert from STORE
>>> (VisualWorks Source-Code Versioning System)
>>> to Tonel format [3].
>>> So I wonder about adoption of Tonel in Squeak land.
>>> Any status/comments?
>> Last year I was given contract employment by Tudor Girba's feenk which in
>> part was to involve me porting VMMaker.oscog to Pharo in order to reap the
>> productivity benefits of the Glamorous Toolkit when applied to VMMaker.
>> The major direction was to unify the opensmalltalk-vm repository with a
>> Toned-Format repository holding the Smalltalk code.
>> This project, though no fault of feenk's did not go well.  A big part of
>> it was my own emotional attachment to Squeak, my "muscle memory" with
>> Squeak and my long experience with Smalltalk-80 derived meta programming
>> which I make extensive use of in VMMaker.oscog.  But a key issue was that I
>> was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it
>> can live in both places.  In particular I will not risk VMMaker.oscog being
>> stranded on Pharo as it moves away from the "image-based rendering model".
>> This is not because I don't believe in pixel-independent rendering models,
>> but because productivity in VMMaker depends much more than on GToolkit
>> inspection on the key architectural feature of being completely, safely
>> simulateable (not a real English word; but meaning capable of being
>> simulated).  As Pharo moves towards external libraries to implement its UI
>> so the degree to which VMMaker is simulated is reduced.  Thus crashes in
>> external code cannot be handled with the same power as with errors
>> presented within the Smalltalk environment itself, and this (as harsh
>> experience over thirty five years has taught me) is far more important for
>> overall productivity than having powerful tailorable inspectors.
>> I therefore wanted a Tonel that could both function for Squeak's
>> Monticello and for Pharo's Iceberg.  I had modified the Tonel serialization
>> a little to provide well-formatted support for method timestamps, which are
>> still a key and extremely useful part of Squeak Monticello's "blame"
>> equivalent.  Until git author attribution can be imported into Squeak's
>> Monticello (something I don't see happening) I wanted merely to be able to
>> have a variant of Tonel, enabled for example by a class variable, and hence
>> /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but
>> still be functional inside Squeak.  I asked Esteban and was met by a flat
>> no.  Not "OK, but this is an option only you will use", but a flat "not
>> under any circumstance”.
>> This is textually my answer (even with the English errors):
>> … “Anyway the answer will be no :)
>> This was considered, and even the first implementation of tonel had it.
>> Now, this was discarded because it does not works with git (or other file
>> backends). It was not even me who complained first (as I said, I
>> implemented it). It was Dale and other people used to work on git.
>> 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.

This is a case of the difference between theory and practice :)

> I do see the possibility of a bug in Pharo when it was using Monticello
> and timestamps though.

When I heard of this timestamp conflict problem I began with the same
belief to do some digging (and you know how I dig deep into things)
with git-only command line experiments and ended up finding its really
true.  I'll try to remember some examples.

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190219/5d4c65a0/attachment.html>

More information about the Pharo-dev mailing list