Progress report debug platform 3 2 m4
This presentation is the property of its rightful owner.
Sponsored Links
1 / 14

Progress Report - Debug Platform (3.2 M4) PowerPoint PPT Presentation


  • 75 Views
  • Uploaded on
  • Presentation posted in: General

Progress Report - Debug Platform (3.2 M4). State of 3.2 M4 Some Demos Next Steps. Progress Summary. The goal: The debug platform should support arbitrary debug architectures and implementations of debuggers. The good news:

Download Presentation

Progress Report - Debug Platform (3.2 M4)

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Progress report debug platform 3 2 m4

Progress Report - Debug Platform (3.2 M4)

  • State of 3.2 M4

  • Some Demos

  • Next Steps


Progress summary

Progress Summary

  • The goal:

    • The debug platform should support arbitrary debug architectures and implementations of debuggers.

  • The good news:

    • The 3.2 M4 debug platform has the ground work in place to support arbitrary debug implementations

  • Disclaimer:

    • Of course, there’s still more to do…


What we have

What We Have

  • Support arbitrary debug models

    • Flexible hierarchy

      • all views support arbitrary content (except breakpoints view)

    • Asynchronous content and labels

      • Hierarchy of asynchronous viewers (tree & table)

      • Adapters provide content and labels

      • Cancelable

      • Customizable per view

    • Model drives the view

      • Model proxy interfaces model with viewer, firing deltas to describe what has changed in the model

      • Platform provides model proxies for standard models


View content

View Content

Viewer

Content Adapter

Model Specific API

retrieveChildren()

Model

add(…)

done()

Request Monitor

setChildren()


View update

View Update

Viewer

Model Proxy

installs

Element

Model Specific API

model deltas

Model

Update Policy

refresh()

update()

select()

expand()


Model proxy what and update policy when

Model Proxy (what) and Update Policy (when)

  • What to update

    • A model proxy reports deltas in a model

    • When an element is added to a viewer, its associated model proxy (if any), is installed in the viewer. When the element is removed from the viewer, its model proxy is removed (disposed).

      • Model drives the view update

      • Factory is used to generate model proxy per element, per view

  • When to update

    • Update policy listens to deltas and updates viewer

      • Created by viewer

      • Platform provides generally useful policies (i.e. update immediately, delayed update, update on demand)


Model proxy

Model Proxy

  • The interfaces:

    • IModelProxyFactory

      • createModelProxy(Object, IPresentationContext)

    • IModelProxy

      • init(IPresentationContext)

      • Installed()

      • dispose()

      • add/removeModelChangedListener(IModelChangedListener)

  • An model proxy updates a single instance of a model in a viewer

    • A model proxy is installed on a specific context/viewer

    • Fires element deltas for an instance of a model


Model proxy cont d

Model Proxy cont’d

  • An model proxy is usually contributed only for the root element in a model (per view)

    • E.g., the model proxy for a standard debug model is contributed for IDebugTarget. The proxy listens to events in that target only, and fires corresponding deltas

      • An implementer could choose to contribute proxies for each of its elements

  • The debug platform contributes Debug view model proxies for:

    • ILaunchManager – fires deltas as launches are added/removed

    • ILaunch – fires deltas process and debug targets are added/terminated

    • IProcess – fires delta when terminate event is fired


Model deltas

Model Deltas

  • Deltas describe changes in a model and actions to take

    • Tree structure similar to resource deltas

    • Each node describes an element in the view and its changes (if any)

      • Change types: ADDED, REMOVED, CHANGED, NOCHANGE

      • Change details: CONTENT, STATE

      • Actions: EXPAND, SELECT

  • Eg. LaunchManager (NOCHANGE)

    • Launch (NOCHANGE)

      • DebugTarget (NOCHANGE)

        • Thread (CHANGE, CONTENT+STATE, EXPAND)

          • Frame (SELECT)


But wait there s more

But Wait - There’s More

  • Debug Context Manager

    • Retargettable actions

      • Step, terminate, etc., work on active context

      • Debug view is default context provider,

    • Flexible view wiring

      • Variables view gets input from active context

      • Expression view updates based on active context

    • Pluggable source lookup

      • based on active context


User interaction

User Interaction

Actions

(getAdapter IStep, etc)

Context activated

Debug

View

Selection

Provides context

Debug Context

Manager

Context activated

Source Lookup

(getAdapter ISourceDisplay)


Demos

Demos

  • Java Debugger

    • Locks & monitors

    • Thread groups

  • Asynchronous Table

    • Ticker table


Thread groups

Thread Groups

  • Added thread groups to our model (IJavaThreadGroup)

  • Implemented & registered adapters:

    • Tree content adapter

    • Label adapter

  • Implemented & registered model proxy

    • Java debug target model proxy replaces the standard debug target model proxy, and generates paths to threads considering thread groups

    • Subclass of standard debug target proxy and standard thread event handler. Overrides one method that generates path to a thread.


Next steps

Next Steps

  • High Priority Viewer enhancements (intended for 3.2)

    • Support for SWT virtual tree

    • Incremental content retrieval

    • Tree table (columns in existing views)

    • Pluggable cell editors

    • Improved Java doc

  • Other considerations (likely post 3.2)

    • Multiple contexts and view sets

    • Drag & drop (maybe 3.2)

    • Consider use of table and tree models

    • Re-useable model proxy hierarchy

    • Re-useable update policies


  • Login