Debugger

A couple of things.

I've noticed that it is now possible to step into Semaphore>>critical: (or was
it Mutex>>critical: ?).  Is that chance by design ?  If not then I'll raise a
bug report.

The other thing is an enhancement request, I don't know if it's possible to get
it into this release (I guess not) but I think it should be scheduled with
pretty high priority for a future release.  I've just spent a day trying to
isolate a problem with OmniBase/STS (see another post) and had a great deal of
difficulty with the debugger.

The problems are caused by the very active nature of the display -- it keeps
invoking code on the objects I'm trying to look at.  Not only does the variable
pane do this (and, just to repeat an earlier post, I don't think making that
ListView virtual was the right thing to do); but also the code-completion
engine keeps doing it too.  OmniBase uses DNU proxies, which are lazily
resolved, and so the debugger's view keeps trying to resolve them -- just as
I'm trying to debug through that operation :-(

For instance, if I want to look at an ODBReference's #odbGetOid (a message that
does not cause it to resolve itself), typing in:

    anODBReference get

causes the code-completion engine to send #class to the reference (which does
cause it to resolve), resulting in a walkback as the resolution fails (which is
what I was attempting to debug).  The real problem isn't really a few
walkbacks, of course, nor the "wrong" values appearing in the variables pane,
but that they disturb the state of the object I'm trying to look at.

I think we need a way to tell the debugger "be very dumb" for use when we are
debugging things with any kind of lazy initialisation.  I (and others) have
asked for this a few times in the past.  I'll raise an ER, but I'll wait till
I've had some feedback here first.

    -- chris

Chris,

> The problems are caused by the very active nature of the display -- it keeps
> invoking code on the objects I'm trying to look at.  Not only does the variable
> pane do this (and, just to repeat an earlier post, I don't think making that
> ListView virtual was the right thing to do); but also the code-completion
> engine keeps doing it too.  OmniBase uses DNU proxies, which are lazily
> resolved, and so the debugger's view keeps trying to resolve them -- just as
> I'm trying to debug through that operation :-(

One thing to consider: does OmniBase define too much of the Object
protocol?  When you say the debugger tries to resolve the proxies, it
might be that OmniBase is doing too much in response to house keeping
inquires by the debugger.  Just a thought.

In general however, your point is well taken.  One of my suggestions was
to make code completion toggleable per view, and that might help if what
I think you are thinking is indeed happening, or something like that :)

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

I wrote:

> I've noticed that it is now possible to step into Semaphore>>critical:
> (or was it Mutex>>critical: ?).  Is that chance by design ?

Sorry, ignore that.  It was actually BlockClosure>>critical I was stepping
into.

    -- chris

Bill,

> One thing to consider: does OmniBase define too much of the Object
> protocol?  When you say the debugger tries to resolve the proxies, it
> might be that OmniBase is doing too much in response to house keeping
> inquires by the debugger.

It's a general problem, not specific to OmniBase -- although it was OmniBase
that I was hitting the problems with, I've had similar problems debugging my
own code that uses similar techniques.

I don't think that the OmniBase proxies do "too much", they seem to be
implemented correctly to me.  The problem is that the debugger does not have a
mode where it will keep its hands off the target objects.

    -- chris

Chris,

Understood - that's an important window in time.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]