cg@cdegroot.com (Cees de Groot) wrote:
Doug Way dway@riskmetrics.com said:
I suppose what we're talking about here is not just a "harvesting" process, but a process for figuring out what goes into Squeak, including larger contributions from the Guides, SqC, etc. I guess we could still use the term "harvesting" to cover all base-Squeak development? And we also have to consider package-level harvesting as the image gets split up into packages.
'Harvesting' implies 'adding'. As far as I'm concerned, it should be a 'stripping' process for the time to come, and then an 'updating/bugfixing' process. So even if the infrastructure stays the same, maybe it should be renamed post-3.5 to something which implies less bloat-orientation ;-).
Well, the new tool will be package aware so it will not only handle FIXes to the image. Thus harvesting is still an ok term IMHO. But I agree of course about what you mean.
OBTW: I'm going to try to port Squeak to Posix (command line, that is). I'll probably fail due to lack of time, but in the light of the whole modular Squeak discussion it does act as a sort of minimum Squeak reference point - just the VM and a minimal RTL. How small should the smallest module be? This small? (which would make a 'core Squeak' distribution already a collection of modules - 'kernel Squeak' plus user interface, primitives for sound/multimedia, etcetera). Not really relevant to the current discussion (except maybe for the infrastructure needed), it just popped up :)
Talk with Andreas and Dan - they have already done stuff in this direction if I am not mistaken. On the other hand I haven't heard anything about their progress so perhaps it has been abandoned. Dan said he would post his minimal image but I never saw it, sigh...
regards, Göran