1 / 14

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. The goal: The debug platform should support arbitrary debug architectures and implementations of debuggers. The good news:

lisandra-church
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Progress Report - Debug Platform (3.2 M4) • State of 3.2 M4 • Some Demos • Next Steps

  2. 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…

  3. 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

  4. View Content Viewer Content Adapter Model Specific API retrieveChildren() Model add(…) done() Request Monitor setChildren()

  5. View Update Viewer Model Proxy installs Element Model Specific API model deltas Model Update Policy refresh() update() select() expand()

  6. 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)

  7. 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

  8. 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

  9. 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)

  10. 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

  11. User Interaction Actions (getAdapter IStep, etc) Context activated Debug View Selection Provides context Debug Context Manager Context activated Source Lookup (getAdapter ISourceDisplay)

  12. Demos • Java Debugger • Locks & monitors • Thread groups • Asynchronous Table • Ticker table

  13. 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.

  14. 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

More Related