RE: [Modules] Unloading and Conflicting VersionsIt's nice to see LindaTalk
surviving all these years, in one way or another... :-)

Hopefully I'll get around to doing more Squeak from now on, we'll see. I'll
then take a look at it ;-)

Keep up the good work !!

marcio
  -----Original Message-----
  From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Withers,
Robert
  Sent: August 21, 2001 10:41 PM
  To: 'squeak-dev at lists.squeakfoundation.org'
  Subject: RE: [Modules] Unloading and Conflicting Versions


  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

    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]
      > 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/20010822/b67f963c/attachment.htm