mbeckerle commented on code in PR #98: URL: https://github.com/apache/daffodil-site/pull/98#discussion_r1035006393
########## site/dev/design-notes/runtime2-todos.adoc: ########## @@ -109,141 +211,26 @@ and try the parse call again as an attempt to resynchronize with a correct data stream after a bunch of failures. -Note that we actually run the generated code in an embedded processor +Note that we sometimes 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. - -=== Javadoc-like tool for C code - -We should consider adopting one of the javadoc-like tools for C code -and structuring our comments that way. +We can implement the fseek function on the embedded processor too +but we would need a good use case requiring recovering after errors. === Validate "fixed" values in runtime1 too If we change runtime1 to validate "fixed" values like runtime2 does, then we can resolve https://issues.apache.org/jira/browse/DAFFODIL-117[DAFFODIL-117]. -=== Improve TDML Runner - -We want to improve the TDML Runner -to make it easier to run TDML tests -with both runtime1 and runtime2. -We want to eliminate the need -to configure a `daf:tdmlImplementation` tunable -in the TDML test using 12 lines of code. - -I had an initial idea which was that -the TDML Runner could run both runtime1 and runtime2 -automatically (in parallel or serially) -if it sees a TDML root attribute -saying `defaultImplementations="daffodil daffodil-runtime2"` -or a parser/unparseTestCase attribute -saying `implementations="daffodil daffodil-runtime2"`. -To make running the same test on runtime1/runtime2 easier -we also could add an implementation attribute -to tdml:errors/warnings elements -saying which implementation they are for -and tell the TDML Runner to check errors/warnings -for runtime2 as well as runtime1. - -Then I had another idea which might be easier to implement. -If we could find a way to set Daffodil's tdmlImplementation tunable -using a command line option or environment variable -or some other way to change TDML Runner's behavior -when running both "sbt test" and "daffodil test" -then we could simply run "sbt test" or "daffodil test" twice -(first using runtime1 and then using runtime2) -in order to verify all the cross tests work on both. -I think this way would be easier than making TDML Runner -automatically run all the implementations it can find -in parallel or serially when running cross tests. - -If the second idea works as I hope it does, -then we can start the process of adding "daffodil-runtime2" -to some of the cross tests we have for daffodil and ibm. -We also chould change ibm's ProcessFactory class -to have a different name than daffodil's ProcessFactory class -and update TDML Runner's match expression to use the new class name. -Then some developers could add the ibmDFDLCrossTester plugin -to their daffodil checkout permanently -instead of having to do & undo that change -each time they want to run daffodil/ibm cross tests. - -=== C struct/field name collisions - -To avoid possible name collisions, -we should prepend struct names and field names with namespace prefixes -if their infoset elements have non-null namespace prefixes. -Alternatively, we may need to use enclosing elements' names -as prefixes to avoid name collisions without namespaces. - -=== Anonymous/multiple choice groups - -We already handle elements having xs:choice complex types. -In addition, we should support anonymous/multiple choice groups. -We may need to refine the choice runtime structure -in order to allow multiple choice groups -to be inlined into parent elements. -Here is an example schema -and corresponding C code to demonstrate: - -[source,xml] ----- - <xs:complexType name="NestedUnionType"> - <xs:sequence> - <xs:element name="first_tag" type="idl:int32"/> - <xs:choice dfdl:choiceDispatchKey="{xs:string(./first_tag)}"> - <xs:element name="foo" type="idl:FooType" dfdl:choiceBranchKey="1 2"/> - <xs:element name="bar" type="idl:BarType" dfdl:choiceBranchKey="3 4"/> - </xs:choice> - <xs:element name="second_tag" type="idl:int32"/> - <xs:choice dfdl:choiceDispatchKey="{xs:string(./second_tag)}"> - <xs:element name="fie" type="idl:FieType" dfdl:choiceBranchKey="1"/> - <xs:element name="fum" type="idl:FumType" dfdl:choiceBranchKey="2"/> - </xs:choice> - </xs:sequence> - </xs:complexType> ----- - -[source,c] ----- -typedef struct NestedUnion -{ - InfosetBase _base; - int32_t first_tag; - size_t _choice_1; // choice of which union field to use - union - { - foo foo; - bar bar; - }; - int32_t second_tag; - size_t _choice_2; // choice of which union field to use - union - { - fie fie; - fum fum; - }; -} NestedUnion; ----- - -=== Choice dispatch key expressions - -We currently support only a very restricted -and simple subset of choice dispatch key expressions. -We would like to refactor the DPath expression compiler -and make it generate C code -in order to support arbitrary choice dispatch key expressions. - === No match between choice dispatch key and choice branch keys -Right now c-daffodil is more strict than scala-daffodil +Right now c/daffodil is more strict than daffodil when unparsing infoset XML files with no matches (or mismatches) between choice dispatch keys and branch keys. -Perhaps c-daffodil should load such an XML file +Such a situation always makes c/daffodil exit with an error. +Perhaps c/daffodil should load such an XML file Review Comment: Agree. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
