[Vm-dev] Need an Alien-Core-eem.102 update

Sat Jan 18 23:42:39 UTC 2020

Hi Torsten,

On Mon, Jan 13, 2020 at 1:54 PM Torsten Bergmann <astares at gmx.de> wrote:

>
> Hi Eliot,
>
> >there's a simpler solution.  We simply delete
> Alien-Core-TorstenBergmann.101
>
> Yes - no problem with that and thanks for taking care. But a copy might
> exist still in local Monticello caches
> on user side.
>
> So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest
> addition to compensate
> the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a
> second time).
>
> >I'll do that by Monday if no one objects. I'm sure Torsten meant no harm
> and was
> >unaware of the issue.
>
> Yes - for the timestamp I did not notice directly (or even forgot because
> I guess I just had a newer Pharo
> image on the machine which was already switched git but still includes MCZ
> tools).
>
> But if you really require the timestamps explicitly on each method for the
> VMMaker / Alien packages
> then it means one is only allowed to use Squeak or old Pharo versions to
> contribute / commit and
> VM development will never move away from MCZs in all our lifetime.
>

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?

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.

The Pharo tools do not have the timestamp in MCZs anymore due to the switch
> to GIT. Because having the timestamp in the file
> format directly would always mean a change/conflict in the diffs of git
> anytime - even if there is no real code change
> on the method or class itself.
>

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.

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.
>

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.

> With git one gets timestamps out of the box - but also a lot more like
> proper branching (which is nearly impossible
> to handle in MCZs for the Monticello/Metacello approach).

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).

> Also GIT can version Smalltalk and non-Smalltalk code
> at the same time and using the same way.

> In fact one rarely finds a project which is Smalltalk code only - often
> you have other assets or code in other languages too.
> And VMMaker is a good example for that.
>

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.

> I personally therefore like git much much more than the old more limiting
> MCZ solutions. Seen from the outside I still fail to
> understand why
>
>   - on one side the VM code is maintained with git on GitHub
>   - on the other side the core Smalltalk parts like VMMaker are still
> versioned as MCZ and hosted on old services like
>     SqueakSource / source.squeak.org
>
> Even Squeak might hopefully move forward and use git in the future. Then
> VMMaker will face the similar issue with the
> timestamps. If I understood sources like
>
>
> https://hpi.de/fileadmin/user_upload/hpi/dokumente/publikationen/technische_berichte/tbhpi121.pdf
>
> correctly then one can already use Git as a backend VCS from Squeak too.
>

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.

> >Torsten is a very nice guy.
>
> Thanks for the compliment - but like any other human I have a dark side
> too :)
>
> >But the issue of no time stamps intr4oduceing lots of noise into
> Monticello repositories
> >is an annoying g piece of passive aggressive B.S. from the Pharo
> community which we should push back against.
>
> What kind of noise exactly are you referring too?
>
> No need for a conspiracy theory or blaming of the overall Pharo community
> - loosing the timestamp is related to the
> git switch as explained.
>
> I know there are sometimes personal differences among members of the
> various communities - and there is potential for
> conflicts depending on personality and if the (code) area of work is the
> same - and when the ideas for the solution(s) differ.
>
> But basically in all the communities I assume the individuals are trying
> to move things and ideas forward. Sometimes
> we all pull/push into similar direction - sometimes not because goals or
> ideas differ slightly or even heavily.
> I assume (and hope) nobody does harmful things willingly just to bug other
> sides.
>

What is your intent here Torsten?  Are you trying to heal a rift?

Anyhow - I hope 2020 will be a good year with good progress for ALL the
> communities.
>
> Thx
> T.
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200118/75f48af4/attachment.html>