- Pharo-dev - lists.pharo.org

[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

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

by Camillo Bruni

>>> 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. >> >> indeed. I remember that my solution didn't change a thing from the image side >> experience. It was "simply" a git backend for MC. > > But maybe we are talking about different things ? > > I used Dale's stuff ( http://github.com/svenvc ), is your FS-Git different ? > Where can we read about it ? (a.k.a. documentation ;-) A demo was run under https://github.com/dh83/fs-git I didn't fully completed the code, so my model of class-extensions i wrong. But dale's filetree is quite close to it, I simply don't care about storing additional meta-data for monticello :P since that's not necessarily needed. The image side-extensions are here: http://ss3.gemstone.com/ss/fs-git.html/ But I don't remember which is the last version of Pharo it ran on, plus most probably FS got refactored a bit in the meantime... Most of it was developed by Max Leske in Berne for his master, and most of it is nicely test covered :)

July 4, 2012

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

by Frank Shearar

On 4 July 2012 13:23, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-07-04, at 14:02, Sven Van Caekenberghe wrote: > >> >> On 04 Jul 2012, at 13:50, phil(a)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. > > indeed. I remember that my solution didn't change a thing from the image side > experience. It was "simply" a git backend for MC. 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

July 4, 2012

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

by Sven Van Caekenberghe

On 04 Jul 2012, at 14:41, Goubier Thierry wrote: > I'm using filetree, which works, but requires that double work flow : Save in monticello, and a quite complex sequence of git commands so that all the changes are taken in account. That is my point exactly: it is not that it is difficult, but you have to work in two environments (image/terminal/git-app) and be extra careful not to make mistakes (like saving two versions locally without committing). I would also like to have the list of MC package versions inside the image and compare things there. Moving to files and even using github to compare versions is way less useful than comparing things in Smalltalk.

July 4, 2012

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

by Goubier Thierry

Le 04/07/2012 14:05, Camillo Bruni a Ã©crit : > > On 2012-07-04, at 13:50, StÃ©phane Ducasse wrote: > >> camillo >> >> we are not ready and we do not want to rush. >> > > you're kidding me... FS-Git is out there since 2 damn years! Ok then. How to use it then ? How does it integrates with a git repo / submodule which contains more than just Smalltalk code ? Which version of Pharo does it works on ? I'm using filetree, which works, but requires that double work flow : Save in monticello, and a quite complex sequence of git commands so that all the changes are taken in account. So, if a better solution is available, i'd be happy to use it. Especially if it allows a better mastery of git concepts and avoiding the use of gitk GUIs and friends to try to make sense of what's happening with the git repository. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 4, 2012

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

by Sven Van Caekenberghe

On 04 Jul 2012, at 14:23, Camillo Bruni wrote: > > On 2012-07-04, at 14:02, Sven Van Caekenberghe wrote: > >> >> On 04 Jul 2012, at 13:50, phil(a)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. > > indeed. I remember that my solution didn't change a thing from the image side > experience. It was "simply" a git backend for MC. But maybe we are talking about different things ? I used Dale's stuff ( http://github.com/svenvc ), is your FS-Git different ? Where can we read about it ? (a.k.a. documentation ;-) Sven

July 4, 2012