Community
Participate
Working Groups
Apply mylar filtering to Breakpoints view
Hmmm... should this have the behavior of automatically disabling breakpoints that are not in your context? I tend not to keep many breakpoints around, but that's probably because I haven't had Mylar to toggle between them. And there are breakpoint working sets, which is more evidence that this is needed. But if you could post a description of what's in your breakpoints view, or better yet a screenshot, that would be useful.
Mik, unfortunately I can't post screenshot here because it will show what I am working on, which I am not allowed to do. Anyways, I am pretty much on the same position as you. I keep my breakpoints view flat (no working sets) and have to manually delete or disable breakpoints when switching between tasks. So, I think your idea about automatically enabling breakpoints for the current context is really great.
Yes enable and disable Breakpoints according to Mylar context. This will have the benefit of keeping the debug information around for the context that is currently worked on. Helps if you have to go back to an old context to see what you have been looking at. If this could also be possible for watches and the like I would love it. Of course you could use breakpoint workingsets (I didn't even know about breakpoint workingsets befor reading this bug ;)) but I would still prefer it if mylar could do this automatically.
*** Bug 123699 has been marked as a duplicate of this bug. ***
This is now working in head and thanks to the magic of structure bridges and apply mylar actions was very straightforward to implement. However, the following call: IType type = JavaDebugUtils.resolveDeclaringType(stackFrame); Is causing major performance problems in the filtering, due to jdt.debug's slowness in mapping from a JDIStackFrame to an IJavaElement, which we need to do for every frame. I hope that we don't end up having to maintain a cache...
Stuck in a WeakHashMap to map frames to types for the time being. Works well enough so this feature is now ready for experimentation.
Yikes, wrong report! This was done for the Debug view, not the Breakpoints view.
I have the same problem described in comment#2. I have many projects that form a framework, and are used by others products, all in the same workspace. At a specific time I can have to work on a issue that can make me debug some part of framework, then switch to another task that uses another part of framework. It is really annoying having to enable/disable breakpoints as you switch tasks, only to not have the debugger stopping on uninteresting places of code. The breakpoint working sets are useful only if you have enough time to organize them :) So if Mylar can determine for me who are the interesting breakpoints, and enable/disable them automatically, I vote for it! This is a must-have feature!
BTW, I've reenabled working sets since then. Eclipse 3.2 brought projects sets from the project groupping, so you can enable/disable whole set in one click.
(In reply to comment #9) > BTW, I've reenabled working sets since then. Eclipse 3.2 brought projects sets > from the project groupping, so you can enable/disable whole set in one click. > However this does not resolve the case when you have different tasks setting breakpoints on the same shared project(s), so when you debug one of them, you have to disable the breakpoints regarding the other one.
I agree that this is a must-have, we'll plan to have it in 1.0, and should have it prototyped well beforehand so that we can get enough feedback on the combination of import/filter/enable of breakpoints that are all possible mechanisms for providing this as discussed on bug 155333.
Unfortunately this very-nice-to-have feature (I guess it's not technically a must-have) won't make the cut for 1.0.
*** Bug 222246 has been marked as a duplicate of this bug. ***
Marking P2 to ensure that we explore the design for this soon, since there has been considerable and ongoing interest in this feature.
+1 Definitely interested, let me know if help is needed from debug.
Curtis: how would you like this to work? For 3.4 we generalized marker filtering so that you can configure the Markers view to show breakpoints, and the focus button will work to show only the breakpoints that are in the current task context. Note that the breakpoint categories currently show IDs instead of labels and the images don't show (bug 225220) but other than that, and the fact that empty categories should probably be hidden (bug 216866) it works. It should be very straightforward for us to add this functionality to the Breakpoints view.
Also note bug 155333, but it's less likely that we can provide that for 3.0 without help.
This is mostly done now, I just need to make a special rule for Java line breakpoints, for which the IMarker does not have a charStart attribute set (all other markers that we filter do have one set). Curtis: could you point me at code that will provide the charStart? I have the IMarker from the breakpoint and the corresponding ICompilationUnit. One final thing we shoudl figure out is whether some breakpoints should always be visible. For example, we could make enabled breakpoints never get filtered.
Created attachment 101004 [details] mylyn/context/zip
(In reply to comment #18) > Curtis: could you point me at code that will provide the charStart? I have the > IMarker from the breakpoint and the corresponding ICompilationUnit. We do not provide a charStart or charEnd attribute on java line breakpoints. We only provide a line number. IMarker.LINE_NUMBER (In reply to comment #16) > Curtis: how would you like this to work? For 3.4 we generalized marker > filtering so that you can configure the Markers view to show breakpoints, and > the focus button will work to show only the breakpoints that are in the current > task context. Note that the breakpoint categories currently show IDs instead > of labels and the images don't show (bug 225220) but other than that, and the > fact that empty categories should probably be hidden (bug 216866) it works. It > should be very straightforward for us to add this functionality to the > Breakpoints view. > If it worked as you described, filtering the breakpoints/markers view and allowing enablement of the active breakpoints, it would meet my needs. Combining filtering with the ability to add breakpoints to the context (bug 155333) would save me a lot of grief in managing the breakpoints view.
(In reply to comment #20) > (In reply to comment #18) > > Curtis: could you point me at code that will provide the charStart? I have > the IMarker from the breakpoint and the corresponding ICompilationUnit. > > We do not provide a charStart or charEnd attribute on java line breakpoints. We > only provide a line number. IMarker.LINE_NUMBER Thanks Curtis. Do you know of any standard code/API for converting line numbers to charStarts?
(In reply to comment #21) > Thanks Curtis. Do you know of any standard code/API for converting line > numbers to charStarts? There is no easy way to accomplish this. The actual CompilationUnit has the information (getPosition()), but I can't see it being straightforward to get the CompilationUnit from the ICompilationUnit. Another possibility would be to create a jface IDocument from the ICompilationUnit. Neither option is simple.
Is there an easy way to go from the marker to the enclosing IJavaElement (e.g. method)?
(In reply to comment #23) > Is there an easy way to go from the marker to the enclosing IJavaElement (e.g. > method)? I think I'm going to have to look at the Mylyn code to see what you are trying to do to give you a good answer. Unfortunately with the RC builds every week, finding time to work on things will be difficult. However, here is some code from our test suite that might help. protected IJavaLineBreakpoint createLineBreakpoint(IType type, int lineNumber) throws Exception { IMember member = null; if (type != null) { IJavaElement sourceElement = null; String source = null; if (type.isBinary()) { IClassFile classFile = type.getClassFile(); source = classFile.getSource(); sourceElement = classFile; } else { ICompilationUnit unit = type.getCompilationUnit(); source = unit.getSource(); sourceElement = unit; } // translate line number to offset if (source != null) { Document document = new Document(source); IRegion region = document.getLineInformation(lineNumber); if (sourceElement instanceof ICompilationUnit) { member = (IMember) ((ICompilationUnit)sourceElement).getElementAt(region.getOffset()); } else { member = (IMember) ((IClassFile)sourceElement).getElementAt(region.getOffset()); } } } Map map = getExtraBreakpointAttributes(member); return JDIDebugModel.createLineBreakpoint(getBreakpointResource(type), type.getFullyQualifiedName(), lineNumber, -1, -1, 0, true, map); }
Curtis: that's helpful. For Mylyn 3.0 I'll have the current the implementation at making line number breakpoints become interesting if the file is interesting, since I'm concerned about creating a Document within a filter. If anyone would like the line-level granularity for breakpoints please file a new bug, and we'll try to figure out if there is a way of avoiding the creation of the documents. Document document = new Document(compilationUnit.getSource()); IRegion region = document.getLineInformation(lineNumber); javaElement = compilationUnit.getElementAt(region.getOffset());
Created attachment 104937 [details] mylyn/context/zip
