Re: [cdt-dev] Do we really need a refresh in Debug View?

[John Cortell <rat042@xxxxxxxxxxxxx>]

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