Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Use timely's logging infrastructure to log Tracker state #321
Add TrackerEvent which records additions or removals
Add DebugEvent which records the state of pointstamps,
Enabling loggers for these events is done the same way as for
At the moment, we use these loggers for comparative testing between
This graph plots the runtime of the computation with and without the changes, and suggests
We got similar results when run on other examples.
Add TrackerEvent which records additons or removals of capabilities, as well as propagation events when chanages in implications are propagated along the internal connections and edges of the graph. Add DebugEvent which records the state of pointstamps, implications, and worklist of Tracker. Enabling loggers for these events is done the same way as for logging::TimelyEvent's.
I have some general questions about the PR!
I think I understand the goal, which is to get out information about the steps that
Would it serve your purposes just as well to instrument the moments and nature of pointstamp updates and propagation?
Hi folks, a couple of more notes from a conversation with @saradecova .
This seems reasonable (we wouldn't know how to encode the type otherwise), however this makes it harder (impossible) for the consumer to know what type to expect for a certain scope. As an example, to be able to replay the behaviour of the
We're wondering if it makes sense to add (or adjust an existing)
One option would be to use
I'm still considering options, but @frankmcsherry let us know if you have opinions.
To follow on @utaal and our conversation, we can encode the type in string using
Moreover, by adding
In pracrise, this could be an event informing us that "A new subscope was created at address