4 ms·

I think a "Omnicient"/"Time-travel" debugger with strong tracing support would be interesting. I'd like to be able to take a recorded run and add tracepoints a

I think a "Omnicient"/"Time-travel" debugger with strong tracing support would be interesting. I'd like to be able to take a recorded run and add tracepoints after the fact, and be able to toggle them on and off, or add or modify conditions on the output, watching the trace change as I do it. When I looked at the Pernosco demo it looked like it had the capabilities to do this sort of thing, but only a rather primitive user interface.

acemarke 4y ago
Mentioned it up thread, but this is _exactly_ what our Replay time-traveling debugger for JS lets you do! We specifically let you add "print statements" to any line of code from the recorded app, let you toggle them or change conditions, and recalculate the logged output every time you make a change: https://docs.replay.io/reference-guide/print-statements https://docs.replay.io/reference-guide/print-statements Longer-term, we have plans to implement functionality for "persistent object IDs" and tracing individual values over time. No ETA on that, but from what our runtime team has said it's feasible. (We actually have a partial hardcoded implementation of that that we're using to track anything that looks like a React internal "Fiber" data structure, and I used that to build some of our support for the React DevTools: https://blog.replay.io/how-we-rebuilt-react-devtools-with-replay-routines https://blog.replay.io/how-we-rebuilt-react-devtools-with-re... )
- jackcviers3 4y ago
  Reply to Grandparent and this: Very cool and definitely useful to record and replay the session and modify breakpoint conditions for replay. I wonder if session recording like this could be safely brought to backend systems. You'd almost have to stub every remote call to allow for replayability in isolation of external services, and the potential for data leakage from a downloaded session is also a concern. I'm glad someone else is working on problems and tools like this. I should note I'm not disparaging the use of debuggers in my comments, but lamenting the nature of the process of debugging the types of systems we deploy today, and the largely non-interactive nature tradeoffs we've made for scalability, reliability, availability, and operability. Sometimes I long for the simplicity of a fully self-contained local system, but I know we just don't live in that world anymore, and haven't for a long time now.
  - acemarke 4y ago
    Yeah, data leakage is a concern in the sense that _everything_ about the process gets recorded. (At Replay, all the recordings are encrypted and access-controlled: https://www.replay.io/security-and-privacy https://www.replay.io/security-and-privacy ) The way Replay specifically works is that we fork and modify the Firefox and Chrome browser and Node runtime to add the necessary support for capturing and stubbing all OS-level syscalls, as well as making other changes to ensure near-deterministic playback. So, when the recording gets replayed, the process gets all the same external inputs it did the first time: - https://docs.replay.io/contribute/how-replay-works https://docs.replay.io/contribute/how-replay-works One of our long-term goals is to bring down recording perf overhead enough that we can do "always-on" recording into a buffer, so that the browser or Node just _always_ runs in recording mode, and if something fails the last minute or so of the buffer gets uploaded for analysis.
mark_undoio 4y ago
VS Code has a concept called "log points" in the C/C++ debug mode that use a debugger to implement logging. So you can combine the best of debugging and logging. At Undo we've done some investigation of how to get this out into the world for time travel debug, so it's interesting to see your idea lines up. What sort of problem do you think this would be useful for?
- mjw1007 4y ago
  Learning about an unfamiliar and underdocumented codebase.
  - mark_undoio 4y ago
    That makes a lot of sense - having a deterministic recording makes a big difference to learning how the code actually works. I also sometimes think that, even when I want a debugger interface to look at the details, I'd also like to see a "big picture" view showing how key values evolve over time. (something like replay.io does for visualising logging statements is probably in about the right place for both of us, though I'm not a web dev)

acemarke 4y ago

Mentioned it up thread, but this is _exactly_ what our Replay time-traveling debugger for JS lets you do! We specifically let you add "print statements" to any line of code from the recorded app, let you toggle them or change conditions, and recalculate the logged output every time you make a change: https://docs.replay.io/reference-guide/print-statements https://docs.replay.io/reference-guide/print-statements Longer-term, we have plans to implement functionality for "persistent object IDs" and tracing individual values over time. No ETA on that, but from what our runtime team has said it's feasible. (We actually have a partial hardcoded implementation of that that we're using to track anything that looks like a React internal "Fiber" data structure, and I used that to build some of our support for the React DevTools: https://blog.replay.io/how-we-rebuilt-react-devtools-with-replay-routines https://blog.replay.io/how-we-rebuilt-react-devtools-with-re... )

jackcviers3 4y ago
Reply to Grandparent and this: Very cool and definitely useful to record and replay the session and modify breakpoint conditions for replay. I wonder if session recording like this could be safely brought to backend systems. You'd almost have to stub every remote call to allow for replayability in isolation of external services, and the potential for data leakage from a downloaded session is also a concern. I'm glad someone else is working on problems and tools like this. I should note I'm not disparaging the use of debuggers in my comments, but lamenting the nature of the process of debugging the types of systems we deploy today, and the largely non-interactive nature tradeoffs we've made for scalability, reliability, availability, and operability. Sometimes I long for the simplicity of a fully self-contained local system, but I know we just don't live in that world anymore, and haven't for a long time now.
- acemarke 4y ago
  Yeah, data leakage is a concern in the sense that _everything_ about the process gets recorded. (At Replay, all the recordings are encrypted and access-controlled: https://www.replay.io/security-and-privacy https://www.replay.io/security-and-privacy ) The way Replay specifically works is that we fork and modify the Firefox and Chrome browser and Node runtime to add the necessary support for capturing and stubbing all OS-level syscalls, as well as making other changes to ensure near-deterministic playback. So, when the recording gets replayed, the process gets all the same external inputs it did the first time: - https://docs.replay.io/contribute/how-replay-works https://docs.replay.io/contribute/how-replay-works One of our long-term goals is to bring down recording perf overhead enough that we can do "always-on" recording into a buffer, so that the browser or Node just _always_ runs in recording mode, and if something fails the last minute or so of the buffer gets uploaded for analysis.

mark_undoio 4y ago

VS Code has a concept called "log points" in the C/C++ debug mode that use a debugger to implement logging. So you can combine the best of debugging and logging. At Undo we've done some investigation of how to get this out into the world for time travel debug, so it's interesting to see your idea lines up. What sort of problem do you think this would be useful for?

mjw1007 4y ago
Learning about an unfamiliar and underdocumented codebase.
- mark_undoio 4y ago
  That makes a lot of sense - having a deterministic recording makes a big difference to learning how the code actually works. I also sometimes think that, even when I want a debugger interface to look at the details, I'd also like to see a "big picture" view showing how key values evolve over time. (something like replay.io does for visualising logging statements is probably in about the right place for both of us, though I'm not a web dev)