<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Feb 2019 at 01:34, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Esteban,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi, <div><br></div><div>I’m so not wanting to be part of this discussion, but here I am. </div><div>Just because it was mentioned my name in a way I consider inaccurate. <br><div><br><blockquote type="cite"><div>On 17 Feb 2019, at 21:27, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:</div><br class="gmail-m_-3469864357008197088gmail-m_-8714945078540956968Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All, Hi Torsten, Hi Jakob,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <<a href="mailto:astares@gmx.de" target="_blank">astares@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].<br>
<br>
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues <br>
with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).<br>
<br>
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel <br>
repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) <br>
to Tonel format [3].<br>
<br>
So I wonder about adoption of Tonel in Squeak land. <br>
<br>
Any status/comments?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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”.</div></div></div></div></div></blockquote><div><br></div><div>This is textually my answer (even with the English errors): </div><div>… “Anyway the answer will be no :)</div><div>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. <br><br>Thing is,  putting timestamps it will generate conflicts massively when there is no reason to it.<br></div></div></div></div></blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>This is a case of the difference between theory and practice :)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though.  </div></div></div></div></blockquote><div><br></div><div><div>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)</div><div>with git-only command line experiments and ended up finding its really true.  I'll try to remember some examples.</div></div><div><br></div><div>cheers -ben</div></div></div>