I agree that aspect-oriented modeling is the right way to go...
The prior checkpointing work is described here:
http://chess.eecs.berkeley.edu/pubs/389.html
and
http://ptolemy.eecs.berkeley.edu/publications/papers/06/incrementalCheckpointing_WSC06/index.htm
Edward
On 1/10/14 10:08 AM, Christopher Brooks wrote:
Ah! I see, I misunderstood.
Yes, it should be possible to use Aspect Oriented programming to do
this. Page 370 of the book has some information about aspect oriented
programming.
I believe you would need to add an actor that would handle the
recording and then annotate the ports that are to use that actor.
There is this larger issue of checkpointing and rollback that could be
useful for long running models. The idea is that if we could
checkpoint a model, then if there was a problem with execution, we
could resume from the checkpoint. If the actors have no state, then
knowing what tokens are on the ports might be sufficient. However, if
the actors have state, then more work would probably be necessary.
There was some work done with modifying actor code to allow
backtracking, though not much has happened with that code for some time.
_Christopher
On 1/10/14 9:44 AM, Rich Morin wrote:
On Jan 10, 2014, at 09:20, Christopher Brooks wrote:
My responses are below.
Thanks!
The following questions have to do with the inter-actor "piping"
and best practices for command debugging and optimization.
Q: Can I add recording and/or archiving as attributes to a pipe?
So, for example, could I tell Kepler to turn on recording for
particular pipes, without needing to explicitly add an actor?
(This could be used for "tracing" key paths in an app.)
I don't know of an actor that has access to pipes. ...
Perhaps I should have said "plumbing". I'm referring to the usual
communication channels used by Kepler/Ptolemy actors, not to Unix
named pipes, etc.
There was a talk at the PII meeting about hanging attributes on
connections. I was wondering if something like this could be used
to enable archiving or analysis of the transmitted data, etc.
-r
--
http://www.cfcl.com/rdm Rich Morin [email protected]
http://www.cfcl.com/rdm/resume San Bruno, CA, USA +1 650-873-7841
Software system design, development, and documentation
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
