Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-dd-dev] FW: prototyping against flexible hierarchy API, notes



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

Back to the top