I think Moore, Kenneth A wrote:
>
> Earnest wrote:
>
> "Another neat new feature is that Jess will use Bean-like
> Events to notify you of various occurrences: the ReteDIsplay class wil
> disappear, replaced by a set of Listener interfaces. These Listeners
> will be much more fine-grained and will be sufficient to, for example,
> build a debugger or graphical interface on top of."
>
> [alanm]
> I am in the process of building a debugger and would like to see what your
> proposed events are. I have been making mods to Jess for just this purpose
> and would prefer to dump my work in favor of a Jess supplied facility.
This is the incomplete list as of today:
DEFRULE_ADDED=0, DEFRULE_REMOVED = 1, DEFRULE_FIRED = 2,
DEFRULE_ACTIVATED = 3, DEFRULE_DEACTIVATED = 4,
DEFFACTS_ADDED = 10, DEFFACTS_REMOVED = 11, FACT_ASSERTED = 12, FACT_RETRACTED =
13,
DEFINSTANCE_ADDED = 30, DEFINSTANCE_REMOVED = 31,
DEFTEMPLATE_ADDED = 30, DEFTEMPLATE_REMOVED = 31,
DEFCLASS_ADDED = 40, DEFCLASS_REMOVED = 41,
DEFGLOBAL_ADDED = 50, DEFGLOBAL_REMOVED = 51,
USERFUNCTION_ADDED = 60, USERPACKAGE_ADDED = 61,
CLEAR = 90, RESET = 91, RUN = 92,
RETE_TOKEN = 100, RETE_TOKEN_LEFT = RETE_TOKEN + Node.LEFT,
RETE_TOKEN_RIGHT = RETE_TOKEN + Node.RIGHT, RETE_TOKEN_SINGLE =
RETE_TOKEN + Node.SINGLE, RETE_TOKEN_ACTIVATE = RETE_TOKEN + Node.ACTIVATE;
Missing are JESS_FUNCTION_CALLED and JAVA_FUNCTION_CALLED - these will
eventually make it in there.
>
> To that end, does your event set provide context information, such as
> current file/line number, so that a dubugger can do source level debugging?
Well, as you point out, this is tough since code can come from
multiple places: executeCommand calls, streams, (batch), etc. But
eventually everything will retain some concept of its
context. Certainly everything will have a source-level representation
of itself.
>
> I have been working on this for sometime now and have not found a clean way
> to add this to Jess. My current thought is to supply a "code context"
> handle (really just a long integer or a pointer to type Object) to be given
> to Jess (via optional Jesp constructor parameter?) when loading from a
> stream. This handle would be passed along with rule execution events and
> allow the debugger to manage the code context itself.
>
> In looking at jesp.java is seems that the parser keeps track line numbers
> and filenames (via JessTokenStream) but I don't see how this information is
> available at runtime (the parser and stream are not available?)
>
> Unfortunately, I fear that the filename/lineno information is simply the
> currently executing stream (probably the one calling the "reset" or "run"
> function) which is not enouph since some rules may have been loaded via a
> separate stream/parser combo.
>
Yes, these line number ares used only by the parser itself for error
reporting. One thing I toyed with is giving the parser an ID string,
so that when you construct one, you tell it how to identify itself -
some of this could be done in default constructors. For example,
you'd pass in "file Foo.clp", so that later you'd find that a
particular construct came from "line 456 in file foo.clp". A Jesp
constructor that took a filename as argument could do this itself.
The internal parser used by executeCommand would be constructed with
"executeCommand() argument".
> Comments, suggestions?
>
> Alan Moore mailto:[EMAIL PROTECTED]
> Intel Corporation http://www.smart-tv.com
> Disclaimer http://www.intel.com/tradmarx.htm
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9214 [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. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
