- Pharo-dev - lists.pharo.org

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Camillo Bruni

On 2012-07-04, at 15:30, Dennis Schetinin wrote: > On Wednesday, 4 July 2012 Ð³. at 16:11, Damien Cassou wrote: >> On Wed, Jul 4, 2012 at 2:09 PM, Dennis Schetinin <chaetal(a)gmail.com (mailto:chaetal@gmail.com)> wrote: >>> Am I wrong considering migration to Git-or-AnythingElseTextOriented to be a >>> give up on hopes for a real object-oriented source control/management as it >>> could and should be in Smalltalk? >>> >> >> >> can you think of any feature we could have now we couldn't with Git? > I didn't say "now", I talked about "hopes". E.g. hopes for "Source" Control Tool being aware of refactorings and other *operations* I apply to my program, instead of treating it as a plain text with some changes of unknown nature. I'm not sure it's possible right now (I know it's not, better to say?). But with a Smalltalk-based source control we can have it on one splendid day in the future. And I think on the Git way we'll finish with just some advanced text-comparison algorithms. No? that has nothing to do with versioning per se. You can always hook in a different merger for git (that's already a built in feature) which simply redirects over a Pharo image and applies some more ST logic there. Going for something that is even more st specific is a waste of time IMO. What can you do else than storing text? ASTs? besides being incompatible with the whole world of text editable things you won't win much :/. Besides source code is quite a compact representation of ast's itself... cami

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Damien Cassou

On Wed, Jul 4, 2012 at 3:29 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > > I didn't say "now", I talked about "hopes". E.g. hopes for "Source" Control Tool being aware of refactorings and other *operations* I apply to my program, instead of treating it as a plain text with some changes of unknown nature. I'm not sure it's possible right now (I know it's not, better to say?). But with a Smalltalk-based source control we can have it on one splendid day in the future. And I think on the Git way we'll finish with just some advanced text-comparison algorithms. No? I think using git or another VCS would prevent us from having this bright future :-). Git for example won't store diffs or patches, it saves the end result. Nothing prevent us from adding meta-data to a commit to remember we did a refactoring at this point. I don't see how the situation could be any better with object-oriented VCS. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Dennis Schetinin

"MC is not good enough" and "We should use Git" are a bit different thoughts. If MC is not good enough we should improve it or create better tools, but (for me) Git seems to be a wrong direction for that. I've tried to explain in another message why. Best regards, Dennis Schetinin Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, 4 July 2012 Ð³. at 16:17, Esteban Lorenzano wrote: > Hi, > > No, what is wrong is considering monticello itself an object oriented control management system. Right now MC does not provides anything that can be thought as that... even more, MC does not provides anything better than current CMS around... > So, what we have now is an old CMS, and a lot of tools trying to be compatible with that old system. Imagine if GIT would tried to be compatible with CVS... and to create an object control management is a considerable effort, no one want to do, and probably pointless... at least right now. > > best, > Esteban > > > On Jul 4, 2012, at 2:09 PM, Dennis Schetinin wrote: > > Am I wrong considering migration to Git-or-AnythingElseTextOriented to be a give up on hopes for a real object-oriented source control/management as it could and should be in Smalltalk? > > > > Best regards, > > Dennis Schetinin > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > > > > On Wednesday, 4 July 2012 Ð³. at 16:02, Sven Van Caekenberghe wrote: > > > > > > > > On 04 Jul 2012, at 13:50, phil(a)highoctane.be (mailto:phil@highoctane.be) wrote: > > > > > > > I am using Mercurial for all of the other projects and technologies. > > > > > > > > With a full copy of everything locally, it helps indeed when we get crashes... > > > > > > > > But GIT/Hg isn't giving you the change sorter. > > > > > > I have used/tried FileTree/Git(hub) a bit and it is cool and it works. > > > But I do miss (tools) integration in the image. > > > The workflow also changes a bit, it is no longer all Smalltalk. > > > > > > IMHO it is not yet quite ready. > > > > > > Sven > > >

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Dennis Schetinin

On Wednesday, 4 July 2012 Ð³. at 16:11, Damien Cassou wrote: > On Wed, Jul 4, 2012 at 2:09 PM, Dennis Schetinin <chaetal(a)gmail.com (mailto:chaetal@gmail.com)> wrote: > > Am I wrong considering migration to Git-or-AnythingElseTextOriented to be a > > give up on hopes for a real object-oriented source control/management as it > > could and should be in Smalltalk? > > > > > can you think of any feature we could have now we couldn't with Git? I didn't say "now", I talked about "hopes". E.g. hopes for "Source" Control Tool being aware of refactorings and other *operations* I apply to my program, instead of treating it as a plain text with some changes of unknown nature. I'm not sure it's possible right now (I know it's not, better to say?). But with a Smalltalk-based source control we can have it on one splendid day in the future. And I think on the Git way we'll finish with just some advanced text-comparison algorithms. No? Best regards, Dennis Schetinin Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Damien Cassou

On Wed, Jul 4, 2012 at 3:13 PM, Friedrich Dominicus < frido(a)q-software-solutions.de> wrote: > Another stuff I simply do not get is package-cache. Why is it local to > every other Pharo image? Why can't I say drop all below package-cache on > my machine that's it. I do not know how many copies I have around here > with the same "information". I can not see why this should make sens in > the "standard" case.... http://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-s… http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/ Add this to ~/.config/pharo/2.0/monticello.st StartupLoader default executeAtomicItems: { StartupAction name: 'Monticello related stuff' code: [| sharedPackageCacheDirectory | FileStream stdout lf; nextPutAll: 'Executing Monticello related stuff'; lf. sharedPackageCacheDirectory := (FileDirectory on: 'XXXXXXX PATH TO GLOBAL CACHE XXXXXXXX') assureExistence; yourself. MCCacheRepository default directory: sharedPackageCacheDirectory. MCDirectoryRepository defaultDirectoryName: 'XXXXXXX PATH TO GLOBAL CACHE XXXXXXXX'. (MCRepositoryGroup default repositories select: [:each | (each isKindOf: MCHttpRepository) and: [(each locationWithTrailingSlash includesSubString: ' www.squeaksource.com') or: [each locationWithTrailingSlash includesSubString: ' http://ss3.gemstone.com/ss/']]]) do: [:each | each user: 'XXXXXXXXXXXXX'; password: 'XXXXXXXXXXXX']. FileStream stdout lf; nextPutAll: 'Finished'; lf]. }. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Sven Van Caekenberghe

On 04 Jul 2012, at 15:10, Camillo Bruni wrote: > For instance check the Pharo-2.0-Core fileout: > https://github.com/PharoProject/pharo-core Cool! But that is a FileTree version with meta data, right ? Not FS-Git ?

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Camillo Bruni

On 2012-07-04, at 15:13, Friedrich Dominicus wrote: > Well I can not follow this completely. I can not find an answer of why > text-based solutions won't cut it and I have also no idea what an > object-oriented revision control might have other than a very good way > of handling text. I guess I wil have to find some older threads to get > an idea. > > Anyway what I can't understand is that we can not simply switch from > fone repository to another. It does not even have to be always > up-to-date. > > Let me just ask you, how much time do you need if squeacksource is gone > to get a new image filled up and running. No I do not know how often you > do that but I for my part do it with nearly every Pharo version there > is. > > I'm now trying to get some stuff installed in Pharo 2.0 (I guess you > want this stuff to be used) and it takes me hours over hours and I still > do not get anywhere. > > So I simply do not get why we just have a register of places where we > can find this stuff and are not "forced" to code that into the > monticello packages. > > Well if I have to than at least Pharo should be able to easily allow me > to run a kind of grep/replace in the ConfigurationOfFiles. AFAIKt I have > the Extended search but this does just searching and not replacing. So > I'm suposed to manually change all the ConfigurationOf to look in my > local cache first. This is at least odd. > > Another stuff I simply do not get is package-cache. Why is it local to > every other Pharo image? Why can't I say drop all below package-cache on > my machine that's it. I do not know how many copies I have around here > with the same "information". I can not see why this should make sens in > the "standard" case.... you're absolutely right :) Here in lille almost everybody sets up symlinks to have a single shared instance of a package-cache :) > > I'm sorry but I simply do not understand a few things really. And well I > can also not see an advantage of not treating sources as text-files for > easier handling. This stupid text-files work since decades.... oh so true.

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Friedrich Dominicus

Well I can not follow this completely. I can not find an answer of why text-based solutions won't cut it and I have also no idea what an object-oriented revision control might have other than a very good way of handling text. I guess I wil have to find some older threads to get an idea. Anyway what I can't understand is that we can not simply switch from fone repository to another. It does not even have to be always up-to-date. Let me just ask you, how much time do you need if squeacksource is gone to get a new image filled up and running. No I do not know how often you do that but I for my part do it with nearly every Pharo version there is. I'm now trying to get some stuff installed in Pharo 2.0 (I guess you want this stuff to be used) and it takes me hours over hours and I still do not get anywhere. So I simply do not get why we just have a register of places where we can find this stuff and are not "forced" to code that into the monticello packages. Well if I have to than at least Pharo should be able to easily allow me to run a kind of grep/replace in the ConfigurationOfFiles. AFAIKt I have the Extended search but this does just searching and not replacing. So I'm suposed to manually change all the ConfigurationOf to look in my local cache first. This is at least odd. Another stuff I simply do not get is package-cache. Why is it local to every other Pharo image? Why can't I say drop all below package-cache on my machine that's it. I do not know how many copies I have around here with the same "information". I can not see why this should make sens in the "standard" case.... I'm sorry but I simply do not understand a few things really. And well I can also not see an advantage of not treating sources as text-files for easier handling. This stupid text-files work since decades.... Regards Friedrich

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Camillo Bruni

On 2012-07-04, at 15:02, Torsten Bergmann wrote: >> can you think of any feature we could have now we couldn't with Git? > > With Squeaksource/Monticello I'm currently able to have a web based > Smalltalk browser. So I dont have to fire up an image to > digg into other peoples code. > > I expect that could be done with Git hosted projects too - but > requires some work and another server providing the ST-IDE like > feeling. > So the "Smalltalk like user experience" is not available out of the > box on the usual hosting services. This is a small step backward. > > One thing is a must: the usual handling of code should be > preserved. As far as I understand this is the case even > with an GIT-based MC!? > > Some questions: > > 1. Usually Git requires a local git installation. > Is the Git-MC binding a pure ST solution > working on all platforms or does it require some native > support? FS-Git is a pure ST implementation to manipulate git repositories. Currently we lack of support for the git-protocols since we don't have ssh support in the image :) > 2. Can I setup an own local repo in a simple directory similar > to Monticello or will it require some github stuff. github has nothing to do with git, it's just a free hosting service (such as gitorious). So yes, you can run evreything locally > 3. Will the local package cache still contain MCZ's? NO! it will store either 1 file per method or 1 single file per class depending on which strategy you chose. But files are directly accessible no zip madness > On the other hand hosting on file based versioning systems > would make source code indexable for search engines and > could raise Smalltalks place in the (stupid) TIOBE index ;) it could and it will! For instance check the Pharo-2.0-Core fileout: https://github.com/PharoProject/pharo-core that is now used on ohloh to track progress :) > I could imagine both: file based repos (Git) as well as > ST-only solutions as long as they work and reliable. > At the end of the day it's nothing more than a different > representation of code. eventually everything is file-based. MC does it using mcz which was a simple and good solution back then but does not scale. Git is a filesystem on it's own with very nice properties. > An ST-only server side solution would at least allow for > easy customization and allow the community to adapt the hosting > to its needs. with git there is no need for that. Git can use almost any source as remote repository: - any mounted volume - a git repository somewhere on a server accessible via ssh

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Camillo Bruni

On 2012-07-04, at 15:01, Frank Shearar wrote: > On 4 July 2012 13:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> Gitocello [1] takes this approach. While Tim Felgentreff started it to >>> ease porting between Squeak and GNU Smalltalk, it works just fine as a >>> new MC backend. I use it a fair bit [2][3][4]. >>> >>> Mind you I _haven't_ tried collaboration with it. If you had conflicts >>> you would need to use git to address the conflicts, and you can have >>> "inter-method" conflicts which are impossible with FileTree. (In other >>> words, conflict markers could start in one method and end in another.) >>> Probably the chunk format's date stuff would get annoying, as well. >>> >>> >>> [1] https://github.com/timfel/gitocello >>> [2] https://github.com/frankshearar/Unification >>> [3] https://github.com/frankshearar/PersistentUnionFind >>> [4] https://github.com/frankshearar/Zippers >>> >>> frank >> >> ah nice, though you went for the one file per class approach. >> >> Which I think is not the best solution for pharo. >> For instance I want to replace the .changes / .sources file with >> one git repository which allows you to simply load new changes on >> demand and find methods with a minimal effort :) > > Well, "you" is "Tim", but sure. Yes. I like Gitocello's approach > because I can use GitHub without having 1000 mini files. I know that doesn't sound super tempting :P > I also like > FileTree's approach of method-per-file, because that's the natural > granularity of Smalltalk code. I seem to recall Sean DeNigris showing > a screenshot of vim that "stitched" multiple files together to solve > the "FileTree problem". I guess one could write a small vim / emacs plugin to ease development with tons of tiny files :) (and here we go, #sendersOf for vim, anyone?) > And I'd say that yes, if you changed the > .changes file into a repo (which is an awesome idea), you'd definitely > want method-per-file. You get method history for free! YES! :) plus one that actually scales!

July 4, 2012