How to improve Squeak
Brad Fuller
brad at sonaural.com
Sun Jul 11 18:47:43 UTC 2004
Hi all,
What is the criteria and approval process of being in the base image?
brad
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
> Behalf Of goran.krampe at bluefish.se
> Sent: Sunday, July 11, 2004 8:59 AM
> To: The general-purpose Squeak developers list
> Subject: Re: How to improve Squeak
>
> Hi all!
>
> Marcus Denker <denker at iam.unibe.ch> wrote:
> > Am 11.07.2004 um 15:45 schrieb David T. Lewis:
> > > On Sun, Jul 11, 2004 at 11:55:56AM +0200, stéphane ducasse wrote:
> [SNIP]
> > > Personally, I don't mind having some incomplete or
> unfinished things
> > > in Squeak. Many of them show good ideas and things that could be
> > > brought to completion in the future.
> > >
> > But there's a lot of stuff that will never be completed
> because it was
> > "officially"
> > abandoned. e.g. the "Squeak Server Pages" are, es much as I
> know, an
> > experiment that was superseded by Projects.
>
> I agree with Marcus and also, experiments are better made in
> a separate package. Then they don't bother anyone and can
> "rot" in peace. :)
>
> Having loose nobody-really-knows-if-it-works-half-rotten-half-finished
> stuff in the base image is simply not good.
>
> > So while I'm personally very much pro experiments (and I'd
> like to see
> > a Squeak that makes real deep experimentation even simpler), the
> > situation we have now has realy gotten out of hand...
> >
> > The Number one Principle of a System made for
> Experimentation: Make it
> > easy to throw stuff away. It's an interesting view of Modularity: A
> > modular system not only allows for easy composition, but
> should make
> > decomposition easy, too.
>
> Yes, and we shouldn't be so scared of touching these things.
> Either we:
>
> 1. Cut it out and put it in a package. It doesn't even have to work.
> This option is nice if it isn't too tangled up.
>
> 2. Delete it. Remember, there are always old images and old
> VM to pick up and look inside if someone wants to salvage it
> in the future.
>
>
> > For the Kernel, we have KCP (I hope to be able to actively
> contribute
> > to that). For Morphic, there once was MCP, but the state of
> Morhpic is
> > so bad that I guess only "thow it away" will work...
> >
> > One question is how to make sure that something like that does not
> > happen in the future again... for the ObjectMemory, we have an
> > automatic garbadge collector.
>
> Well, best is if experimental stuff are in external packages.
> Then they can be marked clearly as half finisihed
> experimental stuff etc. And there is a maintainer, and we can
> see when it last worked etc.
>
> > I think a Team doing experimental work would need to model
> a "garbage
> > collector"
> > in their process. Either distributed among team members or
> one person
> > responsible for cleaning up. No nice job... but it needs to be done.
> >
> > Marcus
>
> Sidenote: There are a multitude of cool things piling up on
> SM that we need to consider if we want to "bless" as being
> part of the official package pool. A good example is Shout -
> it is so DAMN good it should be an official package IMHO. :)
> And it should be in Basic.
>
> Now, what we can do is to simply agree on this - the
> maintainer must be in on it of course - and then Doug can
> simply put out an update loading it. Voila.
>
> Now, of course - 3.7 is close at hand so I propose we take a
> look at these things in the beginning of 3.8. Removals and additions.
>
> regards, Göran
>
>
>
More information about the Squeak-dev
mailing list
|