[
https://issues.apache.org/jira/browse/DAFFODIL-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868658#comment-16868658
]
Brandon Sloane commented on DAFFODIL-758:
-----------------------------------------
> just remove the printing out of the parser - not relevant to a DFDL user.
It might be worth it to add some type of verbose flag to re-enable this. While
not relevant to users, it is sometimes relevant to Daffodil developers.
> improve trace output format
> ---------------------------
>
> Key: DAFFODIL-758
> URL: https://issues.apache.org/jira/browse/DAFFODIL-758
> Project: Daffodil
> Issue Type: Improvement
> Components: CLI, Debugger, Usability
> Affects Versions: s10
> Reporter: Michael Beckerle
> Priority: Major
> Fix For: 2.4.0
>
>
> 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 *␊␍␠␉* (see
> [https://en.wikipedia.org/wiki/Unicode_control_characters#Control_pictures])
> 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.) 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:
> {code:java}
> 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/
> {code}
> 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:
> {code:java}
> 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/
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
