Feathers going Ruffle Ruffle Ruffle. 🙂
setSuccess is a narrow little thing. It's used in the interactive debugger,
Maybe you can change it by adding an optional argument.
Backtracking in the parser involves
* the success/failure flag/object
* diagnostics accumulated since the PoU st
The Short Version:
I believe that we should change PState.setSuccess to take as an argument a
PState.Mark and revert the diagnostics that have occurred since that Mark. The
current uses of setSuccess leave diagnostics in the PState that should be
discarded. Does this ruffle anyone’s feathers?
L
We removed a bunch of warnings a while ago when adding Scala 2.12 support:
https://issues.apache.org/jira/browse/DAFFODIL-2145
I suspect it's just a decent amount of work to reenable these warnings
and fix whatever is broke. Something that definitely needs to be done,
it's just been relatively lo
So I got this from sonarcloud. It identifies an unused variable for sure.
Doesn't help me understand who or why it got into testing.
Question: shouldn't our scala compiler settings be giving us a warning about
this, and aren't warnings fatal per our current practices?
I wouldn't expect we'd nee
Unfortunately, I'm not sure that's an option. We don't actually have any
code to handle CatalogManager.properties file. The logic in
DaffodilXMLLoader.scala just creates a 'new Catalog', which relies on
the built in CatalogManager, and I don't see any way to specify an
alternate file for the .prope
There's some discussion in the PR, but for this mailing list I wanted to
comment that this is indeed a deep area of algorithmic complexity in the
Daffodil runtime.
Whether the code is actually factored adequately such that it enables
implementing the right DFDL behavior is not entirely clear, b
I'm leaning towards +1 for removing these tests. If the reason for keeping
them is good enough (to prevent regressions in the code being tested), then I
would suggest an easier change than creating a separate test module or making
the tests CLI tests. The tests could create files in random tem
Yes, but it feels a bit wasteful to create a new module for three tests.
Note that one of the tests is just testing that the test rig in this
file works correctly. So there's really only two tests here.
Also note that we can't change the working directory when forked per
test, so each test would n
Is there any way to have a separate test module where tests are all run with
fork = true?
From: Steve Lawrence
Sent: Monday, October 26, 2020 9:54 AM
To: dev@daffodil.apache.org
Subject: TestDaffodilXMLLoader non-thread safe tests
We have three tests in TestDaff
We have three tests in TestDaffodilXMLLoader that had a random failure
in Github Actions for a pull request I created that updates SBT to
1.4.1. Looking at these tests, I believe they are not thread-safe and
that's likely causing the failure I'm seeing.
The way they work is each tests creates a sc
10 matches
Mail list logo
