Hi,
First of all, let me say that the order in which rules fire has indeed
changed between Jess 4.4 and the default "depth" strategy in Jess
5.0. The new ordering is the one that is considered "correct" by most
production-system researchers.
The "breadth" strategy, by definition, will never fire "old"
activations as long as there are newer ones on the agenda; since
you're writing rules that deliberately keep generating new
activations, the breadth strategy is not a good choice and you should
stick with the default.
Now. As far as agents with time-dependent behavior: this is something
I do all the time. There are two major strategies, which I'll describe
here. The first one is from the FAQ. In this first strategy, all the
agents are in one process, and you have rules that explicitly depend
on time. In this case you need an "idle' rule, something like
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; This fact will be used to sleep when idle
(deffacts idle-fact
(time 0))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; This rule will always be on the agenda! Make the salience
;; lower than any other rule.
(defrule sleep-if-bored
(declare (salience -100))
?idle <- (time ?)
=>
(retract ?idle)
(call java.lang.Thread sleep 100)
(assert (time (time))))
The rule "sleep-if-bored" is like a clock, which keeps a single fact
(time ?t) on the fact-list all the time. Rules with time dependence
just need to match on this fact:
(defrule initiate-future-action
(some-condition)
(time ?t)
=>
(assert (fire-now (+ ?t 20))))
(defrule execute-future-action
(time ?t1)
?f<- (fire-now ?t2&:(>= ?t2 ?t1))
=>
(retract ?f)
(printout t "It's 20 seconds later!" crlf))
The second rule will fire roughly 20 seconds after the first.
That's the first scheme. In the second scheme, the time-dependent
activities happen outside of Jess - i.e., in Java. This is a good
strategy if the agents are separate Java processes communicating on a
network; messages are received in a background thread and asserted
from those background threads. Then all you need is to keep the engine
running all the time. In this case, simply use (run-until-halt)
instead of (run). This function will sleep when there are no
activations instead of returning; it will wake up automatically when
any new facts are asserted that activate rules.
I could mention a third scheme in which separate Threads are used but
in which all the code is written in Jess. I've got a utility class
JessThread which I use for my own work that looks like this:
package gov.sandia.eiagent.jess;
import jess.*;
/**
* Lets you write the run() method of a Thread in Jess.
*/
public class JessThread extends Thread
{
private String m_name;
private Rete m_engine;
public JessThread(String routineName, Rete engine)
{
m_name = routineName;
m_engine = engine;
}
public void run()
{
try
{
Funcall f = new Funcall(m_name, m_engine);
f.execute(m_engine.getGlobalContext());
}
catch (JessException je)
{
System.out.println("Exception in background thread: " + je);
if (je.getNextException() != null)
System.out.println(je.getNextException());
}
}
}
You can use this like this:
(deffunction run-in-thread() (something-interesting))
(call
(new gov.sandia.eiagent.jess.JessThread run-in-thread (engine))
start)
(run-until-halt)
Now if the function (something-interesting) asserts a fact, it can
cause the main thread to wake up and fire some rules. You can run any
number of Threads at once, of course.
In any event, these techniques should cover pretty much every
situation. An "official" version of JessThread (or something like it)
will appear in a future release.
I think Erwan Tranvouez wrote:
> Hi,
>
> I'm using Jess 5.0 and I have some problems with the rules activations.
>
> I am programming intelligent (cooperatiNG) Agents in/with Jess. For the
> moment, an agent is a jess Console "batching" some behaviours Jess files.
>
> --------------
> REQUISIT :
> --------------
>
> Therefore I need a rule for :
> 1) assuring at least one rule is active (minimal behaviour)
> 2) checking REGULARLY if there is some message in one's agent Mailbox
> 3) enforce REGULARLY some (test ) value based on time. For exemple if I
> want my agent
> to wait for 20 seconds for new messages WITHOUT blocking the other rules
> firing.
>
> Using strategy breadth enabling a "multi-tasking" rule behaviour... and
> avoiding
>
> --------------
> CONTEXT :
> --------------
>
>
> Therefore I used a rule as follows:
>
> (defrule cycle
> ?f <- (cycle ?num)
> =>
> (retract ?f)
> (if < check for message >
> then
> (assert (message <get the message> ) )
> ) ; end if
> (assert (boucle (+ ?num 1) ) ) ; ?num used for debuging ...
> )
>
> Alas, depending on when the rules is loaded, rules depending on (cycle ?)
> to enforce some test (mostly temporal) (test <constraint>) where
> deactivated then reactivated but never fired as cycle was always modifying
> the fact-id.
>
> Therefore, rather than playing with the organisation of the rules I
> developped 2 rules :
>
> (defrule cycle
> ?f <- (cycle ?)
> =>
> <message management>
> (assert (boucle (+ ?num 1) ) )
> (assert (retract-f ?f))
> )
>
> and a rule
> (defrule retract-fact
> ?f2 <- (retract-f ?f1)
> =>
> (retract ?f1 ?f2)
> )
>
> ..
> The solution I admit is rather tricky and not really neat but I used the
> fact that
> rules depending on (cycle) would fire BEFORE the retract-fact rule as
> specified by
> the breadth strategy.
>
> But this may have (sic) resulted in some Overhead in the rule management,
> but worse
> do not work with Jess5. Although some rules are scheduled for activation
> they are not
> immediately activated and the firing behaviour becomes quite strange as if
> Jess forgot
> about my rules and some time after recalled to fire it,...
>
> I was wondering if this was due to the new implementation of the strategy
> class as it
> is now based (if I am correct) on the time of assertion of the rule
> activation ...
>
> So finally is my humble request :
>
> --------------
> QUESTION :
> --------------
>
> Does anyone encountered some pb with the new strategy implementation (ie
> since jess44) and
> if not, does anyone has a neat solution for my 3 points requirement
> described above
> (REQUISIT)...
>
> SOrry for the length of the mail but I wanted to give a good picture of the
> pb (not sure if I succeded...).
>
> Thanks for any answer or even clue ...
>
> Erwan Tranvouez
> ====================================
> Erwan TRANVOUEZ
> _______
> E-mail: [EMAIL PROTECTED]
> URL: http://www.chez.com/~etranvouez
> ____________________________________
> Telephone Personnel/Personal Phone Number
>
> 04 42 89 17 12
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
