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