RE: [Modules] Unloading and Conflicting Versions
It's possible to add all sorts of crazy stuff, but I think one has to have a
goal first. Research ? Fun ? Use as a lower layer of something else ? etc

In my case, I wanted to use it as a base to program actors/agents. I wanted
a different form of communication instead of pure message passing. We used
it to build Agora, an educational software where games etc could be
prototyped. All implemented on Smalltalk/V 286 with Acumen Widgets, using a
different metaphor for communication, implemented on top of Lindatalk.

So, I guess it's necesary to "have a customer" first, to drive the goals &
features. And, as usual, KISS.

marcio
  -----Original Message-----
  From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Rob Withers
  Sent: August 22, 2001 3:30 AM
  To: squeak-dev at lists.squeakfoundation.org
  Subject: LindaTalk


  Yes, 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/58256616/attachment.htm