- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 04/02/2016 13:21, Stephan Eggermont a Ã©crit : > On 04-02-16 13:09, Henrik Johansen wrote: >> Also, the ancestry of all packages in Pharo Core was truncated a few >> years back, which also screwed up merging*. >> I don't think anyone looked into why it happened. > > My experiment in creating one file for a whole project would be a > suitable starting point for fixing that. Yes. I think we need a MC version history recreation / garbage collect. Something that removes dead versions and compress history to make MC merge work correctly. (unless you move to git on metadataless mode and back...). Thierry > Stephan > > > >

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 04/02/2016 14:32, Nicolas Cellier a Ã©crit : > > > 2016-02-04 10:26 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > Le 04/02/2016 10:04, Nicolas Cellier a Ã©crit : > > [... cut ] > Or is it the fact that some .mcz could be missing? > Consider this is a feature, MC tools are robust to missing .mcz > (it's > just that you'll have to redo the merge if you lost a common > ancestor). > > > What? You really consider that a feature? > > > Sure. Consider it's somehow like a git squash... I consider history rewriting a very bad idea... But, if we are at that, I just consider that the removed versions do not exist anymore, and are not visible (should not be visible) in the history, and that you have perfectly predictable correct behavior, not can't do this because package version X is missing. > Or is it the fact that some repository might contain only a slice of > history? > This is another feature... You can view all the versions in a > collection > of repositories without needing to replicate. > > > Understandable in theory. Unworkable over time and change > (repositories disappear and die, and this stops working) > > > But that's the same with over vcs, repositories disappear and die > (google code etc...). > Knowing that you can take usual defensive decisions (replicate what you > depend on and not trust too much). I mean that VCS recreate a working history and log when you are in such a situation. MC just let you believe you have all and fail when you attain the holes. > You can replicate if you want but it's not mandatory and completely > orthogonal. > So yes, this information - the list or repositories you want to > consider > - has to be stored separetely and this can sound quite > unconventional. > But IMO, it's an important feature: it gives much resilience for > a very > low investment. > And that also mean that you can hardly break things (have > unconsistent > history). > > > Maybe when you say broken, you mean not 100% git compatible? > > > No, what I say is true mcz inconsistent history (missing versions > making merges very unreliable, basically). > > Loosing a .mcz on which you branched is a bit more than unfortunate, > it's a lack of understanding of the tool... Not true. MC let you believe it will cope and it doesn't, which is not exactly the same. > I say give git squash and rebase to unexperimented/uninformed people and > that will be far worse. Agreed. > I describe a while ago a case where, thanks to mcz features, I > couldn't merge a small change done to Roassal without generating a > ton of conflicts. I moved the three needed mcz(s) to git (the change > ancestor, the change, and the current head), did git merge and had > no conflicts. > > > Do you mean that git succeeded in merging text because different lines > were changed in different branches? No, in fact it was a clean merge because the changes in the branch were on methods untouched in the main... git recreated a proper history and could merge, whereas MC with the mcz history generated conflicts without any reason. > I agree that it can solve some basic refactoring (renaming...) > But couldn't it lead to syntactically incorrect code? Traditional > Smalltalk IDE are not well equipped for handling this... Yes, this is partly why we're looking at more integration (merge tool) and we may have to do more (a smalltalk syntax checker before commit could be nice; CI does wonders on that). > The biggest grief I have with MC is more about package delimitation, > when code is moved from 1 package to another. > For example, this effectively prevent merging very distant branches like > Squeak and Pharo > (but we do not want to merge, just cherry pick in fact). Ok. Merge with multiple packages, right? > > If you consider those features, then I disagree. > > I'd really like to improve MC and get a better integration. > Considering those as features just make me think that Eliot may well > be right in believing we'll end up throwing away MC completely. > > > As long as it's as efficient, and well integrated in IDE, but again, > it's against the small steps approach... > For me small steps would be to replace mcz name indexing by UUID > indexing and just keep name as a faÃ§ade. I'd agree with that, as long as you don't ask too much of compatibilities with some of MC features (:)). > I'm quite sure most work is at server side. How difficult would it > really be? Why server side? I don't think it is. > No one will consider this maybe, because it's against the stream ;) No, in fact we're on it. Git integration is showing us where MC is weak, and we're trying to fit it with MC. > Coping with MC idiosyncrasies is hard as it is, and at least a > complete replacement is being considered for Pharo. In the meantime, > Cuis has completely given up managing packages in Smalltalk: all is > done in git, externally. > > > But Cuis vcs come from dinosaure era (change sets) so anything else is > already a progress. > Doing that in Squeak would feel like a loss of > tool/functionality/integration. I agree. > Why didn't Pharo took the same path? Than Cuis? Thierry > Thierry > > 2016-02-04 7:53 GMT+01:00 Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>>: > > Le 03/02/2016 23:58, Dale Henrichs a Ã©crit : > > > > On 02/03/2016 02:34 PM, Thierry Goubier wrote: > > Le 03/02/2016 22:51, Eliot Miranda a Ã©crit : > > > > On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier > <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com> > > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>>> wrote: > > Hi Eliot, > > Le 02/02/2016 21:54, Eliot Miranda a Ã©crit : > .... > > > No it's /not/ the end of the story. The > essential part of the > story is > how Monticello remains compatible and > interoperable between > dialects. I > haven't seen you account for how you > maintain that > compatibility. As > far as I can tell, you propose > replacing the > Monticello metadata > with > that from git. How do I, as a Squeak > user with > Monticello, ever > get to > look at your package again? As I > understand > it, moving the > metadata > from Monticello commit time to git > means that > the metadata is > in a > format that git determines, not > Monticello. > > > Yes. See below why. > > So I don't understand how on the one > hand you > can say "The > Monticello > metadata in a git repository is > redundant and > leads to > unnecessary > commit conflicts -- end of story > ....", which > implies you > want to > eliminate the Monticello metadata, and > on the > other hand you say > you're > keeping the Monticello metadata. I'm > hopelessly confused. How > does the > Monticello metadata get reconstituted > if it's > been thrown away? > > What happens to the metadata in the > following > workflow? > > load package P from Monticello > repository R > into an image > change P, commit via git to local git > repository G > load P from G into an image > store P to R via Monticello > > > It's not a scenario I've specifically > worked on, > but all the tech is > implemented / implementable to do that > perfectly. > > The only thing that is problematic there > is that > the only safe > history is the one generated from git... > there are > so many MC > packages with broken history that, on mcz > packages, > you have to > admit that it's not safe to base things on > their > history. > > > I'm sorry but I don't accept that. In the > Squeak trunk > we have history > in our mczs that is correct. Certainly in > VMMaker.oscog > I have history > that goes back a long time. If bugs have > broken history > then efforts > should be made to repair that history. But you > can't > just write off > Monticello history like that. > > > I don't. You presuppose. > > I write tools that work with Monticello > repositories, not > just yours. > I have to do with what is given to me. On a general > level, > as a mcz > user, I'll just have to consider that you are as > susceptible > to be > trusted as with any other mcz producer. This means > not much... > > > ... And this is the reason why I am inclined to favor > option 3, > which > records the package version history as it existed at > the point > it was > copied into a git repo. When copied back out from the > git universe, > create a version history that starts with the original > version > history > and generates a history of the package in git .... > > > Which is not very difficult to do given how GitFileTree is > implemented. And I agree this may well be the way to go. > But ... > > Correct or not, the Monticello version history should be > preserved .... > > > I wonder about that. The property of the Monticello version > history > is that it has value when you can access the versions > listed in it. > If you mix repositories like that, unless you maintain a > link to the > previous mcz repository, pre-git versions can't be > accessed. So, > most of the time, what we do with a project moved under git > is to > clone the previous repository, not take just the current head. > > (you'll notice, by the way, that vcs usually work that way when > moving from, say, CVS to git - you move the entire > repository, not > just the latest version). > > In short, the question would really be: > 1- should we invest into making that integration of past > history a > selling point (but I foresee issues down the road; I've only > described one so far, and I have seen others) > or > 2- into making a better "clone" of a package history, > timestamps and > everything when moving a complete repository to git? > > Honestly, I'd consider 1- to be the easiest to implement. > 2- there > is already some code floating around. > > Thierry > > > > >

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Nicolas Cellier

2016-02-04 10:26 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 04/02/2016 10:04, Nicolas Cellier a Ã©crit : > >> I don't understand broken history either. >> Yes there can be .mcz name clashes but UUID history is stored together >> in metadata no? >> > > Yes. > > If some tool only trust .mcz name without checking UUID, consider it's a >> bug, and let's correct it (there is some in Monticello Configuration Map) >> > > Gofer. In fact, most of Monticello never checks the UUID, only > dependencies do, but this looks like a deprecated feature given how often > it is used. > > Or is it the fact that some .mcz could be missing? >> Consider this is a feature, MC tools are robust to missing .mcz (it's >> just that you'll have to redo the merge if you lost a common ancestor). >> > > What? You really consider that a feature? > Sure. Consider it's somehow like a git squash... > > Or is it the fact that some repository might contain only a slice of >> history? >> This is another feature... You can view all the versions in a collection >> of repositories without needing to replicate. >> > > Understandable in theory. Unworkable over time and change (repositories > disappear and die, and this stops working) > But that's the same with over vcs, repositories disappear and die (google code etc...). Knowing that you can take usual defensive decisions (replicate what you depend on and not trust too much). > > You can replicate if you want but it's not mandatory and completely >> orthogonal. >> So yes, this information - the list or repositories you want to consider >> - has to be stored separetely and this can sound quite unconventional. >> But IMO, it's an important feature: it gives much resilience for a very >> low investment. >> And that also mean that you can hardly break things (have unconsistent >> history). >> > > Maybe when you say broken, you mean not 100% git compatible? >> > > No, what I say is true mcz inconsistent history (missing versions making > merges very unreliable, basically). > > Loosing a .mcz on which you branched is a bit more than unfortunate, it's a lack of understanding of the tool... I say give git squash and rebase to unexperimented/uninformed people and that will be far worse. > I describe a while ago a case where, thanks to mcz features, I couldn't > merge a small change done to Roassal without generating a ton of conflicts. > I moved the three needed mcz(s) to git (the change ancestor, the change, > and the current head), did git merge and had no conflicts. > > Do you mean that git succeeded in merging text because different lines were changed in different branches? I agree that it can solve some basic refactoring (renaming...) But couldn't it lead to syntactically incorrect code? Traditional Smalltalk IDE are not well equipped for handling this... The biggest grief I have with MC is more about package delimitation, when code is moved from 1 package to another. For example, this effectively prevent merging very distant branches like Squeak and Pharo (but we do not want to merge, just cherry pick in fact). > If you consider those features, then I disagree. > > I'd really like to improve MC and get a better integration. Considering > those as features just make me think that Eliot may well be right in > believing we'll end up throwing away MC completely. > > As long as it's as efficient, and well integrated in IDE, but again, it's against the small steps approach... For me small steps would be to replace mcz name indexing by UUID indexing and just keep name as a faÃ§ade. I'm quite sure most work is at server side. How difficult would it really be? No one will consider this maybe, because it's against the stream ;) > Coping with MC idiosyncrasies is hard as it is, and at least a complete > replacement is being considered for Pharo. In the meantime, Cuis has > completely given up managing packages in Smalltalk: all is done in git, > externally. > > But Cuis vcs come from dinosaure era (change sets) so anything else is already a progress. Doing that in Squeak would feel like a loss of tool/functionality/integration. Why didn't Pharo took the same path? Thierry > > 2016-02-04 7:53 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>>: >> >> Le 03/02/2016 23:58, Dale Henrichs a Ã©crit : >> >> >> >> On 02/03/2016 02:34 PM, Thierry Goubier wrote: >> >> Le 03/02/2016 22:51, Eliot Miranda a Ã©crit : >> >> >> >> On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.com >> >> <mailto:thierry.goubier@gmail.com>>> wrote: >> >> Hi Eliot, >> >> Le 02/02/2016 21:54, Eliot Miranda a Ã©crit : >> .... >> >> >> No it's /not/ the end of the story. The >> essential part of the >> story is >> how Monticello remains compatible and >> interoperable between >> dialects. I >> haven't seen you account for how you maintain >> that >> compatibility. As >> far as I can tell, you propose replacing the >> Monticello metadata >> with >> that from git. How do I, as a Squeak user with >> Monticello, ever >> get to >> look at your package again? As I understand >> it, moving the >> metadata >> from Monticello commit time to git means that >> the metadata is >> in a >> format that git determines, not Monticello. >> >> >> Yes. See below why. >> >> So I don't understand how on the one hand you >> can say "The >> Monticello >> metadata in a git repository is redundant and >> leads to >> unnecessary >> commit conflicts -- end of story ....", which >> implies you >> want to >> eliminate the Monticello metadata, and on the >> other hand you say >> you're >> keeping the Monticello metadata. I'm >> hopelessly confused. How >> does the >> Monticello metadata get reconstituted if it's >> been thrown away? >> >> What happens to the metadata in the following >> workflow? >> >> load package P from Monticello repository R >> into an image >> change P, commit via git to local git repository >> G >> load P from G into an image >> store P to R via Monticello >> >> >> It's not a scenario I've specifically worked on, >> but all the tech is >> implemented / implementable to do that perfectly. >> >> The only thing that is problematic there is that >> the only safe >> history is the one generated from git... there are >> so many MC >> packages with broken history that, on mcz packages, >> you have to >> admit that it's not safe to base things on their >> history. >> >> >> I'm sorry but I don't accept that. In the Squeak trunk >> we have history >> in our mczs that is correct. Certainly in VMMaker.oscog >> I have history >> that goes back a long time. If bugs have broken history >> then efforts >> should be made to repair that history. But you can't >> just write off >> Monticello history like that. >> >> >> I don't. You presuppose. >> >> I write tools that work with Monticello repositories, not >> just yours. >> I have to do with what is given to me. On a general level, >> as a mcz >> user, I'll just have to consider that you are as susceptible >> to be >> trusted as with any other mcz producer. This means not much... >> >> >> ... And this is the reason why I am inclined to favor option 3, >> which >> records the package version history as it existed at the point >> it was >> copied into a git repo. When copied back out from the git >> universe, >> create a version history that starts with the original version >> history >> and generates a history of the package in git .... >> >> >> Which is not very difficult to do given how GitFileTree is >> implemented. And I agree this may well be the way to go. But ... >> >> Correct or not, the Monticello version history should be >> preserved .... >> >> >> I wonder about that. The property of the Monticello version history >> is that it has value when you can access the versions listed in it. >> If you mix repositories like that, unless you maintain a link to the >> previous mcz repository, pre-git versions can't be accessed. So, >> most of the time, what we do with a project moved under git is to >> clone the previous repository, not take just the current head. >> >> (you'll notice, by the way, that vcs usually work that way when >> moving from, say, CVS to git - you move the entire repository, not >> just the latest version). >> >> In short, the question would really be: >> 1- should we invest into making that integration of past history a >> selling point (but I foresee issues down the road; I've only >> described one so far, and I have seen others) >> or >> 2- into making a better "clone" of a package history, timestamps and >> everything when moving a complete repository to git? >> >> Honestly, I'd consider 1- to be the easiest to implement. 2- there >> is already some code floating around. >> >> Thierry >> >> >> > >

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 04/02/2016 13:09, Henrik Johansen a Ã©crit : > > Also, the ancestry of all packages in Pharo Core was truncated a few > years back, which also screwed up merging*. I don't think anyone > looked into why it happened. It was done on purpose for the Pharo 3 release to reduce the amount of memory used by the MCVersionInfo instances. For Pharo 4, a lazy loading of the MCVersionInfo was implemented instead. We should have recreated the lost history then, but it seemed not to have been important. Thierry

Feb. 4, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Denis Kudriashov

2016-02-04 11:29 GMT+01:00 Guille Polito <guillermopolito(a)gmail.com>: > And yes, linux VM's are not shipped with the UUID plugin... at least not > since 2014/2013... > > Also, I believe the plugin is not compiled as internal since it is not > listed in > > Smalltalk vm listBuiltinModules. > Smalltalk vm listLoadedModules. > It looks like Monticello ignore UUID failure and just use value from ancestor. Could you investigate it? It can be fixed in that case.

Feb. 4, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Henrik Johansen

> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 04 Feb 2016, at 11:55, Guille Polito <guillermopolito(a)gmail.com> wrote: >> >> Good news, so far, installing NeoUUID and replacing UUID class >> new by: >> >> UUID class >> new >> ^NeoUUIDGenerator new next >> >> seems to work. At it looks that I can trust again my commits. >> >> Thanks Sven :) > > OK. > > Now, the idea is that one instance of the generator is kept around, this is way more efficient, but also more correct, as the random generator should not be created anew each time. > >> Now I do not know how this should be solved, nor if this is reproducible in a machine other than mine... > > I seriously doubt the plugin is better (more random, more unique) then anything that we can do in Pharo itself. I like Pharo code way better, because we all see what it does. > > Anyone else with an opinion ? More random for certain, at least much faster than we could do in Pharo, is certainly possible with a plugin. More unique... well, depends on whether you can trust the source RNG (seeded from data with enough entropy, period much greater than 2^128, etc). A single next:into:startingAt: primitive filling random data (obtained using platform primitives and/or RDRAND/RDSEED) into a buffer would be much nicer/more flexible than the current UUID primitive though. (the linked UUID library is basically just a thin wrapper around the platform primitives, plus setting variant/version bits in the returned UUID bytes) As a stopgap, one could instead use another, more general primitive (but with a less flexible api than next:into:startingAt:) in an otherwise unrelated plugin (but that is built internal to all Cog VM's, at least): rand: aBuffer <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> ^self primitiveFail (which, iirc, resolves to the same platform primitives as UUID lib) Also, the meaning of different UUID versions are well defined in the RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... disingenuous. Cheers, Henry

Feb. 4, 2016

Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

by Marcus Denker

> On 04 Feb 2016, at 12:21, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > We are on âjust bugfixesâ since some time nowâ¦ I delayed the announcement because Epicea still needs to enter and we didnât manage to include it yet. > But wellâ¦ with the exception of Epicea, no new features will be included un Pharo 5â¦ just bugfixes (and we have a lot of bugfixes incomingâ¦ this release will be hard :( ) Indeedâ¦ after taking a small break I now started with February again to push for small fixesâ¦ I will try to invest a couple of Pomodoros each day, there is a lot to be done. Marcus

Feb. 4, 2016

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Aliaksei Syrel

Hi Christophe Thanks for the answer :) What you proposed indeed fixes the issue. it would be great to have it! Because Bloc Universe knows which space is currently running I can detect which UI manager is needed. So I just hacked "new" in bloc ui manager: new > ^ super new space: (%ask universe for correct space%) Ugly but works, until refactoring of SessionManager is done. Please continue your great job :) Cheers, Alex

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Ben Coman

On Thu, Feb 4, 2016 at 5:26 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > In the meantime, Cuis has completely given up managing packages in > Smalltalk: all is done in git externally. Thats very interesting to hear - since 2012 even... http://www.jvuletich.org/Cuis/CuisAndGitHub.html and interesting to compare different approaches... * https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentat… * https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentat… cheers -ben

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Stephan Eggermont

On 04-02-16 13:09, Henrik Johansen wrote: > Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*. > I don't think anyone looked into why it happened. My experiment in creating one file for a whole project would be a suitable starting point for fixing that. Stephan

Feb. 4, 2016