[squeak-dev] Stuff

keith keith_hodges at yahoo.co.uk
Tue Dec 15 23:48:52 UTC 2009


I have re-subscribed to squeak-dev in order to answer a few points I  
have seen on the list via nabble.

Points to answer...

1. Colin seams to think that he needed to develop Mason because Bob  
requires the building code, i.e. Sake to be in the image being built.

This is WRONG, Bob starts from the premise that the build image can be  
ANY image with no dependencies at all. This is necessary because the  
release teams usually cant even be bothered to produce images with the  
latest tools in, so any hope of any release image having an up to date  
Installer or sake in it is negligible. Given that Bob's goal has  
always been to facilitate the building of minimal and kernel images,  
how on earth do you get the idea that Bob needs Sake in the target  
image?

That is what Bob was designed to do. The only requirement that Bob has  
of the image is that the image can be launched from the command line  
and be supplied with a script. Bob is an image, a server that monitors  
what needs doing and invokes builds and tests. Bob uses Sake  
internally do define a hierarchy of build tasks, with dependencies. Oh  
look thats what Mason's description is, what a surprise. Tell me I  
wasn't wasting my time... oh yes I was, silly me.

So basically Colin admits that he didn't even look at Bob before  
writing Mason. This is precisely the same "Not invented Here" approach  
that I spent so long arguing against in the Pharo camp. This is why I  
have left the squeak community.

2. Andreas starts talking about package management being needed.

Welcome to the programme, only two years behind the rest of us.

I notice you cant even be bothered to recall that Sake/Packages  
exists, and has been working for a long period of time, developed  
precisely because the issue of getting things to work with  
dependencies is the number one issue that needs addressing for Squeak  
to be of any use to anyone for anything. Trunk developers can faff  
around with the image all they like but it doesnt fix ANY of squeak  
problems at all, since squeaks problems are all int he usability of  
its packages.

Don't even get me started on Metacello, more not invented here.

3. Someone said Sake/Packages is no good because its not supported on  
Gemstone.

Sake/Packages was designed to be trivial to port to any platform from  
the outset, unlike any other code e.g. Monticello. So that point is  
completely wrong. It doesnt have any dependencies on the tools used  
for loading things either.

Sake/Packages would be the ideal fit for a cross platform package  
manager, since it's content is user maintained rather than publisher  
maintained and those doing ports tend to be the users.

cya

Keith




More information about the Squeak-dev mailing list