Re: [Pharo-users] about balkanisation
Kilon wrote:
If you really want to embrace Github , kill Smalltalkhub
We are not close to doing that. We'll need Monticello support indefinitely, and at least a few years two-way. And that assumes we automatically migrate all open projects. First we need good workflows that also work for complex projects. That includes cross-platform projects like Seaside Stephan
Le 6/11/16 à 17:21, Stephan Eggermont a écrit :
Kilon wrote:
If you really want to embrace Github , kill Smalltalkhub We are not close to doing that. We'll need Monticello support indefinitely, and at least a few years two-way. And that assumes we automatically migrate all open projects.
We decided that iceberg will support one way from MC -> github but not the inverse because we do not have the ressources.
First we need good workflows that also work for complex projects. That includes cross-platform projects like Seaside
We should be able to manage Pharo with the external projects composing it. Moose Seaside should be working too. So yes this is why guille spent some time building cases and evaluate solutions (submodules vs subtrees vs under one umbrella) with pull requests between subprojects and the rest....
Stephan
On 6 November 2016 at 17:21, Stephan Eggermont <stephan@stack.nl> wrote:
Kilon wrote:
If you really want to embrace Github , kill Smalltalkhub
We are not close to doing that. We'll need Monticello support indefinitely, and at least a few years two-way. And that assumes we automatically migrate all open projects.
First we need good workflows that also work for complex projects. That includes cross-platform projects like Seaside
Oh, come on! Throw away everything you had.. and start using something new and trendy, rinse and repeat. Profit! :)
Stephan
-- Best regards, Igor Stasenko.
Mcz repos are useful. STH storage works nicely, that's more the frontend which si bitrotting. I actually have a local FTP based thing on my Synology and it is neat and needs no time to work. Did you ever look into Zinc and see there is also a server there for that? Now, GitHub is better for sharing as there is the *critical mass* there. And the tooling is very good. And we can stuff a lot of other things than mcz in it (and with Git LFS https://git-lfs.github.com/ we could even stuff images and mcz in there right away. This thing is next in line for inclusion in https://github.com/Pharophile/ExternalTools In pvt chats on Slack, there is this tension between moving forward and stabilizing stuff. I hope that with boostrap, we'll be able to have a stable core and LTS assemblies. Reinventing the wheel is fun. But it better has to be a better wheel. Let's alway thing about our "normal" https://www.youtube.com/watch?v=FvmTSpJU-Xc We are at risk of boiling ourselves, in whatever plane we are. I like the progress and I hate to have to adapt. But once past the curve, life is actually better. Lots. Phil On Mon, Nov 7, 2016 at 5:29 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 November 2016 at 17:21, Stephan Eggermont <stephan@stack.nl> wrote:
Kilon wrote:
If you really want to embrace Github , kill Smalltalkhub
We are not close to doing that. We'll need Monticello support indefinitely, and at least a few years two-way. And that assumes we automatically migrate all open projects.
First we need good workflows that also work for complex projects. That includes cross-platform projects like Seaside
Oh, come on! Throw away everything you had.. and start using something new and trendy, rinse and repeat. Profit! :)
Stephan
-- Best regards, Igor Stasenko.
Hi, If anyone *ever* thought we are moving to git because is the new stuff, I need to clarify several things: 1) you donât know me :) 2) git is not new-cool stuff since a couple of years so is not that we are jumping into anything fancy shiny new (we should be trying to use docker as monticello repositories if that would be the case). Now, letâs talk for real: suppose for a second that you are a software architect (whatever that means) that has in your shoulders the responsibility of drive forward this amazing project called is Pharo. Pharo is a HUGE project with a lot of composants all of them moving. Many times because people introduces changes, others because changes affects others (this is not cool, but happens a lot) and some other simply time passes and world changes around us, which also makes our vision of things change. Now, in this context, as a software architect you do an analysis of risk and you get that Pharo has a lot of them, I will quote just a couple: - As a âmoving targetâ, maintainability is the first big issue: the accidental complexity of the system tends constantly to increase (sometimes, as with some version, at speeds you wouldnât believe it). Also, incorporating new tools means new things to maintain, constantly. - We do not have enough resources. No idea if we will ever get enough resources, but we do not have enough people to keep maintaining everything and in addition iterate to evolve Pharo. Of course we benefit of been a large community with many people contributing but that is an advantage but also a risk. - People pushes their own agendas. This is perfectly ok, but that means the effort is not measurable nor dirigible :) - tools are OLD. Many of them (including monticello) were built for a world who do not exists any more: software projects are *different* now: bigger, multi-platform, multi-language, N-tier, etc., etc. etc. - ⦠(I can continue all day detecting risks) Now, always as a software architect, you detected an important amount of risks that can make fail your project, and then you have to take decisions to mitigate this risks. One possibility is stop moving. Freezing that part will add a lot of stability to the system⦠just we will using a relic, and the world will continue changing⦠others have followed this path. Pharo vision is (and has always been) other⦠we need, we want to continue moving. So this solution cannot be taken. Other solution is to hire more people. Of course, no money and no money means no more people. Another solution that cannot be taken. So we arrive to a third solution: Reduce the amount of things that needs to be maintained and are ânon essentialâ, so we can concentrate in developing what is actually our thing: we do Pharo. Replacing Monticello with git goes in this direction: - it allows us to stop maintaining sthub (or any other pharo-based repository). Letâs face it: we will NEVER develop a tool as good as github/gitlab/bitbucket/the next thing. Why? Because it is NOT OUT BUSINESS. They have developers there, whoâs only work is to do such tool. - but also: it allow developing sotfware projects in ways monticello donât: multi language, external sources, etc. - but also: it allow CI without us needing to maintain jenkins (another thing that we will able to not maintain anymore⦠I spent far too much time there and I spent 1% of the time that Christophe spent there, for example). - but also: it reduces the level of âalienessâ that newcomers experiments when they arrive to Pharo (letâs face it: most people arrives to Pharo already knowing other languages and most of them are expecting a file-based way of sharing⦠many of them are expecting git, in fact). In other order of things: - I spent last week replacing a backend made in amber with a backend made in seaside just to remove amber from the equation: so something we need to maintain is pharo-exclusive (this is âarchitecture 101â: systems complexity increases exponentially for each language you add). - I spent last 3 months aligning the PharoVM with the CogVM, removing what was a âde factoâ fork, just to reduce the amount of maintenance effort we need to put there. And to join efforts with Eliot and all others (because joining a larger team and collaborate with them is also a way to incorporate more people into our own VM). - I spent months developing UFFI to remove NativeBoost from the equation with exactly the same purpose: reduce the amount of things we need to maintain. So, as Pharo architect, Pharo fireman, stabilisation faery, whatever you want to call me, it is my responsibility to be sure Pharo will continue moving forward, and this is my answer. But not just me. I work on RMoD team at INRIA. The research team purpose is precisely to support âsoftware evolutionâ. This means I have the luck of work with some of the best people in the world to ask for this kind of questions. And there is also the Pharo board, who is a group of professionals who knows a bit about pharo and software projects developing. So yes⦠if you ever thought we are people who jumps to the new-hyped-thing just because is there⦠think again. Esteban
On 7 Nov 2016, at 07:48, phil@highoctane.be wrote:
Mcz repos are useful.
STH storage works nicely, that's more the frontend which si bitrotting.
I actually have a local FTP based thing on my Synology and it is neat and needs no time to work.
Did you ever look into Zinc and see there is also a server there for that?
Now, GitHub is better for sharing as there is the *critical mass* there. And the tooling is very good.
And we can stuff a lot of other things than mcz in it (and with Git LFS https://git-lfs.github.com/ <https://git-lfs.github.com/> we could even stuff images and mcz in there right away. This thing is next in line for inclusion in https://github.com/Pharophile/ExternalTools <https://github.com/Pharophile/ExternalTools>
In pvt chats on Slack, there is this tension between moving forward and stabilizing stuff. I hope that with boostrap, we'll be able to have a stable core and LTS assemblies.
Reinventing the wheel is fun. But it better has to be a better wheel.
Let's alway thing about our "normal" https://www.youtube.com/watch?v=FvmTSpJU-Xc <https://www.youtube.com/watch?v=FvmTSpJU-Xc>
We are at risk of boiling ourselves, in whatever plane we are.
I like the progress and I hate to have to adapt. But once past the curve, life is actually better. Lots.
Phil
On Mon, Nov 7, 2016 at 5:29 AM, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
On 6 November 2016 at 17:21, Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>> wrote: Kilon wrote:
If you really want to embrace Github , kill Smalltalkhub
We are not close to doing that. We'll need Monticello support indefinitely, and at least a few years two-way. And that assumes we automatically migrate all open projects.
First we need good workflows that also work for complex projects. That includes cross-platform projects like Seaside
Oh, come on! Throw away everything you had.. and start using something new and trendy, rinse and repeat. Profit! :)
Stephan
-- Best regards, Igor Stasenko.
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@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. But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;) Thierry
On 7 Nov 2016, at 10:03, Thierry Goubier <thierry.goubier@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@gmail.com <mailto:estebanlm@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.
But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;)
Stef was angry because he needs to clone, pull, commit, push and make a PR to collaborate⦠and because that process is not correctly documented/tooled. Sadly, this will not change⦠it will always be like that. What we can do is easy the task creating the tools⦠but that will need to be there. Esteban
Thierry
2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 7 Nov 2016, at 10:03, Thierry Goubier <thierry.goubier@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@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. I've seen many things done in Pharo that have a strong NIH tag attached to them. So I allways take the 'I reimplement everything because I know better' with a grain of salt. Nico has a huge task.
But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;)
Stef was angry because he needs to clone, pull, commit, push and make a PR to collaborate⦠and because that process is not correctly documented/tooled. Sadly, this will not change⦠it will always be like that. What we can do is easy the task creating the tools⦠but that will need to be there.
Agreed. It's about time, by the way. Pharo lost some usability on the SLICES/mcz front over the years, and its painfull when teaching Pharo. Thierry
On 11/7/16 7:15 AM, Thierry Goubier wrote:
2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
On 7 Nov 2016, at 10:03, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@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@gmail.com <mailto:estebanlm@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 ... 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 ... 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 ... Dale
Hi Dale, 2016-11-07 12:03 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:
On 11/7/16 7:15 AM, Thierry Goubier wrote:
2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 7 Nov 2016, at 10:03, Thierry Goubier <thierry.goubier@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@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
2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier@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.
2016-11-07 15:42 GMT+01:00 Nicolas Passerini <npasserini@gmail.com>:
2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier@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
2016-11-07 15:59 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:
2016-11-07 15:42 GMT+01:00 Nicolas Passerini <npasserini@gmail.com>:
2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier@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.
2016-11-07 16:13 GMT+01:00 Nicolas Passerini <npasserini@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
2016-11-07 16:26 GMT+01:00 Thierry Goubier <thierry.goubier@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.
On 11/7/16 11:42 AM, Nicolas Passerini wrote:
2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@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.
I agree that the git-oriented tools should not go ot of their may to conform to the MC model .. as you say it just does not fit ... but many of the standard operations that are performed can be performed on both git and mcz repositories without forcing both of the models to share identical implementations ... in image tools should distinguish between mcz and git projects and dispatch the standard operations to the appropriate repository --- and this si the spot where the handling changes based upon the repository model ... Dale
On 11/7/16 11:30 AM, Thierry Goubier wrote:
> Hi Dale,
>
> 2016-11-07 12:03 GMT+01:00 Dale Henrichs
> <dale.henrichs@gemtalksystems.com
> <mailto:dale.henrichs@gemtalksystems.com>>:
>
>
>
> On 11/7/16 7:15 AM, Thierry Goubier wrote:
>>
>>
>> 2016-11-07 11:05 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com
>> <mailto:estebanlm@gmail.com>>:
>>
>>
>>> On 7 Nov 2016, at 10:03, Thierry Goubier
>>> <thierry.goubier@gmail.com
>>> <mailto:thierry.goubier@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@gmail.com <mailto:estebanlm@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).
II think that the work that you did with gitfiletree was very
influential in making git a realistic option for the Pharo community and
I think that the choices you made were excellent, but I think that for a
transition it is important that git be presented as itself more fully
and expose some of the features that set git apart
(project/package/class/method diffs; multi-package commits; etc.) ...
but I also feel that Monticello does not need to be diluted --- the
existing Monticello tools should remain in place for the forseeable
future ...
>
>
> 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?
Well Cypress is not that much of a rewrite ... Cypress definitions are
closely based upon the Monticello definition model... snapshots and
loading based on comparing the snapshot of the repository against the
snapshot of the image are also closely based on Monticello ... The
differences are in the fact that Cypress packages do not have ancestry,
author names or version numbers:
- the ancestry and author is recorded and managed by git (or svn or hg)
- there is only one version of a package in a fieltree repo, so there
is no
need to sort packages by version number to fine the "latest version"
So Cypress is more of a "take all of the really good parts of Monticello
while dropping the bits that are handled better by git" than it is a
complete _rewrite_ ...
>
>
> 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).
There are api differences between MC and Cypress ... MC has ancestry and
package numbers while Cypress does not ... but I don;t think that these
are major items ... I have yet to try to merge MC and Cypress in the
same Metacello code base and I have yet to look closely at the
requirements for Cypress Package Browser tool, but I know that the
Cypress Package Browser will be much simpler ... But the goal for
Metacello is that individual developers will be able to choose the
repository/package model that best fits their work flow and portability
needs ...
> 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".
yes I think this is the area where a Metallo Project Browser comes into
play. The technology for committing the dirty packages in a a
ConfigurationOf has been around for quite awhile, but a tool that
unifies the "multi-package" commit for ConfigurationOf and BaselineOf
hasn't popped out of the wood work ...
>
> 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.
Well I am annoyed as well .. I would say that perhaps we are in
screaming agreement ... I've said that I don't think it's a lot of work
to do the project-centric tool. but a project-centric tool that
encompasses both ConfigurationOf and BaselineOf will expose the features
that "are already there"
>
> I'm trying to code a little something for that... stay tuned for a
> screenshot soon.
Cool:)
Dale
Hi Dale, 2016-11-08 2:03 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:
[ snip ... ]
yes I think this is the area where a Metallo Project Browser comes into play. The technology for committing the dirty packages in a a ConfigurationOf has been around for quite awhile, but a tool that unifies the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped out of the wood work ...
I'm having some issues with the scripting approach of Metacello, for that. Just manipulating a baseline in the Metacello registry (locking it) seems to be like writing a compiler code generation item: write a Metacello script ;) (Metacello>>#lock contains interesting code).
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.
Well I am annoyed as well .. I would say that perhaps we are in screaming agreement ... I've said that I don't think it's a lot of work to do the project-centric tool. but a project-centric tool that encompasses both ConfigurationOf and BaselineOf will expose the features that "are already there"
I'm trying to code a little something for that... stay tuned for a screenshot soon.
Cool:)
And here it is! I'm still fighting with the Metacello lock / unlock thing. [image: Images intégrées 1] If Pharo was more really modular in configurations and baselines, then I would see more things into the registry and I could group packages based on that (instead of having to prepare a ad-hoc classification for my my browser). Thierry
Dale
On 11/8/16 7:09 AM, Thierry Goubier wrote:
Hi Dale,
2016-11-08 2:03 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>>:
[ snip ... ]
yes I think this is the area where a Metallo Project Browser comes into play. The technology for committing the dirty packages in a a ConfigurationOf has been around for quite awhile, but a tool that unifies the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped out of the wood work ...
I'm having some issues with the scripting approach of Metacello, for that. Just manipulating a baseline in the Metacello registry (locking it) seems to be like writing a compiler code generation item: write a Metacello script ;) (Metacello>>#lock contains interesting code). I think I agree:) ... that is why i am talking about a tool ... developers shouldn't have to pass around workspaces to load and manipulate projects .. a project tool can partially automate the process, but I believe that there needs to be a "load spec" object that can be passed around and massaged by code instead of requiring a user to edit a Smalltalk workspace ... it's what I do in tODE ... the only times I have to write Smalltalk load scripts is when I work in Pharo :)
I will repeat that I don't think Pharo should do exactly what I've done with tODE, but a Metacello Project Browser and some sort of "load spec" object that is shared amongst a cluster of images is something that needs to be seriously considered ...
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.
Well I am annoyed as well .. I would say that perhaps we are in screaming agreement ... I've said that I don't think it's a lot of work to do the project-centric tool. but a project-centric tool that encompasses both ConfigurationOf and BaselineOf will expose the features that "are already there"
I'm trying to code a little something for that... stay tuned for a screenshot soon.
Cool:)
And here it is! I'm still fighting with the Metacello lock / unlock thing.
Images intégrées 1
If Pharo was more really modular in configurations and baselines, then I would see more things into the registry and I could group packages based on that (instead of having to prepare a ad-hoc classification for my my browser).
Yes this is headed in the right direction ... I am in Argentina this week so it isn't easy for me to do much collaboration, but I would love to help you with your lock problem next week ... For example ... you do not want to directly expose the Metacello registry as there are "hybrid projects" where a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs to take precedence (I have code for resolving this) and I strongly suggest that the Project Browser not be built-into the Class Browser, but be a separate tool like the CataLogBrowser ... but this is just a suggestion --- a separate tool dedicated only to loaded Projects and unloaded Projects of interest allows one to get a very quick overview of what is in the project or not and when version skew pops up, one can easily see the affected projects ... embedding this kind of information in the code browser can make it hard to get the overview and if you choose to live with version skew can be annoying to ignore .... again these are just my thoughts .. Regardless I think you are definitely headed in the right direction and it isn't all that much work ... yet:) Dale
Hi Dale, 2016-11-10 6:04 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:
On 11/8/16 7:09 AM, Thierry Goubier wrote:
Hi Dale,
2016-11-08 2:03 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com> :
[ snip ... ]
yes I think this is the area where a Metallo Project Browser comes into play. The technology for committing the dirty packages in a a ConfigurationOf has been around for quite awhile, but a tool that unifies the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped out of the wood work ...
I'm having some issues with the scripting approach of Metacello, for that. Just manipulating a baseline in the Metacello registry (locking it) seems to be like writing a compiler code generation item: write a Metacello script ;) (Metacello>>#lock contains interesting code).
I think I agree:) ... that is why i am talking about a tool ... developers shouldn't have to pass around workspaces to load and manipulate projects .. a project tool can partially automate the process, but I believe that there needs to be a "load spec" object that can be passed around and massaged by code instead of requiring a user to edit a Smalltalk workspace ... it's what I do in tODE ... the only times I have to write Smalltalk load scripts is when I work in Pharo :)
Agreed. I would just like to find out which object can be used to act upon (can I call lock on a Metacello project spec... apparently not :))... I'm not too keen on adding another layer on top of it, first because I'm not that found of unneeded layers, second because it may mean a significant rewrite of the environment (have dozens of methods like MyLayer>>#load which is just a call to Metacello load) to get something that starts working. I'm not in a position to impose large scale changes in the Pharo ecosystem; it's the consortium role to take and impose such choices. I can only, like GitFileTree, inject something at a lower level that allow people to complement and experiment with...
I will repeat that I don't think Pharo should do exactly what I've done with tODE, but a Metacello Project Browser and some sort of "load spec" object that is shared amongst a cluster of images is something that needs to be seriously considered ...
I'm really willing to also make something helping to work with Baselines / Configurations because I think they present a significant complexity barrier to the proper use of Metacello features, and I don't see any path avoiding us to write those, given how complex it may be.
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.
Well I am annoyed as well .. I would say that perhaps we are in screaming agreement ... I've said that I don't think it's a lot of work to do the project-centric tool. but a project-centric tool that encompasses both ConfigurationOf and BaselineOf will expose the features that "are already there"
I'm trying to code a little something for that... stay tuned for a screenshot soon.
Cool:)
And here it is! I'm still fighting with the Metacello lock / unlock thing.
[image: Images intégrées 1]
If Pharo was more really modular in configurations and baselines, then I would see more things into the registry and I could group packages based on that (instead of having to prepare a ad-hoc classification for my my browser).
Yes this is headed in the right direction ... I am in Argentina this week so it isn't easy for me to do much collaboration, but I would love to help you with your lock problem next week ... For example ... you do not want to directly expose the Metacello registry as there are "hybrid projects" where a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs to take precedence (I have code for resolving this) and I strongly suggest that the Project Browser not be built-into the Class Browser, but be a separate tool like the CataLogBrowser ... but this is just a suggestion --- a separate tool dedicated only to loaded Projects and unloaded Projects of interest allows one to get a very quick overview of what is in the project or not and when version skew pops up, one can easily see the affected projects ... embedding this kind of information in the code browser can make it hard to get the overview and if you choose to live with version skew can be annoying to ignore .... again these are just my thoughts ..
I'm of a different mind on this. Giving access to the Metacello registry explains well to me what is happening in the system; as long as the GUI accelerate a significant subset of the common operations, then I'll consider it good enough and have it working on a short time frame. Otherwise, you end up with projects like libgit / Iceberg, which are taking significantly longer to reach a better solution... Exposing the exponential time needed to reach the perfect solution. I also hate information duplication: why do I have to write a complex project spec where most (all?) of it has to be rewritten in a different form in a BaselineOf? Same goes for the forks you described the other day: why do I have to write in my project description the information I also have to add inside the repository (an upstream remote) to manage updating with the master project? For version skew, I must be a bit like git designers on that. It has to be an action (a git pull), and this action is required in git anyway (git pull upstream / git pull origin) .. I have no opinion on whether a GUI has to automatically check that everytime I open the project browser.
Regardless I think you are definitely headed in the right direction and it isn't all that much work ... yet:)
I need to keep it reasonable to be able to tackle it :) Thierry
Dale
On Thu, Nov 10, 2016 at 10:12 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Hi Dale,
2016-11-10 6:04 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com> :
On 11/8/16 7:09 AM, Thierry Goubier wrote:
Hi Dale,
2016-11-08 2:03 GMT+01:00 Dale Henrichs <dale.henrichs@gemtalksystems.com
:
[ snip ... ]
yes I think this is the area where a Metallo Project Browser comes into play. The technology for committing the dirty packages in a a ConfigurationOf has been around for quite awhile, but a tool that unifies the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped out of the wood work ...
I'm having some issues with the scripting approach of Metacello, for that. Just manipulating a baseline in the Metacello registry (locking it) seems to be like writing a compiler code generation item: write a Metacello script ;) (Metacello>>#lock contains interesting code).
I think I agree:) ... that is why i am talking about a tool ... developers shouldn't have to pass around workspaces to load and manipulate projects .. a project tool can partially automate the process, but I believe that there needs to be a "load spec" object that can be passed around and massaged by code instead of requiring a user to edit a Smalltalk workspace ... it's what I do in tODE ... the only times I have to write Smalltalk load scripts is when I work in Pharo :)
Agreed. I would just like to find out which object can be used to act upon (can I call lock on a Metacello project spec... apparently not :))... I'm not too keen on adding another layer on top of it, first because I'm not that found of unneeded layers, second because it may mean a significant rewrite of the environment (have dozens of methods like MyLayer>>#load which is just a call to Metacello load) to get something that starts working.
I'm not in a position to impose large scale changes in the Pharo ecosystem; it's the consortium role to take and impose such choices. I can only, like GitFileTree, inject something at a lower level that allow people to complement and experiment with...
I will repeat that I don't think Pharo should do exactly what I've done with tODE, but a Metacello Project Browser and some sort of "load spec" object that is shared amongst a cluster of images is something that needs to be seriously considered ...
I'm really willing to also make something helping to work with Baselines / Configurations because I think they present a significant complexity barrier to the proper use of Metacello features, and I don't see any path avoiding us to write those, given how complex it may be.
Now a BaselineOf is a ConfigurationOf but such things cannot be put in the Catalog because well, there is some incompatibility happening. Getting BaselineOf usable right away would be a small step but a great step. I find myself having to write a BaselineOf for the Git repo and a ConfigurationOfXXX usign the old scheme to be put in the Catalog and pointing to the BaselineOf. Could someone point to the reason why?
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.
Well I am annoyed as well .. I would say that perhaps we are in screaming agreement ... I've said that I don't think it's a lot of work to do the project-centric tool. but a project-centric tool that encompasses both ConfigurationOf and BaselineOf will expose the features that "are already there"
I'm trying to code a little something for that... stay tuned for a screenshot soon.
Cool:)
And here it is! I'm still fighting with the Metacello lock / unlock thing.
[image: Images intégrées 1]
If Pharo was more really modular in configurations and baselines, then I would see more things into the registry and I could group packages based on that (instead of having to prepare a ad-hoc classification for my my browser).
Yes this is headed in the right direction ... I am in Argentina this week so it isn't easy for me to do much collaboration, but I would love to help you with your lock problem next week ... For example ... you do not want to directly expose the Metacello registry as there are "hybrid projects" where a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs to take precedence (I have code for resolving this) and I strongly suggest that the Project Browser not be built-into the Class Browser, but be a separate tool like the CataLogBrowser ... but this is just a suggestion --- a separate tool dedicated only to loaded Projects and unloaded Projects of interest allows one to get a very quick overview of what is in the project or not and when version skew pops up, one can easily see the affected projects ... embedding this kind of information in the code browser can make it hard to get the overview and if you choose to live with version skew can be annoying to ignore .... again these are just my thoughts ..
I'm of a different mind on this. Giving access to the Metacello registry explains well to me what is happening in the system; as long as the GUI accelerate a significant subset of the common operations, then I'll consider it good enough and have it working on a short time frame.
Already having the GTPlayground showing an inspector after loading is nice these days. Before it was more convoluted to understand what was going on. The inspector panes kind of rewrite things their way but still nice to have.
Otherwise, you end up with projects like libgit / Iceberg, which are taking significantly longer to reach a better solution... Exposing the exponential time needed to reach the perfect solution.
What is Iceberg trying to solve exactly? Ah, and I found why my Pharo5 image explodes when using GitFileTree on Windows: because of ProcessWrapper trying to use git which is in turn not in the path, and then boom.
I also hate information duplication: why do I have to write a complex project spec where most (all?) of it has to be rewritten in a different form in a BaselineOf? Same goes for the forks you described the other day: why do I have to write in my project description the information I also have to add inside the repository (an upstream remote) to manage updating with the master project?
There is too much stuff to understand to get anything used by a layman. There isn't so much to do with tools like npm.js etc: write your json thing for the package, use semver and this is all looking logical. So that one can get a junior dev handle it in a day. Try that with what we have. Phil
For version skew, I must be a bit like git designers on that. It has to be an action (a git pull), and this action is required in git anyway (git pull upstream / git pull origin) .. I have no opinion on whether a GUI has to automatically check that everytime I open the project browser.
Regardless I think you are definitely headed in the right direction and it isn't all that much work ... yet:)
I need to keep it reasonable to be able to tackle it :)
Thierry
Dale
[ ... ]
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.
But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;)
No my point was not that. My point is that it is important to pay attention and not to add more noise than necessary. Let us take the time and move alltogether. Stef
Thierry
On 7 November 2016 at 14:28, stepharo <stepharo@free.fr> wrote:
[ ... ]
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.
But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;)
No my point was not that. My point is that it is important to pay attention and not to add more noise than necessary. Let us take the time and move alltogether.
If you want to get somewhere with this story, you don't want to wait till
everything will be ready. Transition will never start unless you force users to enter the minefield and let them clear the mines for you. Step by step. Many will blow themselves up, while some will manage to pass unhurt.. Because else, it will be always a minefield between you and the destination of your journey :)
Stef
Thierry
-- Best regards, Igor Stasenko.
On 11/8/16 11:04 PM, Igor Stasenko wrote:
On 7 November 2016 at 14:28, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
[ ... ]
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.
But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;)
No my point was not that. My point is that it is important to pay attention and not to add more noise than necessary. Let us take the time and move alltogether.
If you want to get somewhere with this story, you don't want to wait till everything will be ready. Transition will never start unless you force users to enter the minefield and let them clear the mines for you. Step by step. Many will blow themselves up, while some will manage to pass unhurt.. Because else, it will be always a minefield between you and the destination of your journey :)
I think that at the early stages of the transition you have to support both approaches ... when the new tools are in place and stabilized then one can consider ... the transition has already started so this is not a case where you need to force folks to change, but a case where you need to support the folks who choose to change ... it can be relatively low cost to keep the old tools around for quite awhile ... I would think ... Dale
On 10 November 2016 at 06:07, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
On 11/8/16 11:04 PM, Igor Stasenko wrote:
On 7 November 2016 at 14:28, stepharo <stepharo@free.fr> wrote:
[ ... ]
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.
But why make the transition so hard? You get Stef angry on a Sunday morning because he can't find things anymore... even if he is a strong proponent of the strategy he complains about ;)
No my point was not that. My point is that it is important to pay attention and not to add more noise than necessary. Let us take the time and move alltogether.
If you want to get somewhere with this story, you don't want to wait till
everything will be ready. Transition will never start unless you force users to enter the minefield and let them clear the mines for you. Step by step. Many will blow themselves up, while some will manage to pass unhurt.. Because else, it will be always a minefield between you and the destination of your journey :)
I think that at the early stages of the transition you have to support both approaches ... when the new tools are in place and stabilized then one can consider ... the transition has already started so this is not a case where you need to force folks to change, but a case where you need to support the folks who choose to change ... it can be relatively low cost to keep the old tools around for quite awhile ... I would think ...
Right, as i said: make a minefield and watch those who wanting to cross it. And big mistake then to shout: hey i will never ever step on it.. This is bad idea, since you discouraging people from doing what you need :)
Dale
-- Best regards, Igor Stasenko.
On Sun, Nov 6, 2016 at 6:22 PM Stephan Eggermont <stephan@stack.nl> wrote:
Kilon wrote:
If you really want to embrace Github , kill Smalltalkhub
We are not close to doing that. We'll need Monticello support indefinitely, and at least a few years two-way. And that assumes we automatically migrate all open projects.
First we need good workflows that also work for complex projects. That includes cross-platform projects like Seaside
Stephan
I remember the first time I asked about Pharo and Git maybe 3 years ago , you are one of the first to tell me exactly what you saying now, Pharo is not close to be ready for Git. My first assumption was that you were wrong but respecting your experience as a Smalltalk coder I decided to not fully embrace Git and instead continue to have my project both in Git and in StHub. Few months in this experiment and I confirmed what I suspecting all along that you were wrong. Git requirements is basically non existent, it mainly works with text files and with less support for binary files. Pharo does not need anything but text files to be ready for Git. We had text files since forever with fileouts and became more convenient with filetree. You are also wrong about Seaside kind of projects. Its actually ironic to talk about complex projects when Git itself was made by the creator of Linux and the Linux kernel developers have been using it for the Linux kernel for ages. Actually one of the reasons why Linux created Git was because he was disappointed how slow and cumbersome SVN was with big and complex projects and to this day Git's speed and ability to handle enormous complexity with ease is what makes it first choice for many projects and probably the most popular VCS. Aa such not only SmalltalkHub has been an extremely poor alternativre to Github , its claims like yours that keep the Pharo community using tools that extremely limited , buggy and close to nowhere as Smalltalky enough. I am not talking about here just for Smalltalkhub but also Monticello. That weird Gui thing , that is just weird and sometimes is also weird. If however here we talk personal taste, if people want to recreate tools that exist outside the pharo image because they prefer to stay inside the pharo image , I am not against that but then I never criticised personal taste. Its a free world after all. Tools like Iceberg are more than welcomed as long as I can easily remove them from my image. Personally the only toolset I will be implementing will be a tool to completely bypass monticello and filetree and instead mark classes for export and code will be exported most likely in a fileout format automatically each time I hit accept in the browser.
Hi Kilon, 2016-11-07 9:57 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
Git requirements is basically non existent, it mainly works with text files and with less support for binary files. Pharo does not need anything but text files to be ready for Git. We had text files since forever with fileouts and became more convenient with filetree.
Agreed (of course!).
You are also wrong about Seaside kind of projects. Its actually ironic to talk about complex projects when Git itself was made by the creator of Linux and the Linux kernel developers have been using it for the Linux kernel for ages. Actually one of the reasons why Linux created Git was because he was disappointed how slow and cumbersome SVN was with big and complex projects and to this day Git's speed and ability to handle enormous complexity with ease is what makes it first choice for many projects and probably the most popular VCS.
Aa such not only SmalltalkHub has been an extremely poor alternativre to Github , its claims like yours that keep the Pharo community using tools that extremely limited , buggy and close to nowhere as Smalltalky enough. I am not talking about here just for Smalltalkhub but also Monticello. That weird Gui thing , that is just weird and sometimes is also weird.
If however here we talk personal taste, if people want to recreate tools that exist outside the pharo image because they prefer to stay inside the pharo image , I am not against that but then I never criticised personal taste. Its a free world after all. Tools like Iceberg are more than welcomed as long as I can easily remove them from my image.
Personally the only toolset I will be implementing will be a tool to completely bypass monticello and filetree and instead mark classes for export and code will be exported most likely in a fileout format automatically each time I hit accept in the browser.
Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me (Jan's format is even more conflict-oriented than Filetree metadata, but it is a design goal). Cuis git repository is a mess to me; very hard to build a coherent 'rebuild a new Cuis here' process on it like I routinely do on Pharo. I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement. (I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991) Regards, Thierry
On 7 Nov 2016, at 10:13, Thierry Goubier <thierry.goubier@gmail.com> wrote:
I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement.
(I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991)
Indeed. I agree 100%.
On 7 Nov 2016, at 10:17, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 7 Nov 2016, at 10:13, Thierry Goubier <thierry.goubier@gmail.com> wrote:
I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement.
(I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991)
Indeed. I agree 100%.
I was even thinking on propose someone (a student project, maybe?) to do an embeddable browser people could put in their README.md, to browse sources âas in Pharoâ :) a Seaside app to do that would not be hard, I think⦠and can be hosted on PharoCloud (or whatever you want). Esteban
Am 07.11.2016 um 10:28 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
On 7 Nov 2016, at 10:17, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 7 Nov 2016, at 10:13, Thierry Goubier <thierry.goubier@gmail.com> wrote:
I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement.
(I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991)
Indeed. I agree 100%.
I was even thinking on propose someone (a student project, maybe?) to do an embeddable browser people could put in their README.md, to browse sources âas in Pharoâ :) a Seaside app to do that would not be hard, I think⦠and can be hosted on PharoCloud (or whatever you want).
I fully agree to your previous mail (the long one) but want to add that it is not only the number of things to maintain that plays an important role in taming complexity. You can count the complexity of each project into that calculation. And proposing something using seaside is not an approach according to this rule ;) Norbert
On 7 Nov 2016, at 10:42, Norbert Hartl <norbert@hartl.name> wrote:
Am 07.11.2016 um 10:28 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
On 7 Nov 2016, at 10:17, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 7 Nov 2016, at 10:13, Thierry Goubier <thierry.goubier@gmail.com> wrote:
I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement.
(I quite enjoy reading filetree-based code on github: it is layed out like my browser, neat and clean. Moreover, all my code involve multiple classes, which means switching between files anyway. Given that reading those !! was never a pleasure, even when I started using Smalltalk in 1991)
Indeed. I agree 100%.
I was even thinking on propose someone (a student project, maybe?) to do an embeddable browser people could put in their README.md, to browse sources âas in Pharoâ :) a Seaside app to do that would not be hard, I think⦠and can be hosted on PharoCloud (or whatever you want).
I fully agree to your previous mail (the long one) but want to add that it is not only the number of things to maintain that plays an important role in taming complexity. You can count the complexity of each project into that calculation. And proposing something using seaside is not an approach according to this rule ;)
I know :) Iâm not saying I will do it⦠or maintain it⦠just that it would be cool and fairly easy :P Esteban
Norbert
" Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me (Jan's format is even more conflict-oriented than Filetree metadata, but it is a design goal). Cuis git repository is a mess to me; very hard to build a coherent 'rebuild a new Cuis here' process on it like I routinely do on Pharo." Cuis I downloaded it, does not seem to have such a tool, talking about auto export of code. Jon Vrany which I found here https://github.com/janvrany?tab=overview&from=2015-12-01&to=2015-12-31&utf8=â appears that he has not done any Smalltalk coding for more than a year and I could not find one repo that has such tool. Just to make it clear what I am proposing here is not just a replacement for filetree but I complete bypass of Monticello. I have been a frequent visitor of the pharo mailing lists for more than 5 years not I never head of such a thing. It is also the first time I mention this idea as well. I had in my mind for so long but it has been a low priority because filetree worked without any issues other than browsing the code in code editor and online Github. "I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement." Well if by dying you mean none else but me will use it, most certainly you are correct. But all my projects are foremost personal I never make something for public consumption other than offering a helping hand with Pharo documentation. I am perfectly ok with the fact that people do not use my projects. And foremost its not as if a tool that would bypass monticello and filetree and gitfiletree and iceberg has any chance to be used when for months now the mailing list has been talking about Iceberg. Its clear that I want to live outside the image. Its clear that others want to live inside the image. Its clear that I am a tiny minority , if not the only one.
2016-11-07 10:43 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
" Aready done. Look for Jan Vrany tools or Cuis. IMHO, not convincing to me (Jan's format is even more conflict-oriented than Filetree metadata, but it is a design goal). Cuis git repository is a mess to me; very hard to build a coherent 'rebuild a new Cuis here' process on it like I routinely do on Pharo."
Cuis I downloaded it, does not seem to have such a tool, talking about auto export of code.
Cuis basically delegates everything to git and use one file per package.
Jon Vrany which I found here
https://github.com/janvrany?tab=overview&from=2015-12-01&to= 2015-12-31&utf8=â
appears that he has not done any Smalltalk coding for more than a year and I could not find one repo that has such tool.
He has a nice lib interface targetting both mercurial? and git; a kind of ancestor to Pharo libgit effort. Mainly targeted at Smalltalk/X
Just to make it clear what I am proposing here is not just a replacement for filetree but I complete bypass of Monticello. I have been a frequent visitor of the pharo mailing lists for more than 5 years not I never head of such a thing. It is also the first time I mention this idea as well. I had in my mind for so long but it has been a low priority because filetree worked without any issues other than browsing the code in code editor and online Github.
"I've seen over the years many, many attempts at replacing the filetree format. I used to contest and debate, now I just let them go and die a few months later. Because none of the alternatives are clearly superior, and it is not worth the effort to reimplement."
Well if by dying you mean none else but me will use it, most certainly you are correct. But all my projects are foremost personal I never make something for public consumption other than offering a helping hand with Pharo documentation.
I mean really dying: like in even the creator isn't using it anymore. You really need good code to hold something alone over the years, something that keeps working across Pharo versions as they evolve with minimum changes. Trust me on that! One strategy is to base yourself on stable core components of Pharo. Some stuff in Pharo changes a lot, some has been very stable since Pharo 3 (or upgraded very nicely while maintaining the same API). You may be better off reimplementing stuff changing too fast / or too buggy in their current incarnation, just to decouple yourself: when you go for a self/alone project, your goals do not align with the main image.
I am perfectly ok with the fact that people do not use my projects.
And foremost its not as if a tool that would bypass monticello and filetree and gitfiletree and iceberg has any chance to be used when for months now the mailing list has been talking about Iceberg.
Its clear that I want to live outside the image.
Its clear that others want to live inside the image.
Its clear that I am a tiny minority , if not the only one.
I think you're less radical than you believe :) Thierry
Cuis basically delegates everything to git and use one file per package.
yes thats the direction I want to go with this, if possible kill any kind of meta information and turn everything to Smalltalk code. Even fileout contains meta data.
He has a nice lib interface targetting both mercurial? and git; a kind of ancestor to Pharo libgit effort. Mainly targeted at Smalltalk/X
are you talking about this https://github.com/janvrany/libgit2 his last commit was 4 years ago. this is going the exact opposite direction once again tries to bring git inside the pharo image. Or are you talking about something else ? "I don't understand how you can say that after so many years. The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of the language, the library and the environment (IDE). You can consider these separately and many projects have taken one element out of it to another context. However it is the combination that is magic. Working (developing) command line or file based in Pharo/Smalltalk feels so uncomfortable that it simply hurts. No browsers, no senders/implementors, no workspaces, no inspector, no debugger, no spotter, no interaction, no ... Anyway, this is my opinion and you are of course entitled to yours." I try to refrain from criticising Pharo, because I don't want to decrease the motivation of people contributing to Pharo which I consider critical to the improvement of Pharo and secondly because my criticisms are largely based on personal taste which I think would make for a very poor discussion since personal taste cannot be debated. The summary of my ideology is that there are only parts of Smalltalk I really like and not the whole thing. I have several ideas about Pharo. Whether some or all of those ideas will be proven bad or too difficult to implement , time will tell. Some of those ideas are 1) a component based environment similar to Delphi (one of the things I loved about Delphi). Basically Objects on steroids. 2) An enhancement of visual coding experience in Pharo. Roassal could help here. 3) The ability to use Emacs as an alternative code editor outside the box. Shampoo has accomplished this goal, but I have not tested it yet. 4) Deep integration with both C++ and Python, this is more than a need since I depend both on Python and C++, this idea is the closest to materialisation and probably my most critical one 5) Modular image = This one I am lucky enough that is already a Pharo goal and an ongoing project 6) A more powerful documentation system , Pillar could help here and the inspector / gtspotter 7) Auto update in the background , not a high priority goal since I will be using the Steam API that handles updates but it would be nice 8) Fragmentation of the image format, this one will be a combination of fuel (or custom format) and bootstrap 9) Removal of any mid ground between Smalltalk code and Git , this is the idea I was talking early on 10) Integration with OS tools , like file browsers, web browsers , system utilities etc 11) Replacement of Morphic with QT, I already can do this at least in part with my python bridge but for now its a low priority 12) Management of user analytics, that will be specific to my games and probably will utilise Steam's and Unreal's analytics for gathering information about the user , obviously with the permission of the user, most likely this will require minimum Pharo code 13) Unification of Browser, Workspace , GTInspector, GTDebugger and GtSpotter under one tool 14) More strict evaluation of potential errors and user mistakes and many more. All those ideas are mostly long term so it may be years if not a decade before they materialise and probably will change along the process to fit practical needs. You could say that Ephestos most likely will turn into an alternative Pharo Distribution like Cuis is for Squeak but with very different goals. Again my goal is not to produce something for public consumption but merely an image that follows more closely my personal taste.
On 7 Nov 2016, at 10:43, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Its clear that I want to live outside the image.
Its clear that others want to live inside the image.
Its clear that I am a tiny minority , if not the only one.
I don't understand how you can say that after so many years. The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of the language, the library and the environment (IDE). You can consider these separately and many projects have taken one element out of it to another context. However it is the combination that is magic. Working (developing) command line or file based in Pharo/Smalltalk feels so uncomfortable that it simply hurts. No browsers, no senders/implementors, no workspaces, no inspector, no debugger, no spotter, no interaction, no ... Anyway, this is my opinion and you are of course entitled to yours. Sven
participants (11)
-
Dale Henrichs -
Dimitris Chloupis -
Esteban Lorenzano -
Igor Stasenko -
Nicolas Passerini -
Norbert Hartl -
phil＠highoctane.be -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier