Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tracecompass-dev] Fw: Fw: Fw: Problems updating plugin using Trace Compass to Eclipse Oxygen SR3

Matthew
Sorry, I misunderstood the constructor accepting a DataProvider id.

Is the idea that my default constructor would call the new constructor instead of the superclass constructor it is calling now? If that's the idea, them maybe that will work after all, assuming I know how to register my class with the DataProviderManager.

Dave
----- Forwarded by David Wootton/Poughkeepsie/Contr/IBM on 03/05/2018 08:49 AM -----

From: David Wootton/Poughkeepsie/Contr/IBM
To: Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>
Date: 03/05/2018 08:38 AM
Subject: Re: [tracecompass-dev] Fw: Fw: Problems updating plugin using Trace Compass to Eclipse Oxygen SR3




Matthew
I looked at the code change, again, without knowing much about Trace Compass internals. I don't think the proposed patch solves my problem since 1) I don't think I have a way to call the new constructor directly, and 2) the constructor is passed a TimeGraphPresentationProvider, where I think I want to specify an alternate class extending AbstractTimeGraphDataProvider where that class would give me access to the trace and thru the trace to the analysis module and the state system.

I don't think I have a way to call the new constructor since my class that extends CallStackView is registered to Eclipse using the org.eclipse.ui.views extension and Eclipse creates my view somewhere internally.

I am currently specifying my class extending CallStackPresentationProvider by calling getTimeGraphViewer().setTimeGraphProvider() in the createPartControl() method of my class extending CalllStackViewer.

I also call the setCallStackView method of my class extending CallStackPresentationProvider, where that method is also marked deprecated so I don't know if that will cause me other problems.

Looking at CallStackView, I didn't see what looks like an easy way to specify a class extending CallStackDataProvider.

Dave

Inactive hide details for Matthew Khouzam ---03/02/2018 10:05:38 AM---Hi David, Would you have the time for a Google(tm) hangouMatthew Khouzam ---03/02/2018 10:05:38 AM---Hi David, Would you have the time for a Google(tm) hangout or something so we can better understand

From: Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>
To: David Wootton <dwootton@xxxxxxxxxx>, Loic Prieur Drevon <loic.prieur.drevon@xxxxxxxxxxxx>, Bernd Hufmann <bernd.hufmann@xxxxxxxxxxxx>
Date: 03/02/2018 10:05 AM
Subject: Re: [tracecompass-dev] Fw: Fw: Problems updating plugin using Trace Compass to Eclipse Oxygen SR3




Hi David,

Would you have the time for a Google(tm) hangout or something so we can better understand the problem and maybe come up with a way forward?

Thanks
Matthew.



From: tracecompass-dev-bounces@xxxxxxxxxxx <tracecompass-dev-bounces@xxxxxxxxxxx> on behalf of David Wootton <dwootton@xxxxxxxxxx>
Sent:
Thursday, March 1, 2018 5:41:04 PM
To:
tracecompass-dev
Subject:
[tracecompass-dev] Fw: Fw: Problems updating plugin using Trace Compass to Eclipse Oxygen SR3

Loic
I've been looking at this problem today, thought I had a solution, but I am running into problems. I think the same solution applies for both the getEventHoverToolTipInfo and getStateTableIndex methods in my class that extends CallStackPresentationProvider.


In both cases I am passed an ITimeEvent thta is actually a TimeEvent or a NamedTimeEvent.. So I need to start with that object and get access to both the quark that matches this event and the state system that has all the attributes I need to build the tooltip text or determine the color and visibility of an interval.


The way my plugin works, I can have several unrelated traces open, and each trace can have up to 3 analysis modules associated with it since I want to display different views of the trace. My code handles the switching of analysis modules for a trace, and that was working as of Oxygen SR3, and for the moment I assume it still works.


I think that means I need to access whatever my view thinks is the current trace, get the analysis module currently being used by that trace and then get the state system I need to access. I didn't look yet at how I get the quark matching the event.


I can get the AbstractTimeGraphDataProvider object that matches the event by using CallStackViewer.getProvider, where the actual class is CallStackDataProvider.


This class knows what the trace and the analysis module are, but unfortunately, there are no public access methods to get either.


I tried defining a class that extended CallStackDataProvider and implemented a method which gave me access to the trace object, but I don't know how I can actually set that provider so that CallStackViewer.getProvider gives me that instead of a CallStackDataProvider object.


The other way thought I could solve this is that I could implement a static method in my class that overrides CallStackViewer that gave me the trace object for the current trace, but that doesn't really seem like the right way to solve the problem.


Do you have any suggestions how I should approach this?


Thanks


Dave

----- Forwarded by David Wootton/Poughkeepsie/Contr/IBM on 03/01/2018 05:08 PM -----


From:
David Wootton/Poughkeepsie/Contr/IBM
To:
tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date:
03/01/2018 11:26 AM
Subject:
Re: [tracecompass-dev] Fw: Problems updating plugin using Trace Compass to Eclipse Oxygen SR3




Loic
I looked at the interval visibility problem a bit this morning and found out what's happening.


I have a class that extends CallstackPresentationProvider and overrides that classes getStateTable, getEventHoverTooltipInfo and getStateTableIndex methods with the intent to set color for the interval depending on specific attributes of the interval I get from the state system and also controls visibility of intervals. My getStateTableIndex method expects to get a CallStackEvent, but is now getting either a TimeEvent or a NamedTimeEvent object. Since my code didn't know what to do with them, it returns ITimeGraphPresentationProvider.INVISIBLE.


My extension of CallstackPresentationProvider does need access to the state system so I can query it in order for the view to work correctly.


I will look at the code you referenced to see what I need to do.


Thanks


Dave


Inactive hide details for Loic Prieur Drevon ---03/01/2018 10:11:13 AM---Hi David, We have undergone some major decoupling workLoic Prieur Drevon ---03/01/2018 10:11:13 AM---Hi David, We have undergone some major decoupling work to separate the core and

From:
Loic Prieur Drevon <loic.prieur.drevon@xxxxxxxxxxxx>
To:
"tracecompass-dev@xxxxxxxxxxx" <tracecompass-dev@xxxxxxxxxxx>
Date:
03/01/2018 10:11 AM
Subject:
Re: [tracecompass-dev] Fw: Problems updating plugin using Trace Compass to Eclipse Oxygen SR3
Sent by:
tracecompass-dev-bounces@xxxxxxxxxxx




Hi David,



We have undergone some major decoupling work to separate the core and

UI classes, which now exchange data through the data provider

interface.



It seems that you needed the ITmfStateSystem to populate your tooltips,

but we try not to access the state system in the UI now. The "new" way

to do it is to use the fetchTooltip method in ITimeGraphDataProvider.

The CriticalPathPresentationProvider, ControlFlowPresentationProvider

and ResourcesPresentationProvider contain examples using this API.



Your states might also not be colored because of missing getStateTable

and getStateTableIndex?



Hope this helps,

Loic



On Wed, 2018-02-28 at 14:51 -0500, David Wootton wrote:

> Sorry if this is a duplicate. My email client picked tracecompass-

> dev-bounces by mistake the first time.

> Dave

> ----- Forwarded by David Wootton/Poughkeepsie/Contr/IBM on 02/28/2018

> 02:50 PM -----

>

> From: David Wootton/Poughkeepsie/Contr/IBM

> To: tracecompass-dev-bounces@xxxxxxxxxxx

> Date: 02/28/2018 11:00 AM

> Subject: Problems updating plugin using Trace Compass to Eclipse

> Oxygen SR3

>

>

> Hi

> I'm trying to update my plugin which uses Trace Compass from Eclipse

> Oxygen SR1 to Oxygen SR3. After the update it still builds cleanly

> but I ran into a couple problems.

>

> After I load a trace, the trace table editor view is filled in and

> appears to work correctly. However, I have a class which extends

> CallStackView. The structure of the trace appears to be present since

> the time line and the stack for each timeline seem to be properly

> filled in. The problem is that the intervals in the trace are all

> invisible.

>

> The second problem is that if I hover the mouse over random places in

> that view, the intervals seem to be present because I get a tooltip

> popup with some basic information about the interval, but the

> additional info by plugin generates is not there. I also get an

> exception at the same time, as pasted below.

>

> I looked at my plugin source and at least part of the problem may be

> related to the CallStackEntry and CallStackEvent classes now being

> deprecated.

>

> Not being sure how to fix this, I started by replacing my use of

> CallStackEntry with TimeEntry as comments in the st, able-3.3 branch

> source suggest, but then I run into another problem since I use the

> CallStackEvent getEntry() method to get an ITmfStateSystem object and

> that method in the superclass returns an ITimeGraphEntry so gets

> flagged in error.

>

> Any suggestions how I resolve this are appreciated.

>

> java.lang.ClassCastException:

> org.eclipse.tracecompass.tmf.ui.widgets.timegraph.model.TimeGraphEntr

> y cannot be cast to

> org.eclipse.tracecompass.tmf.ui.views.callstack.CallStackEntry

> at

> com.ibm.ppedev.hpct.tracecompass.ui.IntervalPresentationProvider.getE

> ventHoverToolTipInfo(IntervalPresentationProvider.java:85)

> at

> org.eclipse.tracecompass.tmf.ui.widgets.timegraph.TimeGraphPresentati

> onProvider.getEventHoverToolTipInfo(TimeGraphPresentationProvider.jav

> a:135)

> at

> org.eclipse.tracecompass.tmf.ui.widgets.timegraph.widgets.TimeGraphTo

> oltipHandler.fillValues(TimeGraphTooltipHandler.java:173)

> at

> org.eclipse.tracecompass.tmf.ui.widgets.timegraph.widgets.TimeGraphTo

> oltipHandler.fill(TimeGraphTooltipHandler.java:93)

> at

> org.eclipse.tracecompass.tmf.ui.viewers.TmfAbstractToolTipHandler$2.m

> ouseHover(TmfAbstractToolTipHandler.java:81)

> at

> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:

> 209)

> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)

> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4428)

> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1079)

> at

> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4238)

> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3817)

> at

> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(Pa

> rtRenderingEngine.java:1150)

> at

> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.ja

> va:336)

> at

> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(Part

> RenderingEngine.java:1039)

> at

> org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Wor

> kbench.java:153)

> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680)

> at

> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.ja

> va:336)

> at

> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.jav

> a:594)

> at

> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)

> at com.ibm.ppedev.rcp.Application.start(Application.java:23)

> at

> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandl

> e.java:196)

> at

> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runAppli

> cation(EclipseAppLauncher.java:134)

> at

> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ec

> lipseAppLauncher.java:104)

> at

> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja

> va:388)

> at

> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja

> va:243)

> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

> at

> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.

> java:62)

> at

> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces

> sorImpl.java:43)

> at java.lang.reflect.Method.invoke(Method.java:498)

> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)

> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)

> at org.eclipse.equinox.launcher.Main.run(Main.java:1499)

> at org.eclipse.equinox.launcher.Main.main(Main.java:1472)

>

> Dave

>

> _______________________________________________

> tracecompass-dev mailing list

> tracecompass-dev@xxxxxxxxxxx

> To change your delivery options, retrieve your password, or

> unsubscribe from this list, visit

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_tracecompass-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=yA1Giwd7Ls577uUKQ3fQWICGHopYggQ46OvlB30WK5M&m=a4kuNW5Xmr3qaAGgtdMVI4wLDH3T_ddhRVzE__FIM1g&s=OSiJHR0wLz5FpdGYreLM6ttjD8g5VgemO_6Been00PI&e=
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_tracecompass-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=yA1Giwd7Ls577uUKQ3fQWICGHopYggQ46OvlB30WK5M&m=a4kuNW5Xmr3qaAGgtdMVI4wLDH3T_ddhRVzE__FIM1g&s=OSiJHR0wLz5FpdGYreLM6ttjD8g5VgemO_6Been00PI&e=






Back to the top