Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DFDL-758

improve trace output format

XMLWordPrintableJSON

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Normal Normal
    • 2.1.0
    • s10
    • CLI, Debugger, Usability
    • None

      The trace output can be improved a little, and then a lot.

      A little: just remove the printing out of the parser - not relevant to a DFDL user.

      A lot: Examples below of

      • better data dump format, with text + hex, or just text, or just hex
      • remove all the redundant parts of filenames. Use just the filename (so long as it is unambiguous), and then at the end of the trace display which files are located in what directories.
      • short schema component designators (see https://opensource.ncsa.illinois.edu/confluence/pages/viewpage.action?pageId=22053271)
      • optional use of the Unicode illustration characters: like ␍␊ which is way better than actually doing a CR and LF because those move the text around. (There are these Unicode characters for all the otherwise non-printing control characters. They are #x240A for linefeed and #x240D for carriage return. You can guess the others.) Note however, that on MS-Windows, the ordinary cmd console isn't unicode-capable by default, so we need these to print as something else on that platform.

      My experience is that

      (1) you sometimes need to see what came right before stopping point so as to infer the cause, not just look at the consequences, hence, the dump starts a little before where the actual stop was.

      (2) unless the data is all text in a uniform encoding with no decoding errors, you will need to see hex and text or both to figure out what could be going on.

      So I'm just laying out for you what that might look like to solicit feedback. Currently the stuff we print has had very little thought put into how it is displayed.

      So, in a scenario where there is a possible mixture of binary data and text data, your message might be:

      Error PE-845-231J: Left over data starting at byte 23.
      Data context in file testData.dat:
       
      Pos                   V                              V
      -- 16: 4e55 2045 6d61 6373 2c20 6f6e 6520 636f NU Emacs, one co
      -- 80: 6d70 6f6e 656e 7420 6f66 2074 6865 2047 mponent of the G <<
      - 144: 4e55 2f4c 696e 7578 206f 7065 7261 7469 NU/Linux operati
      - 208: 6e67 2073 7973 7465 6d2e 0a0a 456d 6163 ng system.␊␊Emac
      - 272: 7320 5475 746f 7269 616c 094c 6561 726e s Tutorial.Learn
       
      Schema component: e1/~t1/G::g1/S/S[2]/e2
      Schema location: line 27 column 17 file baz.dfdl.xsd
      Files mentioned in this trace were:
          baz.dfdl.xsd located at file:/foo/bar/
          testData.dat located at file:/mydata/

      If you were in a 100% text and uniform encoding scenario, then perhaps the dump would drop the hex and make the text lines longer:

      Error: Left over data starting at character 23.
      Data context in file testData.dat:
                                                    V
      -- 1:   ..Welcome to GNU Emacs, one component of the GNU/Linux operati <<
      - 64: ng system...Emacs Tutorial.Learn basic keystroke commands.Emacs
       
      Schema component: e1/~t1/G::g1/S/S[2]/e2
      Schema location: line 27 column 17 file baz.dfdl.xsd
      Files mentioned in this trace were:
          baz.dfdl.xsd located at file:/foo/bar/
          testData.dat located at file:/mydata/

              Unassigned Unassigned
              mbeckerle.dfdl Mike Beckerle
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: