$ java -cp jess.jar jess.Main Jess, the Rule Engine for the Java Platform Copyright (C) 2006 Sandia Corporation Jess Version 7.0p1 12/21/2006
Jess> (jess-version-string) "Jess Version 7.0p2 10/21/2007" (clear) (deftemplate convoy (slot id)(slot x)(slot y)(slot drift)(slot state)) (deftemplate msg (slot mid)(slot id)(slot x)(slot y)(slot drift)(slot qid)) (reset) (assert (convoy (id 5) (x 1) (y 2) (drift -1) (state 1))) (assert (msg (mid 34) (id 5) (x -1) (y -1) (drift -1) (qid -1))) (defmodule INTERCEPT) (defrule process-message (msg (mid ?mid)(id ?id)(x -1)(y -1)(drift -1)(qid -1)) (not (msg (mid ?msgid&:(< ?msgid ?mid)))) (convoy (id ?id)) => ; RHS omitted ) (watch all) (focus INTERCEPT) (run) The above works as expected from the Jess command-line and the rule fires once: Jess> (batch msgtest.clp) <== Focus MAIN ==> Focus INTERCEPT FIRE 1 INTERCEPT::process-message f-2,, f-1 <== Focus INTERCEPT ==> Focus MAIN <== Focus MAIN 1 But when I focus the full INTERCEPT module from my larger Java application... -- where I'm using "convoy" shadow facts definstance'd rather than the deftemplate'd unordered "convoy" fact I used for testing above: (ppdeftemplate convoy) "(deftemplate MAIN::convoy \"$JAVA-OBJECT$ Convoy\" (declare (from-class Convoy)))" -- ...I get this nearly silent result (all watches set): <== Focus MAIN ==> Focus INTERCEPT <== Focus INTERCEPT ==> Focus MAIN Why no rules fired? At the very least, I'm expecting a (msg) fact to activate process-message. In my embedded application, I have a Jess console where I can enter command-line Jess commands and inspect what is going on. These are the relevant facts in working memory: f-0 (MAIN::initial-fact) f-14 (MAIN::convoy (class <snipped>) (drift -1) (id 2) (state 1) (x 1) (y 5) (OBJECT <snipped>)) f-15 (MAIN::convoy (class <snipped>) (drift -1) (id 5) (state 1) (x 1) (y 2) (OBJECT <snipped>)) f-32 (MAIN::msg (mid 34) (id 5) (x -1) (y -1) (drift -1) (qid -1)) f-33 (MAIN::msg (mid 36) (id 4) (x -1) (y -1) (drift -1) (qid -1)) f-34 (MAIN::msg (mid 38) (id 2) (x -1) (y -1) (drift -1) (qid -1)) f-35 (MAIN::msg (mid 39) (id 1) (x -1) (y -1) (drift 0) (qid 0)) f-36 (MAIN::msg (mid 40) (id 1) (x 2) (y 5) (drift 0) (qid 0)) I have three observations: * fact-32 appears to match all slots of the first pattern of rule process-message * there is no (msg) fact with a mid slot value less than 34 (the mid slot value for matching fact-32 in the first patter), and * fact-15 shares an id slot value with that bound in the id slot value for fact-32 But my observations don't explain what's causing my problem here. You might wonder why I used unordered convoy facts for testing, in lieu of the same shadow fact convoy instances as with the embedded version. Well, I tried to get my Convoy.class files on the classpath and was getting bogus class not found messages when trying to fire up jess.Main from the command-line via jess.jar on the same classpath. But I know this is not a classpath problem in my embedded app, because Jess runs just fine with my Java app, and the convoy shadow facts are pattern matching many other rules in other modules as well as other rules in the INTERCEPT module. There is something specific about this particular rule not matching the appropriate (msg) fact. I think my command-line test shows that I'm using the LHS syntax correctly to get the matching I want. But why the non-firing rule when embedded? I also wanted to mention that all the rules in this module have that "match the lowest mid only" pattern, so it makes perfect sense why the *other* rules in the module have not fired: they can only work on the (msg) with the lowest mid slot value, and the values for the other slots in fact-32 do not match their other patterns. I'm still struggling with that command-line classpath trouble because I want to definitively rule out some problem I can't see with convoy shadow facts. But does anyone have any comments on other possible sources for this trouble, in particular what could possibly be different during the embedded run that doesn't affect the command-line behavior of the same rules and facts? V/R, Moon --- here's another case from another (embedded) run where the same thing happened: these facts: (MAIN::initial-fact) (MAIN::msg (mid 40) (id 2) (x -1) (y -1) (drift -1) (qid -1)) (MAIN::convoy (drift 1) (id 2) (state 1) (x 6) (y 3)) should match the LHS patterns of this rule: (msg (mid ?mid)(id ?id)(x -1)(y -1)(drift -1)(qid -1)) (not (msg (mid ?msgid&:(< ?msgid ?mid)))) (convoy (id ?id)) but still got no-fire
