This seems like a very reasonable roadmap for the future debugger. Unfortunately, as great as all the feedback as been from everyone, I think my main focus right now is going to be just getting the current debugger to a more functional state, and if there is time after that, to focus on making a more machine readable output and and wrapping that around a new GUI. I absolutely think what you've described is where we want to head towards and a reasonable approach to get there, but is still likely more effort than I can put towards this at the moment.
On 1/24/21 2:08 PM, Sloane, Brandon wrote: > Following up on the recent discussion about the Daffodil debugger, I would > like > to propose a roadmap for creating graphical debugger. > Organizationally, the GUI debugger is a separate application (maintained in > the > normal Daffodil repository) that may include any of the current Daffodil > libraries as a dependency. > > Phases 1 and 2 focus on developing an enhanced trace functionality; where > Daffodil outputs a machine readable trace of the parse/unparse process. The > GUI > then allows a user to view this trace offline. > > Phase 3 adds support for interactive debugging, by allowing the Daffodil-cli > and > Daffodil-gui-debugger to act in a client/server relationship > > Phase 4 focuses on backend debugger enhancements. > > In more detail: > > Phase 1: > > * Add a --machine-trace flag to Daffodil CLI, that is analogous to the > current > --trace option. Output is a stream of XML parse-state nodes, each one > describing the current state of the parse, including: > o Current infoset > o Current bit position > o Current parser > o A UID of the current state > o A UID of the parent state (in event of backtracking, multiple states > will have the same parent). > * Machine-trace output stream also include input-data nodes, that include: > o A region of (byte aligned) input data (hex encoded?) > o The byte position of the start of the region > o The relative location of the input data nodes is undefined, but given > the complete trace, it should be possible to reconstruct the original > dataset by stitching together the data in the nodes. The goal here is > that we can just output data as Daffodil reads it in. > * --machine-trace take an optional argument of a file path. If provided, its > output will be directed to a file at said location (otherwise stderr) > * Create a GUI program that can ingest the machine trace and display it in a > 4-pane view: > o Pane 1 - trace navigator > + Represents the entire parse in a tree format. Each parse state > corresponds to a node on the tree > + The user can select a node on the tree to load it into the other > panes > o Pane 2 - Infoset viewer > + Shows the complete infoset corresponding to the node selected in > pane 1. > + Indicates the "current" position of the parser within the infoset > + Highlights changes in the infoset relative to the parent node. > o Pane 3 - binary viewer > + Shows a complete hex-dump of the input data, indicating current > location within the parse > o Pane 3 -- parser view > + Shows the current parser. Probably will be a dumping ground for > additional information that does not warrant the addition of a > new pane. > > > Phase 2: > > * Support showing suspensions on unparse > * Display additional data about the parse/unparse state: > o Delimeter stack > o Variables > * Support additional formats for displaying input data > o Text (of selectable encoding) > o Binary (not hex; actual 1s and 0s) > * Support generating traces through the API as well. > > Phase 2.5: > > Gather user feedback and iterate on the trace viewer functionality > > Phase 3: > > * Define protocol for the debugger to talk with the CLI. > * Debugger can load schema, and input data. > * Debugger can step through the parse/unparse > * Viewer built in phases 1 and 2 continually updates as the parse proceeds > * User can send CLI debugger commands and get the textual response; but only > for the current parse/unparse state. > * User can set breakpoints (possibly using textual commands). Debugger > supports continue until breakpoint > > Phase 3.5: > > * Not debugger related, but as long as the Daffodil CLI can operate as a > server, support server mode operations for non-debug use cases. > > > Phase 4: > > * Support time travel debugging, with an interface in both the CLI and GUI > debuggers > * Support associating a trace with schema source, and allowing a "go to > source" functionality where the user can navigate directly to the location > in source corresponding to the current parser > * Support dynamically editing/reloading schema and input data > > Thoughts? > Brandon Sloane | Engineer > > bslo...@owlcyberdefense.com > > Connect with us! > > <https://www.linkedin.com/company/owlcyberdefense/><https://twitter.com/owlcyberdefense> > > <https://owlcyberdefense.com/resources/events/> > > ** > > The information contained in this transmission is for the personal and > confidential use of the individual or entity to which it is addressed. If the > reader is not the intended recipient, you are hereby notified that any > review, > dissemination, or copying of this communication is strictly prohibited. If > you > have received this transmission in error, please notify the sender immediately >
