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 <mailto:mqm at magma.ca>  
To: squeak-dev at lists.squeakfoundation.org
<mailto: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>
[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
<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/20010822/881edb6f/attachment.htm