Skip to content

[Wicket] Enable post-mortem debugging #3070

Open
@andrewjstone

Description

@andrewjstone

TLDR:

  • Move all updatable state into global State struct
  • Derive all visual state in Control::draw callbacks from global State - Can we make &mut self into &self?
  • Fork ratatui and make Rect serialize/deserialize
  • Create a PTY abstraction that allows resize events in wicket-dbg

Details:

The way wicket-dbg works is that a serialized recording of all totally ordered events is replayed from the initial state. Since each even is processed deterministically, replaying all events in order results in the same end state. However, as memory is limited, we cannot store an indefinite number of events. We therefore limit the number of events we store and when we fill the buffer, we take a snapshot of the current State struct. At that point future replays in wicket-dbg will start at event X rather than the initial state.

For snapshotting to work however, all state mutated by incoming events must be stored in the global State struct, and it must be serializable. This is not currently the case, as some mutable state is stored in pane implementations such as UpdatePane. We must move this all to State. In essence, Pane's should not store any state at all, and we should only mutate state when Control::on callbacks are called. Control::draw callbacks should not mutate state, but should take the current state and derive visual state used by TUI widgets.

Additionally, we have a problem where we store tui::layout::Rects in panes. This is to allow dynamic drawing of contents when a Resize event comes in. We need to also store these in the global State. Unfortunately the Rect type is not serializable. We need to fork the new version of tui.rs, ratatui and derive Serialize and Deserialize for Rect.

Besides Rect serialization, we also cannot handle resize of windows themselves properly in wicket-dbg. If a user resizes their window to be smaller, this should work, although it will appear as a partial view into a terminal where the whole thing doesn't get updated. If the user resizes their window larger, we will likely panic from an overflow. What we need is some sort of pty management where we can spawn virtual terminals and resize at will.

Metadata

Metadata

Assignees

No one assigned

    Labels

    DebuggingFor when you want better data in debugging an issue (log messages, post mortem debugging, and more)

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions