From: Darin Wright
[mailto:Darin_Wright@xxxxxxxxxx]
Sent: Friday, February 03, 2006
8:56 AM
To: Piech,
Pawel
Cc: Gaff, Doug; Williams, Ted
Subject: Re: prototyping against
flexible hierarchy API, notes
Hi Pawel,
Thanks
for the constructive feedback. I hope we can leverage your experience in our
talk at EclipseCon.
>
> _The good:_
>
> * The content and label
providers, and model proxy APIs are very
> well aligned with this
design, and I haven't had any issues
> implementing them.
> * The integration between the
old and new components is very smooth,
> and I can even have
implementations of both working side by side
> talking to the same
communication layer.
This is good
news :-)
>
> _Big issues:_
>
> * My goal with the prototype
was to avoid using the synchronous
> interfaces completely,
with exception of launch, source lookup,
> and breakpoints.
Unfortunately it turns out that basic debugging
> functionality still
depends on them, because the run control
> actions do. This
is something that could easily be address by
> converting them to
retargetable actions similarly to run-to-line,
> etc., but with
asynchronous APIs. I don't think this should be
> technically difficult,
and I wouldn't mind contributing it myself
> if time was an issue,
but it would add a new API to the mix.
Correct -
the control actions use the existing IStep, ITerminate, etc., interfaces.
Although these APIs are synchronous, they are non-blocking. So I need to
further understand what the issue is here. For example, the step over action
simple gets the IStep adapter and calls "stepOver". The implementation
of the IStep.stepOver() should initiate the step, but should not wait for the
step to complete. The step completes at a later time, and is indicated by the
model proxy firing an appropriate delta. I think the only issue here is that
there is no way for the model to indicate failure (via a request monitor), if
the failure happens after the step is initiated. So, it's a synch API with
asynch behavior.
Since the
actions simply initiate the function (step, termiante, etc.), and then update
based on model deltas, I'm not sure what we would gain with an async API. The
actions currently don't need to know when the function completes.
Although we
could put async UI wrappers/adapters on the functions, my belief is that you
should still be able to have an async implementation with the existing
interfaces.
>
> _Small issues:_
>
> * Model-ID is used in various
ways by the debugger, like for
> identifying the model
presentation, and for
> debugModelContextBinding
extension point. Model-ID is currently
> retrieved through
IDebugElement. Theoretically it shouldn't be
> hard to add
IDebugElement implementation to the "model context"
> object, but this
interface does have a reference to IDebugTarget,
> which the prototype doesn't
implement, and a reference to ILaunch,
> which the model context
isn't aware of. So I wish there was
> another way to associate
a model-id with an object, like though
> IAdaptable.
Do you know
where we are using the model ID from IDebugElement? In the latest code base we
are trying to be clean. The view binding stuff does use it, but I have a new
implementation waiting to be released (pending a workbench bug), that is based
on the debug context manager, and the IDebugModelProvider adapter. So, we do
have an adapter for this, and we should be clean with respect to using it.
Please file bugs where you find problem areas.
> * Editor positioning and
annotation logic is written around the
> IStackFrame interface,
so I appreciate the ISourceDisplayAdapter
> interface, I just wish
that there was an official way to access
> the standard debugger
images. BTW, ISourceDisplayAdapter is not
> currently accessible
because of restriction on
> org.eclipse.debug.internal.ui.contexts.provisional
package.
Right, our
standard "source display adapter" is based on stack frames. We've
added IInstructionPointerPresentation in 3.2 (enhanced for M5), but it is
intended to be used with the "standard model". Are you just looking
for public image access - currently the instruction pointer images are
internal, but could be made public (there Ids are in IInternalDebugUIConstants
- IMG_OBJS_INSTRUCTION_POINTER and IMG_OBJS_INSTRUCTION_POINTER_TOP. If you can
envision helpful API here, please file enhancement requests. (Note, at this
time we're under the gun to freeze public API (Friday Feb 10), in preparation
for M5).
>
>
> This is all the observations I have so far.
I still have a long TODO
> list for features in the prototype, and I
would like to clean it up as
> much as possible before coming to Toronto.
>
> Cheers
> Pawel
>
Darin
Wright
Eclipse Debug Lead,
Rational Team,
IBM Canada
(204)934-4114
