[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Extending filtering for CallStackView
|
Patrick
This approach seems to work as long as I am only dealing with a single trace with multiple analyses. However, if I open a second trace then I run into problems with preserving filters where the filter settings for the first trace get lost or corrupted by switching to the second trace.
I tried to address this by making the 'key' to my map be an object that contained my TmfTrace object (my trace wrapper object) and analysis id so that I would have one entry in my map for each unique trace wrapper object and analysis id.
My logic is handling traces in terms of my trace wrapper objects, where TmfTrace.getName() returns a name consisting of the original trace name with analysis id appended.
I think the code in AbstractTimeGraphView that handles the existing filter map (fFiltersMap) is interfering with my secondary filter map. The code in AbstractTimeGraphView seems to only be aware of the original trace object, not the trace wrapper objects. There's also code in AbstractTimeGraphView.refresh() that checks 'inputChanged' and if that is true, then among other things, executes fTimeGraphWrapper.setFilters(fFiltersMap.get(fTrace));
I think this ends up where the filters for the original trace object end up getting applied to my wrapper trace objects and then filter handling goes wrong.
I'm not sure if I'm still doing something wrong or if this just isn't possible.
I have discussed this with my project lead since I think I need to move on to other things and he is willing to accept not saving/restoring filtering as an acceptable limitation for now, and he is willing to accept this.
I just wanted you to know how your last suggestion ended up and to thank you for trying to get this working. I have an implementation of my trace tool that is working well with Trace Compass code and which I think is a significant improvement over what we were using previously, so all things considered, the lack of proper saving of filter state is a minor limitation.
Dave
Patrick Tasse ---08/22/2016 06:16:47 PM---From: Patrick Tasse <patrick.tasse@xxxxxxxxx> To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/22/2016 06:16 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
Hi Dave,
I think this is what is happening:
In ShowFilterDialogAction.run(), when it computes 'allElements', it will only get the elements from the currently analysis from the content provider. Then further down the 'filteredElements' will only contain hidden elements from the current analysis, and therefore the filtered elements on the other analysis are lost when you use the filter dialog.
As you stated in your opening message, AbstractTimeGraphView keeps a map of filters for the current trace. Here we are talking about the original trace or perhaps this could be an experiment with multiple traces. That map is private as you noted.
I believe what you could try is have your own map of ViewerFilter[] where the key is the current analysis (or wrapped trace, whatever is easily accessible), and then when you switch analyses you store timegraphViewer.getFilters() in the map for the old analysis and restore (if exists) timegraphViewer.setFilters() from the map for the new analysis.
You might also have to override traceClosed() to remove from the map both ViewerFilter[] when closing the original trace. When switching the original trace from one to the other, AbstractTimeGraphView's private map should restore the correct filters, as long as it also restores the correct elements for the current analysis (I'm hoping this is already working correctly?).
Patrick
On Tue, Aug 16, 2016 at 2:55 PM, Bernd Hufmann <bernd.hufmann@xxxxxxxxxxxx> wrote:Hi DavidGreat to hear that you had progress. Just to let you know that Patrick is on vacation this week. If you have more questions he will be back early next week.
Bernd
On 08/16/2016 01:16 PM, David Wootton wrote:
Patrick
I figured out my problem with child Nodes in the tree at the left side of the view. The hasChildren and getChildren methods were only checking for children for TraceEntry and ProcessEntry objects. The corresponding methods in the content provider in CallStackView were checking for 'instanceof TraceEntry'. Since I don't have access to the internal TraceEntry, ProcessEntry or ThreadEntry classes, I needed to make the same check by getting the class name and checking that, where I missed checking for ThreadEntry.
Dave
David Wootton---08/16/2016 12:45:00 PM---Patrick I did most of what you suggested. I could not override getFunctionName(),
From: David Wootton/Poughkeepsie/Contr/IBM@IBMUS
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/16/2016 12:45 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
Patrick
I did most of what you suggested. I could not override getFunctionName(), by which I assumed you meant CallStackView.getFunctionName() since it's access is package-private and not visible to my class extending CallStackView. I don't think this matters since I'm not doing anything in my implementation with function names at this point.
Once I did this, I am able to open a trace, then switch between analysis 'A' and analysis 'B' as well as load a second trace and switch between its analysis 'A' and analysis 'B' without problems.
If I apply a filter to analysis 'A', switch to analysis 'B' and then switch back to analysis 'A' the filtering for analysis 'A' is preserved.
However, if I switch to analysis 'B' again, set a filter for analysis 'B', then filtering is applied to analysis 'B' correctly. However, when I switch back to analysis 'A', its filtering is reset and all threads are visible. If I set a new filter for analysis 'A' then switch to analysis 'B', the filtering for analysis 'B' is reset.
I did set a breakpoint at the point in getElements() where I return the array of TraceEntry objects (a single object) and walk thru the tree from the TraceEntry object down to the ThreadEntry objects, noting the object id (id=nnn) in the debugger. It looks like the tree is not being modified as te object ids remain the same at that point. Maybe a tree elsewhere is being reconstructed, clearing the filtering?
The other problem I'm still seeing is that the tree on the left side of the view that shows the trace, process and thread entries shows no child elements for the thread elements, so a thread element is not expandable/collabsible even though the timeline showing the intervals for the ThreadEntry object are always shown. So there's something else I'm missing that causes the tree to be incorrectly constructed.
Dave
Patrick Tasse ---08/10/2016 03:25:48 PM---> The wrappers could just be a subclass of TmfTrace that have the original trace as a private field,
From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/10/2016 03:25 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
> The wrappers could just be a subclass of TmfTrace that have the original trace as a private field, and another field to indicate which analysis it should use.
Probably simpler:
Call TmfTraceUtils.getAnalysisModulesOfClass(trace, AbstractCallStackAnalysis.class) on your trace, and for each returned call stack analysis, create a different wrapper and store the analysis as a field in the wrapper. Then each wrapper can return that single analysis in its overridden getAnalysisModules().
Patrick
On Wed, Aug 10, 2016 at 3:18 PM, Patrick Tasse <patrick.tasse@xxxxxxxxx> wrote:
Patrick
Yes, the problem is that if I switch between the two analyses, that when I switch back to the first analysis, the filtering settings are gone and all of the threads in the trace are visible again. If I open the TimeGraphFilterDialog, then all of the thread entries are present and checked.
I tried changing my rebuild() calls to refresh() calls. If I make only that change, then my view does not update with the analysis that I wanted to switch to. I still see the results of the same analysis.
The problem might be that rebuild is recreating the CallStackEntry instances as you state. I did see that the fFiltersMap field is updated when a new trace is loaded, with the ITmfTrace object being the map key, and then that map is used to reset the filter when refresh or rebuild are called, so saving and restoring filters across different traces does work.
(The reason I call rebuild has to do with the way I switch between analyses. I specified both analysis to be run automatically when a trace is loaded. Then my class which extends TmfTrace implements an overriding implementation for getAnalysisModules() which determines which analysis is requested and makes sure the corresponding IAnalysisModule is element zero in the list it returns. I did this because there's a private method CallStackView.getCallStackModule(ITmfTrace) which gets the requested analysis module, and is currently implemented so that it returns element 0 of the list.)
Dave
Patrick Tasse ---08/02/2016 05:28:37 PM---Hi Dave, I'm not sure I understand correctly, is your problem that entries that the
From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/02/2016 05:28 PM
Subject: Re: [tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
Hi Dave,
I'm not sure I understand correctly, is your problem that entries that the user has filtered out with the dialog come back visible when you switch analyses?
I think the problem is that when you switch analyses and call rebuild(), your are creating a whole set of brand new CallStackEntry instances. They do not overload Object's equals(), so they are considered different. Consequently, after calling rebuild() the RawViewerFilter contains obsolete entries that do not match against anything anymore.
Can you avoid calling rebuild() when switching analyses? If you just make sure the content provider hides some entries it should work by just calling refresh()?
Patrick
On Tue, Aug 2, 2016 at 2:10 PM, David Wootton <dwootton@xxxxxxxxxx> wrote: I have figured out how to run multiple analyses extended from AbstractCallStackAnalysis for the same trace. I've also figured out how to set a content provider extending TimeGraphContentProvider to my class extending CallStackView so I can make timelines for individual threads visible or not visible like the existing ability to make an entire process visible or not visible using the TimeGraphFilterDialog. I potentially have a lot of threads per process, so this helps the user reduce clutter.
The problem is that the filtering to hide or show threads does not persist when I switch between analyses for the same thread. If I invoke the TimeGraphFilterDialog to pick a set of threads to hide, the view is updated when I close that dialog.
I invoke CallStackView.rebuild() when I switch between analyses.
It seems that this method and CallStackView.refresh() use a private (AbstractTimeGraphView.fFiltersMap) map to track the specified filter active for each trace when multiple traces are open.
Since I don't seem to have access to this map, I can't update it, so whatever I set using the TimeGraphFilterDialog gets overwritten when I switch analyses.
If I had a way to update this map via getter and setter methods then I think what I am trying will work. Alternatively, if I had access to the actual RawViewerFilter object then I could update the set of objects filtered in or out. However, that is a private class defined in ShowFiulterDialogAction so I don't see any way to get access to it.
Is there any way to get access to these objects? Is there another way I could make this work?
Thanks
Dave
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev