At 7:07 PM -0700 7/19/00, Tim Rowledge wrote:
>  > > > > Would it make sense to be able to generate these platform files from
>>  > > > inside of squeak?
>
>I _really_ don't think the proper place for platform files is in the
>image. You can make a reasonable argument for some sort of canonical
>null-platform set to be there, but actual platform files belong outside.
>Now that we are slowly getting the sourceforge operating, that is
>probably the proper place. They're just too big to have multiple copies
>sitting in the changelog.

Er, guys.  Its the Internet age.  The following propositions are not 
inconsistent:

1.  Being able to generate platform files from inside of Squeak
2.  Avoiding having multiple copies of platform files in the image.

Why not have it all?  Put the platform files in CVS, AND write a CVS 
client/cvsup in Smalltalk so you can generate platform files from 
inside of Squeak.

Big up-side.  In the image is a tremendously useful tool, and now an 
individual can generate his files the same old way, except that 
instead of pulling whatever code happened to be associated with the 
image, you get the latest and greatest real sources (unless earlier 
versions are what you are seeking).

Best of all worlds, as I see it, and a fun project for someone to build.

In addition, it will help to make to make non Mac-o-philes fell less 
like second class citizens.  And aesthetically, keeping raw 
C-language source code in the image is kinda ugly.

It does mean that VM hackers will need to learn a little bit about 
CVS, but the Smalltalk CVS environment can make that more palatable 
-- and perhaps a little bit of fun?

Just a thought.

And as long as we are looking at things -- it would be nice to have 
an easily installable "ports collection" (per FreeBSD) of goodies 
that can be independently maintained, so that we don't lose track of 
all the cool stuff that has been made for Squeak.  Wouldn't it be 
great to just say:

	SqueakPorts fileIn: 'rePlugin'

	SqueakPorts list

	SqueakPorts describe: 'rePlugin'

instead of having to do the multistep task of finding the code, 
loading a changeSet, filing it in and praying?  Having such a tool 
might ease up pressures to keep so many tools in the image, might 
take count of dependencies between modules, and might well help us to 
avoid the image bloat.

If such "ports tree" could be made to work reliably and relatively 
seamlessly, it would be feasible to launch a leaner, tighter image, 
while supporting plural forks of solutions to particular problems.

And at the end of the day, you could still have specialized bloated 
images for those without good internet connectivity.

The virtue of modules is about to take this community by storm -- 
let's start building the tools that can make all this happen.
-- 
Andrew C. Greenberg		acg at netwolves.com
V.P. Eng., R&D, 		813.885.2779 (office)
NetWolves Corporation		813.885.2380 (facsimile)
www.netwolves.com

Please use werdna at mucow.com instead of werdna at gate.net