[Modules] Unloading and Conflicting Versions
Withers, Robert
rwithers at quallaby.com
Wed Aug 22 02:40:54 UTC 2001
That's where I saw it. Thanks, Marcio. By the way, did you notice that
LindaTalk is on the new Squeak CD? I have many changes to it, mainly the
EventTupleSpace and recursive tuple matching, but it isn't quite ready. I
can send it to you if you would like.
cheers,
Rob
-----Original Message-----
From: Marcio Marchini [mailto:marcio at bedarra.com]
Sent: Tuesday, August 21, 2001 2:55 PM
To: Withers, Robert; squeak-dev at lists.squeakfoundation.org
Cc: modsqueak at bluefish.se
Subject: RE: [Modules] Unloading and Conflicting Versions
http://swiki.squeakfoundation.org/squeakfoundation/31
<http://swiki.squeakfoundation.org/squeakfoundation/31>
marcio
-----Original Message-----
From: Withers, Robert [mailto:rwithers at quallaby.com]
Sent: August 21, 2001 2:21 PM
To: 'squeak-dev at lists.squeakfoundation.org'
Cc: modsqueak at bluefish.se
Subject: RE: [Modules] Unloading and Conflicting Versions
Dave, could you please repost these links? I couldn't find them in the
squeak ML archives.
thank you,
Rob
> -----Original Message-----
> From: Dave [ mailto:dave at bedarra.com <mailto:dave at bedarra.com> ]
> Sent: Monday, August 20, 2001 9:06 PM
> To: Les Tyrrell
> Cc: squeak-dev at lists.squeakfoundation.org; modsqueak at bluefish.se
> Subject: Re: [Modules] Unloading and Conflicting Versions
>
>
>
>
> 1. The mechanism for unloading is indeed a good deal more complex than
> loading and was one of the throny problems OTI had to address in
> building embedded Smalltalk and Java.
>
> Perhaps the issue of unloading is something to be deferred until after
> the basic module and component mechanisms are defined and tested?
>
> 2. To my knowledge the only existing system that supports current
> execution of multiple versions classes/methods is MS.NET with their
> assemblies. This itself gets problematic however if you want to run
> shared assemblies. I posted the references earlier for those
> interested
> in the problem.
>
> Regards,
> Dave
>
>
> Les Tyrrell wrote:
> >
> > ----- Original Message -----
> > From: Dan Moniz <dnm at pobox.com>
> > > I'm imagining that when you file in a ChangeSet (let's
> say Foo.cs)
> > > into your image (Bar.image), your image is writing out
> information to
> > > it's Bar.changes file that reflect the things Foo.cs is
> doing to your
> > > image. Then, to back out, you could use a currently
> fictional "Undo"
> > > feature which would allow you to back up steps as recorded in
> > > Bar.changes
> >
> > There are a few things that would need to be done when
> unloading a module. For
> > one, you would like a rapid way of gc'ing or otherwise
> mutating any instances
> > defined by that module. Then, you will want a rapid way of
> removing the
> > definitions found in that module. ChangeSets are no
> better, and no worse, at
> > doing this than any other scheme. There is no need to
> iterate over a change
> > log- the ChangeSet already has an accounting of what it has
> modified. So would
> > an OasisModule, or a Collage Layer.
> >
> > However, while associating a ChangeSet with either a
> Collage Layer or an
> > OasisModule seems reasonable to me, trying to warp
> ChangeSet into becoming more
> > like these things does not seem reasonable.
> >
> > > This may necessitate modifications to userland tools to
> deal with
> > > .changes file, and perhaps some modification to the information
> > > and/or format of information stored in .changes files,
> but I don't
> > > think it would be too drastic and I don't think it
> would have much
> > > with the implementation of ChangeSets themselves.
> >
> > What's wrong with the idea of implementing the roles of a
> Components and
> > Modules? In Oasis, a Module is a component that keeps
> track of Shared Globals,
> > Undeclared variables, Pools, and a few other things.
> ChangeSets don't do this.
> >
> > The role of a changeset is to keep track of changes... the
> role of an
> > OasisModule is to act as a place in which those changes
> take effect. These are
> > separate roles, so I would not reccomend mixing them.
> ChangeSets are just fine
> > the way they are, at least in the sense of the scoping of
> their responsibilities
> > to tracking changes, and no more.
> >
> > Using ChangeSets as a means of identifying chunks of code
> to turn into a package
> > is another issue, as far as I know there is nothing wrong with that.
> >
> > - les
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010821/f23d9212/attachment.htm
More information about the Squeak-dev
mailing list
|