RE: record & replay of probe activity

[Rick Riolo]

Sven
That does indeed sound like a useful facility.

I still really would like to see 'hooks' in things like probes,
especially data entry probes and sim control widgets, 
so that I easily can add custom processing to happen when 
users enter data, press buttons, etc.

re how to send messages to objects that don't exist:
what I have done is assign unique ID's to each object,
so when I record change messages to objects, I include
that ID.   Then on replay, I get the pointer to the object
by looking it up via its ID.

- r

Rick Riolo                       address@hidden
Program for Study of Complex Systems (PSCS)
1061 Randall Lab     University of Michigan
Ann Arbor MI 48109-1120
http://pscs.physics.lsa.umich.edu/PEOPLE/rlr-home.html

On Thu, 29 May 1997, Sven N. Thommesen wrote:

> Date: Thu, 29 May 1997 14:39:23 -0500
> From: Sven N. Thommesen <address@hidden>
> To: address@hidden
> Subject: RE: record & replay of probe activity
> 
> Rick & Steve: 
> 
> I believe we discussed at Swarmfest a concept that went a little beyond
> what you are getting at here: instead of thinking in terms of 'setting a
> variable', think in terms of arbitrary messages being sent to specified
> objects. These messages *may* just alter some variable, or may cause the
> receiver to alter its behavior in a more complex way. Or perhaps it
> triggers a cascade of messages being sent to other objects...
> 
> While much of this can be done using the existing Swarm scheduling
> mechanism (taking input from that saved log file / edited log file / brand
> new script file) -- there's a possible problem: 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) ?
> 
> I strongly support the inclusion of a facility like this in Swarm, because
> it will allow us not only to replay simulations where the operator
> interacted with  the application, but also to create simulations that play
> out a script that represents a possible history of (external?) events.
> 
> Sven Thommesen
> Auburn University
> 
> At 11:45 AM 5/29/97 -0400, you wrote:
> >
> >Steve,
> >I agree there are two functions as you mention,
> >recording what one did and playback of a run including
> >all the changes via gui one did,
> >and that one might use one without the other.
> >(I'm sorry if that wasn't clear in my posting.)
> >
> >I'm not totally comfortable with having the probe
> >do the recording directly, but maybe I can be convinced
> >of the errors of my thinking.
> >My concerns are:
> >
> >1. I like to record all these changes in with the
> >   same file of initialization state *and* with
> >   the data that is produced.
> >   That way I can look at/save one file and have
> >   all I need to see what happened and/or to do the run again.
> >   I'm not sure that can be done cleanly if everything
> >   is turned over to probes.  (eg my report file
> >   will already be an open file, so I'd want to pass a
> >   FILE ptr to the probe, or an equivalent swarm 
> >   output file object.)
> >
> >   Of course I can imagine other people will have a preference
> >   for some other approach, eg, having different files
> >   for initial state, for recording during-run changes,
> >   and for output data.
> > 
> >2. I like having more control over what happens
> >   when I set a variable.
> >   For the recording purposes, I like having control
> >   of the format.
> >   But having a setMyVar: method allows me to do
> >   other things, eg, check the value being set
> >   and conditionally accepting it based on
> >   the values of other variables.
> >   (Of course this can get complicated and not
> >   work in some cases.)
> >   
> >In short, yes, its nice to have Swarm do as much
> >as possible along these lines, so users don't have
> >to do it, where "it" is some standard common approach.
> >
> >But...I still think tools like Probes can also be much
> >more powerful (flexible) if they provide some
> >judiciously placed hooks that allow users to easily
> >add some custom processing.
> >
> >That's why I too like the idea of an setMyVar:
> >method being optionally provided by the user, but if
> >its there, having swarm use it at all the right places
> >(eg in VarProbes).
> >
> >I don't know...maybe I am just furiously agreeing with you!
> >
> > - r
> >
> >Rick Riolo                       address@hidden
> >Program for Study of Complex Systems (PSCS)
> >1061 Randall Lab     University of Michigan
> >Ann Arbor MI 48109-1120
> >http://pscs.physics.lsa.umich.edu/PEOPLE/rlr-home.html
> >
> >On Thu, 29 May 1997, Steven Clark wrote:
> >
> >> Date: Thu, 29 May 1997 11:16:55 -0400
> >> From: Steven Clark <address@hidden>
> >> To: "'address@hidden'" <address@hidden>
> >> Subject: RE: record & replay of probe activity
> >> 
> >> Rick,
> >> 
> >> To incorporate your ideas neatly into Swarm you need Swarm itself to do
> >> all the work.  The design you mentioned requires the object being set to
> >> have a setMethod that records the setting of the IV into a file.  I
> >> suggest that the probe itself record the activity into the file.
> >> 
> >> I agree that things would be cleaner from Swarm's point of view if we
> >> insisted that all probe-settable IVs had setMyVar: methods, but that
> >> would put a burden on the simulation programmer.  I like the idea of
> >> using setMyVar: if it exists, otherwise directly modifying the data of
> >> the object.
> >> 
> >> Back to recording and replaying probe activity, I suggest that you
> >> really want two related, but independent capabilities:  record and
> >> playback.  The record facility would capture all IV settings done via
> >> probes during a run, into a file.  The playback facility would read a
> >> file (of the same format) and schedule all the activities therein to
> >> take place at the appropriate times.  I can imagine situations where one
> >> might want to use either one without the other, or to manually (or
> >> programmatically) edit the file.
> >> 
> >> (I bet that with a fully functional palyback facility we could have
> >> written a script to generate a playback file that would get our "sc01"
> >> simulation into a steady state.)
> >> 
> >> I am suspicious that there were some interesting details in the playback
> >> that you didn't bother to mention in your posting.
> >> 
> >> Steven J. Clark       address@hidden       313-769-4396
> >> Center for Electronic Commerce, Industrial Technology Institute
> >> Box 1485, Ann Arbor, MI  48106
> >> 
> >> 
> >>                   ==================================
> >>    Swarm-Support is for discussion of the technical details of the day
> >>    to day usage of Swarm.  For list administration needs (esp.
> >>    [un]subscribing), please send a message to <address@hidden>
> >>    with "help" in the body of the message.
> >>                   ==================================
> >> 
> >
> >                  ==================================
> >   Swarm-Support is for discussion of the technical details of the day
> >   to day usage of Swarm.  For list administration needs (esp.
> >   [un]subscribing), please send a message to <address@hidden>
> >   with "help" in the body of the message.
> >                  ==================================
> >
> 
>                   ==================================
>    Swarm-Support is for discussion of the technical details of the day
>    to day usage of Swarm.  For list administration needs (esp.
>    [un]subscribing), please send a message to <address@hidden>
>    with "help" in the body of the message.
>                   ==================================
> 

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================