[squeak-dev] Squeak and Tonel

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Feb 15 09:47:24 UTC 2019


Le ven. 15 févr. 2019 à 09:45, Fabio Niephaus <lists at fniephaus.com> a
écrit :

>
>
> On Fri, Feb 15, 2019 at 8:58 AM Jakob Reschke <forums.jakob at resfarm.de>
> wrote:
>
>> With these modest requirements, David, please try the port and open
>> issues for anything that bugs you about it.
>>
>>
>> Am Fr., 15. Feb. 2019, 02:14 hat David T. Lewis <lewis at mail.msen.com>
>> geschrieben:
>>
>>> Hi Torsten,
>>>
>>> Thank you very much for asking about this, and thanks to Nicolas for the
>>> explanations.
>>>
>>> As a package maintainer (OSProcess and others), I want to be able to
>>> provide continued support for Pharo users, and it would probably be
>>> helpful
>>> if I could read and write to Tonel as an external format. I am also
>>> interested
>>> in being able to browse and read the projects (many of them quite
>>> excellent)
>>> that are being developed in Pharo from my Squeak image.
>>>
>>> I am a big fan of git, but I do not care about integrating it with the
>>> image (Squeak/Pharo) because I prefer using the in-image tools in Squeak,
>>> and when I do use git, I prefer to use git tools directly.
>>>
>>
> I believe Jakob's Git integration (see below) can also be controlled from
> within a workspace.
>
>
>>
>>> I am not well informed about this topic, but overall I would say that
>>> being
>>> able to read and write Tonel format from Squeak would be very helpful,
>>> and
>>> I would probably not care very much about version control integration.
>>>
>>> Thanks again for asking,
>>>
>>> Dave
>>>
>>>
>>> On Thu, Feb 14, 2019 at 11:15:23PM +0100, Nicolas Cellier wrote:
>>> > I think that we should at least support the input/output of tonel
>>> packages
>>> > for inter-operability.
>>> > Since the git repositories are metadataless, we can't do much more
>>> without
>>> > a lot of work.
>>> >
>>> > Since tonel has no support for timestamps, it looses authorship (it is
>>> > replaced by committer-ship).
>>> > If we don't want to loose authorship, then we need to port whole
>>> history to
>>> > git with known initials <-> git(hub) account database.
>>> > This is currently working for single package with complex graph (to
>>> > filetree format, but could work for Tonel too).
>>> > If you want to commit several MC packages in same git repository, then
>>> it's
>>> > currently impossible to support complex history.
>>> > There is generally no information that enables inter-MC-package
>>> > synchronization (unless some sort of MCConfigurationMap is used, which
>>> at
>>> > least gives a few sync point in history...).
>>>
>>
> Agreed. Too bad Tonel has become the default format in Pharo already. If
> we want to support it, we also have to live with it's flaws...
>
>
I think that Pharo is on the right path: if you want to be a mainstream
language, you cannot always swim against the tide.
In this battle, Pharo can't afford waiting for a better solution tomorrow,
they prefer a good enough solution today.
Perfect MC tools that would not integrate in github development (code
review, issue tracker, test bots on feature branches/pull requests, ...) is
not interesting them.
It's a recipe for being categorized as bizarre and outdated.

It's just that Squeak goals are a bit different.
So yes, we have to live with it...
Maybe it is time to refresh what these Squeak goals/directions are (based
on last year inquiry?)

>
>>> > If we want to perform essential operations like commit/pull/merge or
>>> access
>>> > essential information as history/revisions/diffs then we have to
>>> > - either reproduce the very hard work that began in Pharo: program a
>>> git
>>> > client inside the image,
>>> > - or loose inside image tools.
>>> >
>>> > Squeak MC tools are much more productive than Pharo MC tools:
>>> > - they scale well even for massive changes (i did check with auto
>>> generated
>>> > Smallapack interface)
>>> > - they support cherry-picking: you see and control what you commit
>>> > - they are quasi bugfree
>>> > - the magma backend provides a few additional features (revisions...)
>>> > Pharo team has produced huge effort for the github switch, but it does
>>> not
>>> > go without pain. Despite the importance of being visible on github, and
>>> > profit by state of the art web collaborating tools, i don't see Squeak
>>> able
>>> > to take this major turn in near future.
>>>
>>
> Squeak's MC tools are great and I also thought Squeak can't support Git
> any time soon. It turns out Jakob has already done most of the heavy
> lifting as he worked on a Smalltalk implementation of Git. It even comes
> with a Sourcetree-like UI which supports the most important operations
> already. In case you haven't seen it, you can install it via "Do" >
> "Installer installGitInfrastructure" (Squeak-5.2 or later). You can then
> find it's UI under "Apps" > "Git Browser". Please file bugs at [1].
> Unfortunately, the bus factor of this integration is still quite low, but
> I'd like to see more people working on it.
>
> Fabio
>
> [1] https://github.com/hpi-swa/Squot/issues
>
>
I'll be very happy to be proven wrong about near future :)
I wish I had more time to support Squot...
But even with very little time, the least we can do is to try it, report
problems, make suggestions.
Last time I checked, it was good enough for converting single package
history to git, so we can do it.
I did not take time to play with git integration though.
A bit late for new year resolutions, but I promise I'll try again soon ;)

>
>>> > If we want to have mix development with packages maintained both in a
>>> MC
>>> > repository and a git metadataless repository,
>>> > then we have the problem of finding a common ancestor.
>>> > I think that this could be doable with some conventions (like storing
>>> the
>>> > .last_known_mc_ancestor in a file)
>>> > Of course, it's re-introduction of metadata, but the minimal possible,
>>> and
>>> > leads to easy to resolve conflicts (that can be automated)...
>>> >
>>> > The last grief I have with Tonel is that it is not syntax agnostic.
>>> > Since we have a language where we can define compilerClass/parserClass,
>>> > that's unfortunate (The application i developed in the 90's did use
>>> such
>>> > important feature, it's not just theoretical)
>>> > It could have been language agnostic with very little effort (remember
>>> the
>>> > discussion on Pharo-dev, just using an arbitrary number of [[[   ]]] as
>>> > method body separators would suffice)
>>> > For most packages, that will not be a problem though.
>>> >
>>> >
>>> > Le jeu. 14 f??vr. 2019 ?? 15:17, Torsten Bergmann <astares at gmx.de> a
>>> ??crit :
>>> >
>>> > > Hi,
>>> > >
>>> > > as some of you might already know "Tonel" is a file-per-class format
>>> for
>>> > > monticello repositories [1].
>>> > >
>>> > > In Pharo land many projects are already converted to it - as regular
>>> "file
>>> > > tree" solution faces issues
>>> > > with git handling due to very long file names / deep file hierarchy
>>> (often
>>> > > leading to trouble on Windows).
>>> > >
>>> > > Dales's Rowan (a new project/package manager for Smalltalk) supports
>>> > > FileTree and also Tonel
>>> > > repositories [2]. There is also a tool to convert from STORE
>>> (VisualWorks
>>> > > Source-Code Versioning System)
>>> > > to Tonel format [3].
>>> > >
>>> > > So I wonder about adoption of Tonel in Squeak land.
>>> > >
>>> > > Any status/comments?
>>> > >
>>> > > Thx
>>> > > T.
>>> > >
>>> > > [1] https://github.com/pharo-vcs/tonel
>>> > > [2] https://github.com/GemTalk/Rowan
>>> > > [3]
>>> > >
>>> https://pharoweekly.wordpress.com/2019/01/20/ann-sett-store-export-to-tonel-tools-for-pharo6-1/
>>> > >
>>> > >
>>> > >
>>> > >
>>>
>>> >
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190215/8ba37b20/attachment.html>


More information about the Squeak-dev mailing list