Hi Norbert,


On Jan 13, 2018, at 4:12 AM, Norbert Hartl <norbert@hartl.name> wrote:



Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda@gmail.com>:

Hi Stephan,


On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan@stack.nl> wrote:

Eliot Miranda <eliot.miranda@gmail.com>
wrote:
Isn't it important to preserve the ability to exchange code
between Pharo,
Squeak and Cuis?  Don't you care that the VM development is directly
affected by this?  Is the VM and plugin support not important to Pharo?

Git support turns out to be much more work than we hoped and expected. Too
many library updates needed, support for different workflows and platforms,
switch to file per class. The Iceberg channel on Discord is one of the
busiest channels. 

You don't say?  One of Cl��ment's themes in recent talks on VM performance is that we, as a very small team, are able to develop such a sophisticated optimizer because we use Smalltalk.  We are hugely productive in the vm simulator.  People using Smalltalk, including the Pharo, Squeak and Cuis dialects that constitute our community, report the same in many different domains, notably Bloc, GT Toolkit and Rossal.

Then why on /earth/ would one stop using Smalltalk in /the most central part/ of the collaborative programming process, version control?  This is a huge blunder.  Now a major part of the Pharo community's efforts goes into an external component, upon which Pharo is entirely dependent, and slowly but surely it is cutting itself off from its sibling communities.  Iceberg is well named.  People rearranged the chairs on deck while the Titanic sank.

Can we agree that a class/method/��� stops being smalltalk after it has been serialized to text? If you can agree to this I don���t know what you are talking about. We exchange the to-text-serializer monticello-backend with git-backend. The rest (the important part) stays nearly the same.

Nearly the same is not all the same ;-). Somehow the export through gif is fiffetebt; it has been losing the time stamp metadata for ages (I was noticed gong this in Esteban's VMMaker commits at least a year ago) and still it doesn't work.

But a big difference is that the Monticello mcz package (only one among many formats) uses zip file support written in Smalltalk (from which a vm plugin is generated) and the zip file format is much sikmpler as an API than the API needed to integrate with git. 

Another difference is that, because hot is a version control system in its own right, integrating with it is a poison pill.  People will (and do!) want to use their own git tools and so the pressure is on to make Smalltalk fit git rather than got fit Smalltalk, to put effort on the git side instead of improving the Monticello side.

And the other difference is the number and nature of the crashes with the git integration.  There are crashes in c libraries.  There are certificate problems.  There are password problems.  The surface is much larger and do there are more problems.

The exchange is necessary because the possibilities of collaboration are limited when using monticello only. So what would be the alternative?

Beno��t answered this well.  But as they say, there are many ways to skin a cat.  With the right statement of principles the right kind of integration might be definable.  For example, with a class per file approach has anyone considered publishing two files, one that preserves all data and another that is designed for GitHub's code diffing?

There are even a lot of people that don���t like git (including me). But I like the collaboration model because that can do what no smalltalk tool can do to my knowledge. 

Git can do nothing that Monticello cannot do except manage external files.  But extending Monticello to manage external files is possible because we control it.  GitHub, on the other hand, /is/ different.  It provides a social platform, issue tracking, and a globally recognized brand.

I use both git and Monticello in the vm work and Monticello is a joy to work with.  I wish I could say the same for git.  I do think that github is good.  I do wish that it wasn't so git-centric :-(

Or to turn your argument around. You are a small vm team and you have to be small because I doubt with the current collaboration model you are able to grow. 

Not at all.  Monticello scales to the entire Pharo and Squeak community so it cannot be the limiting factor on the size of the vm sub culture.  And of bourse putting the generated C code on GitHub has been a huge improvement over Subversion.  But the vm maintains a comfortable split between VMMaker & Smalltalk under Monticello and the generated C under git & GitHub. 

Norbert


Stepha

_,,,^..^,,,_ (phone)