Cleaning unneeded UpdateStreamDownloader
Locked
Cleaning unneeded UpdateStreamDownloader
 
|
I wish we have .cs as in old days , but some people like using clumsy tools.
So if we do not use .cs anymore why have UpdateStreamDownloader and related to lo download .cs from server ? Edgar @morplenauta |
Re: Cleaning unneeded UpdateStreamDownloader
|
|
Hi Edgar, Yes, there are good reasons for not using .cs. .cs do not scale. Or history has to be purely linear, which does not happen in real world. Merging concurrent versions is impractical, or even impossible without a history of branches. I've used .cs for more than ten years in the 90s, and even with a team reduced to 3 persons, it was far from ideal! Some features would take time to implement, and inevitably lead to conflicts. We finally had to put version history in method/class comments (author+timestamp+reason of change). A poor man source code versionning that bloated the source code with orthogonal information... I separated UpdateStream in own package in 2013 for the purpose of removing it, but this is unfinished work... One has to check if there are not unique implementor sends leaking outside the package. 2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene <[hidden email]>: I wish we have .cs as in old days , but some people like using clumsy tools. |
Re: Cleaning unneeded UpdateStreamDownloader
|
|
Could send this to Cuis list ?
Like what Juan have to said.
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
2018-07-22 17:17 GMT+02:00 Edgar De Cleene <[hidden email]>:
If you look at https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/CodeManagementInCuis.md you will see that package had to be introduced in Cuis for easing contributions. Why packages are not managed with change set? Because it would not scale... They are handled by git/github. Then there is a big ball called Cuis Core which is thus kind of special package still managed with change set... First, I ask you: how many people can integrate the change set in the core image apart Juan? See for example, when by miracle a change set is integrated immediately (otherwise it would have to change update number), Even if not written by Juan, it is integrated by Juan. And you see a linear history without branches in the update numbers. But pull requests are not necessarily linear. It means that Juan so far deploy efforts to sort out the changes and integrate them. It also fits well his volunty to control Cuis. You see that Cuis is an exact example of https://en.wikipedia.org/wiki/Benevolent_dictatorship. It's not our model in Squeak. Second, I maintain that it would not scale for us. There are 14 contributors in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors and 81 closed pull request in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls, and only a subset of them concerning change sets. So probably not many conflicts so far. Please compare to how many package versions in Squeak inbox and treated inbox. Third, what if I forked https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates and made several changes, some accepted and integrated by Juan, but with a different update number, some yet not integrated, some refused... How am i supposed to merge? That's the manual handling of change sets that typically is difficult and error prone, and that I don't want to live with anymore. Last, since there are packages, why do Cuis Core has to be handled specially? Because of live updating. We use the image to change the image, so from time to time, special actions (scripts) are required for bootstrapping. A good example is changing compiler or core features in Morphic. This is the main reason for keeping changeset: git does not have anything to offer for live update, git is designed for dead code. So I guess that rather than inventing own new way to handle live update thru git (it could mean something as complex as the Pharo bootstrapping efforts), Juan preferred to keep the .cs like he always did when the project was single-manned. This does not make .cs a good choice, just a default choice. In Squeak we have same problem with live update. We have to use the MonticelloConfigurationMap (MCM) for live updating the image. These live-update mcm are numbered, like the CoreUpdates are numbered in Cuis. They have to be loaded/merged in sequence because of bootstrap scripts, and thus cannot be applied in arbitrary orders which severely limit the opened branching model of git... But a big difference with Cuis is that a new MCM is emitted if and only if a bootstrap srcipt is necessary, not for every core change! And a second enormous difference: these mcm do not contain code. They only contain reference to package versions. This is what enables the whole source code to be managed in a single way: Monticello packages. This gives possibility to browse every method edition unlike .cs. This also give the possibility to merge with local image modifications rather than overwrite like in Cuis (though there is no guaranty that the bootstrap scripts will work in a modified image, like with .cs). I don't want to discuss more the choices of Juan. They were done in a certain context that does not match ours. He always refused to integrate MC for not bloating the Cuis image. The will to be present on github guided him to this package solution, in this context Monticello could be viewed more as an obstacle than a solution. The live update problem forced him to be conservative with .cs with a scope reduced to Core. Given the smaller size of core code in Cuis and the benevolent dictatorship model, it may last. I can tell you that I used both .cs and MC and would never go back. One is clearly superior. For Squeak, .cs would be a big regression!
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
Good explain why do not use .cs Realize don’t think in a collaborative system versus a one man ruling all. On Sun, 22 Jul 2018 at 19:01 Nicolas Cellier <[hidden email]> wrote:
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
So is the outcome of this discussion that UpdateStreamDownloader
should be removed? On 7/23/18, Edgar De Cleene <[hidden email]> wrote: > Good explain why do not use .cs > Realize don’t think in a collaborative system versus a one man ruling all. > > > On Sun, 22 Jul 2018 at 19:01 Nicolas Cellier < > [hidden email]> wrote: > >> 2018-07-22 17:17 GMT+02:00 Edgar De Cleene <[hidden email]>: >> >>> Could send this to Cuis list ? >>> Like what Juan have to said. >>> >>> If you look at >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/CodeManagementInCuis.md >> you will see that package had to be introduced in Cuis for easing >> contributions. >> Why packages are not managed with change set? Because it would not >> scale... >> They are handled by git/github. >> >> Then there is a big ball called Cuis Core which is thus kind of special >> package still managed with change set... >> >> First, I ask you: how many people can integrate the change set in the >> core >> image apart Juan? >> See for example, when by miracle a change set is integrated immediately >> (otherwise it would have to change update number), >> >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdates/3369-Make-SmalltalkEditorMenu-dynamic-HernanWilkinson-2018Jul10-18h51m-HAW.1.cs.st >> Even if not written by Juan, it is integrated by Juan. >> And you see a linear history without branches in the update numbers. But >> pull requests are not necessarily linear. >> It means that Juan so far deploy efforts to sort out the changes and >> integrate them. >> It also fits well his volunty to control Cuis. >> You see that Cuis is an exact example of >> https://en.wikipedia.org/wiki/Benevolent_dictatorship. >> It's not our model in Squeak. >> >> Second, I maintain that it would not scale for us. >> There are 14 contributors in >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors >> and 81 closed pull request in >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls, >> and only a subset of them concerning change sets. >> So probably not many conflicts so far. >> Please compare to how many package versions in Squeak inbox and treated >> inbox. >> >> Third, what if I forked >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates >> and made several changes, some accepted and integrated by Juan, but with >> a >> different update number, some yet not integrated, some refused... >> How am i supposed to merge? That's the manual handling of change sets >> that >> typically is difficult and error prone, and that I don't want to live >> with >> anymore. >> >> Last, since there are packages, why do Cuis Core has to be handled >> specially? >> Because of live updating. We use the image to change the image, so from >> time to time, special actions (scripts) are required for bootstrapping. >> A good example is changing compiler or core features in Morphic. >> This is the main reason for keeping changeset: git does not have anything >> to offer for live update, git is designed for dead code. >> So I guess that rather than inventing own new way to handle live update >> thru git >> (it could mean something as complex as the Pharo bootstrapping efforts), >> Juan preferred to keep the .cs like he always did when the project was >> single-manned. >> This does not make .cs a good choice, just a default choice. >> >> In Squeak we have same problem with live update. >> We have to use the MonticelloConfigurationMap (MCM) for live updating the >> image. >> These live-update mcm are numbered, like the CoreUpdates are numbered in >> Cuis. >> They have to be loaded/merged in sequence because of bootstrap scripts, >> and thus cannot be applied in arbitrary orders which severely limit the >> opened branching model of git... >> >> But a big difference with Cuis is that a new MCM is emitted if and only >> if >> a bootstrap srcipt is necessary, not for every core change! >> And a second enormous difference: these mcm do not contain code. They >> only >> contain reference to package versions. >> This is what enables the whole source code to be managed in a single way: >> Monticello packages. >> This gives possibility to browse every method edition unlike .cs. >> This also give the possibility to merge with local image modifications >> rather than overwrite like in Cuis >> (though there is no guaranty that the bootstrap scripts will work in a >> modified image, like with .cs). >> >> I don't want to discuss more the choices of Juan. They were done in a >> certain context that does not match ours. >> He always refused to integrate MC for not bloating the Cuis image. >> The will to be present on github guided him to this package solution, in >> this context Monticello could be viewed more as an obstacle than a >> solution. >> The live update problem forced him to be conservative with .cs with a >> scope reduced to Core. >> Given the smaller size of core code in Cuis and the benevolent >> dictatorship model, it may last. >> >> I can tell you that I used both .cs and MC and would never go back. One >> is >> clearly superior. >> For Squeak, .cs would be a big regression! >> >> >> >>> >>> On 22 Jul 2018, at 09:49, Nicolas Cellier < >>> [hidden email]> wrote: >>> >>> Hi Edgar, >>> Yes, there are good reasons for not using .cs. >>> .cs do not scale. Or history has to be purely linear, which does not >>> happen in real world. >>> Merging concurrent versions is impractical, or even impossible without a >>> history of branches. >>> I've used .cs for more than ten years in the 90s, and even with a team >>> reduced to 3 persons, it was far from ideal! >>> Some features would take time to implement, and inevitably lead to >>> conflicts. >>> We finally had to put version history in method/class comments >>> (author+timestamp+reason of change). >>> A poor man source code versionning that bloated the source code with >>> orthogonal information... >>> >>> I separated UpdateStream in own package in 2013 for the purpose of >>> removing it, but this is unfinished work... >>> One has to check if there are not unique implementor sends leaking >>> outside the package. >>> >>> 2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene <[hidden email]>: >>> >>>> I wish we have .cs as in old days , but some people like using clumsy >>>> tools. >>>> So if we do not use .cs anymore why have UpdateStreamDownloader and >>>> related >>>> to lo download .cs from server ? >>>> >>>> >>>> Edgar >>>> @morplenauta >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> > |
Re: Cleaning unneeded UpdateStreamDownloader
|
|
On Mon, Jul 23, 2018 at 12:27:05PM +0200, H. Hirzel wrote:
> So is the outcome of this discussion that UpdateStreamDownloader > should be removed? > I would be happy just to see UpdateStreamDownloader get a good class comment that explains what it is, and that clarifies the difference between our current Montecello based update stream and the older change set based stream. An update stream is not a version control system. The update stream that we use today happens to be built on top of Montecello, but if we ever wanted to decouple the update stream from the version control system (for example, if someone wanted to use git for version control), then it might be important to have a simple change set based mechanism that works independent of the version control systems. I can also imagine a scenario in which we would want to provide some kind of "mirror" of Squeak trunk on GitHub in order to make the system more visible and accessible to the world at large. In that case, it might be helpful to have a change set based update stream that follows the real one in Montecello. Dave We do not currently use the UpdateStreamDownloader mechanism, but I think it is import > On 7/23/18, Edgar De Cleene <[hidden email]> wrote: > > Good explain why do not use .cs > > Realize don???t think in a collaborative system versus a one man ruling all. > > > > > > On Sun, 22 Jul 2018 at 19:01 Nicolas Cellier < > > [hidden email]> wrote: > > > >> 2018-07-22 17:17 GMT+02:00 Edgar De Cleene <[hidden email]>: > >> > >>> Could send this to Cuis list ? > >>> Like what Juan have to said. > >>> > >>> If you look at > >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/CodeManagementInCuis.md > >> you will see that package had to be introduced in Cuis for easing > >> contributions. > >> Why packages are not managed with change set? Because it would not > >> scale... > >> They are handled by git/github. > >> > >> Then there is a big ball called Cuis Core which is thus kind of special > >> package still managed with change set... > >> > >> First, I ask you: how many people can integrate the change set in the > >> core > >> image apart Juan? > >> See for example, when by miracle a change set is integrated immediately > >> (otherwise it would have to change update number), > >> > >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdates/3369-Make-SmalltalkEditorMenu-dynamic-HernanWilkinson-2018Jul10-18h51m-HAW.1.cs.st > >> Even if not written by Juan, it is integrated by Juan. > >> And you see a linear history without branches in the update numbers. But > >> pull requests are not necessarily linear. > >> It means that Juan so far deploy efforts to sort out the changes and > >> integrate them. > >> It also fits well his volunty to control Cuis. > >> You see that Cuis is an exact example of > >> https://en.wikipedia.org/wiki/Benevolent_dictatorship. > >> It's not our model in Squeak. > >> > >> Second, I maintain that it would not scale for us. > >> There are 14 contributors in > >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors > >> and 81 closed pull request in > >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls, > >> and only a subset of them concerning change sets. > >> So probably not many conflicts so far. > >> Please compare to how many package versions in Squeak inbox and treated > >> inbox. > >> > >> Third, what if I forked > >> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates > >> and made several changes, some accepted and integrated by Juan, but with > >> a > >> different update number, some yet not integrated, some refused... > >> How am i supposed to merge? That's the manual handling of change sets > >> that > >> typically is difficult and error prone, and that I don't want to live > >> with > >> anymore. > >> > >> Last, since there are packages, why do Cuis Core has to be handled > >> specially? > >> Because of live updating. We use the image to change the image, so from > >> time to time, special actions (scripts) are required for bootstrapping. > >> A good example is changing compiler or core features in Morphic. > >> This is the main reason for keeping changeset: git does not have anything > >> to offer for live update, git is designed for dead code. > >> So I guess that rather than inventing own new way to handle live update > >> thru git > >> (it could mean something as complex as the Pharo bootstrapping efforts), > >> Juan preferred to keep the .cs like he always did when the project was > >> single-manned. > >> This does not make .cs a good choice, just a default choice. > >> > >> In Squeak we have same problem with live update. > >> We have to use the MonticelloConfigurationMap (MCM) for live updating the > >> image. > >> These live-update mcm are numbered, like the CoreUpdates are numbered in > >> Cuis. > >> They have to be loaded/merged in sequence because of bootstrap scripts, > >> and thus cannot be applied in arbitrary orders which severely limit the > >> opened branching model of git... > >> > >> But a big difference with Cuis is that a new MCM is emitted if and only > >> if > >> a bootstrap srcipt is necessary, not for every core change! > >> And a second enormous difference: these mcm do not contain code. They > >> only > >> contain reference to package versions. > >> This is what enables the whole source code to be managed in a single way: > >> Monticello packages. > >> This gives possibility to browse every method edition unlike .cs. > >> This also give the possibility to merge with local image modifications > >> rather than overwrite like in Cuis > >> (though there is no guaranty that the bootstrap scripts will work in a > >> modified image, like with .cs). > >> > >> I don't want to discuss more the choices of Juan. They were done in a > >> certain context that does not match ours. > >> He always refused to integrate MC for not bloating the Cuis image. > >> The will to be present on github guided him to this package solution, in > >> this context Monticello could be viewed more as an obstacle than a > >> solution. > >> The live update problem forced him to be conservative with .cs with a > >> scope reduced to Core. > >> Given the smaller size of core code in Cuis and the benevolent > >> dictatorship model, it may last. > >> > >> I can tell you that I used both .cs and MC and would never go back. One > >> is > >> clearly superior. > >> For Squeak, .cs would be a big regression! > >> > >> > >> > >>> > >>> On 22 Jul 2018, at 09:49, Nicolas Cellier < > >>> [hidden email]> wrote: > >>> > >>> Hi Edgar, > >>> Yes, there are good reasons for not using .cs. > >>> .cs do not scale. Or history has to be purely linear, which does not > >>> happen in real world. > >>> Merging concurrent versions is impractical, or even impossible without a > >>> history of branches. > >>> I've used .cs for more than ten years in the 90s, and even with a team > >>> reduced to 3 persons, it was far from ideal! > >>> Some features would take time to implement, and inevitably lead to > >>> conflicts. > >>> We finally had to put version history in method/class comments > >>> (author+timestamp+reason of change). > >>> A poor man source code versionning that bloated the source code with > >>> orthogonal information... > >>> > >>> I separated UpdateStream in own package in 2013 for the purpose of > >>> removing it, but this is unfinished work... > >>> One has to check if there are not unique implementor sends leaking > >>> outside the package. > >>> > >>> 2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene <[hidden email]>: > >>> > >>>> I wish we have .cs as in old days , but some people like using clumsy > >>>> tools. > >>>> So if we do not use .cs anymore why have UpdateStreamDownloader and > >>>> related > >>>> to lo download .cs from server ? > >>>> > >>>> > >>>> Edgar > >>>> @morplenauta > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >>> > > > |
Re: Cleaning unneeded UpdateStreamDownloader
|
|
One idea covering both
The trunk , 5.2 and beyond is the master Each person start forking and have his own .image The changes each person have was saved somewhere And the number is Edgar 1.cs David 1.cs Nicolas 1.cs This way, each squeaker become his ruler And any could have changes of others. Could have some stats of owner.nnnn.cs And kind of competition of popular ones.
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
Hi David, Edgar,
2018-07-23 16:00 GMT+02:00 Edgar De Cleene <[hidden email]>:
This is only a solution for forking, but won't work for merging...
By principle of encapsulation, a comment should not tell about the implementation of another class. So if we need a comparison, it should lie somewhere else.
But if the update stream does not refer to the VCS, then we get an image out of sync with the VCS which is an undesirable property. If we would switch to git or whatever, we should arrange to keep the link between image and git repository.
If github is not the source but only a mirror, then we loose the efficiency of github interface. And here again a change set is a bad solution for tracking changes, it does not fit git model of code: a change to a single method would be split across many different .cs like is the case for Cuis now. There is no way for git to figure out that different files represent a different edition of a single method. With .cs, it's like you want to impose the internal format of VCS (diff with a method granularity). Forget about .cs, the mourning period is over ;)
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
Why ?
Each become his master I could take your Nicolas.32.cs and David.44.cs as long was useful. Become Edgar.14.cs and Edgar.15.cs. I talking about forks of trunk private. The merge occurred on trunk when/if someone send to inbox Sent from my iPhone
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
2018-07-23 17:37 GMT+02:00 Edgar De Cleene <[hidden email]>:
Sure, you can copy and rename files. Then next time you want to merge, you just have to perform O(N^2) diff...
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
On Mon, Jul 23, 2018 at 8:18 PM Nicolas Cellier <[hidden email]> wrote:
+1 Best, Karl
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
In reply to this post by Nicolas Cellier
2018-07-23 20:18 GMT+02:00 Nicolas Cellier <[hidden email]>:
This deserves more explanations: O(N^2) is if you want to use VCS to merge. That's because the source code of each method can be in each .cs... It's just impossible. If you don't use VCS for storing the .cs, then you get the problem of not having the history of the method. You diff from your image, find a difference, but you don't know if this is a fork from an older common ancestor... And since the model you describe is just cherry picking, then you have examine if you reject or accept it, and redo this each time you want to merge... And you also lost the ordering of changes which was the only interesting part of .cs. How could this scale? |
Re: Cleaning unneeded UpdateStreamDownloader
|
|
OK. Forget .cs
How git could help us ? Which master repo and several cloned (how much people wish his own Squeak ? ) I open to new things and realize is 2018 now not 1998 when Squeak was unique and cool. In a ideal world. We have a kernel as Pharo bootstrap try to made (or maybe they have ). An intermediate like Cuis An all purpose Squeak And a roadmap how to go from kernel to SuperSqueak
|
Re: Cleaning unneeded UpdateStreamDownloader
|
|
In reply to this post by Nicolas Cellier
On Mon, Jul 23, 2018 at 05:08:57PM +0200, Nicolas Cellier wrote:
> > On 23 Jul 2018, at 09:51, David T. Lewis <[hidden email]> wrote: > > > > I would be happy just to see UpdateStreamDownloader get a good class comment > > that explains what it is, and that clarifies the difference between our current > > Montecello based update stream and the older change set based stream. > > By principle of encapsulation, a comment should not tell about the > implementation of another class. > So if we need a comparison, it should lie somewhere else. Fair enough. But I would still be happy if UpdateStreamDownloader could have a good class comment. Oops, I fear that I have just given myself an assignment ;-) > > An update stream is not a version control system. The update stream that we > > use today happens to be built on top of Montecello, but if we ever wanted > > to decouple the update stream from the version control system (for example, > > if someone wanted to use git for version control), then it might be > > important > > to have a simple change set based mechanism that works independent of the > > version control systems. > > But if the update stream does not refer to the VCS, then we get an image > out of sync with the VCS which is an undesirable property. > If we would switch to git or whatever, we should arrange to keep the link > between image and git repository. > Fully agree. I was thinking of a scenario in which the update stream is generated by, and is not a replacement for, the VCS. I think that this has been done in the past with our MC based update stream. Maybe Andreas did it? Or Edgar? Sorry I do not remember. For any VCS, including Monticello, if it is possible to implement an update stream with that VCS, then it must also be possible for an image that is being updated to keep track of its update history in the form of a list of change sets. And it should be possible for that list of change sets to be re-applied to another image to achieve that same end result. Dave |
Re: Cleaning unneeded UpdateStreamDownloader
|
|
I proud to work with Andreas once.
Keep the mail exchange as treasure. I have now in a Monticello modify. Made a numbered .cs from each trunk update. A way of keep my version and not the trunk one for all packages except Monticello. And off course my .sar inside Monticello . I skip Monticello update for this reason You could see a experimental list here: http://squeakros.org/updates/ Edgar @morplenauta On 23/07/2018, 20:30, "David T. Lewis" <[hidden email]> wrote: > Fully agree. I was thinking of a scenario in which the update stream > is generated by, and is not a replacement for, the VCS. I think that this has > been done in the past with our MC based update stream. Maybe Andreas did it? > Or Edgar? Sorry I do not remember. For any VCS, including Monticello, if it > is possible to implement an update stream with that VCS, then it must also be > possible for an image that is being updated to keep track of its update > history in the form of a list of change sets. And it should be possible for > that list of change sets to be re-applied to another image to achieve that > same end result. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |