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@bedarra.com] Sent: Tuesday, August 21, 2001 2:55 PM To: Withers, Robert; squeak-dev@lists.squeakfoundation.org Cc: modsqueak@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@quallaby.com] Sent: August 21, 2001 2:21 PM To: 'squeak-dev@lists.squeakfoundation.org' Cc: modsqueak@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@bedarra.com mailto:dave@bedarra.com ] Sent: Monday, August 20, 2001 9:06 PM To: Les Tyrrell Cc: squeak-dev@lists.squeakfoundation.org; modsqueak@bluefish.se Subject: Re: [Modules] Unloading and Conflicting Versions
- 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?
- 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@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
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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Withers, Robert Sent: August 21, 2001 10:41 PM To: 'squeak-dev@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@bedarra.com] Sent: Tuesday, August 21, 2001 2:55 PM To: Withers, Robert; squeak-dev@lists.squeakfoundation.org Cc: modsqueak@bluefish.se Subject: RE: [Modules] Unloading and Conflicting Versions
http://swiki.squeakfoundation.org/squeakfoundation/31
marcio -----Original Message----- From: Withers, Robert [mailto:rwithers@quallaby.com] Sent: August 21, 2001 2:21 PM To: 'squeak-dev@lists.squeakfoundation.org' Cc: modsqueak@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@bedarra.com] > Sent: Monday, August 20, 2001 9:06 PM > To: Les Tyrrell > Cc: squeak-dev@lists.squeakfoundation.org; modsqueak@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@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 > >
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@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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Withers, Robert Sent: August 21, 2001 10:41 PM To: 'squeak-dev@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@bedarra.com] Sent: Tuesday, August 21, 2001 2:55 PM To: Withers, Robert; squeak-dev@lists.squeakfoundation.org Cc: modsqueak@bluefish.se Subject: RE: [Modules] Unloading and Conflicting Versions
http://swiki.squeakfoundation.org/squeakfoundation/31
marcio -----Original Message----- From: Withers, Robert [mailto:rwithers@quallaby.com] Sent: August 21, 2001 2:21 PM To: 'squeak-dev@lists.squeakfoundation.org' Cc: modsqueak@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@bedarra.com] > Sent: Monday, August 20, 2001 9:06 PM > To: Les Tyrrell > Cc: squeak-dev@lists.squeakfoundation.org; modsqueak@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@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 > >
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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Rob Withers Sent: August 22, 2001 3:30 AM To: squeak-dev@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@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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Withers, Robert Sent: August 21, 2001 10:41 PM To: 'squeak-dev@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@bedarra.com] Sent: Tuesday, August 21, 2001 2:55 PM To: Withers, Robert; squeak-dev@lists.squeakfoundation.org Cc: modsqueak@bluefish.se Subject: RE: [Modules] Unloading and Conflicting Versions
http://swiki.squeakfoundation.org/squeakfoundation/31
marcio -----Original Message----- From: Withers, Robert [mailto:rwithers@quallaby.com] Sent: August 21, 2001 2:21 PM To: 'squeak-dev@lists.squeakfoundation.org' Cc: modsqueak@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@bedarra.com] > Sent: Monday, August 20, 2001 9:06 PM > To: Les Tyrrell > Cc: squeak-dev@lists.squeakfoundation.org; modsqueak@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@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 > >
RE: [Modules] Unloading and Conflicting VersionsMarcio and everyone,
Here is the base LindaTalk code, with some changes since the version in the NuBlue book. Changes from the base version I received from you are:
- Resubclassing of Tuple adn TupleSpace (back and forth some, it may be the original subclassing - Collection api - refactored the matching code to follow the protocol #lindaMatch: and implemented double dispatching to detect the correct combination of args in the matching when a straight equality doesn't succeed. Supports matching of nested tuples.
Let me know if you see something you like or dislike adn let's see where we can take it. This includes understanding how we can use it, because my head starts to hurt when I start thinking about using it as a parser. :)
cheers, Rob
----- Original Message ----- From: Marcio Marchini To: squeak-dev@lists.squeakfoundation.org Sent: Wednesday, August 22, 2001 11:47 AM 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
squeak-dev@lists.squeakfoundation.org