[Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial.
Hi, guys! Here is a project idea for GSoC. Something that, I think, one day came into everyone's mind. I've just written it: --------------------------- ++ Pharo/Squeak integration with git/mercurial. Source code management is highly important aspect of every software project. Currently in Squeak/Pharo world developer has very limited choice of such tools. The only available full-featured SCM tool is Monticello. Other alternatives such as changesets lack in some areas. Monticello in its own turn has some disadvantages: it can only handle Smalltalk code while typical software project has many other artefacts (represented primarily as files) such as documentation, scripts, diagrams and so on, which would be nice to have in the same repository. This project aims to get round these disadvantages by creating a possibility for developers to use modern distributed source code management tools, which are popular outside of the Smalltalk community. The most recognized are git and mercurial. **Technical details** This project may go different ways towards it's goal, depending on decisions being made during it. Initial steps will be: * Examining git/mercurial and choose one of them considering simplicity of API and it's ease of use, supported operating systems on and other important factors. * Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk. * Studying how Squeak/Pharo handles system changes (changes of classes, methods). Then implement handlers for such changes to translate them to working copy using the mapping or through SCM API. * (optional but desirable) Implementing Smalltalk interface to the chosen SCM. It can be based on the SCM's command line interface or on it's API. These will require using OSProcess or FFI (or writing a plugin) respectively. Additional steps may include: * Implementing import/export tool for Monticello repositories. * Implementing simple user interface for the chosen SCM so that programmer can work with it from within the Smalltalk environment. Integration with widely used OmniBrowser would be even better. In addition to this a local git/mercurial repository can be used instead of sources/changes files. This will require: * Exploring the current mechanism used in Pharo/Squeak to maintain method version history. * Replacing it with the developed system which will write changes to the local git/mercurial repository. **Benefits to the student** The student will: * learn about modern source code management systems; * study their interfaces, both command line and API; * study Pharo/Squeak internal mechanisms related to handling of classes and methods changes and storing of method versions. * get experience in usage of FFI or writing plugins for Smalltalk VM; * get experience with making GUI in Pharo/Squeak; * enjoy writing programs in Smalltalk :) **Benefits to the community** Developers will be able to choose SCM system grounding this choice on their own preferences. The community will gain access to some famous source code hosting services such as GitHub or Bitbucket. Among other benefits it will increase visibility of the community and the Smalltalk language in whole. It also will lower the entry barriers to newcomers and as a consequence will help community grow. Getting rid of sources/changes files offers potentially unlimited method version history and avoids so called "condensing changes". And using local git/mercurial repository for this purpose will make managing changes more natural and uniform in small (every method accepting) and in large (changes at the project level). ---------------------------- I would like to be a mentor (if no one agrees to mentor) or co-mentor, if you guys don't mind. Hope it's not too late :) George
Hi George. Thanks for the proposal. Yes, you have time until tomorrow morning :) Would be cool to see what other think. Now...do this make sense if we already have SqueakSVN ? which this new project would be better than SqueakSVN or why isn't it worth to continue with SqueakSVN instead of start from scratch ? Is it just because GIT seems to be better than SVN ? Maybe a clarification of this in your proposal will be better so that people like me understand why this project is interesting. Cheers Mariano On Thu, Mar 11, 2010 at 7:27 PM, George Herolyants < george.herolyants@gmail.com> wrote:
Hi, guys!
Here is a project idea for GSoC. Something that, I think, one day came into everyone's mind. I've just written it:
---------------------------
++ Pharo/Squeak integration with git/mercurial.
Source code management is highly important aspect of every software project. Currently in Squeak/Pharo world developer has very limited choice of such tools. The only available full-featured SCM tool is Monticello. Other alternatives such as changesets lack in some areas. Monticello in its own turn has some disadvantages: it can only handle Smalltalk code while typical software project has many other artefacts (represented primarily as files) such as documentation, scripts, diagrams and so on, which would be nice to have in the same repository. This project aims to get round these disadvantages by creating a possibility for developers to use modern distributed source code management tools, which are popular outside of the Smalltalk community. The most recognized are git and mercurial.
**Technical details**
This project may go different ways towards it's goal, depending on decisions being made during it.
Initial steps will be: * Examining git/mercurial and choose one of them considering simplicity of API and it's ease of use, supported operating systems on and other important factors. * Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk. * Studying how Squeak/Pharo handles system changes (changes of classes, methods). Then implement handlers for such changes to translate them to working copy using the mapping or through SCM API. * (optional but desirable) Implementing Smalltalk interface to the chosen SCM. It can be based on the SCM's command line interface or on it's API. These will require using OSProcess or FFI (or writing a plugin) respectively.
Additional steps may include: * Implementing import/export tool for Monticello repositories. * Implementing simple user interface for the chosen SCM so that programmer can work with it from within the Smalltalk environment. Integration with widely used OmniBrowser would be even better.
In addition to this a local git/mercurial repository can be used instead of sources/changes files. This will require:
* Exploring the current mechanism used in Pharo/Squeak to maintain method version history. * Replacing it with the developed system which will write changes to the local git/mercurial repository.
**Benefits to the student**
The student will: * learn about modern source code management systems; * study their interfaces, both command line and API; * study Pharo/Squeak internal mechanisms related to handling of classes and methods changes and storing of method versions. * get experience in usage of FFI or writing plugins for Smalltalk VM; * get experience with making GUI in Pharo/Squeak; * enjoy writing programs in Smalltalk :)
**Benefits to the community**
Developers will be able to choose SCM system grounding this choice on their own preferences. The community will gain access to some famous source code hosting services such as GitHub or Bitbucket. Among other benefits it will increase visibility of the community and the Smalltalk language in whole. It also will lower the entry barriers to newcomers and as a consequence will help community grow.
Getting rid of sources/changes files offers potentially unlimited method version history and avoids so called "condensing changes". And using local git/mercurial repository for this purpose will make managing changes more natural and uniform in small (every method accepting) and in large (changes at the project level).
----------------------------
I would like to be a mentor (if no one agrees to mentor) or co-mentor, if you guys don't mind. Hope it's not too late :)
George
Hi, Mariano. 2010/3/11 Mariano Martinez Peck <marianopeck@gmail.com>:
Would be cool to see what other think. Now...do this make sense if we already have SqueakSVN ? which this new project would be better than SqueakSVN or why isn't it worth to continue with SqueakSVN instead of start from scratch ?
There's some points. First, Git and Mercurial become more and more popular, especially in the open source world. Second, they are distributed which is important aspect, especially again for the open source. I tried SqueakSVN and it also requires some work. Less than this project, of course. But I think some parts of the SqueakSVN can be reused. SVN is client-server SCM so it can't compete with Monticello which is highly distributed. Competition is good, and more choice is better. I even think that developing them in parallel can help each of them and Monticello too. And I'm generally interested in distributed solutions, while svn isn't one of them. Also, Git/Mercurial suit better to replace changes/sources again because of their distributed nature.
"George" == George Herolyants <george.herolyants@gmail.com> writes:
George> Initial steps will be: George> * Examining git/mercurial and choose one of them considering George> simplicity of API and it's ease of use, supported operating systems on George> and other important factors. I believe someone has already written Smalltalk code to parse the git object tree. I forget where I heard it, but I definitely went "cool!" in response. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
2010/3/11 Randal L. Schwartz <merlyn@stonehenge.com>:
I believe someone has already written Smalltalk code to parse the git object tree. I forget where I heard it, but I definitely went "cool!" in response.
Yeah! I've just found it here http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/142806. So as I already mentioned the idea isn't new :) And some people did real progress on the issue, while it was only in my "to look at" list with possible transition to the "todo" list. :) Maybe I should ask the author of it?
On Thu, Mar 11, 2010 at 8:42 PM, George Herolyants < george.herolyants@gmail.com> wrote:
2010/3/11 Randal L. Schwartz <merlyn@stonehenge.com>:
I believe someone has already written Smalltalk code to parse the git object tree. I forget where I heard it, but I definitely went "cool!" in response.
Yeah! I've just found it here http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/142806 . So as I already mentioned the idea isn't new :) And some people did real progress on the issue, while it was only in my "to look at" list with possible transition to the "todo" list. :)
Maybe I should ask the author of it?
Yes!!! moreover he can be co-mentor or something like that...Of course, if the project still have sense (I have no idea what is done in that project)
Argh... This "reply to" vs. "reply to all". ---------- Forwarded message ---------- From: George Herolyants <george.herolyants@gmail.com> Date: 2010/3/12 Subject: Re: [Pharo-project] [GSoC] Idea: Pharo/Squeak integration with git/mercurial. To: Mariano Martinez Peck <marianopeck@gmail.com> 2010/3/11 Mariano Martinez Peck <marianopeck@gmail.com>:
Yes!!! moreover he can be co-mentor or something like that...Of course, if the project still have sense (I have no idea what is done in that project)
So I emailed him (Tony Garnock-Jones) yesterday. Still have no reply. I should have cc'ed the email to this list, but it was at the end of the day and my brain just stopped working :)
Here's slightly updated proposal (I included some info about SqueakSVN project and about Smalltalk implementation of Git storage format): ----------------------------- ++ Pharo/Squeak integration with git/mercurial. Source code management is highly important aspect of every software project. Currently in Squeak/Pharo world developer has very limited choice of such tools. The only available full-featured SCM tool is Monticello. Other alternatives such as changesets lack in some areas. Monticello in its own turn has some disadvantages: it can only handle Smalltalk code while typical software project has many other artefacts (represented primarily as files) such as documentation, scripts, diagrams and so on, which would be nice to have in the same repository. This project aims to get round this and some other disadvantages by creating a possibility for developers to use modern distributed source code management tools, which are popular outside of the Smalltalk community. The most recognized are git and mercurial. There is already SqueakSVN project but it aims to SVN integration. SVN is classic client-server SCM. But nowadays this kind of SCM's become less popular, while popularity of distributed SCM's (such as git/mercurial) is still growing. It is also crucial for open source projects like Pharo/Squeak to have distributed SCM to ease development process. Monticello is highly distributed and the new SCM must be distributed as well to successfully compete with Monticello. So git/mercurial fits this goal very well. **Technical details** This project may go different ways towards it's goal, depending on decisions being made during it. Initial steps will be: * Examining git/mercurial and choose one of them considering simplicity of API and it's ease of use, supported operating systems on and other important factors. There's also pure Smalltalk implementation of Git storage format, so this step will require examining it as well. * Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk. (There's also pure smalltalk implementation of Git storage format on SqueakSource. * Studying how Squeak/Pharo handles system changes (changes of classes, methods). Then implement handlers for such changes to translate them to working copy using the mapping or through SCM API. * (optional but desirable) Implementing Smalltalk interface to the chosen SCM. It can be based on the SCM's command line interface or on it's API. These will require using OSProcess or FFI (or writing a plugin) respectively. Additional steps may include: * Implementing import/export tool for Monticello repositories. * Implementing simple user interface for the chosen SCM so that programmer can work with it from within the Smalltalk environment. Integration with widely used OmniBrowser would be even better. In addition to this a local git/mercurial repository can be used instead of sources/changes files. This will require: * Exploring the current mechanism used in Pharo/Squeak to maintain method version history. * Replacing it with the developed system which will write changes to the local git/mercurial repository. **Benefits to the student** The student will: * learn about modern source code management systems; * study their interfaces, both command line and API; * study Pharo/Squeak internal mechanisms related to handling of classes and methods changes and storing of method versions. * get experience in usage of FFI or writing plugins for Smalltalk VM; * get experience with making GUI in Pharo/Squeak; * enjoy writing programs in Smalltalk :) **Benefits to the community** Developers will be able to choose SCM system grounding this choice on their own preferences. The community will gain access to some famous source code hosting services such as GitHub or Bitbucket. Among other benefits it will increase visibility of the community and the Smalltalk language in whole. It also will lower the entry barriers to newcomers and as a consequence will help community grow. Getting rid of sources/changes files offers potentially unlimited method version history and avoids so called "condensing changes". And using local git/mercurial repository for this purpose will make managing changes more natural and uniform in small (every method accepting) and in large (changes at the project level). -------------------------------
Oh, sorry, here it is: ++ Pharo/Squeak integration with git/mercurial. Source code management is highly important aspect of every software project. Currently in Squeak/Pharo world developer has very limited choice of such tools. The only available full-featured SCM tool is Monticello. Other alternatives such as changesets lack in some areas. Monticello in its own turn has some disadvantages: it can only handle Smalltalk code while typical software project has many other artefacts (represented primarily as files) such as documentation, scripts, diagrams and so on, which would be nice to have in the same repository. This project aims to get round this and some other disadvantages by creating a possibility for developers to use modern distributed source code management tools, which are popular outside of the Smalltalk community. The most recognized are git and mercurial. There is already SqueakSVN project but it aims to SVN integration. SVN is classic client-server SCM. But nowadays this kind of SCM's become less popular, while popularity of distributed SCM's (such as git/mercurial) is still growing. It is also crucial for open source projects like Pharo/Squeak to have distributed SCM to ease development process. Monticello is highly distributed and the new SCM must be distributed as well to successfully compete with Monticello. So git/mercurial fits this goal very well. **Technical details** This project may go different ways towards it's goal, depending on decisions being made during it. Initial steps will be: * Examining git/mercurial and choose one of them considering simplicity of API and it's ease of use, supported operating systems on and other important factors. There's also pure Smalltalk implementation of Git storage format on SqueakSource, so this step will require examining it as well. * Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk. * Studying how Squeak/Pharo handles system changes (changes of classes, methods). Then implement handlers for such changes to translate them to working copy using the mapping or through SCM API. * (optional but desirable) Implementing Smalltalk interface to the chosen SCM. It can be based on the SCM's command line interface or on it's API. These will require using OSProcess or FFI (or writing a plugin) respectively. Additional steps may include: * Implementing import/export tool for Monticello repositories. * Implementing simple user interface for the chosen SCM so that programmer can work with it from within the Smalltalk environment. Integration with widely used OmniBrowser would be even better. In addition to this a local git/mercurial repository can be used instead of sources/changes files. This will require: * Exploring the current mechanism used in Pharo/Squeak to maintain method version history. * Replacing it with the developed system which will write changes to the local git/mercurial repository. **Benefits to the student** The student will: * learn about modern source code management systems; * study their interfaces, both command line and API; * study Pharo/Squeak internal mechanisms related to handling of classes and methods changes and storing of method versions. * get experience in usage of FFI or writing plugins for Smalltalk VM; * get experience with making GUI in Pharo/Squeak; * enjoy writing programs in Smalltalk :) **Benefits to the community** Developers will be able to choose SCM system grounding this choice on their own preferences. The community will gain access to some famous source code hosting services such as GitHub or Bitbucket. Among other benefits it will increase visibility of the community and the Smalltalk language in whole. It also will lower the entry barriers to newcomers and as a consequence will help community grow. Getting rid of sources/changes files offers potentially unlimited method version history and avoids so called "condensing changes". And using local git/mercurial repository for this purpose will make managing changes more natural and uniform in small (every method accepting) and in large (changes at the project level).
On 2010-03-11, at 11:18 PM, George Herolyants wrote:
Oh, sorry, here it is:
++ Pharo/Squeak integration with git/mercurial.
* Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk.
Ok, sitting on my desktop here is the work from "The squeak world tour", Ginsu via Joseph Pelrine and John Sarkela. I think this might have some relevance to the project since it : I'll quote Joseph: "maps classes and methods (or better, their semantic definitions) into Subsystems, each of which can have a separate execution environment, allowing remote image work, alternate compilers, passive images, tethered compilation, etc. You can work on and validate code that's not installed in the image." But it is missing the repository backend. -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Excellent. I have just put it. Which level do you think it should be ? beginner, intermediate or advanced ? Cheers Mariano On Fri, Mar 12, 2010 at 8:18 AM, George Herolyants < george.herolyants@gmail.com> wrote:
Oh, sorry, here it is:
++ Pharo/Squeak integration with git/mercurial.
Source code management is highly important aspect of every software project. Currently in Squeak/Pharo world developer has very limited choice of such tools. The only available full-featured SCM tool is Monticello. Other alternatives such as changesets lack in some areas. Monticello in its own turn has some disadvantages: it can only handle Smalltalk code while typical software project has many other artefacts (represented primarily as files) such as documentation, scripts, diagrams and so on, which would be nice to have in the same repository. This project aims to get round this and some other disadvantages by creating a possibility for developers to use modern distributed source code management tools, which are popular outside of the Smalltalk community. The most recognized are git and mercurial.
There is already SqueakSVN project but it aims to SVN integration. SVN is classic client-server SCM. But nowadays this kind of SCM's become less popular, while popularity of distributed SCM's (such as git/mercurial) is still growing. It is also crucial for open source projects like Pharo/Squeak to have distributed SCM to ease development process. Monticello is highly distributed and the new SCM must be distributed as well to successfully compete with Monticello. So git/mercurial fits this goal very well.
**Technical details**
This project may go different ways towards it's goal, depending on decisions being made during it.
Initial steps will be: * Examining git/mercurial and choose one of them considering simplicity of API and it's ease of use, supported operating systems on and other important factors. There's also pure Smalltalk implementation of Git storage format on SqueakSource, so this step will require examining it as well. * Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk. * Studying how Squeak/Pharo handles system changes (changes of classes, methods). Then implement handlers for such changes to translate them to working copy using the mapping or through SCM API. * (optional but desirable) Implementing Smalltalk interface to the chosen SCM. It can be based on the SCM's command line interface or on it's API. These will require using OSProcess or FFI (or writing a plugin) respectively.
Additional steps may include: * Implementing import/export tool for Monticello repositories. * Implementing simple user interface for the chosen SCM so that programmer can work with it from within the Smalltalk environment. Integration with widely used OmniBrowser would be even better.
In addition to this a local git/mercurial repository can be used instead of sources/changes files. This will require:
* Exploring the current mechanism used in Pharo/Squeak to maintain method version history. * Replacing it with the developed system which will write changes to the local git/mercurial repository.
**Benefits to the student**
The student will: * learn about modern source code management systems; * study their interfaces, both command line and API; * study Pharo/Squeak internal mechanisms related to handling of classes and methods changes and storing of method versions. * get experience in usage of FFI or writing plugins for Smalltalk VM; * get experience with making GUI in Pharo/Squeak; * enjoy writing programs in Smalltalk :)
**Benefits to the community**
Developers will be able to choose SCM system grounding this choice on their own preferences. The community will gain access to some famous source code hosting services such as GitHub or Bitbucket. Among other benefits it will increase visibility of the community and the Smalltalk language in whole. It also will lower the entry barriers to newcomers and as a consequence will help community grow.
Getting rid of sources/changes files offers potentially unlimited method version history and avoids so called "condensing changes". And using local git/mercurial repository for this purpose will make managing changes more natural and uniform in small (every method accepting) and in large (changes at the project level).
participants (4)
-
George Herolyants -
John M McIntosh -
Mariano Martinez Peck -
merlyn＠stonehenge.com