July 2012 - Pharo-dev - lists.pharo.org

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

[Pharo-project] renggli mirror created on smalltalkhub

by Torsten Bergmann

>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? 2. Can I setup an own local repo in a simple directory similar to Monticello or will it require some github stuff. 3. Will the local package cache still contain MCZ's? 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 ;) 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. An ST-only server side solution would at least allow for easy customization and allow the community to adapt the hosting to its needs. Bye T.

July 4, 2012

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

by Frank Shearar

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 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". 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! frank

July 4, 2012

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

by Esteban Lorenzano

different things, Camillo, probably need different answers :) sources can be replaced by file-per-class, changes (since is a delta, not a class), cannot. Let's don't try to replace a silver bullet with another silver bullet... better an arsenal of good fitted answers. Esteban On Jul 4, 2012, at 2:52 PM, Camillo Bruni 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 :) >

July 4, 2012

Re: [Pharo-project] Is there a backup place for

by Damien Cassou

On Sat, Jun 30, 2012 at 10:37 AM, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > http://source.lukas-renggli.ch > ? > > At least today it is not reachable from here. If people are interested we (Guillermo, Friedrich, and I) brought many mcz from Lukas together in a dropbox folder,. Please ask if you are interested. -- 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 Camillo Bruni

> 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 :)

July 4, 2012