https://bugs.eclipse.org/bugs/show_bug.cgi?id=306868
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf
Of Pawel Piech
Sent: March 23, 2010 3:05 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Recursive
DSF view model nodes in the debug view
Alexiev, Dobrin wrote:
Pawel,
I followed your advice to have my container
VM node return the top node - Container(1).
In that case
DefaultVMModelProxyStrategy.buildChildDeltasForEventContext() properly matches
Container(1) with the returned from getVMProvider().updateNode() since they
both are the top ones.
But later in the next call of
DefaultVMModelProxyStrategy.buildChildDeltasForEventContext() when the thread
VM node is asked with getVMProvider().updateNode() it won’t return any nodes
since there are no Thread children of Container(1). The threads are children of
child container - Container(2) in my case - so the stack VM node won’t be asked
for the delta.
Without overriding my container VM node
getContextForEvent() it returns the bottom one - Container(2) then
DefaultVMModelProxyStrategy.buildChildDeltasForEventContext() cannot match that
one against Container(1) - which is returned from getVMProvider().updateNode().
I agree that returning all containers in a
getContextForEvent() won’t help either.
Either way it doesn’t work…
Do you want me to open a Bugzilla entry and
we can transfer the discussion there?
Yes, please. That'd be a good idea.
-Pawel
Thanks
Dobrin
Alexiev, Dobrin wrote:
Looking at the example (DSF Example - File
Browser) I was trying to fit my use case, unfortunately unsuccessful so far.
Here is my use case:
The VM nodes hierarchy is setup as:
LAUNCH - has child CONTAINER
CONTAINER - has children CONTAINER
and THREAD
THREAD - has child STACK_FRAME
When I have an instance:
Launch(1)
Container(1)
Thread(1)
Stack_Frame(1)
the delta is generated properly and
stepping selects the top stack frame.
When I have an instance of recursive
container:
Launch(1)
Container(1)
Container(2)
Thread(1)
Stack_Frame(1)
The debug view shows it properly,
but the delta is not generated the way I was hoping.
LaunchManager .NO_CHANGE
Launch(1). NO_CHANGE
Container(1).NO_CHANGE
Container(2).NO_CHANGE
I have my ContainerVMNode generate
the delta in a similar way to FileVMNode.java - it includes all container nodes
that are parents of the suspended thread.
My ThreadVMNode adds the thread
delta to the bottom container.
At this moment I am not sure what
should my ContanerVMNode.getContextsForEvent return?
I think it should return the top container.
Because your VM node is responsible for adding deltas for all the elements
under the top container.
Its default implementation return
the bottom container - Container(2).
But when that is passed to
DefaultVMModelProxyStrategy.buildChildDeltasForEventContext()
getVMProvider().updateNode(…)
returns the immediate children of the Launch node - Container(1).
When I change DefaultVMModelProxyStrategy.buildChildDeltasForEventContext()
to return both containers I get one step ahead
Did you mean you have
"ContanerVMNode.getContextsForEvent()" return both contexts? I
don't think that should work either.
The delta now includes
the thread:
LaunchManager .NO_CHANGE
Launch(1). NO_CHANGE
Container(1).NO_CHANGE
Container(2).NO_CHANGE
Thread(1) NO_CHANGE
But the stack frame is still not
there.
I can't tell without having a working model to debug
with.
I’ll keep debugging, but
Before I continue on this I wanted
to check if I am on the right track modifying
ContanerVMNode.getContextsForEvent() to return the hierarchy of containers, or
that is not the right approach and I am missing something else.
You shouldn't have to return a hierarchy, because your
node is reponsible for creating this hierarchy in buildDelta(). But I
have to admit that you are doing something rather new here so you could be
running up against limits of current implementation. So don't be afraid
to experiemnt :-)
Cheers,,
Pawel
Thanks in advance.
Dobrin
Hi Dobrin,
I'm sorry I haven't had time to look at this, could you create a bug with your
patch so it doesn't get lost?
Thanks!
Pawel
Alexiev, Dobrin wrote:
Thanks Pawel for the pointers.
I’ll follow them for my recursive
container.
BTW,
I think the Windows version of
FileVMNode.java needs slight adjustment to handle the multiple drives case.
You can see if the attached patch makes
sense.
Without the patch pasting a path will
expand all drives (root nodes) instead of one.
May be there is a better fix than this
patch?
See how all drives are included in the
delta when I paste “C:\Program Files\Adobe”.
How can I make sure that only C drive is
included in the delta?
Thanks
Dobrin
RECEIVED DELTA: Model Delta
Start
Element: File Browser Viewer Input
Flags: NO_CHANGE
Index: 0 Child Count: 5
Element: C:\
Flags: NO_CHANGE
Index: 0 Child Count: 85
Element: C:\Program Files
Flags: NO_CHANGE
Index: 58 Child Count: 92
Element: C:\Program Files\Adobe
Flags: EXPAND | SELECT |
Index: 0 Child Count: 5
Element: E:\
Flags: NO_CHANGE
Index: 1 Child Count: 7
Element: M:\
Flags: NO_CHANGE
Index: 2 Child Count: 1
Element: P:\
Flags: NO_CHANGE
Index: 3 Child Count: 0
Element: Q:\
Flags: NO_CHANGE
Index: 4 Child Count: 59
Model Delta End
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Pawel Piech
Sent: March-04-10 7:26 PM
To: CDT
General developers list.
Subject: Re: [cdt-dev] Recursive
DSF view model nodes in the debug view
Hi Bobrin,
Alexiev, Dobrin wrote:
Hello,
Has anyone tried recursive view
model hierarchy in the debug view using DSF?
Yes, you can even look at
org.eclipse.cdt.examples.dsf.filebrowser for an example ;-)
It's a simplistic example though, so you may uncover new bugs in this area.
I’d trying something like
launch
container
thread
stack frame(s)
container
container
container
container
thread
stack
frame(s)
container
thread
stack frame(s)
It does show up properly in the
debug view.
But when I fire suspended event on
the thread for some reason my StackFrameVMNode.buildDelta doesn’t get called
even though its getDeltaFlags returns properly CONTENT + EXAPND + SELECT for
ISuspendedDMEvent.
I’ll keep digging into
DefaultVMModelProxyStrategy code tomorrow.
I just saw a comment “Avoid
descending into recursive node hierarchy's when calculating the delta.” and
decided to make sure I am not trying a use case that is not supported by design.
What this means is that if you have a recursive
hierarchy (i.e. a node that has itself as a child), then this node is
responsible for building a delta with all the levels in this hierarchy.
For example, in the hierarchy you have above when the container node is called,
it needs to build a delta for all the nested containers before it completes so
that the thread vm node can build on top of that.
Hope this helps,
Pawel
In other words, when the ContainerVMNode.buildDelta() is called it needs to
Thanks in advance!
Dobrin
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev