The push to this branch on my fork usually causes our workflows that test it on all those configurations, to run.
Nothing running though. It says no workflows. Anybody have a clue why? On Sun, Mar 24, 2024 at 12:24 AM Mike Beckerle <notificati...@github.com> wrote: > *@mbeckerle* commented on this pull request. > > Latest update resolves all issues I know of. > @olabusayoT <https://github.com/olabusayoT> @tuxji > <https://github.com/tuxji> or others, I need additional review. > There are many changes here, but most are uninteresting. The thing to do > is look at the layers in daffodil-runtime1-layers > <https://issues.apache.org/jira/browse/DAFFODIL-runtime1-layers>, and the > tests of those in daffodil-core > <https://issues.apache.org/jira/browse/DAFFODIL-core>/src/test/.../layers > and daffodil-test > <https://issues.apache.org/jira/browse/DAFFODIL-test>/src/test/.... > layers. Then the implementation in daffodil-runtime1 > <https://issues.apache.org/jira/browse/DAFFODIL-runtime1> > /src/main/...layers. > > I think there should be good test coverage now also. As I added a bunch of > tests to exercise the error paths. > ------------------------------ > > In > daffodil-runtime1-layers/src/main/scala/org/apache/daffodil/layers/runtime1/BoundaryMarkLayer.scala > <https://github.com/apache/daffodil/pull/1187#discussion_r1536734445>: > > > + * the data stream on unparsing. > + * @param layerEncoding a string which is the name of the character set > encoding used to > + * decode characters during the search for the > boundary mark, and used > + * to encode characters when inserting the boundary > mark when unparsing. > + */ > + private[layers] def setLayerVariableParameters( > + boundaryMark: String, > + layerEncoding: String, > + ): Unit = { > + this.boundaryMark = boundaryMark > + if (boundaryMark.isEmpty) > + processingError("The boundaryMark variable value may not be empty > string.") > + if (boundaryMark.length > maxBoundaryMarkLength) > + processingError( > + s"The boundaryMark string length may not be greater than the limit: > $maxBoundaryMarkLength", > + ) > > Latest commit the approach to this has changed. All exceptions are by > default fatal, but a call to setProcessingErrorException can be used to > mark an exception (or runtime exception) to be converted into a parse error. > > — > Reply to this email directly, view it on GitHub > <https://github.com/apache/daffodil/pull/1187#pullrequestreview-1956471656>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AALUDA5TKUBOBHJEDB7RK2LYZZIOXAVCNFSM6AAAAABEZV4WB6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNJWGQ3TCNRVGY> > . > You are receiving this because you are subscribed to this thread.Message > ID: <apache/daffodil/pull/1187/review/1956471...@github.com> >