<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi, <div class=""><br class=""></div><div class="">I’m so not wanting to be part of this discussion, but here I am. </div><div class="">Just because it was mentioned my name in a way I consider inaccurate. <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 17 Feb 2019, at 21:27, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" class="">eliot.miranda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">Hi All, Hi Torsten, Hi Jakob,</div><br class=""><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" class="">astares@gmx.de</a>> wrote:<br class=""></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">Hi,<br class="">
<br class="">
as some of you might already know "Tonel" is a file-per-class format for monticello repositories [1].<br class="">
<br class="">
In Pharo land many projects are already converted to it - as regular "file tree" solution faces issues <br class="">
with git handling due to very long file names / deep file hierarchy (often leading to trouble on Windows).<br class="">
<br class="">
Dales's Rowan (a new project/package manager for Smalltalk) supports FileTree and also Tonel <br class="">
repositories [2]. There is also a tool to convert from STORE (VisualWorks Source-Code Versioning System) <br class="">
to Tonel format [3].<br class="">
<br class="">
So I wonder about adoption of Tonel in Squeak land. <br class="">
<br class="">
Any status/comments?<br class=""></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""></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 class=""><br class="">Thing is, putting timestamps it will generate conflicts massively when there is no reason to it.<br class="">So, we drop it… and we add support for the equivalent using the tool we use (iceberg gives you not just the author that modified last the method but all of them, along the history).<br class=""><br class="">I hope is an understandable reason?”</div><div><br class=""></div><div>And then in other mail of same thread I suggested an approach viable for squeak: </div><div><br class=""></div><div><div class="">"Now, what I’m sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :)</div><div class=""><br class=""></div><div class="">We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using.</div><div class=""><br class=""></div><div class="">In the middle, there was/is gitfiletree. </div><div class="">(I think I suggested you to look at it to adapt it for tonel and squeak).</div><div class=""><br class=""></div><div class="">Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. “</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. </div><div class="">Since they need the blame support, they could use OSProcess and external git for it.</div><div class=""><br class=""></div><div class="">Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). </div><div class="">And Pharo can read that format but it will ignore all extensions. </div><div class="">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. </div><div class=""><br class=""></div><div class="">Anyway, as you can see my answer was not “not under any circumstances”. Was “no, because is not convenient”.</div><div class=""><br class=""></div><div class="">Esteban</div><div class=""><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.</div><div class=""><br class=""></div><div class="">I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.</div><div class=""><br class=""></div><div class="">Here's the kind of crap people like Ducasse throw at me:</div><div class=""><br class=""></div><div class="">"<span style="" class="">Eliot </span></div><div style="" class=""><br class=""></div><div style="" class=""><span class="gmail-il">At</span> the <span class="gmail-il">end</span> of the <span class="gmail-il">day</span> I will probably ask the two phds that should work <span class="gmail-il">on</span> language design to use truffle or pypy</div><div style="" class="">because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have </div><div style="" class="">to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is <span class="gmail-il">in</span> the pico world </div><div style="" class="">of the “open” smalltalk VM. "</div><div style="" class=""><br class=""></div><div style="" class="">I am so over this crap.</div></div><div dir="ltr" class="gmail-m_-2601350501237284002gmail_signature"><div dir="ltr" class=""><div class=""><span style="font-size:small;border-collapse:separate" class=""><div class="">_,,,^..^,,,_<br class=""></div><div class="">best, Eliot</div></span></div></div></div></div></div>
</div></blockquote></div><br class=""></div></body></html>