You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For debugging purposes, I was imagining a function that traced how a collection changes over ticks. It would function somewhat similarly to how stdio works now (though shouldn't). The default messaging would be better, though, something like Trace: myTable added these tuples: ["a", "b"], ["c", "d"].
I imagine an interface something like this, with two functions, trace_enter and trace_exit:
trace_enter shows updates to a collection at the beginning of ticks. Optimal for interface inputs, to trace when they arrive.
trace_exit shows updates the ends of ticks. Optimal for outputs or tables modified during the tick.
These methods maintain the opaqueness of a tick by only instrumenting before or after the tick. Additionally, since a trace would display updates since the last trace on the same object, using both trace_enter and trace_exit would allow you to trace tables that may be used as both inputs and outputs (though that's probably not good coding practice in general).
Any thoughts on this idea? Would it possibly be a worthwhile addition to the bud base support, or just extra garbage on top?
The text was updated successfully, but these errors were encountered:
For debugging purposes, I was imagining a function that traced how a collection changes over ticks. It would function somewhat similarly to how stdio works now (though shouldn't). The default messaging would be better, though, something like
Trace: myTable added these tuples: ["a", "b"], ["c", "d"]
.I imagine an interface something like this, with two functions,
trace_enter
andtrace_exit
:trace_enter
shows updates to a collection at the beginning of ticks. Optimal for interface inputs, to trace when they arrive.trace_exit
shows updates the ends of ticks. Optimal for outputs or tables modified during the tick.These methods maintain the opaqueness of a tick by only instrumenting before or after the tick. Additionally, since a trace would display updates since the last trace on the same object, using both
trace_enter
andtrace_exit
would allow you to trace tables that may be used as both inputs and outputs (though that's probably not good coding practice in general).Any thoughts on this idea? Would it possibly be a worthwhile addition to the bud base support, or just extra garbage on top?
The text was updated successfully, but these errors were encountered: