I'm trying to go with your latter suggestion, registering JessListeners to Nodes, and I noticed that all RETE_LEFT_TOKEN events do not carry Token objects as part of the event. Rather some event generators, Node1 and Node1LTR, carry Facts as the event objects, whereas others, NodeTest and Node2, carry Tokens. This inconsistency in JessEvent object references makes instrumenting the network difficult, because I would like to make use of the Token tag to trap additions versus removals. Also, it appears that the ViewFunctions.NodeViewer.eventHappened method assumes that all event object will be tokens, and therefore it breaks when Nodes broadcasting Facts are being displayed.
I suggest that Node RETE_LEFT_TOKEN events carry Tokens as their objects. Currently, the broadcasted facts are actually derived from the associated Token object via the topFact method. Consequently, the change to a Token reference rather than the topFact method invocation is a trivial change, and it reduces processing by one method call. I probably don't have a full appreciation for the issues, so I look forward to the feedback. Thanks, Steve > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of [EMAIL PROTECTED] > Sent: Monday, April 22, 2002 4:36 PM > To: [EMAIL PROTECTED] > Subject: Re: JESS: Debug Utility > > > If you double-click a join node in the "view" display, it shows you > the contents of both memories in that node; in theory, this is > equivalent to the information you're looking for, if not so > convenient. The (matches) command give out this same information. Both > (matches) and (view) get their information from Node2.displayMemory(), > so that would be one place to look. But be warned that using > package-protected interfaces to get at the contents of the Rete nodes > is dangerous business, as things do change quite a bit between > releases -- both the interfaces and the data representation may > change. > > The only public interface to what happens inside the Rete network is > an event-based one. Every jess.Node object support JessListeners. You > can add a JessListener to a node and it will send you an event > whenever a token is delivered to it. Unfortunately there's no publi > API for getting the nodes in a rule; but cheating and using > HasLHS.getNodes() should be pretty safe. > > > I think Steve Webster wrote: > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > All, > > > > I'm interested in writing a utility that's similar to the > (view) command, > > with a bit of a twist. I'm interested understanding which predicates are > > matched, failing a rule activitation. However, I'm having difficulty > > understanding where to instrument the Rete network in order to > trap these > > partial matches. Any approaches to this problem would be greatly > > appreciated. > > > > Much obliged, > > Steve > > > > > --------------------------------------------------------- > 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] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
