[Modules] a summary of joseph's work

Paul McDonough wnchips at yahoo.com
Tue Sep 4 20:38:46 UTC 2001


--- danielv at netvision.net.il wrote:
> As another Squeaker that was there -
-- As one who wasn't, but is well familiar with the
ModSqueak code base ... and hasn't weighed into this
fine discussion for quite a while ...

[...]
> For the rest, I think what we really need is a
> higher stable starting
> point for various explorations, and the ModSqueak
> work is engineered to
> allow that.
-- quite.

> You want to load two versions of a method at once
> and manage their
> co-existance? ModSqueak won't do it, but it'll raise
> an exception when
> the conflict occurs on loading, and you can catch it
> and play around.
-- there's also the possibility to "load" both
methods, which must be in separate modules, leaving
one module "loaded" but not "installed" whilst
installing the other.  That means both modules are
under ModSqueak's management and can be edited,
versioned, sent to other images, etc.; but one of them
has not been compiled into the current image, and is
thus inactive, and not available to the other Squeak
tools and browsers.  NB:  this feature has not yet
been surfaced into the toolset, and only the rather
determined developer will want to attempt it (yet).

[...]
> Anyway, I think the real issue we should be thinking
> about is "Given a
> good load mechanism, a clean (empty?) base SWT
> image, how does this
> affect the way we work?"
> 
> * Are you going to start working daily in the SWT
> image? 
> * and not use all the tools you're used to (Celeste,
> in my case) but
> aren't part of SWT?
-- ModSqueak is intended to be applicable to stock
Squeak images as well as SWT.  The work to segment out
a different code base into modules would still (I
presume) need to be done.  But it's nothing the
"Ginsu" wouldn't be able to handle (hrm, actually,
isn't Ginsu a registered trademark? well, if they sue
they can only sue for code, right? ;-).

> 	We might need to start separating those out into
> modules we can
> maintain independent of the SqC image.
-- precisely.

> * and not see all the new cool eToy stuff SqC is
> working on?
> * and anyway, if Lex and Daniel do start maintaining
> Celeste in a module
> outside the SqC image, how does this mix in with the
> updates review
> team? 
> * how will I get the bug fixes and tweaks for
> Celeste, if that's not in
> the update stream?
-- I think the end goal (one of them) should be for
ModSqueak to provide its facilities in a robust
enough, and distributed enough, fashion for both SqC
and the rest of us to work in modules.  As long as at
some point along the chain the source code can be
converted to a standard such as SIF, or (later?)
another accepted standard, ModSqueak shouldn't really
care where it came from.  Changesets can easily be
translated into Packages, for example, so it's not
hard to imagine enabling a ModSqueak "server" to talk
to client images in changeset format.  Having that
work robustly ... is a tad more difficult to image.

Just thinkin' out loud really,
Paul

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com




More information about the Squeak-dev mailing list