[rules-users] Problem with Negative Patterns and Temporal Constraints

Geoffrey De Smet ge0ffrey.spam at gmail.com
Tue Jan 17 05:09:55 EST 2012



Op 17-01-12 10:41, Mark Proctor schreef:
> On 17/01/2012 08:27, Weiss, Wolfgang wrote:
>>
>> Thank you for the quick answer! This makes absolutely sense and the 
>> rules work now as expected.
>>
>> Unfortunately, I was not able to find this somewhere in the 
>> documentation. It would be nice to see it in the documentation of 
>> drools fusion.
>>
> Documentation is something anyone can do with a spare 10 minutes:
> 1) install git
> 2) install xmlmind
> 3) "fork" drools on github, https://github.com/droolsjbpm/drools
> 4) clone your fork locally
> 5) make changes to files with xmlmind, or xml editor of choice
> https://github.com/droolsjbpm/drools/tree/master/drools-docs/drools-fusion-docs/src/main/docbook/en-US
> 6) commit changes, push changes back to github
> 7) use github gui to submit a pull request for your changes.
>
> It'll be more obvious to users what documentation is missing, and 
> they'll be able to word it better in a way that makes more sense to 
> other users.
If it's just a typo you want to fix, there's a very fast method:
1) Go to github to the correct file, for example:
https://github.com/droolsjbpm/drools/blob/master/drools-docs/drools-fusion-docs/src/main/docbook/en-US/Chapter-Features/Chapter-Events/Section-Events_Semantics.xml
2) Click "Edit this file", edit it and save
3) We automatically get a pull request and can accept it easily.

The only thing that can take longer then a few seconds here is 1) 
finding the file.
But maybe the pressgang-styles can be adjusted
to generate a link next to each section title to the docbook source file 
on github.
>
> Mark
>>
>> Best,
>>
>> Wolfgang
>>
>> *Von:*rules-users-bounces at lists.jboss.org 
>> [mailto:rules-users-bounces at lists.jboss.org] *Im Auftrag von 
>> *Wolfgang Laun
>> *Gesendet:* Montag, 16. Jänner 2012 15:58
>> *An:* Rules Users List
>> *Betreff:* Re: [rules-users] Problem with Negative Patterns and 
>> Temporal Constraints
>>
>> I don't see that the "not" CE excludes the AnalysisCue bound to $cue 
>> from being
>> matched by the pattern inside the "not". I recommend using
>>
>> *   not*(AnalysisCue(*this != $cue*, this after[0ms,2500ms] $cue) from
>>
>> since "[0ms,..." does not inhibit the same event being matched by 
>> both patterns,
>> which precludes the rule from firing.
>>
>> -W
>>
>> 2012/1/16 Weiss, Wolfgang <Wolfgang.Weiss at joanneum.at 
>> <mailto:Wolfgang.Weiss at joanneum.at>>
>>
>> Hi all!
>>
>> We have the problem that the following rule never fires:
>>
>> *rule*"test-rule"
>>
>> *agenda-group* "evaluation"
>>
>> *salience* 100
>>
>> *when*
>>
>>              $cue : AnalysisCue() *from* entry-point "LowLevelCueStream"
>>
>> *not*(AnalysisCue(*this* after[0ms,2500ms] $cue) *from* entry-point 
>> "LowLevelCueStream")
>>
>> *then*
>>
>>              logger.debug("... some message ..");
>>
>> *end*
>>
>> We found out that the problem is the combination of the negation with 
>> the conditional element "not" and the temporal constraint 
>> "[0ms,2500ms]". Using the temporal operator "this after $cue" without 
>> a temporal constraint works correct in its semantics.
>>
>> Interestingly, when adding a constraint (cueType == 1) to the type in 
>> the negative pattern the rule begins to work. The rule would look 
>> like as follows:
>>
>> *rule*"test-rule"
>>
>> *agenda-group* "evaluation"
>>
>> *salience* 100
>>
>> *when*
>>
>>              $cue : AnalysisCue() *from* entry-point "LowLevelCueStream"
>>
>> *not*(AnalysisCue(cueType == 1, *this* after[0ms,2500ms] $cue) *from* 
>> entry-point "LowLevelCueStream")
>>
>> *then*
>>
>>              logger.debug("... some message ..");
>>
>> *end*
>>
>> unfortunately the rule then fires with a delay of 4 to 5 seconds. The 
>> second parameter of the temporal constraint influences the delay.
>>
>> When changing the first parameter of the temporal constraint to a 
>> value greater than 0 the rule works as expected! The constraint would 
>> then look like as follows: "[1ms, 2500ms]". Whereas in our case, we 
>> want to evaluate the time window from 0 -- 2500ms.
>>
>> Our system works in the stream mode and we could reproduce this 
>> behaviour with the versions 5.3.1 and 5.4.0 Beta 1.
>>
>> Can anybody confirm if this is a bug in Drools, or did I overlook 
>> here something?
>>
>> Best regards,
>>
>> Wolfgang Weiss
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-- 
With kind regards,
Geoffrey De Smet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120117/bb007617/attachment.html 


More information about the rules-users mailing list