Andrew Stone of Oxide Engineering joined Bryan, Adam, and the Oxide Friends to talk about his purpose-built, replay debugger for the Oxide setup textual UI. Andrew borrowed a technique from his extensive work with distributed systems to built a UI that was well-structured... and highly amenable to debuggability. He built a custom debugger "in a weekend"!Some of the topics we hit on, in the order that we hit them:
tui-rs
Crossterm
The reedline crate
Episode about the "Sidecar" switch
Elm time-travel debugging
Replay.io
Devtools.fm episode on Replay.io
AADEBUG conference
California horse meat law
The (lightly) edited live chat from the show:

MattCampbell: I'm gathering that this is more like the fancy pseudo-GUI style of TUI, which is possibly bad for accessibility

ahl: we are also building with accessibility in mind, stripping away some of the non-textual elements optionally

MattCampbell: oh, cool

ahl: Episode about the "Sidecar" switch: https://github.com/oxidecomputer/oxide-and-friends/blob/master/2021_11_29.md


MattCampbell: ooh! That kind of recording is definitely better for accessibility than a video.

uwaces: Were you inspired by Elm? (The programming language for web browsers?)

bcantrill: Here's Andrew's PR for this, FWIW: oxidecomputer/omicron#2682


uwaces: Elm has a very similar model. They have even had a debugger that let you run events in reverse: https://elm-lang.org/news/time-travel-made-easy


bch: I’m joining late - 1) does this state-machine replay model have a name 2) expand on (describe ) the I/o logic separation distinction?

ahl: http://dtrace.org/blogs/ahl/2015/06/22/first-rust-program-pain/


zk: RE: logic separation in consensus protocols: the benefit of seperating out the state machine into a side-effect free function allows you to write a formally verified implementation in a pure FP lang or theorem prover, and then extract a reference program from the proof.

we're going to the zoo: lol i’m a web dev && we do UI tests via StorybookJS + snapshots of each story + snapshots of the end state of an interaction

ig: At that point you could turn the recording into an “expect test”. https://blog.janestreet.com/the-joy-of-expect-tests/


we're going to the zoo: TOFU but for tests ?

uwaces: Are you at all worried that you are replicating the horror that is the IBM 3270 terminal? — I have personal history programming on z/OS where the only interface is a graphical EBCDIC 3027 interface — the horror is that people write programs to interact with graphical window (assuming a certain size).

ahl: https://docs.rs/serde/latest/serde/#data-formats


ahl: SHOW NOTES Bryan as "semi-elderly" engineer

MattCampbell: didn't Bryan write a blog post on this?

MattCampbell: http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/


uwaces: https://www.replay.io


ahl: https://devtools.fm/episode/9


ahl: e.g. https://altsysrq.github.io/proptest-book/intro.html


we're going to the zoo: https://github.com/AFLplusplus/LibAFL


ig: Are you using proptest, quickcheck, or something else?

nickik: This really started with Haskell https://hackage.haskell.org/package/QuickCheck Its also cool that it does 'narrowing' meaning it will try to find an error, and then try to generate a simpler error case.

endigma: how different is something like this from what go calls "fuzzing"

Riking: Fuzzing does also have a minimization step

we're going to the zoo: https://github.com/dubzzz/fast-check


Riking: Property-based testing tends to be structured differently in philosophy, while fuzzers are more aligned to "give you a bag of bytes"

nickik: http://www.quviq.com/products/erlang-quickcheck/


endigma: yeah I can tell its a different structure, but the overall goal seems similar

we're going to the zoo: they are nonexclusive approaches to testing

papertigers: I think Kelly was doing a bunch of tests at Joyent based on quick check and prop test. First time I encountered it

we're going to the zoo: libafl provides a #[d