RE: [Modules] Unloading and Conflicting VersionsThere's very little info on
Agora under www.edugraf.ufsc.br somewhere (the link is probably down,
there's a big university strike going on these days)

There's an article we submitted & presented at a workshop at ECOOP'94 I
think (Bologna, Italy). I may be able to find it in some backup I have.

I remember sending a hardcopy of the Lindatalk and the Agora papers to Alan
Kay back in 95, when I was trying to get him to talk at a conference on
Educational Software in Brazil (unfortunately that didn't work <grin>). So,
I must have the ps file somewhere, I will check.

Considering any object as a tuple works too, you just need to customize the
TupleSpace/#match: I guess, possibly by subclassing. As I said, the
possibilities are many, it all depends on your goals :-)

We implemented our own serialization stuff, called SaveLoad back then. It
was student-quality code, though. Little did I know back then that I'd be
working on serialization stuff again in the future :-(  but that's another
story

Networking on Smalltalk/V 286 meant C & packet drivers back then. Mostly a
waste of time. That's when we started small-winsock to have a free interface
to winsock back then (started to move to ST/V Win).

Too bad we had to do so much plumbing when all we wanted was to play more
with the educational, construtivism stuff <sigh>.

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 22, 2001 12:48 PM
  To: 'squeak-dev at lists.squeakfoundation.org'
  Subject: RE: LindaTalk


  Exactly right...I have been enamoured with researching it's capabilities,
to a certain extent (parser, unification, trellis).  However, the primary
reason I picked it up was to use as a distributed communications mechanism,
with Store-and-Forward and arbitrary message structures supporting pattern
matching.  Do you have a link to Agora?  The ability to match based on
content is a powerful enabler for quickly prototyping communications
mechanisms and protocols.  I wanted it to be eventful, so a client could
register callbacks.  It should also be asynchronous, to support concurrency.
Finally, I am interested in it being remote, thus requiring object
serialization.  It supports all but the last at this time.

  The new EventTupleSpace is much more KISS, although depending on an async
messaging implementation.  it will take this weekend to dig it out and
finish the latest refactoring.

  - Rob

  PS.  the most incredible realization, that John Sarkala mentioned to me,
was that every object in the squeak environment is a tuple with a particular
arity.   Would it be possible to implement an Interpreter and ObjectMemory
using a TupleSpace?
    -----Original Message-----
    From: Marcio Marchini [mailto:mqm at magma.ca]
    Sent: Wednesday, August 22, 2001 11:47 AM
    To: squeak-dev at lists.squeakfoundation.org
    Subject: RE: LindaTalk



    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/e59a8ecf/attachment.htm