Is that all? :-). I would add some criteria testing runtime2's conformance to the DFDL 1.0 specification as well. Here goes...
1) Sufficient functionality to describe at least one example, of sufficient message complexity to indicate that other similar "real" examples should be possible Yup. We have 7 schemas in daffodil-test/src/test/resources/org/apache/daffodil/runtime2 that have "real" examples of messages with sufficient complexity to indicate that other real messages should be possible. 2) contains built-in tests for one or several such examples, showing each supported aspect working. Yup. We have TDML tests and binary data/XML infoset files for each of these 7 schemas. 3) the tests are fully integrated - they run every time 'sbt test' is run on daffodil. Yup. We have Scala test classes for each of these 7 schemas' TDML tests in daffodil-test/src/test/scala/org/apache/daffodil/runtime2. 4) setup instructions for developers are there so that people know how to insure the required C tool-chain elements are there. These need to work on Linux and Windows. Needs work. The top-level README lists daffodil-runtime2's build requirements under Build Requirements and has a single sentence under Getting Started telling developers that they will need a C toolchain in order to build daffodil-runtime2. However, I didn't make it clear in the README that developers must setup a C toolchain as well as a Java/Scala toolchain and I need to add a "C Setup and Notes" page to the Confluence Wiki with step-by-step instructions showing developers how to setup a C toolchain on Linux and Windows. I hope developers won't mind if we make it mandatory to setup both Java/Scala and C toolchains before building Daffodil. I don't like the idea of some developers building Daffodil without checking that the C files compile successfully and the runtime2 tests pass successfully. I think it's sufficient to guarantee that end-users of Daffodil never have to install a C toolchain to use Daffodil. When end-users install Daffodil, they will get a pure Scala Daffodil just like before. The only user-visible change is that this Daffodil will know how to generate, compile, and run C code on the end-user's system if the user asks Daffodil to do that. I also would add another criteria: 5) A subset of Daffodil's DFDL 1.0 specification conformance TDML tests modified to run on runtime2 as well as runtime1 during 'sbt test'. We have lots and lots of TDML tests checking that Daffodil conforms to the DFDL 1.0 specification. We should be able to find a subset of these tests that should pass on runtime2 as well and verify that they do keep passing when run on both runtime1 and runtime2. This step would go a long way to ensure that people working on other aspects of Daffodil do not break the C backend inadvertently without knowing it. Note that this makes it even more mandatory that Daffodil developers setup both Java/Scala and C toolchains. What do you all think? -----Original Message----- From: Beckerle, Mike <mbecke...@owlcyberdefense.com> Sent: Thursday, March 11, 2021 9:27 AM To: dev@daffodil.apache.org Subject: EXT: Re: Acceptance criteria for merging DFDL-to-C backend (runtime2-2202)? Acceptance criteria to me: 1) Sufficient functionality to describe at least one example, of sufficient message complexity to indicate that other similar "real" examples should be possible 2) contains built-in tests for one or several such examples, showing each supported aspect working. 3) the tests are fully integrated - they run every time 'sbt test' is run on daffodil. 4) setup instructions for developers are there so that people know how to insure the required C tool-chain elements are there. These need to work on Linux and Windows. I believe these things insure that people working on other aspects of Daffodil will not be inadvertently breaking the C backend indetectably. That's one major concern I would have. ________________________________ From: Interrante, John A (GE Research, US) <john.interra...@ge.com> Sent: Wednesday, March 10, 2021 4:24 PM To: dev@daffodil.apache.org <dev@daffodil.apache.org> Subject: Acceptance criteria for merging DFDL-to-C backend (runtime2-2202)? Thanks to Mike's suggestion, I have moved the Runtime2 ToDos (changes requested by reviewers) from the DAFFODIL-2202<https://issues.apache.org/jira/browse/DAFFODIL-2202> issue to an AsciiDoc document in the dev/design-notes subtree of the Daffodil website which you can read here: https://daffodil.apache.org/dev/design-notes/runtime2-todos/ I would like to discuss which acceptance criteria the runtime2-2202 development branch must meet before I can submit a pull request to merge the DFDL-to-C backend and code generator into the main branch. I plan to address the Runtime2 ToDos and I especially want to run some of Daffodil's TDML tests on the new runtime2 backend as well as the runtime1 backend by adding defaultImplementations="daffodil daffodil-runtime2" to certain TDML tests' attributes. (Although I suggest we use the shorter name "daf-c" or "runtime2" because "daffodil daffodil-runtime2" is a lot of characters to put into the defaultImplementations attribute.) Daffodil's Confluence describes Runtime2's design here: https://cwiki.apache.org/confluence/display/DAFFODIL/WIP:+Daffodil+Runtime+2 In particular, it suggests we divide the implementation of runtime2 into two distinct phases: * Phase 1 (aka Runtime2P1): No expressions. All lengths are fixed. All arrays have fixed length. * Phase 2 (aka Runtime2P2): Adding the DFDL expression language, lengthKind 'explicit', occursCountKind 'expression'. I think phase 1 is almost done but we need to run a subset of Daffodil's TDML tests on runtime2 before we can really say for sure. Here is an initial set of discussion points - more questions and criteria are welcome: 1. Which Daffodil TDML tests do we need to run on runtime2 to assert that phase 1 is complete? 2. Can we merge runtime2 when these tests pass and then build out phase 2 in the main branch, hopefully with help from other developers once they see how useful phase 1 is? 3. Which of the Runtime2 ToDos need to be done before the merge as well? Once we agree on a minimal set of acceptance criteria for the merge, I'll copy the criteria to the JIRA issue.