Hi Alan,
At the very least, this adds a synchronized method call (to check the
size of the listener pool) to every Jess function call, and this is
really too large of an overhead. Actually, it might add at least several such
calls, since there would be a separate listener pool for each Rete
object, and the static 'execute' methods would need to find the
appropriate pool, then check the size.
You can certainly do what you want via defadvice, though. You would
advice all functions with a stub that fired off the events. It could
track the (per-thread, per-Rete) Jess stack and put this information
into the events. The stub object itself would accept the debugger as a
listener.
On the other hand, the cost of having this event source built-in could
be reduced by using an 'event mask'. Checking the mask to see whether
or not to check the size of the listener pool to see whether or not to
fire events... would be much cheaper; just checking a bit in a member
field, maybe two unsynchronized method calls to get the field.
An event mask might be a good way to improve performance in other
ways, too. I'll take a look and see what I can do with that idea.
I think Alan Moore wrote:
>
> Will source context be available? The debugger needs to know that function
> xyz is being called from the RHS of a specific rule (it may also be that
> function xyz is called from multiple lines of code in a given RHS.) This
> information is needed in order need to display the source code and current
> line of execution.
>
> As noted in the readme file:
>
> "In this release, there is only one event class, one listener interface, and
> one callback method which covers all possibilities. This is likely to change
> in the future."
>
> I hate to suggest more work but could a new event and/or listener interface
> be introduced to support source level debugging? Such a feature would
> presumably be used only by debuggers and, as such, performance degradation
> would be expected. I would think that in the non-debug case, checking for
> non-existent listeners would be fairly inexpensive.
>
> I am willing to prototype such a beast but only if there is at least a slim
> chance that the changes will make it into a Jess release (I hate writing and
> debugging throw away code.)
>
> alanm
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of Ernest Friedman-Hill
> > Sent: Tuesday, February 16, 1999 6:12 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: JESS: Debugger Event Notifications
> >
> >
> > I played with the idea of having a 'function called' event, but it is
> > too computationally expensive. There's a very noticeable slowdown, of
> > the order of 25% or so, with even a few listeners.
> >
> > Instead, the next release of Jess will have a feature called
> > 'defadvice'. Defadvice lets you attach code to a Jess function to be
> > called before or after that function runs. There will be an option to
> > advice all functions at once, too. In any case, you'll be able to
> > advice all funtions with a generic debugger stub, which will let you
> > do what ypu want.
> >
> > The advantage of this method is that it adds no overhead at all,
> > unless you use it, of course.
> >
> > I think Alan Moore wrote:
> > >
> > > I am building a debugger for jess but cannot find a way to enable single
> > > step debugging (assuming that "single step" means that the
> > debugger can step
> > > through the function calls/control structures on the RHS of a rule.)
> > >
> > > The closest thing that I can find is the DEFRULE_FIRED event
> > but it is not
> > > granular enough.
> > >
> > > Would it be possible to fire an event inside the Funcall class,
> > possibly in
> > > execute() or simpleExecute()? Ideally, the source context
> > (stream?) would
> > > be made available with the event but I would settle for whatever I can
> > > get...
> > >
> > > If necessary, I can make the modifications myself and give them
> > to you for
> > > validation and integration into your sources.
> > >
> > > Suggestions?
> > >
> > > alanm
> > >
> > > Alan Moore (mailto:[EMAIL PROTECTED])
> > > Quadrant International (http://www.qi.com)
> > >
> > > ---------------------------------------------------------------------
> > > 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]
> > > ---------------------------------------------------------------------
> > >
> > >
> >
> >
> > ---------------------------------------------------------
> > 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]
> > ---------------------------------------------------------------------
> >
>
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
>
---------------------------------------------------------
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]
---------------------------------------------------------------------
