Greetings, I've tried to use the current event model to determine which Node passed a given Token along to its successor, without any success. I have no way of tracking a Token, since new Tokens are created for each hop in the Rete network and their current attribution does not carry a unique identifier. Consequently, I have no way of disambiguating which predecessor Node that caused a RETE_TOKEN_LEFT event in a given Node, when that Node has multiple predecessors. Consequently, I can not identify which Nodes have propagated a Token after a change in the fact base. From my perspective, there are three choices ...
1) Modify the event model to provide events upon exit from a given Node, as described below. I would be happy to take a crack a modifying the code and including it as suggested patch. However, I'm inferring by the lack of response to my previous post that this modification would not be welcome. With any luck, I'm wrong. 2) Add state information to the Token object which reflects which Node generated the Token. This approach does not appeal, because obviously the Rete implementation functions quite nicely without it, it adds overhead, and it's applicability is very narrow. 3) Give up, and fork the code base. A horrible solution, for obvious reasons! ;) If I've left anything out, please let me know. I'm quite excited in that my application's view of the Rete network has already providing great debugging assistance to my development team, even though some false positives result. Regards, Steve > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of Steve Webster > Sent: Thursday, April 25, 2002 2:40 PM > To: [EMAIL PROTECTED] > Subject: RE: JESS: Debug Utility > > > Ernest, > > You raise points that I had not considered, but I think you get > to the issue > when you mention, "a NodeViewer gets an event, and it knows it > describes the > node being displayed." The difference in our perspective can be attributed > to how our respective applications "describe the node being displayed." > > Here's where I demonstrate my ignorance of the Rete algorithm and probably > your implementation, but let me proceed none the less. Description of the > node has to do, from my perspective, with which tokens it successfully > passes to its successors, not the tokens it acts upon. Stated another way, > I'm not interested in all the tokens a node sees, rather I'm only > interested > in the tokens that satisfy the node's propagation logic. I > noticed that many > of your Node's toString results describe nodes as "Tests ...." I'm > interested in displaying whether those test have been met. If the network, > as depicted by other event consumers such as "(view)," is better described > by the Token inputs, then my argument is invalid. > > Finally, I understand your reluctance to expose the JESS > internals, but the > tag should be benevolent. Since Java would return this value by copy, > there's no opportunity for hacks like me to corrupt JESS during > run time. I > knew better than to ask you for hasLHS.getNodes to be public for just that > reason! > > HTH, > Steve > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > > Behalf Of [EMAIL PROTECTED] > > Sent: Thursday, April 25, 2002 1:58 PM > > To: [EMAIL PROTECTED] > > Subject: Re: JESS: Debug Utility > > > > > > I think Steve Webster wrote: > > > Ernest, > > > > > > Thanks for your support. Now that you've given me a leg to stand upon, > > > perhaps I could suggest another change. > > > > > > I noticed that these node events that now carry tokens are > all generated > > > upon the token's arrival in the class. Ideally, the event would > > be generated > > > right before the token is propagated to the next node. Under > the current > > > implementation, there's no way to determine what node delivered > > the token > > > that triggered the event broadcast. However, if the event was > > generated by a > > > node just before the token is propagated to adjacent nodes, one could > > > uniquely determine how far the token propagated through the > > Rete network. If > > > one was still interested in determining which nodes were > > getting the token, > > > that information would still be available via the originating node's > > > getSuccessor method. > > > > This also has the added benefit that the number of events is reduced by > > the "fan-out" factor. On the other hand, it does complicate the > > application that the whole mechanism was originally designed for, > > doesn't it? In the current "view" implementation, a NodeViewer gets an > > event, and it knows it describes the node being displayed. In the > > proposed implementation, a NodeViewer would have to listen to the > > inputs instead. Since there are currently no back-pointers in the Rete > > network, I'm not sure how this would get set up. > > > > You've probably got something in mind, so let me know how it would work. > > > > > > > > > > Finally if you're so inclined, perhaps you could introduce a > > public accessor > > > method for the Token's m_tag attribute. > > > > This is obviously necessary for what you're doing, but you can imagine > > it makes me shudder a bit. The more detail is exposed, the more > > headaches I have when things change. OTOH, this is pretty stable, so OK. > > > > > > > > Thanks again, > > > 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] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
