On 1. Aug 2019, at 23:24, Hai-son X Nguyen wrote:
>
> We could adjust the update to return FSArray
> instead to meet the source compatibility too.
The type system descriptor knows which kind of feature structure is returned,
so we should use that information. It saves client code from
checked signatures: OK - but the filename is missing
from uimaj-2.10.4-source-release.zip.sha512
installed binary & ran document analyzer: OK
checked docs: OK
build from sources: OK
checked signatures & docs: OK
extracted the build & ran document analyzer: OK
ran an NLP pipeline with many
Sorry, let me rephrase, the 3.0.0 - 3.0.2 version exposed potential bugs. As
our code is littered with FSArrays I wanted to fix the warnings to prevent
future calamities like below:
Sentence sentence = ...;
FSArray tokens = sentence.getTokens();
tokens.set(1, sentence); // <- compile error
On 1. Aug 2019, at 21:41, Hai-son X Nguyen wrote:
>
> for (FeatureStructure attrFS : (Iterable)
> aElement.getAttributes()) {
> ...
> }
>
> I don't think it is a runtime error but a bug on the DKPro side, the FSArray
> contract is FSArray implements Iterable
I also don't think it'd be a
This is a good catch; I think properly the loop needs a better castt:
for (FeatureStructure attrFS : (Iterable)
aElement.getAttributes()) {
...
}
I don't think it is a runtime error but a bug on the DKPro side, the FSArray
contract is FSArray implements Iterable
Thanks!
Hai-Son
On 8/1/19,
On 1. Aug 2019, at 20:44, Marshall Schor wrote:
>
> I'm wondering if other codes will also break, and if the benefit of this
> change
> is worth the trouble it will cause in being backwards compatible.
>
> Opinions?
I think the change is a good one and should be kept.
Getters and setters
I'm wondering if other codes will also break, and if the benefit of this change
is worth the trouble it will cause in being backwards compatible.
Opinions?
Mine tends to lean toward not doing this kind of thing, until we have a good
reason to cause the user community to do maintenance on their
On 1. Aug 2019, at 16:24, Marshall Schor wrote:
>
> Is this easy to "fix" in DkPro ?
Yep, easy to fix. Basically just remove the explicit type-cast.
But still it's something I wouldn't expect in a bugfix release.
-- Richard
ouch...
I tend to agree with you...
Is this easy to "fix" in DkPro ?
-Marshall
On 8/1/2019 6:09 AM, Richard Eckart de Castilho wrote:
> dist artifact signature check: ok
> README spot check: ok
> RELEASE_NOTES spot check: ok
> API report spot check: ok
> Built from sources: ok
>
> Building
dist artifact signature check: ok
README spot check: ok
RELEASE_NOTES spot check: ok
API report spot check: ok
Built from sources: ok
Building DKPro Core against the RC, I get a compiler error:
With v3.0.2, JCasGen generated this code:
```
public FSArray getAttributes() { return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Spot checked source changes: ok
Dist artifact signatures: good
Built from svn tag: ok
RELEASE NOTES: ok
API report spot check: ok
Fixed issues list: ok
README file: ok
There were a few additional oddly indented lines - I have committed
11 matches
Mail list logo
