<div dir="ltr"><div dir="ltr">Hi Torsten,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 1:54 PM Torsten Bergmann <<a href="mailto:astares@gmx.de">astares@gmx.de</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"> <br>
Hi Eliot,<br>
<br>
>there's a simpler solution.  We simply delete Alien-Core-TorstenBergmann.101<br>
<br>
Yes - no problem with that and thanks for taking care. But a copy might exist still in local Monticello caches<br>
on user side.<br>
<br>
So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest addition to compensate<br>
the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a second time).<br>
<br>
>I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was<br>
>unaware of the issue.<br>
<br>
Yes - for the timestamp I did not notice directly (or even forgot because I guess I just had a newer Pharo<br>
image on the machine which was already switched git but still includes MCZ tools).<br>
<br>
But if you really require the timestamps explicitly on each method for the VMMaker / Alien packages<br>
then it means one is only allowed to use Squeak or old Pharo versions to contribute / commit and<br>
VM development will never move away from MCZs in all our lifetime.<br></blockquote><div><br></div><div>I disagree with this interpretation. Pharo chose to discard timestamps and did not care about the impact on anyone else.  Further. timestamps are not a property of MCZ's but of methods.  It would have been simple to retain timestamps in the Tonel format (I'e modified Tonel to preserve these), but Pharo decided not to.  I find method timestamps extremely useful in finding out who did what when, and hence who to ask.  I don't find Iceberg provides the same convenience, several years after I was told that Pharo/Git integration would be as good as Monticello.  Personally I don't find it so.  Specifically in the image how do I find out who made the last change to a method?  </div><div><br></div><div>So in staying with timestamps I am simply trying to remain productive and will be coerced by the Pharo community.  If it choses to fork the repository, stop collaborating, break compatibility with Squeak that is its choice, but it will live with the consequences, and I will be coerced into losing productivity, or moving to technologies I experience as inferior.</div><div><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">The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file<br>
format directly would always mean a change/conflict in the diffs of git anytime - even if there is no real code change<br>
on the method or class itself.<br></blockquote><div><br></div><div>Well, it would be easy to write a tool that put them back, and synthesized timestamps for those methods that changed.  But for several years it has been the case that timestamps have been screwed up.  The solution is not to simply discard them because something useful is too difficult to program.  But that seems to be a default position for Pharo.  Backwards compatibility, playing nicely with other related communities, are too onerous.</div><div><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">We all know git is widely accepted in IT shops around the world, really a breeze to work with - now even with and in Smalltalk code.<br></blockquote><div><br></div><div>I use git daily.  I find it still has significant bugs, complexities, a truly horrible command vocabulary, an insistence on line feeds, and so on.  And unlike Monticello I can't realistically do anything about it.  Whereas Monticello belongs to us and we can (and have) evolved it quickly and productively many times.  Git, if it has any advantages, does so in the context of GitHub.  And I know from personal experience that it is possible to use git as a backend for Monticello.  An approach that could have kept everyone happy.</div><div> </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">
With git one gets timestamps out of the box - but also a lot more like proper branching (which is nearly impossible<br>
to handle in MCZs for the Monticello/Metacello approach). </blockquote><div><br></div><div>I disagree.  We branch with Monticello occasionally (Clément implemented incremental compaction in a branch).  What are these impossibilities you mention?  And where are these timestamps of which you speak? I use Pharo 7.x in my consulting work and I see no per-method last-commit information in the browser, or in the commit diff tool (Iceberg->Repository->commit to commit comparison).</div><div> </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">Also GIT can version Smalltalk and non-Smalltalk code<br>
at the same time and using the same way.</blockquote><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">
<br>
In fact one rarely finds a project which is Smalltalk code only - often you have other assets or code in other languages too.<br>
And VMMaker is a good example for that.<br></blockquote><div><br></div><div>And we have a solution.  We use git for the generated C and all non Smalltalk assets.  And we use Monticello with timestamps for the Smalltalk code, and it works well.  Those of us using this scheme are able to fix bugs that have been long outstanding and not fixed by the Pharo VM engineers.  I have just completed a JIT for the ARMv8 in record time while also doing a consulting gig.  So I'm not unhappy with my style of work and won't be bullied into changing it because I'm told it's so much better doing it a different way.  I use Pharo in my consulting work and I'm amazed by constant quality issues, an editor that gets in my way, an input event system that stops responding to meta key modifiers, still has no accelerator for ifTrue:ifFalse:, uses fixed pitch fonts, and on, and on.  I'm very happy where I am.  I'm sorry that doesn't suit you.  I am not forcing you to change.  I would appreciate the same respect.</div><div> </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">I personally therefore like git much much more than the old more limiting MCZ solutions. Seen from the outside I still fail to<br>
understand why<br>
<br>
  - on one side the VM code is maintained with git on GitHub<br>
  - on the other side the core Smalltalk parts like VMMaker are still versioned as MCZ and hosted on old services like<br>
    SqueakSource / <a href="http://source.squeak.org" rel="noreferrer" target="_blank">source.squeak.org</a><br>
<br>
Even Squeak might hopefully move forward and use git in the future. Then VMMaker will face the similar issue with the<br>
timestamps. If I understood sources like<br>
<br>
   <a href="https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi121.pdf" rel="noreferrer" target="_blank">https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi121.pdf</a><br>
<br>
correctly then one can already use Git as a backend VCS from Squeak too.<br></blockquote><div><br></div><div>I spent at least month last year trying to get Tonel and Git working in Squeak.  It didn't work.  Esteban refused point blank to allow me to maintain an optional alternative Tonel that preserved time stamps.</div><div> </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">>Torsten is a very nice guy.<br>
<br>
Thanks for the compliment - but like any other human I have a dark side too :)<br>
<br>
>But the issue of no time stamps intr4oduceing lots of noise into Monticello repositories<br>
>is an annoying g piece of passive aggressive B.S. from the Pharo community which we should push back against.<br>
<br>
What kind of noise exactly are you referring too?<br>
<br>
No need for a conspiracy theory or blaming of the overall Pharo community - loosing the timestamp is related to the<br>
git switch as explained.<br>
<br>
I know there are sometimes personal differences among members of the various communities - and there is potential for<br>
conflicts depending on personality and if the (code) area of work is the same - and when the ideas for the solution(s) differ.<br>
<br>
But basically in all the communities I assume the individuals are trying to move things and ideas forward. Sometimes<br>
we all pull/push into similar direction - sometimes not because goals or ideas differ slightly or even heavily.<br>
I assume (and hope) nobody does harmful things willingly just to bug other sides.<br></blockquote><div><br></div><div>What is your intent here Torsten?  Are you trying to heal a rift?</div><div><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">Anyhow - I hope 2020 will be a good year with good progress for ALL the communities.<br>
<br>
Thx<br>
T.<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></div>