- Pharo-users - lists.pharo.org

Re: [Pharo-users] About balkanisation

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 07/11/16 02:50, Esteban Lorenzano wrote: [...] > What I mean is that we can help any transition, but at the end there is no way of having a ânice, coexistingâ ecosystem: we will have one OR the other, or something that does not works at all, but we will not have seamlessly one AND the other (which does not means people using monticello will be forced to use git tools or vice-versa, just that you will need to chose oneâ¦ right now many (many for real) of our problems come from the attempt of keeping our git support behaving as regular monticelloâ¦ and that way of doing has a limit. A limit I think we already passed. [...] That's clarifying. Thanks a lot Esteban. I will try to keep myself on the Monticello boat a little longer, until the filetree and Iceberg stuff become clearer to me and I can see how to use them in a way that doesn't interrupt the workflow I have now (as happens with Monticello and Fossil). > Anyway, if you can list what you think we will need for the transition, I will be very glad to see what we can do :) Yes, Dale, your experience would be very appreciated. Cheers, Offray

Nov. 7, 2016

Iceberg/GitFileTree (was Re: about balkanisation)

by Thierry Goubier

Nicolas, I changed the subject, it seems appropriate. 2016-11-07 16:56 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > > 2016-11-07 16:26 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >>> The problem I found is that in order to recreate sequential numbers, you >>> have to load all commits into the image. >>> >> >> Why? GitFileTree doesn't need to do that at all! Well, you know the code: >> it just ask git log to rebuild the parent / child relations for a package >> directory, and that is all... Then, like a mcz, the package isn't loaded >> into the image unless you select it in the GUI. So why did you need to load >> all the commits? >> >> Well, at the beginning, I was trying to read all the filetree metadata >> stored in the repository to build the versions as if it was mczs... and >> that was a really bad idea (slow parser for version files, hundred of files >> to scan, many files were even unreadable/broken by conflicts leftovers in >> the filetree repository). >> > > Yes you are right, I expressed myself badly. You don't have to load "the > commits". > But, you still have to create an MCVersionInfo for each version of the > package in the repository. > What you're saying is that you are using the same trick as GitFileTree does, but you have performance issues, which means... we're not talking about exactly the same thing :) (and trust me, my development machine is on the "very" slow end for the Pharo community, so I'm sensitive to performance issues). > > In fact... you can create them, it will not kill you, but I think that > this structure is not so useful, because it is always faster to use > log/revwalk to ask about the relationship between two versions/commits. > Agreed. But you will allways create some sort of MCVersionInfo / MCAncestry to be able to represent the start of this inside your system... Subtypes of MCVersionInfo do work fine there. Just have a nice, correct API call that allow you to compare two versions. (Little trick used in GitFileTree: all ancestry based on a specific commitID is shared among all the versions with it as an ancestor, in memory). Weak version info will take care of cleaning the unneeded stuff anyway. > > Moreover, we do not want to think about packages too much, we prefer to > think in terms of a whole project, so the most interesting concept for us > is the commit and not the version. Therefore, when I build a history > (sometimes I do) I create a graph of commits and not a graph of versions. > As long as you don't track commits for which the package has no version, then that seems perfectly fine. > > Finally, this leads to that, even in the case you want to load a specific > version of a specific pacakge (which is not the normal case for Iceberg), > you would specify a commitish (+ a package name) and not a version name. > I never specify a commitish, I use the GUI or Metacello (and since I'm using baselines, Metacello doesn't uses version numbers except to compare with what is inside the image). GitFileTree only uses commitish to load a version... it just happens to be able to also convert version numbers to a commitish if it is presented with a version number. The attention to version numbering is a thing of people using too much ConfigurationOf, and those people are living in the past. Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Nicolas Passerini

2016-11-07 16:26 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> The problem I found is that in order to recreate sequential numbers, you >> have to load all commits into the image. >> > > Why? GitFileTree doesn't need to do that at all! Well, you know the code: > it just ask git log to rebuild the parent / child relations for a package > directory, and that is all... Then, like a mcz, the package isn't loaded > into the image unless you select it in the GUI. So why did you need to load > all the commits? > > Well, at the beginning, I was trying to read all the filetree metadata > stored in the repository to build the versions as if it was mczs... and > that was a really bad idea (slow parser for version files, hundred of files > to scan, many files were even unreadable/broken by conflicts leftovers in > the filetree repository). > Yes you are right, I expressed myself badly. You don't have to load "the commits". But, you still have to create an MCVersionInfo for each version of the package in the repository. In fact... you can create them, it will not kill you, but I think that this structure is not so useful, because it is always faster to use log/revwalk to ask about the relationship between two versions/commits. Moreover, we do not want to think about packages too much, we prefer to think in terms of a whole project, so the most interesting concept for us is the commit and not the version. Therefore, when I build a history (sometimes I do) I create a graph of commits and not a graph of versions. Finally, this leads to that, even in the case you want to load a specific version of a specific pacakge (which is not the normal case for Iceberg), you would specify a commitish (+ a package name) and not a version name.

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

2016-11-07 16:13 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > > I started creating version names using the unix date (the number of > seconds since 1970), which allows me to provide version numbers without > complex calculations and without breaking Monticello. > > Numbers are not nice but we do not use them any way, it is just to comply > with Monticello requirements. > There is a human effect to them (I like to see the numbers increasing as I add new versions, of course!) but, well, since Dale said working with .1 would work, so it is :) Git short commit ID are only convenient for long-time git experts. > >> >>> On one side, trying to re-create monticello sequential file numbers in >>> git is simply not possible, at least in a reliable way. On the other side, >>> loading the graph of package versions and dependencies is really slow for >>> big repositories (such as pharo-core), once we removed that requirement >>> Iceberg got like 100x faster. >>> >> >> Yes, this is performance sensitive code. I spent a significant amount of >> time trying to optimize the smalltalk part of that in gitfiletree a few >> years ago... before I was shown that it could only scale to ~ 1000 commits >> (with a repository that had more than 8000 different versions for a >> package). >> >> Delegating everything to `git log` solved the issue. No code duplication! >> >> Overall, this is something that has worried me since the beginning of >> libgit. Libgit is low level and pushes some of the processing into Pharo, >> which is not the best tool to do high-speed processing of tree structures. >> And then, instead of designing the best solution to our problem, you end up >> trying to get the best design that doesn't hit a performance issue... >> > > I am using git log extensively, turns out to be a very powerful tool. > Libgit provides a very similar tool called revwalk ( > https://libgit2.github.com/libgit2/#HEAD/group/revwalk) So in each case > Pharo does not have to do those performance sensitive computing. > Yes! Problem solved. > > The problem I found is that in order to recreate sequential numbers, you > have to load all commits into the image. > Why? GitFileTree doesn't need to do that at all! Well, you know the code: it just ask git log to rebuild the parent / child relations for a package directory, and that is all... Then, like a mcz, the package isn't loaded into the image unless you select it in the GUI. So why did you need to load all the commits? Well, at the beginning, I was trying to read all the filetree metadata stored in the repository to build the versions as if it was mczs... and that was a really bad idea (slow parser for version files, hundred of files to scan, many files were even unreadable/broken by conflicts leftovers in the filetree repository). Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Nicolas Passerini

2016-11-07 15:59 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > 2016-11-07 15:42 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > >> >> 2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> Thierry, If I'm not mistaken, Esteban is referring to the fact that in >>>> FileTree we are still using Monticello to do the load of the packages and >>>> even when we are running metadataless, we end creating fake meta data to >>>> simulate an mcz ... you and I have had conversations about ways to >>>> eliminate this "requirement" because it is meaningless in a git context ... >>>> >>> >>> Yes, this I understood. I do believe that what I suggested at one point >>> (have the ability to compare versions with an 'isAncestorOf') would be very >>> nice for that transition (work in mcz as well as on git with/without >>> metadata). >>> >> >> I would like to listen to your ideas about this topic, but I am not sure >> it is possible to achieve that compatibility. In fact we tried to do it for >> Iceberg and at some point we decided to abort it. >> > > I have an idea where such comparisons are done. I'd simply start by > changing version numbers to the short commit ID, and see where it breaks ... > I started creating version names using the unix date (the number of seconds since 1970), which allows me to provide version numbers without complex calculations and without breaking Monticello. Numbers are not nice but we do not use them any way, it is just to comply with Monticello requirements. > >> On one side, trying to re-create monticello sequential file numbers in >> git is simply not possible, at least in a reliable way. On the other side, >> loading the graph of package versions and dependencies is really slow for >> big repositories (such as pharo-core), once we removed that requirement >> Iceberg got like 100x faster. >> > > Yes, this is performance sensitive code. I spent a significant amount of > time trying to optimize the smalltalk part of that in gitfiletree a few > years ago... before I was shown that it could only scale to ~ 1000 commits > (with a repository that had more than 8000 different versions for a > package). > > Delegating everything to `git log` solved the issue. No code duplication! > > Overall, this is something that has worried me since the beginning of > libgit. Libgit is low level and pushes some of the processing into Pharo, > which is not the best tool to do high-speed processing of tree structures. > And then, instead of designing the best solution to our problem, you end up > trying to get the best design that doesn't hit a performance issue... > I am using git log extensively, turns out to be a very powerful tool. Libgit provides a very similar tool called revwalk ( https://libgit2.github.com/libgit2/#HEAD/group/revwalk) So in each case Pharo does not have to do those performance sensitive computing. The problem I found is that in order to recreate sequential numbers, you have to load all commits into the image.

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

2016-11-07 15:42 GMT+01:00 Nicolas Passerini <npasserini(a)gmail.com>: > > 2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Thierry, If I'm not mistaken, Esteban is referring to the fact that in >>> FileTree we are still using Monticello to do the load of the packages and >>> even when we are running metadataless, we end creating fake meta data to >>> simulate an mcz ... you and I have had conversations about ways to >>> eliminate this "requirement" because it is meaningless in a git context ... >>> >> >> Yes, this I understood. I do believe that what I suggested at one point >> (have the ability to compare versions with an 'isAncestorOf') would be very >> nice for that transition (work in mcz as well as on git with/without >> metadata). >> > > I would like to listen to your ideas about this topic, but I am not sure > it is possible to achieve that compatibility. In fact we tried to do it for > Iceberg and at some point we decided to abort it. > I have an idea where such comparisons are done. I'd simply start by changing version numbers to the short commit ID, and see where it breaks ... > On one side, trying to re-create monticello sequential file numbers in git > is simply not possible, at least in a reliable way. On the other side, > loading the graph of package versions and dependencies is really slow for > big repositories (such as pharo-core), once we removed that requirement > Iceberg got like 100x faster. > Yes, this is performance sensitive code. I spent a significant amount of time trying to optimize the smalltalk part of that in gitfiletree a few years ago... before I was shown that it could only scale to ~ 1000 commits (with a repository that had more than 8000 different versions for a package). Delegating everything to `git log` solved the issue. No code duplication! Overall, this is something that has worried me since the beginning of libgit. Libgit is low level and pushes some of the processing into Pharo, which is not the best tool to do high-speed processing of tree structures. And then, instead of designing the best solution to our problem, you end up trying to get the best design that doesn't hit a performance issue... Thierry

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Nicolas Passerini

2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Thierry, If I'm not mistaken, Esteban is referring to the fact that in >> FileTree we are still using Monticello to do the load of the packages and >> even when we are running metadataless, we end creating fake meta data to >> simulate an mcz ... you and I have had conversations about ways to >> eliminate this "requirement" because it is meaningless in a git context ... >> > > Yes, this I understood. I do believe that what I suggested at one point > (have the ability to compare versions with an 'isAncestorOf') would be very > nice for that transition (work in mcz as well as on git with/without > metadata). > I would like to listen to your ideas about this topic, but I am not sure it is possible to achieve that compatibility. In fact we tried to do it for Iceberg and at some point we decided to abort it. On one side, trying to re-create monticello sequential file numbers in git is simply not possible, at least in a reliable way. On the other side, loading the graph of package versions and dependencies is really slow for big repositories (such as pharo-core), once we removed that requirement Iceberg got like 100x faster.

Nov. 7, 2016

Re: [Pharo-users] Pharo desktop UI

by Johan Fabry

I understand what you are asking, in previous versions of the documentation we had something like this. However this turned out to be a bad idea since this is too closely linked to the actual implementation. Making internal changes to the Spec interpreter means that this documentation also needs to be updated. We donât have the resources for that, sadly this documentation became out of date and simply wrong so we had to remove it. So for what you are asking the code is the only reference, sorry. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On 06 Nov 2016, at 18:23, vikenti <vikenti.potapov(a)gmail.com> wrote: > > Maybe you can give some brief explanaition how to create Spec-compatible custom UI control? (Like TextModel or ButtonModel, etc.) How to create model class, corresponding adapter and how to process common and custom UI events (mouse\keyboard\focus ordering\changing). > I think such guide should also be included in Spec booklet.

Nov. 7, 2016

Re: [Pharo-users] Looking for the library to sort object

by Tudor Girba

Hi, Indeed, I forgot about this one. I would like to add this in Moose because it looks quite handy. Cheers, Doru > On Nov 7, 2016, at 2:35 PM, stepharo <stepharo(a)free.fr> wrote: > > Thanks! > > > > Le 7/11/16 Ã 12:37, Sven Van Caekenberghe a Ã©crit : >> This is very nice: >> >> http://smalltalkhub.com/#!/~emaringolo/SortFunctions >> >>> On 7 Nov 2016, at 12:25, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi >>> >>> I know that "steffen" did a nice library to sort objects and I know that this is a nice extension. >>> >>> But I cannot find it. >>> >>> Stef >>> >>> >> >> > > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Nov. 7, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

Hi Dale, 2016-11-07 12:03 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > > > On 11/7/16 7:15 AM, Thierry Goubier wrote: > > > > 2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 7 Nov 2016, at 10:03, Thierry Goubier <thierry.goubier(a)gmail.com> >> wrote: >> >> Hi Esteban, >> >> I cut out the rest, because I agree with all your points, except for... >> >> 2016-11-07 9:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> [ ... ] >>> >>> Replacing Monticello with git goes in this direction: >>> >>> [ ... ] >>> >> >> And this one I don't understand. A smooth, git / iceberg oriented >> transition over Monticello/Metacello is perfectly doable... As Dale >> explained. A nice Iceberg gui reworking / making git usable is perfect. >> >> >> Wellâ¦ I disagree with this. >> All my experience says the opposite: this is a convenience usage that in >> the long way does not match (the thing that we simulate mcz packages do not >> workâ¦ and makes things a lot harder to maintain later). >> Nico has worked a lot on this, maybe he has something to say. >> > > I'd like to. Simulating mcz? That I don't get it. > > Thierry, If I'm not mistaken, Esteban is referring to the fact that in > FileTree we are still using Monticello to do the load of the packages and > even when we are running metadataless, we end creating fake meta data to > simulate an mcz ... you and I have had conversations about ways to > eliminate this "requirement" because it is meaningless in a git context ... > Yes, this I understood. I do believe that what I suggested at one point (have the ability to compare versions with an 'isAncestorOf') would be very nice for that transition (work in mcz as well as on git with/without metadata). > > With the work that Richard Sargent did on the > CypressReferenceImplementation, I would prefer to say that Cypress can > provide an Alternative to Monticello rather than replace it ... the > CypressReferenceImplementation includes a package loader so it isn't > necessary to convert Filetree format on disk to Mcz format in the image --- > without all of the ancestry, "latest version stuff" and package-cache the > loading process becomes much, much simpler... > > I think that both Monticello and Cypress can live together in the image ... > For me, MC is also the code / diff model behind: will Cypress rewrites all that too? > > I have created a version of Metacello that uses Monticello OR Cypress and > I expect to eventually (in the next several months --- it doesn't take that > long, but I've got other things on my plate) to have a version of Metacello > that uses Monticello AND/OR Cypress again I think that smooth transitions > (that may take a long time) are better supported in this fashion than to > draw a line in the sand and force the usage of one OR the other ... > As long as Cypress behaves as a MC repository and fits into the same API, I really don't see where is the difficulty. As we are saying now, adding a type of repository / emulating the MC overall API is no real difficulty in itself and isolates one from all the project management issues (because that means Metacello, ConfigurationOf and BaselineOf just keep working as usual). We need to get the MC repository API to evolve a bit, in part to handle the "save multiple packages, do one commit without using package dependencies." required now, and also to expose more of the repository organisation (remotes, branches) for the GUI above. And remove some of the things saying "I'm MC trying to do Metacello's job". What is a bit annoying, really, is this talk of rewriting everything where some of the pieces (the project browsing you're talkin about, for example) is already there in the image, just not exposed. I'm trying to code a little something for that... stay tuned for a screenshot soon. Thierry > > Dale >

Nov. 7, 2016