[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Do we really need a refresh in Debug View?
|
Hi,
there's been some very good points made for both sides of
the argument. From where I stand, here's my opinion:
1- I use the refresh for views quite often, but it is most
often to fix a out-of-sync view that is caused by a bug
2- As a user, I agree that it is suspicious that there is a
refresh button; "Doesn't eclipse keep the views up to date???" I would
wonder.
3- But I also agree that user's going to the debug console
will cause views to fall out-of-sync. I think this is a limitation on the
console, but I think it is impossible to fix 100% of the time as we cannot
predict all the things a user would do.
So, I'm ok with the idea of removing the refresh button
from the views, as long as there is still a way to do the refresh. An
action set would be ok, although I don't think it is limited to Update Modes; or
a key binding sounds fine to me (SHIFT-F5 is
mapped to Reverse Step Into. Maybe CTRL-F5?)
Thanks
Marc
Would you argue that the refresh capability in the
projects/resources/etc view also be removed? It's basically the same idea.
Often, you use that refresh action because they've changed the file system
outside of eclipse. But sometimes you need to use it even when you haven't,
because some activity has screwed up Eclipse's view of the file system. Either
way, the refresh button is very handy.
Back to the debugger situation.
It's possible that something outside the CDT debugger can change the target
state...maybe the user has broken out to the run-control layer (say, via a
shell) during a debug session, and has modified registers or memory.
More likely is the scenario where there's a specialized feature/view in a
commercial debugger that modifies memory in a way that does not propagate to
the rest of the views. This may not be a bug but just a limitation. Like I
said, if the user is doing basic debugging, then he should never have to use
the refresh action. I agree with you that if he does, that would constitute a
serious bug. But for advanced debugging, the out-of-synch scenario is pretty
likely, and having that refresh button is a big help. Desktop debuggers fall
into the "basic debugging" category. Embedded debuggers fall into the
"advanced" one. My guess is CDT is used more in the embedded world than the
desktop one.
John
At 07:51 AM 1/16/2010, James Blackburn
wrote:
2010/1/15 John Cortell <rat042@xxxxxxxxxxxxx>
- Indeed. I mistook ICachingVMProvider for IRefreshAllTarget.
Regardless, I think it's useful to be able to refresh at both
scopes--per-view and all-views. If I think the call stack is hokey, it's
nice to be able to get that to refresh, and only that. I for one would
like to see the action stay.
Coming at this from the
POV of a user I don't see how the refresh action gives any confidence in the
debugger. If you ever find yourself pressing refresh and seeing the
call-stack change, I'd say that that's a _very_ serious bug. There's
no way a user could be expected to think: "Gee, that doesn't look right, I
bet the debug model's out of sync, let me try a refresh". They tend to
struggle for an hour before giving up and going back to some other debugger
(+ loudly swearing to their developer friends that they should steer clear
of the cdt debugger because it shows the wrong data).
I see the point
that some advanced users might not want some expensive views to refresh
automatically, but I'd bet these people are in the minority. Having
spent hours chasing a CDI bug where a flummoxed user saw the memory view and
variables view showing different data, I know first hand that is really
destroys confidence in the debugger.
Finding bugs can hard, and
potentially impossible if you don't trust your tools or they lie to you. I'd
really hope that the refresh action is for refreshing expensive views and
not for recovering for a debug model failure. If it's the latter users will
run away fast.
Cheers,
James
- John
- At 05:06 PM 1/15/2010, Pawel Piech wrote:
- Hi John,
- I agree with you also that in many practical situations it's very
helpful to flush the caches and refetch data.
- However there is more to the refresh actions story.
IRefreshAllTarget is invoked by a different action then the one in the
view. It's invoked by the "Refresh Debug Views" top-level
menu/toolbar action which is tied to the "Debug Update Modes" action
set. This action set also enables the "Update Modes" menus in the
various debug views that support them.
- The refresh actions which are in the views are implemented using the
org.eclipse.cdt.dsf.debug.internal.ui.viewmodel.actions.RefreshActionDelegate,
and they refresh only the contents of the view in which they are
registered. There is also a global command handler:
RefreshHandler, which is active whenever the DSF refresh action is
active in a view. This handler is tied to the top level menu
File->Refresh action.
- Would it be sufficient if for our users if the toolbar icon wasn't
there bug the top-level handler was still available? Unfortunately
the standard key binding for the refresh command (F5) is mapped to the
Step Into action when debugging. But we could also create a new
mapping for refresh (e.g. Shift+F5). Also, we could leave the
action delegate as public API so that any product that wants it, could
add it without much trouble.
- Cheers,
- Pawel
- John Cortell wrote:
- I agree with you that the reuse of the icon is confusing and
should be changed. As for whether you can submit a bugzilla/patch to
remove it: absolutely; you certainly can. I can predict with high
confidence, though, that it won't be accepted. Generally speaking,
committers don't develop useless features. If it's in there, I assure
you there's a reason for it, and probably a good one. Before
considering a patch to remove an action, a good first step is to
discover what the action does and why someone felt it was an important
capability.
- The action invokes the IRefrehAllTarget interface, which is
documented as follows:
- A retargetable
action target which allows a debugger to refresh all of its active
views with fresh data from the debug target.
- This capability is very useful. While a debugger should be smart
and try to update as much as possible automatically, coherency between
the many features/views of a debugger is never going to be 100%
reliable. For example, there will be cases where the user does
something in one particular view that affects data being displayed in
another view, and because of the complexity of the relationship, or
because of performance considerations, that second view gets out of
synch with the target--perhaps others, too. For this reason, it's
important that the user have the ability to tell the debugger to toss
out all cached information and retrieve (and display) the latest
target state. In practice, the action is probably not used all that
often. Certainly not when just doing basic debugging.
- This is very similar to how Refresh works in views that display
workspace resources. You can't rely on Eclipse always being in synch
with the file system, so sometimes you need to tell it to synch up.
- John
-
- At 03:54 PM 1/15/2010, Mehregani, Navid wrote:
- Content-Language: en-US
- Content-Type: multipart/related;
-
boundary="_004_496565EC904933469F292DDA3F1663E602AA311C88dlee06enttico_";
-
type="multipart/alternative"
- Do we really need a refresh button in Debug view? I
think Debug view should automatically refresh when need be.
- To make things more confusing, this button uses the same icon as
restart button. Can I submit a Bugzilla and patch to
remove this button?
- If there is a good reason for this button, please enlighten
us.
- Thanks,
- Navid
- _______________________________________________
- 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
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev