You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by "Interrante, John A (GE Research, US)" <Jo...@ge.com> on 2021/04/16 15:02:41 UTC
RE: [daffodil-site] branch asf-site updated: Publishing from
64abbf0df41a006a7a19d7daad29749b0a7dd6b5
@@ -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-bot@apache.org <gi...@apache.org>
Sent: Friday, April 16, 2021 10:57 AM
To: commits@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 <in...@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">