You can disregard the classpath trouble I mentioned in my previous message. It was due to some Korn shell issue that I won't have time to ferret out right now. But the definstance'd shadow facts work fine when I fire the command-line via Windows shell (cmd.exe):
Jess> (batch msgtest.clp) <== Focus MAIN ==> Focus INTERCEPT FIRE 1 INTERCEPT::process-message f-2,, f-1 <== Focus INTERCEPT ==> Focus MAIN <== Focus MAIN 1 So the mystery persists in my embedded app. Why does the exact same code work from the command-line, but not via embedded? On Wed, Feb 27, 2008 at 10:06 AM, D Moon <[EMAIL PROTECTED]> wrote: > $ 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 >
