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:
     *   Current infoset
     *   Current bit position
     *   Current parser
     *   A UID of the current state
     *   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:
     *   A region of (byte aligned) input data (hex encoded?)
     *   The byte position of the start of the region
     *   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:
     *   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
     *   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.
     *   Pane 3 - binary viewer
        *   Shows a complete hex-dump of the input data, indicating current 
location within the parse
     *   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:
     *   Delimeter stack
     *   Variables
  *   Support additional formats for displaying input data
     *   Text (of selectable encoding)
     *   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

[cid:e3942e8c-91b8-46c9-946e-a7d444bda4a7]

bslo...@owlcyberdefense.com

Connect with us!

[cid:54cd2295-7dba-42bb-a70f-0a93aa44b072]<https://www.linkedin.com/company/owlcyberdefense/>[cid:7d97c978-b1c6-4c20-b747-570920dded63]<https://twitter.com/owlcyberdefense>

[cid:1e0d1441-a879-4f36-bd0a-7fc68bb1d58e]<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

Reply via email to