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