Squeak and Tonel

Personally, I am very fond of the use of Git instead of Monticello, but not convinced of Tonel so far. 

Also note that vmmaker history as proposed in opensmalltalk pr was broken (no respect of branch topology). Maybe retry with Squot? 

https://github.com/hpi-swa/Squot

Esteban,

On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <[hidden email]> wrote:

Thing is,  putting timestamps it will generate conflicts massively when there is no reason to it.

How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed.  I see no problem with this.

And Pharo can read that format but it will ignore all extensions. 

Now, another problem is to WRITE: Pharo would write those packages in “pharo format” and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to “honour” that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled. 

Anyway, as you can see my answer was not “not under any circumstances”. Was “no, because is not convenient”.

It was still no.  And my request was clear.  I asked if you would allow Tonel to support timestamps, not that Pharo would use timestamps.  This avoids forking Tonel, which I see as essential (it is essential that Tonel *not* fork) for Tonel to be a format that can serve as an interchange between Squeak and Pharo.

Esteban,

On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <[hidden email]> wrote:

Hi, 

I’m so not wanting to be part of this discussion, but here I am. 

Just because it was mentioned my name in a way I consider inaccurate. 

On 17 Feb 2019, at 21:27, Eliot Miranda <[hidden email]> wrote:

Hi All, Hi Torsten, Hi Jakob,

On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <[hidden email]> wrote:

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?

Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker.  The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.

This project, though no fault of feenk's did not go well.  A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog.  But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places.  In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model".  This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated).  As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced.  Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.

I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg.  I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent.  Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak.  I asked Esteban and was met by a flat no.  Not "OK, but this is an option only you will use", but a flat "not under any circumstance”.

This is textually my answer (even with the English errors): 

… “Anyway the answer will be no :)

This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git. 

Thing is,  putting timestamps it will generate conflicts massively when there is no reason to it.

How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed.  I see no problem with this.

I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though. 

Hi Eliot,

You raise a few technical concerns related to VMMaker that seem addressable:

1. Rendering technology: Both in Pharo and in GT, there exist in-image canvases, Athens and Sparta respectively, that are backend independent. This allows us to have image-based drawing logic, like BitBlt or even better, the drawing capabilities that Juan Vuletich built in Morphic 3, transparently. In fact, we even started to look at the code from Morphic 3 and we think it’s not much effort to make it work behind Sparta. This would provide a complete solution that would not rely on any external libraries.

2. Git history. We used to have the author and timestamp in the metadata of Tonel but because it generated unwanted conflicts it was decided to remove it. I think this is a good decision and one based on the experience of using it. But, why do you think the algorithm of retrieving Git could not be made to work in Squeak? Is there a specific technical reason, or is it more that you do not see the effort being spent in this direction? I am asking to understand what could a possible solution be.


But, let’s take a step back. George and Andrei did move the VMMaker code, including all its history, into Git using (and enhancing) https://github.com/peteruhnak/git-migration.

The code is here:
https://github.com/feenkcom/opensmalltalk-vm/tree/pullrequest5/vmmaker

Our goal was to make the code loadable and runnable in Pharo through Git. We have a reproducible process to produce this history, and this means that we can also synchronize all changes from the Monticello VMMaker repository and produce a history-preserving Git repository.

The current code comes with a BaselineOfVMMaker that loads in Pharo, and the code generation seems to work to a good extent without much effort. There is still work that needs to be done especially on the simulation part, but we think most of it can be addressed through a Pharo-specific package that provides compatibility logic.

I see two benefits for doing this:
1. It allows people in Pharo to play with the VM within the Pharo context and consequently contribute.
2. It allows us to build an environment dedicated for VM development without affecting the current contribution process. We can judge later whether this is useful.

Cheers,
Doru


> On Feb 17, 2019, at 9:27 PM, Eliot Miranda <[hidden email]> wrote:
>
> Hi All, Hi Torsten, Hi Jakob,
>
> On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <[hidden email]> wrote:
> 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?
>
> Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker.  The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.
>
> This project, though no fault of feenk's did not go well.  A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog.  But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places.  In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model".  This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated).  As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced.  Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.
>
> I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg.  I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent.  Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak.  I asked Esteban and was met by a flat no.  Not "OK, but this is an option only you will use", but a flat "not under any circumstance".
>
> So here I am joining in this thread reluctantly.  I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects.  Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch.  The port *does not work*.  Metacello fails to load Scorch.  Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me.  So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.
>
> I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress.  I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether.  The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.
>
> Here's the kind of crap people like Ducasse throw at me:
>
> "Eliot
>
> At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy
> because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have
> to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world
> of the “open” smalltalk VM. "
>
> I am so over this crap.
> _,,,^..^,,,_
> best, Eliot

--
www.feenk.com

“Software has no shape. Actually, it has no one shape. It has many."

> > In any case, you would need something to access the Git history and object database. In Pharo this is the libgit2 binding. In Squot it is FileSystem-Git, which could also be reused to write something
>
> What I had in my mind was a lot simpler: watch a repository for new
> commits. When a new commit appears, fetch it, load the tonel code into an
> image and create the new .mczs. Store the new .mczs in a repository.
> Repeat.
>
> > for Monticello. But since it is coupled with FileSystem, the next discussion will be whether that should finally be adopted into Trunk, and if so in which form. Again, I've heard multiple proponents
> > to make this move.
>
> I'm fine with moving to FileSystem, provided it is ready for production.
> I see two possible ways to achieve that:
> 1. create a layer on top of FileSystem which works like FileDirectory,
> then release it and deprecate it. :)

That's backwards.  FileDirectory is the smaller, faster, lower-level,
more-utilitarian framework.  FileSystem is a "boutique" domain and
framework with powerful high-level capabilities, but suffers from a
performance-killing design issue.  So it'd probably make more sense
for FileSystem use FileDirectory as its "primitive", and then we can
simply keep FileDirectory around as-is for legacy apps.

> 2. add FileSystem to the Trunk and gradually migrate all uses of
> FileDirectory to it.

This would be asking virtually every app to do a similar migration.
All because of Squot?

3.  Port Squot to use FileDirectory.

4.  Don't port anything.  Side-by-side existence.  People who need
Squot simply load Filesystem too.

> > After that, the next problem will be that the current MCRepository hierarchy couples file formats and ancestry storage. In the case of Monticello-in-another-VCS, these are orthogonal: you can have
> > FileTree layouts in Git, you can have Tonel layouts in Git, you could have both at the same time, you could have both in a different VCS in the future... So instead of a "FileTree"-Repository and a
> > "Tonel"-Repository, I think there should rather be a "Git"-Repository that picks the correct readers and writers dynamically to process the files and directories in each commit. To make the smell more
> > tangible: I think neither MCFileTreeRepository (or whathever its name actually is) nor TonelRepository should be subclasses of MCFileBasedRepository (they are today), although it sounds crazy.
>
> I don't think it is a good idea to mix MC and git at all. IMO we only
> need tools to safely and reliably migrate from one to the other to start a
> change.
>
> Levente
>
> >
> > Am Mo., 18. Feb. 2019 um 11:45 Uhr schrieb Levente Uzonyi <[hidden email]>:
> >       On Mon, 18 Feb 2019, Jakob Reschke wrote:
> >
> >       > Am Mo., 18. Feb. 2019, 01:39 hat Levente Uzonyi <[hidden email]> geschrieben:
> >       >
> >       >       Is it a must to use Metacello to load code in Tonel format?
> >       >       What does Metacello add to the mix?
> >       >       Can't we just map each git commit to an mcz?
> >       >
> >       >       Levente
> >       >
> >       >
> >       > Strictly speaking, Metacello is not required. But you would have to resolve the package dependencies yourself and gather them from external repositories, which is the main benefit of
> >       Metacello. So I
> >       > understand that Eliot wants it to work.
> >       >
> >       > There is no mcz to map to. If one were to create a new kind of MCRepository that maps commits to MCVersions, you would have 0..* MCVersions per commit because each commit may touch
> >       multiple packages
> >       > or none. Each commit describes a particular configuration of package versions, so one could generate an artificial MCConfiguration for each commit. Note that Squot / the Git Browser
> >       already supports
> >       > these scenarios for FileTree repositories, albeit without using Monticello for the version control.
> >
> >       Looking at the repository in question[1], there seem to be multiple
> >       packages stored in it[2]: BaselineOfScorch, Scorching, ScorchingDev,
> >       ScorchingTests, ScorchingVMTests. My impression is that these could be
> >       converted to individual mczs for each commit, which would mean that the
> >       same code would be available as MC packages. Then you could load the code
> >       with MC/Metacello/whatever from the .mczs.
> >
> >       Am I missing something?
> >
> >       Levente
> >
> >       [1] https://github.com/clementbera/Scorch
> >       [2] https://github.com/clementbera/Scorch/tree/master/repository
> >
> >       >
> >       >
> >
> >
> >

Fair enough. 

I should not have step in this discussion.

Esteban

On 18 Feb 2019, at 19:48, Eliot Miranda <[hidden email]> wrote:

Esteban,

On Mon, Feb 18, 2019 at 10:37 AM Esteban Lorenzano <[hidden email]> wrote:

Still that’s not the point. 

Not having an agreement is very different that the behaviour you described about me (and that to justify your own actions).

You presented my opposition as it would have been “just because” and I presented you my arguments. Even more, I *was* trying to find a solution.

I can be right or wrong, but I’m not an idiot trying to be more than I am. 

Honestly, discussing with you many times feels like it is “my way or the highway”, and it’s hard to follow you :(

I am not trying to force my way.  I am trying to find a way that works for me.  I asked you to support an option in Tonel.  I did not ask you8 to change they way Pharo uses Tonel. You can choose to read my request as some kind of threat, or you can choose to read it as a straightforward request.  I am not trying to get you to follow me.

I am frustrated at being mistrusted.  I have not asked you to follow me.  I have tried to work with you.  But you don't trust me.

I have done everything I can in the VM (let's ignore source code control and building for now) to support Pharo.  I have done *nothing* to interfere with Pharo's use of the VM in the code base itself.  have I?  Point to actions I have taken, code I have written to try and harm you.

We now have a situation where we support differences in the code base (FilePlugin API, command line argument parsing, version printing) that extend *those I put in at the beginning to support differences* (such as plugins.ext and plugins.int to allow builders to configure the VM as they choose).  Where have I tried to block Pharo?

But you left vm-dev.  You decided to stop communicating.  And now you continue to describe a straight-forward request to allow an optional behavior in  Tonel with a flat refusal, plus some BS about me trying to insist that you follow me.

I don't understand Esteban.  You and I do not communicate.  I feel that you top not want to work with me, that you dislike and distrust me.  I cannot work with you.  I have tried for years and we are still in difference and disagreement.

Esteban

On 18 Feb 2019, at 18:34, Eliot Miranda <[hidden email]> wrote:

Esteban,

On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <[hidden email]> wrote:

Hi, 

I’m so not wanting to be part of this discussion, but here I am. 

Just because it was mentioned my name in a way I consider inaccurate. 

On 17 Feb 2019, at 21:27, Eliot Miranda <[hidden email]> wrote:

Hi All, Hi Torsten, Hi Jakob,

On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <[hidden email]> wrote:

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?

Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker.  The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code.

This project, though no fault of feenk's did not go well.  A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog.  But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places.  In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model".  This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated).  As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced.  Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors.

I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg.  I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent.  Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak.  I asked Esteban and was met by a flat no.  Not "OK, but this is an option only you will use", but a flat "not under any circumstance”.

This is textually my answer (even with the English errors): 

… “Anyway the answer will be no :)

This was considered, and even the first implementation of tonel had it. Now, this was discarded because it does not works with git (or other file backends). It was not even me who complained first (as I said, I implemented it). It was Dale and other people used to work on git. 

Thing is,  putting timestamps it will generate conflicts massively when there is no reason to it.

How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed.  I see no problem with this.

I do see the possibility of a bug in Pharo when it was using Monticello and timestamps though.  There was a time when you, Esteban, were contributing to VMMaker.oscog from Pharo and often there would be many changes where just the timestamp had changed.  SO the problem seems to be not with timestamps but with mismanagement of them.

So, we drop it… and we add support for  the equivalent using the tool we use (iceberg gives you not just the author that modified last the method but all of them, along the history).

Who is we?  I ask from a different perspective.  I ask not too have Pharo use it but to allow Squeak to use it so that I can have timestamps for Squerask and still use Tonel.  But still "“Anyway the answer will be no :)".

So, your first statement is false.  If things are correct there will *not* be massive generation of conflicts when there is no reason.  Second, I am not asking you to change Tonel in Pharo.  i am only asking you to allow Tonel to support timestamps in systems that want to use it.

I hope is an understandable reason?”

And then in other mail of same thread I suggested an approach viable for squeak: 

"Now, what I’m sure is that if you are trying of using the 100% of Monticello and to use git just as another repository backend, it will not work (we already tried). It will consume far too much effort and you will finish beating the purpose of use git and a file-based-format, and you will be in the worst of two worlds :)

We started like that, and we ended up implementing Iceberg to take benefit of the tools we are using.

In the middle, there was/is gitfiletree. 

(I think I suggested you to look at it to adapt it for tonel and squeak).

Gitfiletree uses OSProcess to call git as external tool and it makes all the operations needed. “

Now, what I was suggesting was a way to use tonel backed with OSProcess (which works in squeak) instead backing it with libgit2 as us. 

Since they need the blame support, they could use OSProcess and external git for it.

Of course squeak (and any other dialect) are free to take tonel and adapt it to their needs (in fact, Mariano extended Tonel for VA specific things). 

And Pharo can read that format but it will ignore all extensions. 

Now, another problem is to WRITE: Pharo would write those packages in “pharo format” and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to “honour” that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled. 

Anyway, as you can see my answer was not “not under any circumstances”. Was “no, because is not convenient”.

It was still no.  And my request was clear.  I asked if you would allow Tonel to support timestamps, not that Pharo would use timestamps.  This avoids forking Tonel, which I see as essential (it is essential that Tonel *not* fork) for Tonel to be a format that can serve as an interchange between Squeak and Pharo.

Esteban

So here I am joining in this thread reluctantly.  I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects.  Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch.  The port *does not work*.  Metacello fails to load Scorch.  Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me.  So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista.

I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress.  I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether.  The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI.

Here's the kind of crap people like Ducasse throw at me:

"Eliot 

At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy

because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have 

to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world 

of the “open” smalltalk VM. "

I am so over this crap.

_,,,^..^,,,_

best, Eliot

-- 

_,,,^..^,,,_

best, Eliot

-- 

_,,,^..^,,,_

best, Eliot

3.  Port Squot to use FileDirectory.