Re: TypePriorities configured in the descriptor of an aggregate engine are not added in uima-as

[nelson rivera]

Jerry, i understand and wait. Thanks for your attention.

2017-08-16 15:09 GMT-04:00, Jaroslaw Cwiklik :
> Nelson, I need more time to look into this. Quite busy at a moment. Unless
> someone else wants to jump in here I will address the problem when I am
> done with current work load,
>
> Jerry
>
> On Mon, Aug 14, 2017 at 4:36 PM, Jaroslaw Cwiklik 
> wrote:
>
>> Thanks, I will try to test this scenario and get back to ya.
>>
>> Jerry
>>
>> On Mon, Aug 14, 2017 at 4:27 PM, nelson rivera 
>> wrote:
>>
>>> Yes, that is happening
>>>
>>> 2017-08-14 15:40 GMT-04:00, Jaroslaw Cwiklik :
>>> > Please confirm that this is happening:
>>> >
>>> > 1) You deploy an aggregate and specify TypePriorities in aggregate
>>> analysis
>>> > engine descriptor.
>>> > 2) After uima-as client initilizes, you call client's
>>> > public ProcessingResourceMetaData getMetaData();
>>> > 3) You check the returned meta and the type priorities are missing
>>> >
>>> > You are observing correct behavior when you declare type priorities in
>>> > a delegate analysis engine descriptor of the aggregate
>>> >
>>> > Jerry
>>> >
>>> > On Fri, Aug 11, 2017 at 12:12 PM, nelson rivera <
>>> nelsonriver...@gmail.com>
>>> > wrote:
>>> >
>>> >> i have configured a priorityList in the descriptor of my aggregate
>>> >> engine, with the objetive of use correctly subiterator() function in
>>> >> my client code over the result CAS.
>>> >>
>>> >> After deploy the aggregate in uima-as, in my client code that
>>> >> consumes
>>> >> de uima-as service aggregate to check the priorityList configured i
>>> >> use the instruccion
>>> >> uimaAsynchronousEngine.getMetaData().getTypePriorities(); and not
>>> >> appear the priority configured. This does that the use of subiterator
>>> >> not have the expected behavior in the uima-as client.
>>> >>
>>> >> If the configuration of priorityList is made in the descriptor of one
>>> >> of the delegate of the aggregate, then if the instruccion
>>> >> uimaAsynchronousEngine.getMetaData().getTypePriorities()   in client
>>> >> code shows the priorityList configured and then the  behavior is the
>>> >> expected.
>>> >>
>>> >
>>>
>>
>>
>

Re: TypePriorities configured in the descriptor of an aggregate engine are not added in uima-as

[Jaroslaw Cwiklik]

Nelson, I need more time to look into this. Quite busy at a moment. Unless
someone else wants to jump in here I will address the problem when I am
done with current work load,

Jerry

On Mon, Aug 14, 2017 at 4:36 PM, Jaroslaw Cwiklik 
wrote:

> Thanks, I will try to test this scenario and get back to ya.
>
> Jerry
>
> On Mon, Aug 14, 2017 at 4:27 PM, nelson rivera 
> wrote:
>
>> Yes, that is happening
>>
>> 2017-08-14 15:40 GMT-04:00, Jaroslaw Cwiklik :
>> > Please confirm that this is happening:
>> >
>> > 1) You deploy an aggregate and specify TypePriorities in aggregate
>> analysis
>> > engine descriptor.
>> > 2) After uima-as client initilizes, you call client's
>> > public ProcessingResourceMetaData getMetaData();
>> > 3) You check the returned meta and the type priorities are missing
>> >
>> > You are observing correct behavior when you declare type priorities in
>> > a delegate analysis engine descriptor of the aggregate
>> >
>> > Jerry
>> >
>> > On Fri, Aug 11, 2017 at 12:12 PM, nelson rivera <
>> nelsonriver...@gmail.com>
>> > wrote:
>> >
>> >> i have configured a priorityList in the descriptor of my aggregate
>> >> engine, with the objetive of use correctly subiterator() function in
>> >> my client code over the result CAS.
>> >>
>> >> After deploy the aggregate in uima-as, in my client code that consumes
>> >> de uima-as service aggregate to check the priorityList configured i
>> >> use the instruccion
>> >> uimaAsynchronousEngine.getMetaData().getTypePriorities(); and not
>> >> appear the priority configured. This does that the use of subiterator
>> >> not have the expected behavior in the uima-as client.
>> >>
>> >> If the configuration of priorityList is made in the descriptor of one
>> >> of the delegate of the aggregate, then if the instruccion
>> >> uimaAsynchronousEngine.getMetaData().getTypePriorities()   in client
>> >> code shows the priorityList configured and then the  behavior is the
>> >> expected.
>> >>
>> >
>>
>
>

Re: Ruta COUNT issue

[Peter Klügl]

Hi,


I haven't tested the rule for bugs yet , so here's just a comment for now.

The order of evaluation of the conditions is fixed. The usage of 
conditions on a wildcard can lead to unexpected matches (and it can 
considerbaly decrease the runtime performance).


There is a difference between a wildcard and a reluctant quantfier like 
"ANY+?".


The wildcard takes a look at the next rule element and then evaluates 
its conditons. If a condition fails, the next rule element is consulted 
again, like moving forward on its iterator, and then the conditions are 
checked again. With a normal matching rule, the conditions are directly 
evaluated and the next element is not considered anew or skipped.



I have to test the rule in order to give you a specific answer, but that 
will take some time (I am a bit busy right now)



Best,


Peter


Am 11.08.2017 um 22:23 schrieb Tom Vacek:

Assume I have made PositiveContext and NegativeContext annotations from a
word list.   I would like a wildcard rule that allows any number of
PositiveContext tokens, some (eg 4) unknown tokens, but no NegativeContext
tokens.
I have this rule:
INT contextCount;
(Keyword1  #{COUNT(PositiveContext,0,100,contextCount),
CONTAINS(W,0,contextCount+4), -CONTAINS(NegativeContext)} Keyword2
The rule behaves unpredictably, perhaps as if the order of evaluation of
the conditions is not fixed.  Is this the case?  Or is it some other bug?

Thanks,

Tom