RE: [Modules] Unloading and Conflicting VersionsYes, it has been educational for me.  I initially tore it apart pretty badly, then went back and only changed just a few things.  The match: algorithm and added a collection api.  The new EventTupleSpace, which is not in the version on the CD, uses an async message sending mechanism to generate events during access (read, take, write, scan).

I looked briefly at unification, in Lisp, to attempt to bring this to LindaTalk, but I quickly ran out of steam.  Another idea was expressed where we can use a TupleSpace as a parser, adding token rules and grammar productions, then streaming input into the space.  I believe it would just act as a state machine, where matches for particular productions would transition the parser state, allowing other productions to be matched.  I was to the point where I thought there might be a context tuple, which contains the current state,  and it would be taken, modified, then written, by the productions (eval actions).  It's complicated!

Welcome home!  ;-)

Rob
  ----- Original Message ----- 
  From: Marcio Marchini 
  To: squeak-dev at lists.squeakfoundation.org 
  Sent: Wednesday, August 22, 2001 1:02 AM
  Subject: RE: [Modules] Unloading and Conflicting Versions


  It'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/536ec19c/attachment.htm