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