@@ -155,8 +193,7 @@ and structuring our comments that way.</p> <h3 id="dsom-fixed-getter">DSOM "fixed" getter</h3> <div class="paragraph"> <p>Note: If we change runtime1 to validate "fixed" values -like runtime2 does, then -we can close <a href="https://issues.apache.org/jira/browse/DAFFODIL-117">DAFFODIL-117</a>.</p> +like runtime2 does, then we can resolve {% jira 117 %}.</p> </div>
So much for hoping that the site generator supports the markdown jira macro :). https://daffodil.apache.org/dev/design-notes/runtime2-todos/ -----Original Message----- From: github-...@apache.org <github-...@apache.org> Sent: Friday, April 16, 2021 10:57 AM To: comm...@daffodil.apache.org Subject: EXT: [daffodil-site] branch asf-site updated: Publishing from 64abbf0df41a006a7a19d7daad29749b0a7dd6b5 This is an automated email from the ASF dual-hosted git repository. github-bot pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/daffodil-site.git The following commit(s) were added to refs/heads/asf-site by this push: new fc38a6c Publishing from 64abbf0df41a006a7a19d7daad29749b0a7dd6b5 fc38a6c is described below commit fc38a6c0ac407b77f77b222f9270c53509055f5b Author: John Interrante <inter...@research.ge.com> AuthorDate: Fri Apr 16 14:57:03 2021 +0000 Publishing from 64abbf0df41a006a7a19d7daad29749b0a7dd6b5 --- content/dev/design-notes/runtime2-todos/index.html | 81 ++++++++++++++++------ 1 file changed, 59 insertions(+), 22 deletions(-) diff --git a/content/dev/design-notes/runtime2-todos/index.html b/content/dev/design-notes/runtime2-todos/index.html index 184f6be..362c979 100644 --- a/content/dev/design-notes/runtime2-todos/index.html +++ b/content/dev/design-notes/runtime2-todos/index.html @@ -113,34 +113,72 @@ in order to avoid duplication.</p> </div> </div> <div class="sect2"> -<h3 id="error-struct-instead-of-error-message">Error struct instead of error message</h3> +<h3 id="reporting-errors-using-structs-not-strings">Reporting errors +using structs, not strings</h3> <div class="paragraph"> -<p>This change is almost complete. -We have replaced error message strings +<p>We have replaced error message strings with error structs everywhere now. -However, we should support passing -a schema location and/or data position -through the error struct as well as -an error code, an integer, and a string. -We may need to store schema locations -(filenames and line numbers) in ERD objects -and pass an ERD in the error struct.</p> +However, we may need to expand the error struct to include a pointer +(pstate/ustate for data position) and another pointer (ERD or static +context object for schema filename/line number).</p> </div> <div +class="paragraph"> <p>We also may want to implement error logging +variants that both do and don’t humanize the errors, e.g., a +hardware/FPGA-type implementation might just output numbers and an +external tool might have to "humanize" these numbers using knowledge of +the schema and runtime data objects, like an offline log processor +does.</p> </div> </div> <div class="sect2"> -<h3 id="different-types-of-errors">Different types of errors</h3> +<h3 id="recovering-after-errors">Recovering after errors</h3> <div class="paragraph"> -<p>When runtime2 grows larger, -we may need to distinguish & handle -more types of errors. -Right now we handle only -fatal errors and validation errors. -Fatal errors stop the program immediately. +<p>As we continue to build out runtime2, we may need to distinguish +more types of errors and allow backtracking and retrying. +Right now we handle only parse/unparse and validation errors in limited +ways. +Parse/unparse errors abort the parsing/unparsing and return to the +caller immediately without resetting the stream’s position. Validation errors are collected in an array and printed after parsing or unparsing. -Later we may need to handle -parser/unparser warnings and errors -and allow backtracking after these errors.</p> +The only places where there are calls to stop the program are in +daffodil_main.c (top-level error handling) and stack.c (empty, +overflow, underflow errors which should never happen).</p> </div> <div +class="paragraph"> <p>Most of the parse functions set +pstate→error only if they couldn’t read data into their +buffer due to an I/O error or EOF, which doesn’t seem recoverable +to me. +Likewise, the unparse functions set ustate→error only if they +couldn’t write data from their buffer due to an I/O error, which +doesn’t seem recoverable to me.</p> </div> <div +class="paragraph"> <p>Only the parse_endian_bool functions set +pstate→error if they read an integer which doesn’t match +either true_rep or false_rep when an exact match to either is required. +If we decide to implement backtracking and retrying, they should call +fseek to reset the stream’s position back to where they started +reading the integer before they return to their callers. +Right now all parse calls are followed by if statements to check for +error and return immediately. +The code generator would have to generate code which can advance the +stream’s position by some byte(s) and try the parse call again as +an attempt to resynchronize with a correct data stream after a bunch of +failures.</p> </div> <div class="paragraph"> <p>Note that we actually +run the generated code in an embedded processor and call our own +fread/frwrite functions which replace the stdio fread/fwrite functions +since the C code runs bare metal without OS functions. +We can implement fseek but we should have a good use case.</p> </div> </div> <div class="sect2"> @@ -155,8 +193,7 @@ and structuring our comments that way.</p> <h3 id="dsom-fixed-getter">DSOM "fixed" getter</h3> <div class="paragraph"> <p>Note: If we change runtime1 to validate "fixed" values -like runtime2 does, then -we can close <a href="https://issues.apache.org/jira/browse/DAFFODIL-117">DAFFODIL-117</a>.</p> +like runtime2 does, then we can resolve {% jira 117 %}.</p> </div> </div> <div class="sect2">