Hi David,
I needed to use 5.0b3 to reproduce the problem: both my current
working copy and Jess44 do the right thing (you didn't say what
version you were using.) Anyway, I believe this is a symptom of a bug
in 5.0b3 I've already fixed; here's the appropriate patch:
diff -r jess/Node.java d:/temp/Jess50b3/jess/Node.java
71,73c71
< * Cannot use removeElement here. Some Nodes compare equal using equals(),
< * but aren't the same physical node. We only want to remove the ones that
< * are physically equal, not just conceptually.
---
> * @param s
77,82c75
< for (int i=0; i<m_succ.size(); i++)
< if (s == m_succ.elementAt(i))
< {
< m_succ.removeElementAt(i);
< return;
< }
---
> m_succ.removeElement(s);
i.e., change the single line "m_succ.removeElement(s);" at line 75 of
Node.java to the for-loop shown above.
I think G. David Barnett wrote:
> Hello-
>
> I had some code that was working great just before it stopped working in a
> very unusual place. It took me forever to realize that I unintentionally
> had two rules of the same name. Fixing this fixed the 'unrelated'
> problem. I found this odd but I was unable to determine what the
> significance was at that time due to the complexity of the application and
> time constraints. Then it happened again.
>
> Normally, issuing a defrule with a duplicate name should simply replace
> the definition and the network adjusted appropriately. This does indeed
> seem to happen for most cases. I now have some simplified code that
> demonstrates when it doesn't, but I'm still not sure exactly what is going
> on. Basically, part of the network seems to become disjoined when the
> replacement rule is added, which explains how my partially running
> application began stopping at an unusual point.
>
> View the differences in the following when the indicated defrule name is
> changed:
>
>
> ;;; BEGIN CODE
>
> (watch all)
>
> (defrule phase-change
> (declare (salience -10))
> ?phase-fact <- (phase ?x)
> ?phase-list-fact <- (phase-list ?next $?remaining)
> =>
> (retract ?phase-fact ?phase-list-fact)
> (assert (phase ?next))
> (assert (phase-list $?remaining)))
>
> (defrule a
> (phase a)
> =>
> (printout t "phase a" crlf))
>
> (defrule b
> (phase b)
> =>
> (printout t "phase b" crlf))
>
> (defrule aa ;;;;;; change 'aa' to 'a' to break it
> (phase aa)
> =>
> (printout t "phase aa" crlf))
>
> (assert (phase a))
> (assert (phase-list b c d e))
>
> (run)
>
> ;;; END CODE
>
>
> It seems I had to use salience to get it to break. Hope this is a simple
> bug for somebody else to fix . . . .
>
>
> -Dave Barnett
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
