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