[Pharo-project] Distributed versioning ... MonticelloHub?
At first it usually takes some time to get one's head around the Smalltalk way of working in a live image. The next question is usually something around, how can I make this work in a team environment, what about version control, how can I share and/or re-use external packages/classes? After some research there appears to be something called: - SqueakMap: an out-dated collection of publicly shared packages? - Package Universe: an attempt to manage dependency of SqueakMap packages? - Monticello: a nifty distributed package version control system. It seems to me that the concept of a distributed repository system and the implementation of Monticello was ahead of its time in 2003 and makes perfect sense given the fact that everyone is working in their own image ... or repository if you will. How does the now extremely popular Git compare to Monticello actually? Are there any plans for the Pharo Project to create some sort of PharoHub or MonticelloHub (taking the example of GitHub here) where everyone can browse through available repositories and their packages? Anyhow, maybe I am jumping ahead a bit since the first goal is getting towards the big Pharo one point O, but I just wanted to see what other people's thoughts are o this? -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p231... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Monticello actually? Are there any plans for the Pharo Project to create some sort of PharoHub or MonticelloHub (taking the example of GitHub here) where everyone can browse through available repositories and their packages? Anyhow, maybe I am jumping ahead a bit since the first goal is getting towards the big Pharo one point O, but I just wanted to see what other people's thoughts are o this?
You named everything but the thing you're looking for. We have squeaksource.com, which is kind of like github, a place to share Monticello packages. Ramon Leon http://onsmalltalk.com
Ramon Leon wrote:
You named everything but the thing you're looking for. We have squeaksource.com, which is kind of like github, a place to share Monticello packages.
Ramon Leon http://onsmalltalk.com
As you can see I am still finding my feet here :) Amazing though, that during during my research I didn't come across http://squeaksource.com squeaksource.com myself. I actually had come across SqueakSource some time ago when I started to look at Squeak. So, am I correct in assuming that SqueakSource was intended to replace SqueakMap and Package Universe then? Since Pharo is a fork of Squeak, wouldn't it need some sort of Pharo specific repositories or would all SqueakSource repositories continue to work on Pharo? The whole SqueakMap, Package Universe, SqueakSource and Monticello is very confusing. SqueakSource doesn't really look as inviting as Github either ... I did see there is a SqueakSource 2 project though. -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p231... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Geert wrote:
Ramon Leon wrote:
You named everything but the thing you're looking for. We have squeaksource.com, which is kind of like github, a place to share Monticello packages.
Ramon Leon http://onsmalltalk.com
As you can see I am still finding my feet here :) Amazing though, that during during my research I didn't come across http://squeaksource.com squeaksource.com myself. I actually had come across SqueakSource some time ago when I started to look at Squeak.
So, am I correct in assuming that SqueakSource was intended to replace SqueakMap and Package Universe then? Since Pharo is a fork of Squeak,
Squeaksource is the place to manage the source that makes up a project. You can also set up your own repositories (with ftp for example), much like other scm tools. SqueakMap/Universes/ and Sake/Packages are places to publish the end results of projects, for others to load. SqueakMap - is intended to be the directory of all packages, but it doesn't support dependencies. Universes - has packages with dependencies targeted for a specific version of squeak. Sake/Packages - has package definitions browseable in a standard class browser - supports dependencies - supports unloading - load current published / or latest beta code it can find hope this helps clarify our murky world Keith
Keith Hodges wrote:
Squeaksource is the place to manage the source that makes up a project. You can also set up your own repositories (with ftp for example), much like other scm tools.
SqueakMap/Universes/ and Sake/Packages are places to publish the end results of projects, for others to load.
SqueakMap - is intended to be the directory of all packages, but it doesn't support dependencies.
Universes - has packages with dependencies targeted for a specific version of squeak.
Sake/Packages - has package definitions browseable in a standard class browser - supports dependencies - supports unloading - load current published / or latest beta code it can find
hope this helps clarify our murky world
Keith
Thanks Keith, I had not heard of Sake before ... other than it being a beautiful Japanese beverage :) All these things do seem to serve a different purpose. Would it be an idea to simplify things a bit to make it easier to collaborate, share and innovate? -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p232... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
what is cruelly needed is a build integration server. Keith is working on Bob and he needs help. Now what is needed is that people go also over the code of keith to minimize overrides and other things, else we will have again such discussion and people will get frustrated and think we are assholes (which is not the case) :). In pharo we really want to avoid overrides and extensions for the sake of them. So this means that we should integrate changes. I'm planning to go over kernel extensions today. following the mail and analysis we did with damien in october (argh) Stef On Feb 14, 2009, at 1:17 AM, Geert wrote:
Keith Hodges wrote:
Squeaksource is the place to manage the source that makes up a project. You can also set up your own repositories (with ftp for example), much like other scm tools.
SqueakMap/Universes/ and Sake/Packages are places to publish the end results of projects, for others to load.
SqueakMap - is intended to be the directory of all packages, but it doesn't support dependencies.
Universes - has packages with dependencies targeted for a specific version of squeak.
Sake/Packages - has package definitions browseable in a standard class browser - supports dependencies - supports unloading - load current published / or latest beta code it can find
hope this helps clarify our murky world
Keith
Thanks Keith, I had not heard of Sake before ... other than it being a beautiful Japanese beverage :)
All these things do seem to serve a different purpose. Would it be an idea to simplify things a bit to make it easier to collaborate, share and innovate? -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p232... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse-2 wrote:
what is cruelly needed is a build integration server. Keith is working on Bob and he needs help.
Now what is needed is that people go also over the code of keith to minimize overrides and other things, else we will have again such discussion and people will get frustrated and think we are assholes (which is not the case) :). In pharo we really want to avoid overrides and extensions for the sake of them. So this means that we should integrate changes. I'm planning to go over kernel extensions today. following the mail and analysis we did with damien in october (argh)
Stef
I reckon you guys are all doing a great job! I just feel like I am way too inexperienced to go over the code you guys write. I am actually more a Myers-Briggs (ENFP) visionary type of person and I am looking forward to be able to use Pharo Smalltalk as a platform to bring some of my ideas come to live :P Maybe that's why I am thinking more in terms of high level infrastructure and architecture? Anyway, I will be following this project closely and I will try to get up to speed ASAP so I will ask less silly questions here :) -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p232... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
But geert you can help if you want there are simple things to do such as writing tests or trying to fix some issues on the bugtracker. In any case you are welcome and if you do something you will get feedback Stef On Feb 14, 2009, at 10:15 AM, Geert wrote:
Stéphane Ducasse-2 wrote:
what is cruelly needed is a build integration server. Keith is working on Bob and he needs help.
Now what is needed is that people go also over the code of keith to minimize overrides and other things, else we will have again such discussion and people will get frustrated and think we are assholes (which is not the case) :). In pharo we really want to avoid overrides and extensions for the sake of them. So this means that we should integrate changes. I'm planning to go over kernel extensions today. following the mail and analysis we did with damien in october (argh)
Stef
I reckon you guys are all doing a great job! I just feel like I am way too inexperienced to go over the code you guys write. I am actually more a Myers-Briggs (ENFP) visionary type of person and I am looking forward to be able to use Pharo Smalltalk as a platform to bring some of my ideas come to live :P Maybe that's why I am thinking more in terms of high level infrastructure and architecture? Anyway, I will be following this project closely and I will try to get up to speed ASAP so I will ask less silly questions here :) -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p232... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
So this means that we should integrate changes. I'm planning to go over kernel extensions Why? we dont use it any more, it was split up into fixes on mantis. Unfortunately this approach, while allowing you to add only the fixes needed for a particular package, doesn't enable them to be unloaded.
For the important ones, download http://ftp.squeak.org/3.11/3.10.2-build/090213-0428-Squeak3.10.2-build-beta.... and view the change sets, together with the instance side of Squeak310MakeBuildCandidate. I think that you will find that you have most of them already. cheers Keith
On Sat, Feb 14, 2009 at 12:17 PM, Keith Hodges <keith_hodges@yahoo.co.uk> wrote:
I think that you will find that you have most of them already.
Yes, only issue #456 (which includes the fix and is already in PharoInbox) needs to be included. I guess there are no or very few overrides left. -- Damien Cassou http://damiencassou.seasidehosting.st
sorry you lost me on this one. Stef On Feb 16, 2009, at 10:30 AM, Damien Cassou wrote:
On Sat, Feb 14, 2009 at 12:17 PM, Keith Hodges <keith_hodges@yahoo.co.uk
wrote: I think that you will find that you have most of them already.
Yes, only issue #456 (which includes the fix and is already in PharoInbox) needs to be included. I guess there are no or very few overrides left.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Feb 16, 2009 at 8:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
sorry you lost me on this one.
Do not take care of KernelExtensions. It's not needed anymore to load Sake/Packages and LPF into Pharo. Start by integrating issue #456 on PharoInbox. -- Damien Cassou http://damiencassou.seasidehosting.st
The point is that the cleanUp and freeSomeSpace extensions are interesting. stef On Feb 17, 2009, at 8:26 AM, Damien Cassou wrote:
On Mon, Feb 16, 2009 at 8:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
sorry you lost me on this one.
Do not take care of KernelExtensions. It's not needed anymore to load Sake/Packages and LPF into Pharo.
Start by integrating issue #456 on PharoInbox.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
The point is that the cleanUp and freeSomeSpace extensions are interesting.
stef
I do not understand how Issue 456: 7272: BlockContext equality test is missing is related to kernel extensions? http://code.google.com/p/pharo/issues/detail?id=204&q=kernel%20extensions&co... Hi list, we (with Stef) are browsing Kernel-Extensions, here are some notes for discussion, as we think there is stuff that should be merged in Pharo. Null and Split-Join could be packaged on their own since they are well-defined features. Most of the cleanup methods make sense, but what's the difference between cleanUp and freeSomeSpace ? AppRegistry class >> removeObsolete "AppRegistry removeObsoleteClasses" self registeredClasses copy do:[:cls| (cls class isObsolete or:[cls isBehavior and:[cls isObsolete]]) ifTrue:[self unregister: cls]]. self subclasses do:[:cls| cls removeObsolete]. Behavior class >> flushObsoleteSubclasses "Behavior flushObsoleteSubclasses" ObsoleteSubclasses finalizeValues. Behavior >> sourceMatchesBytecodeAt: Class class >> freeSomeSpace "Fix some problems with classes. Use Smalltalk allClassesDo: since it does not use the subclass list, which we may be modifying during this iteration" Smalltalk allClassesDo: [:ea | ea fixObsoleteSuperclass. ea removeDuplicateSubclassEntries] Collection >> contains: should probably be standardized as part of the STEPS project Collection >> reject:thenDo: and select:thenDo: should be included and similar enumerations reimplemented in this way too SystemDictionary >> forgetClass: aClass logged: aBool badly named but interesting "Delete the class, aClass, from the system. Note that this doesn't do everything required to dispose of a class - to do that use Class>>removeFromSystem." aBool ifTrue: [SystemChangeNotifier uniqueInstance classRemoved: aClass fromCategory: aClass category]. SystemOrganization removeElement: aClass name. self removeFromStartUpList: aClass. self removeFromShutDownList: aClass. self removeKey: aClass name ifAbsent: []. DataStream classRemoved: aClass. self flushClassNameCache SystemDictionary >> globals needs to pay attention that compiled methods share the associations Number >> to: stop do: aBlock displayingProgress: aString would be probably nicer with the block argument last === To discuss: Collection >> removeAll: comment should explain in which cases it is useful "the slow way" ^ self removeAllSuchThat: [ :each | true ] SequenceableCollection >> <= smells funny⦠what is it useful for ? SequenceableCollection >> replacing:with: replaces in place, not obvious from the name the stream methods like putOn: ⦠convenience ? are they coherent ? String >> withoutTrailing: probably makes sense but then this is mostly useful for line breaks⦠why not a #trimLinebreak Set >> likeOrAdd: ok but then that should be available for any collection (and renamed addIfAbsent:) "Include newObject as one of the receiver's elements, but only if not already present. Answer the oldObject." === Useless: ProtoObject >> iconOrThumbnailOfSize: Object >> askFor: and askFor:ifDefault: that's a workaround Object >> deprecated is already here Object >> log should be packaged in a logging package since it's a convenience method SequenceableCollection >> copyReplacing:with: just to type one space less ?
Squeaksource SqueakMap/Universes Sake/Packages Monticello 1, 1.5, 2?
It gets even murkier :) I have now just stumbled on SourceTalk as being the "new" SqueakSource? Is Pharo Smalltalk actually planning to use Monticello 1 or 2? What is Pharo Smalltalk's view of SourceTalk? Why not "use" SourceTalk for Pharo Smalltalk? -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p234... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sourcetalk is for MC20 and this is too early. Trust us. There are plenty of things to help now. and once it will be ready we will use it. Stef On Feb 18, 2009, at 3:22 AM, Geert wrote:
Squeaksource SqueakMap/Universes Sake/Packages Monticello 1, 1.5, 2?
It gets even murkier :)
I have now just stumbled on SourceTalk as being the "new" SqueakSource? Is Pharo Smalltalk actually planning to use Monticello 1 or 2? What is Pharo Smalltalk's view of SourceTalk? Why not "use" SourceTalk for Pharo Smalltalk? -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p234... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
As you can see I am still finding my feet here :) Amazing though, that during my research I didn't come across http://squeaksource.com squeaksource.com myself. I actually had come across SqueakSource some time ago when I started to look at Squeak.
So, am I correct in assuming that SqueakSource was intended to replace SqueakMap and Package Universe then? Since Pharo is a fork of Squeak, wouldn't it need some sort of Pharo specific repositories or would all SqueakSource repositories continue to work on Pharo? The whole SqueakMap, Package Universe, SqueakSource and Monticello is very confusing. SqueakSource doesn't really look as inviting as Github either ... I did see there is a SqueakSource 2 project though.
It is all rather confusing but all these things seem to have different goals. From what I gather it's something like this... - SqueakMap: Meant as a distribution point for sharing published code in any format for any version of Squeak. The downside is it doesn't handle dependencies and is for sharing releasable versions, it's not a source code repository meant for development like squeaksource. The expectation is that if you see something in SqueakMap, it might work, it might not, it might with a bit of hacking and careful manual checking of possible dependencies. Was around before Monticello when people were still slinging sars and change sets for sharing code. SqueakMap is not meant to be a package manager, just a global single place to find all things squeak. - Package Universe: Seems to have been intended to be a version specific repository of packages and dependencies that are known to work in that particular version of Squeak. The expectation is that if you see something in Universe, it should work and will install any necessary dependencies. While this isn't always the case, most stuff seems to work pretty well. Admittedly, there's some overlap with SqueakMap here but it's really meant to be more like a package manager for your squeak image. It's comparable to apt-get or aptitude in Debian. - Monticello: Distributed version control and now the main format most squeakers share code in. Packages can be shared via package universe, squeakmap, and squeaksource. - SqueakSource: A public repository for the community to open and host Monticello projects. Of course, anyone can host their own such repositories as well and some do, but many big projects are on SqueakSource. Through here you be find the latest development versions, commit by commit, whether it's been released or not and can join and contribute code to these projects. You might have installed your software from squeakmap or package universe initially, but it's here you'll keep much of it up to date with the latest versions or find the latest bug fixes. Of course SqueakSource isn't as inviting as github, it has a vastly smaller community and mindshare than git and that's not going to change any time soon. Though we Smalltalk'ers keep hoping, Smalltalk still hasn't taken over the world and probably never will. As for Pharo and whether Squeak code from those places will work on Pharo, for now, yes, most of it does; however, as Pharo continues to grow and differentiate itself from Squeak, eventually it'll have to be considered a separate platform that is no longer Squeak compatible. That is rather the point, it just so happens the fork is recent enough that it's still basically Squeak 3.9 but that won't last forever. Pharo is not Squeak, so it'll be interesting to see how much of the community it captures and it all unfolds. Me, I'm just a working programmer and this is all just my opinion, but that's how it all looks to me. Squeak paid my bills, Pharo is replacing it. Good riddance to the silly mouse, name, and look, and hello to a serious business oriented open source Smalltalk that I'm not embarrassed to mention to clients. Ramon Leon http://onsmalltalk.com
As for Pharo and whether Squeak code from those places will work on Pharo, for now, yes, most of it does; however, as Pharo continues to grow and differentiate itself from Squeak, eventually it'll have to be considered a separate platform that is no longer Squeak compatible. That is rather the point, it just so happens the fork is recent enough that it's still basically Squeak 3.9 but that won't last forever. Pharo is not Squeak, so it'll be interesting to see how much of the community it captures and it all unfolds.
We will see but our goal is not to captures people :) Our goal is to open a free space for good, clean and robust software. I would love to see all kind of software running on top of pharo - education - web - new languages the real problem with squeak was that we got stuck in death kiss with the past. I like experiment made by people but experiment should be either cleaned, used, maintained... or belong to the past.
Me, I'm just a working programmer and this is all just my opinion, but that's how it all looks to me. Squeak paid my bills, Pharo is replacing it. Good riddance to the silly mouse, name, and look, and hello to a serious business oriented open source Smalltalk that I'm not embarrassed to mention to clients.
Yes the look, the look and the look. :) Money is not evil and I have been thinking that it would be great if we could build a community of companies that could offer Pharo enhancements (kind of support but in a bounty way). For now we should get 1.0 out of the door but after that this would be the time to think about that. Stef
We will see but our goal is not to captures people :)
It might not be, but it's what will happen. It's going to be much easier to do business with Pharo with a strait face.
Our goal is to open a free space for good, clean and robust software. I would love to see all kind of software running on top of pharo - education - web - new languages
the real problem with squeak was that we got stuck in death kiss with the past.
Agree, which is why I'm glad you guys started Pharo. Ramon Leon http://onsmalltalk.com
On Feb 13, 2009, at 5:18 PM, Ramon Leon wrote:
We will see but our goal is not to captures people :)
It might not be, but it's what will happen.
yes :) probably but I wanted to make sure people know that this is not our intention :)
It's going to be much easier to do business with Pharo with a strait face.
This is the goal
the real problem with squeak was that we got stuck in death kiss with the past.
Agree, which is why I'm glad you guys started Pharo.
Thanks ramon. I hope that we will build great software on top of it. I'm dreaming about better tools and supporting changes we have in mind. Stef
Of course SqueakSource isn't as inviting as github,
In two minutes you have an account and project you can share. Now geert when you publish with MC you always get a copy of the package on your disc so what I do is to always develop in the same folder so that all the packages goes into my package cache which I never empty this way I have a copy of what I'm doing on my disc. Now it should be simple to automatically publish the local folder to the net in case you were only locally working.
it has a vastly smaller community and mindshare than git and that's not going to change any time soon. Though we Smalltalk'ers keep hoping, Smalltalk still hasn't taken over the world and probably never will.
participants (5)
-
Damien Cassou -
Geert -
Keith Hodges -
Ramon Leon -
Stéphane Ducasse