Awesome Richard,
All our tests pass with this PR. I only migrated a utility class, which is used
in several places. This is just a trial balloon for comparing performance and
behaviour with JCasUtil. I tried the uimaFIT benchmark you mentioned, and
judging from the output of this, it appears
On 3. Nov 2020, at 15:01, Mario Juric wrote:
>
> I created the Jira issue with a small Maven project that reproduces the
> issue. However, it seems to be related to the use of uimaFIT, since removing
> the uimaFIT references and running the test in uimaj-core didn’t reproduce
> the problem.
Hi Jerry,
> On 3. Nov 2020, at 17:52, Jaroslaw Cwiklik wrote:
>
> My apologies for a late reply to your question. The UIMA-AS client does not
> support vm protocol between clients and services. Only tcp and http are
> currently supported as you've noted. You can manage broker persistence
>
My apologies for a late reply to your question. The UIMA-AS client does not
support vm protocol between clients and services. Only tcp and http are
currently supported as you've noted. You can manage broker persistence
settings in the broker configuration See
http://activemq.apache.org/persistence
His Richard,
I created the Jira issue with a small Maven project that reproduces the issue.
However, it seems to be related to the use of uimaFIT, since removing the
uimaFIT references and running the test in uimaj-core didn’t reproduce the
problem.
Cheers
Mario
> On 3 Nov 2020, at 14.00,
Hi,
I tried enabling type priorities, but not surprisingly it didn’t make any
difference when I also haven’t defined type priorities. If its true that the
behaviour for coveredBy is that undefined without type priorities, so that it
doesn’t include annotations with the same bounds, then it
Hi Richard,
I also just tried to add the same test to uimaFIT JCasUtilTest, replacing
SubType with Token as well, but keeping the code that creates the JCas using
JCasFactory. In this project it fails as well. So, I guess the problem must
somehow be related to the uimaFIT use. Maybe you could
Maybe you can attach a full Maven project which reproduces the issue on your
machine to the Jira.
If I can reproduce it locally, I can look into fixing the issue.
-- Richard
> On 3. Nov 2020, at 13:52, Mario Juric wrote:
>
> Hi Richard,
>
> I was in the middle of reporting the issue in
Hi Richard,
I was in the middle of reporting the issue in JIra, when I received your mail.
The test fails in my project, but it passes when I do like you do. Don’t know
what the difference is, except that we use uiamFIT in our project. I also tried
to define SubType manually outside the XML
On 3. Nov 2020, at 11:42, Richard Eckart de Castilho wrote:
>
>> I checked out the latest from master and installed it, but the unit test
>> still fails in the same way.
>
> roger, I'll check it out.
>
> If you want to do me a favor, please open an issue on Jira and put your test
> case code
On 3. Nov 2020, at 12:10, Raffaella Ventaglio
wrote:
>
> Hi, unfortunately I can't try your example at the moment, but if
> `/JCasUtil.selectCovered/` behavior is similar to
> `AnnotationIndex.subiterator` behavior, than having an arbitrary ordering
> between your annotation types could
On 03/11/20 11:19, Mario Juric wrote:
Thanks Rafaella.
We haven’t had any need for type priorities yet, so we don’t use this feature
at all. I am not sure, how the problem I am describing, where these annotations
are not included in the selection, can be caused by arbitrary ordering?
Hi,
Hi,
> On 3. Nov 2020, at 11:40, Mario Juric wrote:
>
> I checked out the latest from master and installed it, but the unit test
> still fails in the same way.
roger, I'll check it out.
If you want to do me a favor, please open an issue on Jira and put your test
case code there.
Cheers,
--
Hi Richard,
I checked out the latest from master and installed it, but the unit test still
fails in the same way.
Cheers
Mario
> On 3 Nov 2020, at 11.07, Mario Juric wrote:
>
> Thanks for the info Richard.
>
> This is good to know, so we’ll stick with uimaFIT for now. Given some of the
>
Thanks Rafaella.
We haven’t had any need for type priorities yet, so we don’t use this feature
at all. I am not sure, how the problem I am describing, where these annotations
are not included in the selection, can be caused by arbitrary ordering?
Cheers
Mario
> On 3 Nov 2020, at 09.49,
Thanks for the info Richard.
This is good to know, so we’ll stick with uimaFIT for now. Given some of the
things I read about it, I expected the SelectFS to be faster, but to be sure I
also intended to make my own performance measurements as part of these initial
steps, therefore its nice that
Btw...
> On 2. Nov 2020, at 22:16, Mario Juric wrote:
>
> jCas.select(annotationType).coveredBy(annotation)
I did some local speed measurements and in particular for the "coveredBy"
selector,
SelectFS is presently a good deal slower than the uimaFIT equivalent. I didn't
look
into speeding
HI Mario,
> On 2. Nov 2020, at 22:16, Mario Juric wrote:
>
> In this case all annotations that have the exact same bounds as annotation
> are not selected, only those that are completely enclosed get selected (begin
> > annotation.getBegin() and end < annotation.getEnd()). The JCasUtil
Hi Mario,
Have you defined the TypePriority[0] for your /SubType/ Annotation?
As per the /AnnotationIndex/ documentation[1] this property impacts the
ordering of different annotation types with an equal span coverage:
* Annotations whose start offsets are equal and whose end offsets are
19 matches
Mail list logo
