record & play of probe events

[glen e. p. ropella]

OK.  I've done a minimal amount of thinking about this.  But, I'm
going to post my thoughts, anyway. [grin]

First, it's helpful to back up and think about what probes are for
(which means that this discussion probably belongs on the
swarm-modelling list).  When I first got here, I assumed that probes
were a mechanism for data flow from any object to any other object.
So, I saw the current implementation as hopelessly incomplete.  Part
of the reason I thought that way was our general thrust that reads
"Anything a human can do, a software agent can do, and vice versa."
This thrust led me to believe that agents should be able to "probe"
other agents, which led me to believe that probes should really be
more general data-flow objects specifiable as pipes, queues, buffers,
etc.

I call this the *data-flow* model of probes.

Roger and Chris talked me out of this model of how probes should work
by telling me that probes were originally intended as a way of
*violating* the "objecthood" of an object and getting/changing the
state of an object (as well as providing a way for the User agent (UA)
to call methods on the object).  This way of thinking about probes
seems to partially fulfill both the "probes as a violation" objective
and the "Anything a human can do ..." thrust.  But, for now, I'm going
to focus on the "probes as a violation" part of this model.

I'll call this one the *state accessibility* model of probes.

So, the point I'm trying to get at is:  What are probes for?

Working under the data-flow model, a probe is responsible for
providing a communications channel between any two objects.  (Never
mind that a "channel" must consist of a bi-directional probe or 2
probes, one in each direction.)  Whether these are file objects,
software agents (SWA), or UAs, is irrelevant.

Working under the state accessibility model, a probe is simply a way
to violate the objectified software so that a UA can tweak the state
and initiate unscheduled methods.  This is nothing more than
"interactibility".  And Swarm depends on this for its larger thrust
"To build simulations as intuition building tools."

In the latter case, using probes as a fundamental part of the
simulation doesn't really fit.  There might be a way to force it to
fit by saying that probes are really a part of the ObserverSwarm
machinery, and, thereby, rate full applicability.  But, this still
implies that any agent should be capable of opening up an
"objecthood-violating" probe on any object or any other agent for
which it has the class information.  And if we're giving them this
ability, we should be explicit about what kind of agents have that
ability and what kinds don't.


So, anyway, now that I've gotten that off my chest... [grin]

I see 2 problems of possible relevance to the record&play of probe
events (or GUI events, in general.... I mean, why shouldn't pauses,
steps, continues, blt events, and raster manipulation be considered as
well?):

  1) Given that you've recorded (or pre-scripted) a list of probe
events and now want to play them back, Rick suggested they get played
back based on time.  Unfortunately, time is not necessarily a good
measure for when an event should occur.  For a time-driven trace of
probe events to be "valid" in the context of a given simulation, the
simulation must have been started with the same random seeds with
which the simulation was started when the events were logged.
Otherwise, one could be instigating probe events for objects that
might have gone away or somesuch.

Hence, I don't think time is the best way to handle the indexing into
the series of probe events.  (It may be the only possible one or the
only practical one... But, it doesn't seem like a good one.)

Also, it seems philosophically unpleasant simply because the event
trace for probes (and for the rest of the GUI) is totally disconnected
from the action trace for the simulation.  This makes it hard to
justify forcing an artificial connection when either event trace is
replayed.

  2) There could be a problem (or just a confusion) between replaying
probe events and retaining the capability of accepting new probe
events during that replay.  This is very minor compared to #1; but,
unless we completely cut off the interactive probe feature during a
replay, the actions of the *present* UA could invalidate an action in
the probe trace being replayed.  This would obviously lead to problems
like that mentioned in #1.

A possible solution to this one is to simply force *no* interaction
with the sim during a replay.  This is not really a problem, since it
seems natural to distinguish between "play" mode and "record" mode.
It would only become a problem to those who are use to working in
recording studios and have worked with something like sound waves
where superposition applies. [grin]

  ===============================================================

Now, all this is an attempt to address the motivation for putting this
record & replay functionality into the probe code.  It doesn't answer
any technical details.  As far as Rick's suggestion goes, if we adopt
the "state accessibility" model for probes and assume that there are
SWAs that have the right to vivisect their brethren, then the way he
proposes recording the events seems as good as any, to me.  But, I
think we could come up with a more Swarm-y way to do this if we back
up into discussion of the larger issues.  [whew!]


Furthermore, [grin] in answer to Sven's question: "how do you schedule
a message to an object (agent) who hasn't been created yet (but
presumably will exist by the time the message is to be delivered?"

Rick's answer is a good one.  But, Roger mentioned that one can do
things in a more general way by writing a function that executes a
method on a given object (where that object may not yet exist) and
then put the call for that function on the schedule with a
   [bobActionGroup createActionCall: (func_t) functionXYZ];

So, since the process of science is to generate more questions when
trying to answer any one question, I think I'll stop here, eh?  Any
thoughts?

glen
-- 
{glen e. p. ropella <address@hidden> |  Send lawyers, guns, and money!  }
{Hive Drone, SFI Swarm Project         |            Hail Eris!            }
{http://www.trail.com/~gepr/home.html  |               =><=               }


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================