I always have two squeak images running - (at least) one development
image, and one mail image, with my favorite Celeste goodies and filters
loaded. I don't normally load experimental code into the mail image, to
avoid screwing it up.

Layers/environments, as you say, could theoretically give me this
partitioning of code in the image, but in practice, I screw up my
development images often enough in ways that this doesn't solve
(resources, tight loops without possibility for breaking) that I'd still
prefer to trust the OSes address space protection.

This could change if Squeak moves towards being more robust in the face
of bugs. I think this is a good direction, and definitely possible. For
example, it would be nice to be able to log into an image that's
misbehaving from telnet, for example, with a high priority prompt, to
kill off obnoxious processes.

On a related topic, comparing two pieces of code doesn't require this
kind of protection. I disagree with Anthony's argument that having
everything be classes is better than having two concepts. From a code
management perspective, I want to have generalized tools that allow me
to compare many versions of code, from various sources (the current SM
version, the current version in the image, all the revisions I have in
my monticello repository/changeset directory), without all of them being
(even potentially) active. I might want to browse another image code
without even loading a whole logical "layer" - just peeking at pieces.
"What I can look at" and "what I might be running" are better off
separate.

Daniel

Joshua 'Schwa' Gargus <schwa at cc.gatech.edu> wrote:
> On Wed, Dec 11, 2002 at 04:50:21PM -0500, Brent Vukmer wrote:
> > You replied:
> > >And downloading packages without worry about
> > >conflict.  
> > 
> > If a new image becomes quick-n-easy to build, then conflict becomes no
> > big deal.  Do some quick diagnosis then build afresh! 
> 
> But what if you want to use two packages in your everyday Squeaking, but
> they conflict with each other?  Using two images is not a satisfactory
> solution.
> 
> > Also I would
> > rather diagnose package conflicts here then in a multi-namespace image.
> 
> But there is no conflict in a multi-namespace image, at least in the
> (most important) sense that packages that would stomp on each other in
> (A) would coexist and function properly in (B).
> 
> > >Also, having multiple packages in the image available for
> > >analysis, that would be conflicting in (A) and therefore not both
> > >visible.
> > 
> > I'm trying to imagine a sample scenario where running multiple package
> > releases in the same image would be helpful in development...  
> 
> What about unifying the underlying code of two packages that conflict?
> In (A), you'd have to run each package in a different image as you made
> changes to each so that they would be consistent.  In (B), you wouldn't
> strictly NEED to unify the code, but if you decided to (in the interest
> of elegance and orthogonality), it would certainly be easier within the
> same image, especially since tools could be built to specifically support
> this kind of work.
> 
> <snip>
> 
> Joshua
> 
> > 
> > 
> > Cheers,
> > Brent
> > 
> > 
> > 
> > 
> > 
> >