Many thanks!
Darin Wright wrote:
Thanks Pawel,
I applied patches for two of the
minor
fixes (213719
and 213609),
and we'll use this as a guide to tackle the others that are more
involed.
>
> [209883] _expression_ view actions use getAdapter() to work with non-
> standard debug models
> This bug is already being considered for 3.4 pending IP review.
> Fixing this bug would complete making the Expressions view
agnostic
> of the debug model being used.
We'll fix this in 3.4 pending IP approval.
>
> [213069] Extend PresentationContext to save and restore properties.
> This is a minor but a very useful feature. Currently, DSF actions
> which need to store settings about a given view are not persisted.
> We could invent an independent storage mechanism for these
settings
> but it would be partly redundant and more complicated than the
> solution proposed in this bug. The patch itself is actually
very
> straightforward and it includes a unit test.
Will consider for 3.4.
>
> [166155] VariablesView should use the ISelection object as viewer
input.
> This is also a minor change, which would make the flexible
hierarchy
> views even more flexible. It modifies the viewer input provider
> framework which was introduced in 3.4, so I think it would be nice
> if this feature request was considered before the viewer input
> provider makes it to a release. DSF probably would not take
> advantage of this feature in Ganymede, but it would definitely use
> it in the future.
Please see question on bug.
>
> [188704] Top index not maintained properly in variables /
registers
view.
> The patch in this bug is a complex solution to a complex problem.
> I've spent about a week and a half developing and testing this
patch
> so I'd love to see it included in 3.4. Specifically, the patch
> addresses a number of race conditions present when saving and
> restoring the state of the views. These race conditions are
> dependent on the frequency of changes in the viewer input and the
> amount of state information that needs to be persisted. The
> proposed solution adds logic to deal with partially-restored
viewer
> states and works even when stepping code, or changing selection in
> Debug view very rapidly.
> As mentioned the patch is fairly large and may require IP review.
> Also, Samantha requested to have this bug targeted for 3.4... if
> that helps in staffing it.
Will consider for 3.4. Will likely need IP
approval
due to size of fix.
>
> [212316] Allow multiple debuggers to create breakpoints using the
same editor.
> This is a fairly extensive feature which may require IP review.
It
> would address a long standing platform debug design problem (a
> problem for Wind River at least) where multiple debuggers cannot
use
> different breakpoints with the same editor. But beyond that,
it
> would also create a convenient and a standard mechanism to allow
> users to create breakpoints with different options enabled. For
> example, the patch includes a feature for JDT, where the user can
> switch back and forth to toggle breakpoints which are filtered to
> the currently selected thread.
> It should only take a couple of hours to try out the patches and
see
> the workflow. While the patch itself is large, it is closely
based
> on the extension mechanism of the detail panes so I hope it'll be
> easy to digest.
Will need IP approval, but still needs more
evaluation
before we consider for 3.4.
>
> [213074] "Run to line" action cannot be used with non-standard
debug models.
> Run to line adapters have the same problem as toggle breakpoint
> adapters, in that only one can be registered per editor. They
also
> have a larger problem in that they are synchronous interfaces. I
> realized the second problem only after I started working on the
> first one. I think overall this bug should be deferred till
after
> 3.4, but I made one small request in the bug: to made the run-to-
> line retargetable action check the debug element for the adapter.
> This way there could be multiple adapters used with the same
editor,
> but the asynchronous issue would remain to be looked at later.
Deferred, but we might consider asking the target
for the adapter in 3.4, before checking the editor.
>
> [210027] TreeModelLabelProvider does not cancel stale updates.
> This is mainly a performance improvment in the flexible hierarchy
> viewer. It would also make it easier to implement view data
caching
> in DSF, but DSF can also work around this problem.
Needs more evaluation before considering.
>
> [213609] Need a clarification on usage of IElement*Provider
> interfaces with update arrays.
> Comment changes, no code.
Applied.
>
> [213629] Flexible hierarchy provider interfaces should specify
that
> they will be invoked on the UI thread.
> Past 3.4
Deferred.
>
> [213719] NPE when closing the Variables view.
> NPE bug with a simple fix.
Applied.
>
> [211158] Add a modules view to the set of standard debugger views.
> [210466] Make the detail pane UI support classes a public API.
> Both these bugs are mainly to clean up CDT code a bit, and avoid
> constantly breaking the CDT build when certain platform debug
> internal APIs change.
>
>
Darin
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
|