Community
Participate
Working Groups
This is a follow-up bug to bundle the discussions about determining the interest of breakpoints from #155333 and #384067. In the recent Patch Set (https://git.eclipse.org/r/#/c/6338/) I tried to adopt the interest calculation from resources. That is, adding/editing a breakpoint has the same interest weight as adding/editing a resource. If we stick with this approach, consequently hitting a breakpoint might have the same weight as selecting a resource. As far as I know uninteresting objects (i.e. objects in the invisible section of context editor) will still make it to context file. In any case, as Sam pointed out, we should avoid removing breakpoints after task deactivation just because they became uninteresting. I'd encourage you to test the current approach and make sure, if it makes sense - especially with large context files (I was only able to test with smaller sized ones). Other ideas are very welcome, too.
One clue that a breakpoint is not interesting would be if the user consistently his resume as soon as it is hit, without inspecting any variables or anything. I don't know how we could detect that, but if we could, we could do something similar to music players that prompt the user to remove tracks that they skipped from the current playlist. I don't know how useful this would be though.
My gut feeling is that just removing breakpoints when a task is deactivated, so that you always have only the breakpoints created while working on the current task, will provide so much benefit that there will be little further benefit to be had by computing interest for breakpoints.
(In reply to comment #1) > One clue that a breakpoint is not interesting would be if the user consistently > his resume as soon as it is hit, without inspecting any variables or anything. > I don't know how we could detect that, but if we could, we could do something > similar to music players that prompt the user to remove tracks that they > skipped from the current playlist. I don't know how useful this would be > though. I love the idea. Sounds like fun :). I'll investigate if there is a way to measure such user behavior and report back. (In reply to comment #2) > My gut feeling is that just removing breakpoints when a task is deactivated, so > that you always have only the breakpoints created while working on the current > task, will provide so much benefit that there will be little further benefit to > be had by computing interest for breakpoints. Think so, too. Only real benefit I see is for the context editor. If we should decide to show breakpoints in context editor it's a nice feature that they react like resources in sense of flipping between the context view and the invisible elements list.
(In reply to comment #1) > One clue that a breakpoint is not interesting would be if the user consistently > his resume as soon as it is hit, without inspecting any variables or anything. I have tried to find a way to observe this, but was stopped by the observation that Eclipse displays relevant variables (e.g. method parameters, local variables, ...) on the top level of the variables tree in the debug perspective, which is visible immediately. As a result, for the majority of (easy) debugging scenarios that I ended up looking at during my daily work (like "is this variable null", "is the parameter set correctly", "do we hit this line") there is no need to interact with the IDE prior to hitting the resume button. Thus, from a programmatically observable perspective in many cases we just click resume as soon as we hit a breakpoint.
Thanks, that's an interesting discovery. It's true, often all you want to know is whether a line is hit, so I guess it wouldn't be possible to distinguish this from the "I don't care about this breakpoint" case.
Here is an update on how we currently determine breakpoint interest: - Add/Edit Breakpoints: Highly interesting, equally interesting as creating/modifying resources (as part of the initial debug plugin code https://git.eclipse.org/r/#/c/6338/) - Hit Breakpoint: Somewhat interesting, equally interesting as selecting a resource Breakpoint hit observation (https://git.eclipse.org/r/#/c/7198/) currently only works for java breakpoints. We don't want to merge the proposed code like that as it introduces a dependency to JDT for o.e.m.debug.ui. It's still valid to test the behavior. Still searching for more "out of this world" / sophisticated scenarios ;)
(In reply to comment #6) > Here is an update on how we currently determine breakpoint interest: > > - Add/Edit Breakpoints: Highly interesting, equally interesting as > creating/modifying resources (as part of the initial debug plugin code > https://git.eclipse.org/r/#/c/6338/) That sounds like the approach to monitor interest that is consistent with other interaction monitoring implementations. > - Hit Breakpoint: Somewhat interesting, equally interesting as selecting a > resource That's a neat idea and is something that we could explore. I'm not sure that the context framework is the right place for this though since it sounds somewhat experimental. I am wondering if we should consider putting this into the Incubator for now. > Breakpoint hit observation (https://git.eclipse.org/r/#/c/7198/) currently only > works for java breakpoints. We don't want to merge the proposed code like that > as it introduces a dependency to JDT for o.e.m.debug.ui. It's still valid to > test the behavior. I think this should be either part of the Incubator sandbox or it should be moved to the Java bridge.
(In reply to comment #7) > (In reply to comment #6) > > Here is an update on how we currently determine breakpoint interest: > > > > - Add/Edit Breakpoints: Highly interesting, equally interesting as > > creating/modifying resources (as part of the initial debug plugin code > > https://git.eclipse.org/r/#/c/6338/) > > That sounds like the approach to monitor interest that is consistent with > other interaction monitoring implementations. > > > - Hit Breakpoint: Somewhat interesting, equally interesting as selecting a > > resource > > That's a neat idea and is something that we could explore. I'm not sure that > the context framework is the right place for this though since it sounds > somewhat experimental. I am wondering if we should consider putting this > into the Incubator for now. Sounds good. +1 for using the add/edit breakpoint actions to monitor interest for now and moving the java-specific hit detection to incubator / postpone it until we tested the plugin in depth.
Marking as WONTFIX for now but we can revisit this idea once we have the basic breakpoint in context support fully working (bug 428378).
