On 13 January 2018 at 20:12, Norbert Hartl <[email protected]> wrote: >> >> Am 13.01.2018 um 12:39 schrieb Eliot Miranda <[email protected]>: >> >> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <[email protected]> wrote: >>> >>> 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?
I sure Eliot referred to the external C library of libgit2 regarding stepping outside of the Smalltalk environment. Its the root source of the segfaults that is killing the reliability. > 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. The > exchange is necessary because the possibilities of collaboration are limited > when using monticello only. So what would be the alternative? The alternative would be a Smalltalk implementation of git. This would surely reduce segfaults and make debugging easier with a wider pool of contributors. The downside would be tracking the evolution of git. Perhaps when libgit2 was selected the balance was foreseen in its favour. However with current experience perhaps this balance is worth review. For POC, here are some other language native implementations of git... http://www.eclipse.org/jgit/ https://github.com/jelmer/dulwich https://github.com/mirage/ocaml-git https://github.com/danlucraft/git.js https://github.com/henon/GitSharp THIS ARTICLE is really informative... http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ Can anyone here familiar with Haskell help with converting those code examples to Smalltalk? @Eliot, Given that Pharo is likely to continue down the git path, how interested do you think the Squeak community would be in a Smalltalk implementation of git to facilitate future collaboration. Maybe the question could be raised there separately? @Juan, IIUC Cuis already primarily uses git for Smalltalk source code management. How is this currently done and would you partake in a Smalltalk implementation of git? > 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. Simply we either stay the same; Or we move. Moving does risk that a wrong path is started, or we go a long way round, but even on a non-optimal paths much can be learnt. Pharo zen is "Learning from mistakes." and while I don't believe libgit2 was a mistake since it allowed Iceberg development to start at a higher level, perhaps replacing it with a native Smalltalk implementation is worth a trial. Some subparts of this might make a good GSoC project (?) cheers -ben P.S. No-one has mentioned the "content addressable" nature of git which I believe is the *real* paradigm shift in VCS that we should pursue. With a CompiledMethod referencing a hash of its method-source rather than a location in a particular file on a filesystem, opens the possibility of a dozen different providers for locating that method-source that are all equivalent and substitutable with one another for maintaining compatibility between Smalltalk dialects. The hash could reference a "git object" of that hash, or an entity on IPFS (https://ipfs.io) or http://my.simpleServer.com/methodhash.
