sbt treats each argument as a separate sbt comand. So when you run:
sbt testOnly **.Link16Test
because of the space, those are seen as two separate arguments, which is
equivalent to running these back to back:
sbt testOnly
sbt **.Link16Test
If you have a single command with a space in
So due to bug DAFFODIL-2302, I have a schema where I can't run all the tests at
once via 'sbt test'.
I wanted to run the tests separately via 'sbt testOnly **.Link16Test' and 'sbt
testOnly **.Link16DERGTest' which are two different TDML test suites.
But when I do that, in every case it runs
I did have interest, but it doesn't look like I'll have the time to do any
Daffodil work for at least the next 2 weeks. I have non-issue with someone
else taking this one.
Josh
On Mar 25, 2020 3:56 PM, Olabusayo Kilo wrote:
I'd like to have the below done for 2.6.0
I'd like to have the below done for 2.6.0
https://issues.apache.org/jira/browse/DAFFODIL-2305 - Remove some unused
methods from Term.scala
https://issues.apache.org/jira/browse/DAFFODIL-2275 - Reduce code smells
and make some configuration changes to Sonarqube
I don't mind managing the
It is possible to modify in a way that is 100% compatible with existing
"correct" practice, which is to lock and unlock the object. Lock the state when
any parse/unparse call is in flight, unlock when none are in flight.
setters can then block waiting for the lock to be freed.
That's
My one minor concern about the locking after parse/unparse is that it
changes behavior, and could potentially break things (I assume use after
lock is an assertion of some kind?).
It's definitely possible to use the DataProcessor in a safe manner while
mutating the state currently if someone is
A fully functional API is probably good to have, and I'd like to define that
also and cut over to using that within Daffodil.
We would need a dataProcessor.reset() method that creates a new dp which has
had all external vars, tunables, basically any of those formerly settable
things, forgotten
I have two issues I'd like fixed for 2.6.0
https://issues.apache.org/jira/browse/DAFFODIL-2302 - this is making it
difficult to update a Link16 schema that is in use by multiple parties.
There's a second issue, which is that we still have this "NadaParsers are
supposed to optimize out"
This feels like the right approach. Thoughts on instead of having to
manually clone() and having some sort of locking mechanism when parse is
called, we just make a DataProcessor completely immutable, and setting a
variable will implicitly create a copy with modified state, something like:
val dp
Agreed on deprecating setting variables in the Compiler. It really just
doesn't make sense to be doing that.
Definitely seems reasonable to add the ability to set variables when
calling parse/unparse as that's the most threadsafe way to handle it,
and feels natural to me. Note that we still have
Here's my concrete proposal to fix DataProcesor's API.
We add a clone() method. It copies the object sharing the big/expensive stuff
like the compiled schema but gives you a separate copy of all the state that is
settable via setValidationMode, setExternalDFDLVariable, and setTunable.
So you
To respond to my own thread here, I think given that we allow multiple
simultaneous calls to parse/unparse from different threads, we must say that
the DataProcessor object is immutable once parse or unparse are called.
I suppose we could say that it is mutable, but behavior is undetermined if
Why does the API for Daffodil have
Compiler.setExternalDFDLVariable(...)
and
Compiler.setExternalDFDLVariables(...)
on it.
I believe we should deprecate this.
Compilers are parameterized by some of the tunables I understand.
But the external DFDL variables? These cannot affect compilation.
13 matches
Mail list logo
