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?

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 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.

Geert 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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?

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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 :)

> 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.zip

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sat, Feb 14, 2009 at 12:17 PM, Keith Hodges <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

sorry you lost me on this one.

Stef

On Feb 16, 2009, at 10:30 AM, Damien Cassou wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Mon, Feb 16, 2009 at 8:22 PM, Stéphane Ducasse
<[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

The point is that the cleanUp and freeSomeSpace extensions are  
interesting.

stef

On Feb 17, 2009, at 8:26 AM, Damien Cassou wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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&colspec=ID%20Type%20Status%20Summary


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 ?



_______________________________________________
Pharo-project mailing list
[hidden email]
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
>  
http://bugs.squeak.org/view.php?id=7244

Keith

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project