swarm-modeling
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: record & play of probe events


From: Steven Clark
Subject: RE: record & play of probe events
Date: Tue, 3 Jun 1997 13:17:26 -0400

>  -----Original Message-----
> From: glen e. p. ropella [SMTP:address@hidden
> Sent: Monday, June 02, 1997 7:59 PM
> To:   address@hidden
> Subject:      record & play of probe events
> 
> [Steven Clark]  I'm in a good mood today.  Insert [grin]s liberally
> throughout my comments.
> 
> 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."
> 
> [Steven Clark]  Yes!  Sometimes the real world of:
> *     developers needing to debug their code,
> *     simulation writers needing to understand their simulations, and
> *     in general human beings needing to get their work done
> interferes with an idealized object-oriented universe.
> 
> Analysis comes from Greek "to take apart".  We couldn't analyze our
> Swarm simulations if we couldn't open them up and see what's inside.
> 
> 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.
> 
> [Steven Clark]  I have no idea what point you're trying to make here.
> Having probes for humans to use to analyze simulations has nothing at
> all to do with simulation agents probing each other.  Allowing humans
> to investigate the inner workings of their simulations does not in any
> way imply endorsing or condoning agent behavior that includes
> violation of unconsenting agents.
> 
>   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.)
> 
> [Steven Clark]  It's a good thing you weren't the author of sh, or we
> wouldn't be able to write shell scripts that execute commands based on
> sequence.  After all, the file I plan to read on line 12, that was
> created on line 6, might have been deleted.
> 
> If you need to record a script and play it back, but you need to
> trigger the events in the script by something other than the clock, I
> think it's safe to say that you have an application-specific problem
> that warrants an application-specific solution.  Later, if other
> people encounter similar problems for which a general tool can be
> built, and the time-based script recording and playback mechanisms
> were designed really well (using the best OO methods of course), you
> can extend them to handle your non-time-based scripting.
>  
> 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.
> 
> [Steven Clark]  I suggested that the recording mechanism be set up in
> such a way that the simulation implementor had control over where the
> scripting output went.  I can easily imagine situations where it is
> best kept separate and others where it is best interleaved.  By the
> way, most action traces I have seen are indexed by time, and the
> proposed event trace is also indexed by time.  Two traces both indexed
> by time are not "totally disconnected" - "fairly disconnected" I'll
> agree with, but not "totally". 
> 
>   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.
> 
> [Steven Clark]  OK, so if we allow sh scripts, we have to disallow any
> user input during the execution of a sh script because the user might
> delete that file between lines 6 and 12.
> 
> If I have a question about my simulation run (that involved user
> interaction via probes) and I want to replay it, shouldn't I be able
> to stop it and analyze what's going on?  If I think I see what's going
> on, but I need to change that "3" to a "4" in order to be sure I've
> got it, shouldn't I be able to?  If I tweak something so that an agent
> dies before it receives a scripted message, that's potentially useful
> information and hardly a reason to disallow all tweaking.
> 
> glen
> 
> Steven J. Clark       address@hidden       313-769-4396
> Center for Electronic Commerce, Industrial Technology Institute
> Box 1485, Ann Arbor, MI  48106
> 


                  ==================================
   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.
                  ==================================


reply via email to

[Prev in Thread] Current Thread [Next in Thread]