[squeak-dev] Re: [Pharo-project] cant squeak map

Andreas Raab andreas.raab at gmx.de
Thu Mar 12 14:50:44 UTC 2009


Hi -

Just for the record, the primary reason why I like SM is that stuff in 
SM is findable. In other words, I recently needed a copy of some older 
code that I had written. Googling it:

http://www.google.com/search?q=squeak+mapiclient

SM came out on top. The trouble with all the other solutions is that 
they are not findable. Which means that for all practical purposes the 
stuff in Squeaksource and Universes might as well not exist.

Cheers,
   - Andreas

Göran Krampe wrote:
> Hi!
> 
> (being the creator of SM I can't resist this thread on Pharo-list...)
> 
> Yes, I am cross-posting, so sue me.
> 
> Stéphane Ducasse wrote:
>> Yes yes  yes but we do not use SM since years.
>> I cannot load one single package without breaking my image.
>> If you read the comments of a package you should not load it because  
>> most
>> of the time people entered that the code may work.
>> Then the version identification is often obsolete.
> 
> The above is not really a problem with SM "as a tool" but with the 
> contents of SM. And as I predicted a few years back, SS (Squeaksource) 
> and PU (package universes) are indeed competing with SM and would (as it 
> did) cause us to get a fragmentation. I am not blaiming anyone, but I do 
> see that as the primary cause of "data rot".
> 
> Since a lot of projects use SCM hosting as available on SS they don't 
> bother taking the extra step in keeping entries at SM fresh. 
> Understandable but still a pity we couldn't create some harmony there.
> 
> PU was a clear "fork" of SM (not the codebase but the use case) adding 
> dependencies. I still think it was sad that people couldn't instead help 
> out in SM making it better.
> 
>> So you may be able to load SM in pharo but we will not use it as a 
>> way  to manage code.
> 
> Ehm... SM was never meant to "manage code". It is not an SCM.
> 
>> Sorry guys. clean SM first if you want it to be a credible alternative.
> 
> This last line is... odd. What do you mean with "guys"? And why do you 
> think "cleaning it" would solve something? I am not saying that cleaning 
> is not needed - just saying that cleaning is not solving the real 
> problem. We can't seriously tell people to maintain their packages in 3 
> different places (SS, PU, SM) IMHO.
> 
> I am interested in creating a new SM3 that can replace both PU and SM 
> and that plays very well with SS installations (there are more than one 
> even though squeaksource.com is the most important one) and can use 
> Deltastreams. By "replace" I mean that SM3 of course should simply 
> replace current SM but also that it could possibly "auto mirror" 
> packages from SS installations making them available on SM3 *without any 
> extra effort at all*. If SM3 also covers the functionality that PU has 
> (dependencies etc) then perhaps we could migrate over to it from PU. Or 
> again, we could make SM3 be able to "auto mirror" PUs, but that would be 
> less optimal I think.
> 
> Yes, I am picking up Deltastreams, have fixed lots of broken tests over 
> the last few days and have read up on Matthew's code. I think DS is a 
> really promising technology that can open up new nice tools, and still 
> not compete head on with MC/MC2. Instead it should hopefully replace 
> changesets and form a nice complement to MC/MC2.
> 
> Finally, I have always felt that SM should work in as many Squeak images 
> as possible - and Pharo is one of them of course. I don't care if Pharo 
> decides to not have SM as a "first class" citizen - as long as it can be 
> loaded into Pharo, and I will try to help out with ensuring that it can 
> - hopefully that is an effort that Pharo developers appreciate. (?)
> 
> regards, Göran
> 
> 
> 




More information about the Squeak-dev mailing list