[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-debug-dev] Re: [cdt-debug-dev] Re: AsynchronousTreeViewer and IMemoryBlockRetrieval
|
Hi John -
Yes, the Memory View will still support address space.
The Memory View will show a hierarchy for any element that implements
IMemoryBlockRetrieval. (i.e. the root element in the tree viewer is always
an IMemoryBlockRetrieval.) Clients can show address space objects under an
IMemoryRetrieval element.
Thanks...
Samantha
John Cortell
<john.cortell@fre
escale.com> To
Samantha Chan/Toronto/IBM@IBMCA
02/27/2006 02:56 cc
PM
Subject
Re: [cdt-debug-dev] Re:
AsynchronousTreeViewer and
IMemoryBlockRetrieval
Samantha,
These changes are directly tied to the memory window supporting
address spaces, right? If I'm reading this right, this has more to do
with providing the memory window a more flexible set of context
objects. But without that support, the debugger will still support
address spaces, right?
John
At 01:28 PM 2/27/2006, you wrote:
>Hi all -
>
>I investigated using the current debug context as the tree viewer's input.
>The purpose of this change is to allow IMemoryBlockRetrieval objects to
not
>extend from PlatformObject. It also makes the view more flexible by
>allowing any debug element as its viewer input.
>
>Currently, the Memory View shows the following hierarchy in the tree view
>pane:
>IMemoryBlockRetrieval -> IMemoryBlock
>
>If the current debug context is used, the Memory View shows hierarchy as
>follows:
>IDebugTarget -> IMemoryBlock (if a debug target is selected)
>IThread -> IMemoryBlock (if a thread is selected)
>IStackframe -> IMemoryBlock (if a stackframe is selected)
>
>To be backward compatible, the platform will have to provide content
>adapters to IDebugTarget, IThread and IStackframe. These content adapters
>discovers the IMemoryBlockRetrieval that is associated with the selected
>debug element and returns a list of memory blocks from the same memory
>block retrieval.
>
>The platform also needs to provide a model proxy for IDebugTarget, IThread
>and IStackframe for the Memory View. The model proxy responds to memory
>block added / removed event and updates its view accordingly.
>
>The new approach presents a number of problems:
>
>* It causes the Memory View to flash more. Every time the selection is
>changed in the Debug View, the Memory View's tree view pane will have to
>change its input to the newly selected debug element. This causes the
>Memory View selection to change and will cause the renderings to refresh
>unnecessarily.
>
>* It also causes the view to interact with its model more. Whenever the
>debug context is changed, the tree view pane will be updated. It causes
>the renderings to get updated and will have to get memory from their
models
>again. This could pose performance problems if getting memory is slow.
>
>* User experience suffers because expansion and selection cannot be
>maintained properly when a different debug element is selected. For
>example, the Memory View shows two address spaces, Address Space A and
>Address Space B. Under each address space, we have Memory Block A and
>Memory Block B. When StackFrame A is selected from the debug view, the
>user has expanded Address Space A and selected Memory Block A. As the
user
>switches to StackFrameB, the Memory View is forced to change the input to
>the viewer. And since the viewer has not previously shown that input, the
>viewer is not able to maintain expansion and selection in the view. To
see
>the same memory block, the user must manually expand and select the same
>memory block again.
>
>* Finally, if a client ever wants to show a different hierarchy in the
>tree view pane, a client has to override a lot more adapters than it used
>to. In the "old" world, a client only needs to override the content
>adapter for its IMemoryBlockRetrieval and to provide customized model
proxy
>for its IMemoryBlockRetrieval. In the new world, a client must override
>content adapters for all elements that can show up in the debug view. It
>also needs to provide customized proxies for all the debug elements that
>might show up in the Debug View. The new approach makes it more difficult
>for a client to show flexible hierarchy in the Memory View.
>
>Looking at these problems. I am not convinced that allowing the current
>debug context to be the viewer input is the correct way to go. The Memory
>View is really intended to show a hierarchy under an
IMemoryBlockRetrieval.
>Allowing any object as viewer input and providing adapters for these
>objects feel like a hack to me. The only benefit resulted from this
change
>is that IMemoryBlockRetrieval does not have to implement PlatformObject.
>The extra flexibility can be achieved by returning a different memory
>retrieval based on the selected debug element.
>
>I do not have a strong use case for this change. I plan on using
>IMemoryBlockRetrieval as the tree viewer's input in the Memory View for
3.2
>and IMemoryBlockRetrieval objects must subclass from PlatformObject..
>However, if you have a use case for this change, please let me know.
Maybe
>it will help me better understand the different hierarchies.
>
>Also, if you have any question, please let me know.
>
>Thanks...
>Samantha
>
>
>
>
>
> "Mikhail
> Khodjaiants"
> <mikhailk@xxxxxxx
To
> > "Eclipse Platform Debug component
> Sent by: developers list."
> platform-debug-de <platform-debug-dev@xxxxxxxxxxx>
> v-bounces@eclipse
cc
> .org
>
Subject
> Re: [platform-debug-dev]
> 12/30/2005 12:50 AsynchronousTreeViewer and
> PM IMemoryBlockRetrieval
>
>
> Please respond to
> "Eclipse Platform
> Debug component
> developers list."
>
>
>
>
>
>
> > Maybe what we need is to
> > update the java docs and mark the internal APIs as "experimental"?
>
>That would be very helpful.
>Thanks.
>
>----- Original Message -----
>From: "Samantha Chan" <chanskw@xxxxxxxxxx>
>To: "Eclipse Platform Debug component developers list."
><platform-debug-dev@xxxxxxxxxxx>
>Sent: Thursday, December 29, 2005 7:47 PM
>Subject: Re: [platform-debug-dev] AsynchronousTreeViewer and
>IMemoryBlockRetrieval
>
>
> > Hi Mikhail -
> >
> > There is now a bug entry for this work item: : )
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=122349
> >
> > I believe extending from platform's debug target content adapter should
> > be
> > the right solution.
> >
> > As to distinguish what classes and interfaces are going to be public, I
> > do
> > not think we have a systematic way of doing it. Maybe what we need is
> > to
> > update the java docs and mark the internal APIs as "experimental"?
> >
> > Thanks...
> > Samantha
> >
> >
> >
> >
> >
> > "Mikhail
> >
> > Khodjaiants"
> >
> > <mikhailk@xxxxxxx
> > To
> > > "Eclipse Platform Debug
component
> >
> > Sent by: developers list."
> >
> > platform-debug-de <platform-debug-dev@xxxxxxxxxxx>
> >
> > v-bounces@eclipse
> > cc
> > .org
> >
> >
> > Subject
> > Re: [platform-debug-dev]
> >
> > 12/29/2005 04:58 AsynchronousTreeViewer and
> >
> > PM IMemoryBlockRetrieval
> >
> >
> >
> >
> >
> > Please respond to
> >
> > "Eclipse Platform
> >
> > Debug component
> >
> > developers list."
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Samantha,
> >
> > > One of the things on my to-do list is to remove the requirement of
> > > passing
> > > IMemoryBlockRetrieval object to the tree viewer as the input.
> >
> > Is there a bugzilla entry for it?
> >
> > Thanks,
> > Mikhail
> >
> > ----- Original Message -----
> > From: "Samantha Chan" <chanskw@xxxxxxxxxx>
> > To: "Eclipse Platform Debug component developers list."
> > <platform-debug-dev@xxxxxxxxxxx>
> > Sent: Thursday, December 29, 2005 10:00 AM
> > Subject: Re: [platform-debug-dev] AsynchronousTreeViewer and
> > IMemoryBlockRetrieval
> >
> >
> > > Hi -
> > >
> > > One of the things on my to-do list is to remove the requirement of
> > > passing
> > > IMemoryBlockRetrieval object to the tree viewer as the input.
> > Instead,
> > > the
> > > current debug context will be passed as the input to the viewer.
It's
> > > up
> > > to the content adapter of that object to retrieve the correct
> > > IMemoryBlockRetrieval and associated memory blocks when asked to
> > > populate
> > > the view. This approach will make the viewer more flexible as any
> > > object
> > > can now become the input to the viewer. It also removes the needs of
> > > making IMemoryBlockRetrieval an IAdaptable.
> > >
> > > So, for the modules view, is it possible for your viewer to accept
any
> > > object as input. And then the content adapter of that object will be
> > > responsible for getting the modules?
> > >
> > > Thanks...
> > > Samantha
> > >
> > >
> > >
> > >
> > >
> > > "Mikhail
> > >
> > > Khodjaiants"
> > >
> > > <mikhailk@xxxxxxx
> > > To
> > > >
> > <platform-debug-dev@xxxxxxxxxxx>
> > >
> > > Sent by:
> > > cc
> > > platform-debug-de
> > >
> > > v-bounces@eclipse
> > > Subject
> > > .org [platform-debug-dev]
> > >
> > > AsynchronousTreeViewer and
> > >
> > > IMemoryBlockRetrieval
> > >
> > > 12/28/2005 02:49
> > >
> > > PM
> > >
> > >
> > >
> > >
> > >
> > > Please respond to
> > >
> > > "Eclipse Platform
> > >
> > > Debug component
> > >
> > > developers list."
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > > An IMemoryBlockRetrieval object is passed to the Memory view's viewer
> > as
> > > an
> > > input. This object is required to be an instanceof of IAdaptable to
> > work
> > > with AsynchronousTreeViewer.
> > > The IMemoryBlockRetrieval interface defines a functionality, not a
> > model
> > > object and I am not sure if it is right to make it adaptable.
> > > I implemented the CDT Modules view based on the asynchronous tree
> > > viewer,
> > > but I had the same problem - I had to make the object responsible for
> > > the
> > > modules retrieval to extend PlatformObject.
> > >
> > > Thanks,
> > > Mikhail Khodjaiants
> > > QNX Software Systems _______________________________________________
> > > platform-debug-dev mailing list
> > > platform-debug-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
> > >
> > >
> > > _______________________________________________
> > > platform-debug-dev mailing list
> > > platform-debug-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
> >
> > _______________________________________________
> > platform-debug-dev mailing list
> > platform-debug-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
> >
> >
> > _______________________________________________
> > platform-debug-dev mailing list
> > platform-debug-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>
>_______________________________________________
>platform-debug-dev mailing list
>platform-debug-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
