ominique Toupin* <mailto:dominique.tou...@ericsson.com>>
Date: Fri, Jun 20, 2014 at 9:32 AM
Subject: Re: [linuxtools-dev] TMF parser & Pcap
To: Linux Tools developer discussions <mailto:linuxtools-dev@eclipse.org>>
Hi,
Wireshark replacement was not our top priority this ye
Hi,
Wireshark replacement was not our top priority this year, wireshark is already
open source and doing a great job.
Having said that it is not the first time people are asking about pcap and
wireshark for TMF, it make sense because people want to correlate the pcap
network protocol tracing/mo
Hi Alexandre and Florian,
Thanks for the information, I understand a bit more the TMF project and
its current status and roadmap, good to see that this project is in-line
with most of my requirements. From what you said, it seems I just need
to wait and see because everything is planned ;-) Al
Hi Hisham,
Thanks for your interest!
Right now (with the patch that Florian linked to previously), the
data-driven time graph view only displays rectangles of different
colors. But the "real" time graph view in TMF also supports displaying
arrows from one state to another, as well as text lab
Hi Florian,
Your example works fine!
Regarding the address bus representation, you are right, this is another
way of representing the same data (but so convenient to me to check any
value change in a specific trace). Also I think rectangles are fine
enough, the missing thing is only the value
Hi,
I updated the GDB.UST.xml file with the current XML definition.
So I think it works with the patch 23161.
You have one trace example in the same github ("Sample UST trace.zip").
To answer quickly to your question, there is no view to show a digital bus.
But we have the Control Flow and I thi
Hi Hisham,
The XML based views are not currently in the master branch, but you can
try the XML control flow view with this patch in review :
https://git.eclipse.org/r/#/c/23161/
The XML definition is already in TMF, you can find an example here :
https://git.eclipse.org/r/#/c/23159/7
To import a n
Hi Patrick
Thank you very much for the detail description.
It is very helpful
Ran-How
On Mon, Apr 7, 2014 at 10:59 PM, Patrick Tasse wrote:
> Hi Ran-How,
>
> The spirit of TMF framework is that you would define a new trace type with
> the org.eclipse.linuxtools.tmf.core.tracetype extension p
Hi Ran-How,
The spirit of TMF framework is that you would define a new trace type with
the org.eclipse.linuxtools.tmf.core.tracetype extension point. I'm guessing
you have already done so and that your trace type id is
Activator.TRACETYPE_ID, although that means your plugin only has 1 trace
type.
Hi Xavier
I pushed a patch to disallow opening the RCP with the same workspace
multiple times.
Please have a look and let me know if it's ok with you.
https://git.eclipse.org/r/#/c/24544/
Thanks
Bernd
On 04/07/2014 08:37 AM, Bernd Hufmann wrote:
Hi Xavier
I wasn't aware that the workspace c
Hi Xavier
I wasn't aware that the workspace can be re-used in an RCP. I expected
the same behaviour
than Eclipse where a workspace can't be opened multiple times at the
same time. I guess
we need to implemented the behaviour manually to avoid the problem that
you and your
user faced.
I'll in
Hi Patrick
Got it, actually, I saw the dummy helper for validation purpose also ^^
The cause I ask it is that I am trying to to some injection under the TMF
way implementation for a new TraceType
I try to implementation a E4 based service that can do some additional PIPE
like trace processing
F
> Regarding multiple instances of the RCP running at the same time, I
> guess we didn't really think about it... I just tried doing it, it opens
> a separate instance, but the shared workspace makes it work weirdly. If
> I open a trace in one, refreshing the other will show the newly added
> t
Hi Ran-How,
The reason we can't use the ITmfTrace instance owned by the trace type
helper is that we need a different instance for each opened trace (they
have different resources, paths, indexers, etc.).
The instance in the trace type helper is a dummy trace instance that is
only used for trace
Hi Xavier
there are 2 possibilities to change the default workspace of the RCP:
1) change the traceViewer.ini file
In there replace @noDefault with an absolute path to the new workspace
directory.
2) use the environment variable TRACING_RCP_ROOT
Setting the environment variable before launchi
(note to self: read emails completely before answering!)
Regarding multiple instances of the RCP running at the same time, I
guess we didn't really think about it... I just tried doing it, it opens
a separate instance, but the shared workspace makes it work weirdly. If
I open a trace in one, r
Hi Xavier,
Yes, we put the workspace in ~/.traceviewer.
We also added a --open command line option, to do exactly what you
describe ;) But I didn't know about the Open File feature you
mentioned. I guess we could have saved some code!
Cheers,
Alex
On 04/02/2014 06:01 AM, Xavier Raynaud wr
On 14-02-20 10:52 AM, Geneviève Bastien wrote:
>
>
> * The LTTng UST Memory usage analysis is a more tricky (and
> interesting!) case: It has events. Adding the context TID and procname
> will give a more interesting analysis, but the analysis can still do
> something without it.
That's interestin
>>
>> Some questions:
>> - A "string" requirement is quite generic. What actual types of
>> requirements do you have in mind? I can see event type (or event name),
>> but what else? If we can pinpoint a few specific types of requirements,
>> we could have a couple of methods specifically for those
Hi Guilliano,
Thanks! I'll add your contribution so far on gerrit to be able to better
appreciate it and review it.
On 02/20/2014 10:11 AM, Guilliano Molaire wrote:
Hi Alex,
On 19/02/2014 4:45 PM, Alexandre Montplaisir wrote:
Hi Guilliano,
Interesting project! Indeed, there is already an A
Hi Alex,
On 19/02/2014 4:45 PM, Alexandre Montplaisir wrote:
Hi Guilliano,
Interesting project! Indeed, there is already an API for traces to
indicate if they contain specific events (hasEvent(String),
hasAllEvents(String[]),...).[1] The next step would be to have a way
for an analysis to spec
Hi Guilliano,
Interesting project! Indeed, there is already an API for traces to
indicate if they contain specific events (hasEvent(String),
hasAllEvents(String[]),...).[1] The next step would be to have a way
for an analysis to specify which event types they need, so we can match
the traces and
Hi Patrick,
Many thanks for your answers.
1) Retrieving bookmark through trace->editorInput->editor->bookmark is
OK, but a bit clunky, isn't it ?
Yes, I've a use-case for needing the bookmarks file for a trace.
For my product, the time chart view is the most important:
- it gives
Hi Xavier,
1)
I had to go back far to remember when TmfExperiment.getBookmarksFile() was
introduced. It is a leftover from when we had an Events view that needed to
get the file from its experiment to pass it to the embedded events table.
The Events view did not support traces, only experiments, t
> Note that I did something similar to this in the extensions that I
> did earlier to TMF (the ones that I didn't follow through with
> properly submitting...) In that extension there was the possibility
> of adding any number of possible data driven state system providers
> that automatically ch
- Original Message -
> On 13-12-12 10:55 AM, Aaron Spear wrote:
> > Hi Michel,
> >
> > I think that the "This is a file type that I handle" return value would be
> > useful if it was not just boolean, but rather a rank of some sort. [...]
>
> Hi Aaron,
>
> The idea of rank, or "priority
On 13-12-12 10:55 AM, Aaron Spear wrote:
> Hi Michel,
>
> I think that the "This is a file type that I handle" return value would be
> useful if it was not just boolean, but rather a rank of some sort. [...]
Hi Aaron,
The idea of rank, or "priority", is pretty good! It's so simple too, I
wonder
Hi Genevieve
thank you very much for the summary of our discussion. I'm looking
forward seeing your suggestions.
I plan to work on patch-set 4. I hope I can do that before Christmas.
Otherwise early next year.
Best Regards
Bernd
This Communication is Confidential. We only send and receive e
> TMF must open several "trace" types, some of which are stored in
> directories and others as almost arbitrary text files. Thus, it does
> not fit too well with the usual file open dialog pattern. Yet, we
> often feel that TMF does not just open the file as it should... Here
> is a proposed "algor
Hi Michel,
I think that the "This is a file type that I handle" return value would be
useful if it was not just boolean, but rather a rank of some sort. A generic
CTF reader could handle many different types of traces, and yet there will be
handlers that have specialized knowledge of the trace
Hi Xavier
this would be nice feature. Current Histogram implementation is quite
generic. The data model (see HistogramDataModel.java) can
be used for different types data. For the viewing part is implemented in
base class (Histogram.java). All the pieces are there for what
you've suggested. We
Sounds like a good idea, we just have to figure out what is the best way to
show this to the user without taking up too much valuable window space.
Here's a proposal:
We could put a [+]/[-] widget next to the full trace histogram (when it is
an experiment/trace set), and expanding it would show th
Sounds cool, I was toying (wishing) with the idea of moving the
histogram view to swtchart, that way we can have filters and whatnot in
the histogram too.
On 13-11-27 12:25 PM, Xavier Raynaud wrote:
> Hi,
>
> I've a question (and perhaps an enhancement proposal) about the
> histogram.
> When displa
Hi Xavier,
There is also a TmfSignalThrottler class, in tmf.core.signal, which you
can use to limit the rate at which a view/component sends signals. It
queues signals and only sends the latest one after a configurable delay
has passed with no signal being sent.
We use it for example in the histo
Solved with a simple
while (PlatformUI.getWorkbench().getDisplay().readAndDispatch());
after each signal.
X
On 11/15/2013 01:34 PM, Xavier Raynaud wrote:
Hi,
I wrote some tests on top of my product, based on TMF.
This test generates a lot of TmfTimeSynchSignal.
This tests is OK on TMF-1.2 (Ju
>From what I understood from Xavier's demo, he added it to the base
TimeGraph view, so that all views deriving from it (like the Control
Flow view for example) would display the bookmarks as a vertical black
line, making them a bit more visible overall. It looked nice, as did his
custom Bookmarks V
Hi Xavier,
I'm a bit confused, is this for the TimeChartView from the framework, or a
modified one you use? Because the Time Chart view already does show
bookmarks as a little banner above the corresponding events (see the code
in TimeChartView$DecorateThread).
It also doesn't have a getExperimen
Hi Florian,
Wow, great work! I know many people are eagerly awaiting something like
this!
If you want to squash/rebase your commits on master and push it to
Gerrit, I'll be happy to review it. Perhaps you could add a bit more
comments and a bit saner spacing to the XML files, with that it will be
On 09/04/2013 01:17 PM, Alexandre Montplaisir wrote:
[...]
For renaming I'm a bit less sure. What would be your use case? In our
case, the data in the entries is taken directly from the trace, so
it's already the "true" values. If the user was to modify it, how
would they restore the initial
Hi Xavier,
On 13-09-04 04:46 AM, Xavier Raynaud wrote:
> Hi,
>
> I develop on top of TMF to display traces coming from a massively
> parallel device (16x16 cores for compute + 4x4 cores for IOs + 16
> cores for control).
> TMF is excellent for this usage - Many thanks guys, it's a real
> pleasure
Hi Bernd,
Thanks for the comments. I think we're getting there. Note that I
don't expect (or want) the first patch on the topic to fully respond
adequately to every point, but just to be satisfying enough to get the
concepts in TMF and start being used by actual analysis. It will
improve a
Hi Genevieve and Alex
Sorry for getting so late into the discussion, but I was on vacation and
had to catch up with work.
Before doing big changes and additions to the framework we need to look
what is already available and we need to understand the goals of the
analysis type.
[1] Event Ba
Hi Alex,
On 07/31/2013 01:39 PM, Alexandre Montplaisir wrote:
On 13-07-31 11:52 AM, Geneviève Bastien wrote:
Hi there,
Here is a first patch for review of this feature:
https://git.eclipse.org/r/#/c/14935/
Alexandre, I know you're not hot at the idea of adding extension
points. I'd like to k
On 13-07-31 11:52 AM, Geneviève Bastien wrote:
> Hi there,
>
> Here is a first patch for review of this feature:
> https://git.eclipse.org/r/#/c/14935/
>
> My main issue is to hook the views to the analysis.
>
>>> Initially I proposed one extension point
>>> org.eclipse.linuxtools.tmf.core.analysis
Hi there,
Here is a first patch for review of this feature:
https://git.eclipse.org/r/#/c/14935/
My main issue is to hook the views to the analysis.
Initially I proposed one extension point
org.eclipse.linuxtools.tmf.core.analysis having attribute "provided
views", but that should be really
Just going through the rest of the comments...
On 13-07-15 04:33 PM, Geneviève Bastien wrote:
> [...]
>
>> Right now the trace type defines some of the elements you put in the
>> "analysis" (like state systems and custom statistics). It's also
>> possible to define a specific perspective (collecti
On 13-07-16 01:25 PM, Geneviève Bastien wrote:
> Hi Alex,
>
> You bring up a good point here: views (more generally analysis
> outputs) and analysis really need to be separated. Analysis have
> outputs (like the state system files or statistics, or just an object
> on which more can be done)
I wo
Hi Alex,
You bring up a good point here: views (more generally analysis outputs)
and analysis really need to be separated. Analysis have outputs (like
the state system files or statistics, or just an object on which more
can be done) and views are just a convenient way to display it. With
t
On 13-07-15 04:33 PM, Geneviève Bastien wrote:
> Hi Alex,
>
> Thanks for your feedback.
>
> Just to be clear: experiment types and this analysis types model are
> two different things.
> * Experiment types[1] are an extension of the experiment to allow the
> user to define 'roles' for the traces c
Hi Alex,
Thanks for your feedback.
Just to be clear: experiment types and this analysis types model are two
different things.
* Experiment types[1] are an extension of the experiment to allow the
user to define 'roles' for the traces composing it. Traces can then be
treated differently acco
On 13-07-15 03:19 PM, Francis Giraldeau wrote:
> 2013/7/12 Geneviève Bastien :
>> Each new analysis can then be implemented in its own standalone plugin, with
>> core and ui, which would require only the tmf.core|ui (and the plugins
>> containing other analysis it requires of course). The main plu
2013/7/12 Geneviève Bastien :
> Each new analysis can then be implemented in its own standalone plugin, with
> core and ui, which would require only the tmf.core|ui (and the plugins
> containing other analysis it requires of course). The main plugins would not
> require any analysis modules.
>
> I'
Hi Geneviève,
Interesting stuff! As we discussed previously however, "everything is an
analysis" is quite far from what we have currently in the framework.
Perhaps it'd be easier to go step by step, starting with introducing
experiment types.
Right now the trace type defines some of the elements
Hey Salman,
// we won't get overflow with these values
// this will give a nice gaussian value;
int step = 1;
for (int j = 0; j < 50; j++) {
if (rnd.nextBoolean()) {
step++;
}
}
I wante
Le 24/04/2013 16:59, Alexandre Montplaisir a écrit :
> Ah yes, sometimes we do "ongoing" queries to the state system to get
> attribute names.
> We can also do it for state values themselves (for example, in the
> kernel state provider, in sched_process_fork we will copy over the
> syscall_name att
On 13-04-23 09:41 PM, Florian Wininger wrote:
> Hi Alexandre and Aaron,
>
> Thank you for the discussion.
>
> Replies below,
>
> [...]
> I like this tree defition. But we must add the possibilities to make
> quey on the State Sytem in the path (as was proposed in /New Features in
> TMF about filter
Hi Alexandre and Aaron,
Thank you for the discussion.
Replies below,
Le 23/04/2013 14:22, Alexandre Montplaisir a écrit :
> On 13-04-23 12:40 PM, Aaron Spear wrote:
>> Hi Alexandre,
>>
>> replies below:
>>
>> - Original Message -
>>
>>> - In the XML files to define the state changes, you
On 13-04-23 12:40 PM, Aaron Spear wrote:
> Hi Alexandre,
>
> replies below:
>
> - Original Message -
>> - I think what you call "context" in the stateflow plugin is pretty much
>> the same thing we call "attribute" in the TMF state system. You've
>> probably seen o.e.l.internal.tmf.core.sta
Hi Alexandre,
replies below:
- Original Message -
> - I think what you call "context" in the stateflow plugin is pretty much
> the same thing we call "attribute" in the TMF state system. You've
> probably seen o.e.l.internal.tmf.core.statesystem.Attribute. We already
> use the notion of "
d for
copying and pasting.
Best Regards
Bernd
On 04/23/2013 07:39 AM, Bernd Hufmann wrote:
-- Forwarded message --
From: *Aaron Spear* mailto:asp...@vmware.com>>
Date: Thu, Apr 18, 2013 at 6:39 PM
Subject: Re: [linuxtools-dev] TMF/LTTng: best way to control LTTng
from ot
Hi Aaron,
Sorry for not replying earlier, I was swamped with various stuff last week.
I started looking at your branch on Github, after rebasing it on latest
master. It looks quite good! I will continue experimenting with it this
week, so far I had a couple comments (of course, anybody reading an
Hi Bernd!
Thanks much for the helpful feedback. I almost have this approach working. At
the moment I cloned a fair bit of the logic in TargetNodeComponent.java to
manage the trace lifetime. I basically wrote code that created a trace project
on demand, put the UST traces (the raw traces) into
Hi Aaron
First of all, I think it's a good idea to re-use the code that was done for
the ControlView. It gives you the API to issue LTTng commands remotely as
well as provides the parsing of the command result. I think it's thoroughly
tested using JUnit tests (see plug-in
org.eclipse.linuxtools.lt
Hi Aaron,
This looks great! I will look at it in details over the next few days.
For Gerrit, the idea is to push to a special "refs/for/*" branch. The
Gerrit daemon on the server listens for anything pushed to these
branches, and will create a corresponding review on the website. For
example, pu
Le 2013-03-25 11:58, Geneviève Bastien a écrit :
> Hi all,
>
> As trace analysis tools become available in TMF (trace
> synchronization, critical path calculation, latency, etc), a
> requirement is to be able to express dependencies between events.
As for the critical path, I'm working on a flat v
Hi Bernd,
Thanks for your feedback.
On 03/26/2013 10:08 AM, Bernd Hufmann wrote:
Hi Geneviève
Please see below.
BR,
Bernd
On Mon, Mar 25, 2013 at 11:58 AM, Geneviève Bastien
wrote:
The dependency graph could be displayed also as a sequence diagram. It could
also be exported as a dot file
Hi Michel,
Thanks for your feedback.
I'd propose to use a graph structure to represent those dependencies
(a set of vertices - an object at a given timestamp - and edges - a link
between two vertices).
Do the "vertices" already exist or you plan to "add" new objects. Currently,
events in the
Hi Geneviève
Please see below.
BR,
Bernd
On Mon, Mar 25, 2013 at 11:58 AM, Geneviève Bastien
wrote:
> Hi all,
>
> As trace analysis tools become available in TMF (trace synchronization,
> critical path calculation, latency, etc), a requirement is to be able to
> express dependencies between eve
> As trace analysis tools become available in TMF (trace synchronization,
> critical path calculation, latency, etc), a requirement is to be able to
> express dependencies between events.
Yes, an example is a process A writing to a pipe to send a request to process
B, and waiting and receiving
Hello Aaron
I'm really happy to see that the effort and work that has been done in
recent years for the LTTng/TMF project (State System, improved time
chart widgets, Custom Parsers CTF etc.) attracts your interest and
your are working on extensions to it. I can't wait to see the code.
In the ema
Ah, thanks Patrick!
I had that code snippet commented out with a FIXME comment on it as it seemed
to change from the version that I started with to the current version and I had
not yet figured out what the correct syntax was. I will give that a go.
Sensible time stamp formatting is another t
Hi Aaron,
Nice work!
You might want to try this on your time graph combo since your time stamps
seem to be epoch-based:
timeGraphCombo.getTimeGraphViewer().setTimeFormat(TimeFormat.CALENDAR);
Patrick
On Fri, Mar 15, 2013 at 6:46 PM, Aaron Spear wrote:
>
> > I think that I can see your point
Hi Michel,
> > Attached are some screen shots of this working now. One of them is for
> > a simple text log file and shows a hierarchy of DataCenter > Host > VM
> > and then state values are on the VM's only. (I work for VMware, so
> > that hierarchy seemed relevant). The text log uses the built i
On 13-03-15 12:56 PM, Aaron Spear wrote:
> [...]
> The problem as I see it is the requirement to derive a new type of trace in
> order to get state. I want to have a facility that can create state for
> *any* trace knowing the event schema, but irrespective of the trace format.
> So, I wanted
> display state over time for any sort of object, using data from any
> trace from which state can be extracted
Yes, in fact you derive values (state or metrics) to be stored in the state
tree (and state history database) from events. You thus need expressions to
match events and set the state
Hi Alex,
Thanks for the positive feedback. Some replies below.
> > 1) I changed the TMF code base so that it was possible to have a plugin
> > contribute a named factory that can be used to create state systems. The
> > base implementation of TmfTrace.buildStateSystem checks to see if there is
>
Hi Aaron,
Wow, this is really impressive! :)
So far we had a vague idea of how to move forward to support
"GUI-defined-states" and custom views, but as they say code talks, so
your implementation could really drive how it's done in TMF in the end!
One of the first steps we will have to work on i
Hi Matthew,
On 13-03-12 11:31 AM, Matthew Khouzam wrote:
Hey Florian,
Welcome to the cyberspace bulletin board of linux tools. Great to see
your feedback! So first, could you differentiate string from
identifiers? Is RUNNING a value or a variable? I'm asking because if
it's ambiguous.
If
Hey Florian,
I was thinking over lunch, why would we need assignation in the
specification of the filter?
So if we decide to make it java like, we can have
x.equals(y)
x.contains.(y)
x.compareTo(y)
x > y
x < y
x >= y
x <= y
!x.equals(y)
or C-like
x == y
...
...
x > y
x < y
x >= y
x <= y
x != y
> However, with the recent discussions of
> an eventual build-your-own-state-provider GUI, we are starting to wonder
> if it's really worth exposing all the complexity of the statesystem
> (attribute tree, paths, etc.) to the end-user.
Somehow the user needs to understand the information available
> So first, could you differentiate string from identifiers? Is RUNNING a value
> or a variable?
> I'm asking because if it's ambiguous.
If you dont have relative paths, or a special syntax for relative paths,
RUNNING would be a value.
> Can we have "/jazz/blues/artist == ${/artist}" ?
Hum
Hi Florian,
This is definitely interesting! However, with the recent discussions of
an eventual build-your-own-state-provider GUI, we are starting to wonder
if it's really worth exposing all the complexity of the statesystem
(attribute tree, paths, etc.) to the end-user.
Another hurdle is that ri
Hey Florian,
Welcome to the cyberspace bulletin board of linux tools. Great to see
your feedback! So first, could you differentiate string from
identifiers? Is RUNNING a value or a variable? I'm asking because if
it's ambiguous.
Can we have "/jazz/blues/artist == ${/artist}" ?
Just out of curiosi
Hi François,
Very interesting! Some more comments below
On 13-02-26 04:07 PM, François Rajotte wrote:
> [...]
>
> By using the kernel state system, we have effectively halved the amount of
> information we have to store in the statistics state system.
> By doing so, we have also heavily coupled t
Hello all,
I have implemented some of the ideas discussed here, mostly as a proof of
concept.
The idea was to see where were the major hurdles in implementing more
advanced statistics in the current framework.
For simplicity, I have only implemented the cpu usage of every TID for each
CPU.
For s
> suppose we want to calculate per - cpu CPU utilization of
> each process
> I n the meantime , suppose we are also interested to have a
> reverse statistics: per - process CPU utilization for each CPU
> By using the current organization of the attribute tree , we may
> need to duplicate the
Hello
I want to mention a general case, in which we want to support "group by"
queries for different attributes and resources.
Regarding the problem mentioned by François, suppose we want to calculate *
per*-*cpu CPU utilization of each process* (select CPU usages for each CPU
separately, group
On 13-02-12 04:45 PM, François Rajotte wrote:
>
> I believe the main concern was if we want the information about _many_
> processes at a given timestamp.
> If only one query is necessary (Michel's proposal), then we are sure
> to have all the information in one query. (constant in the number of
>
On Wed, Feb 13, 2013 at 9:26 AM, Alexandre Montplaisir <
alexmon...@voxpopuli.im> wrote:
>
> >> this method only requires a single "attribute" to store the cumulative
> time and whether or not the process is in an active interval. Its value is
> changed at schedule in and at schedule out. However,
> If you fall on a "real" interval, there is no additional queries. If
> you fall on a null interval, you have to do one additional query, to get the
> previous interval. If you want to query a range, you have to do 2
> queries already, by definition. So in the worst case, you end up doing 4
> que
>> this method only requires a single "attribute" to store the cumulative time
>> and whether or not the process is in an active interval. Its value is
>> changed at schedule in and at schedule out. However, you need to do
>> additional queries. For instance, if you want to show the CPU usage p
On 13-02-12 08:18 AM, Michel Dagenais wrote:
>> - If you fall on a "real" interval, you know you are in a time where the
>> process was active on the CPU. You will need to do the interpolation
>> between the value (which represents the cumulative amount at the
>> start of the interval), the length
> - If you fall on a "real" interval, you know you are in a time where the
> process was active on the CPU. You will need to do the interpolation
> between the value (which represents the cumulative amount at the
> start of the interval), the length of the interval, and the current
> position in t
Some other considerations that came to mind after writing the whole thing:
1 - In fact that state history would NOT be storable in a partial
history (aka "partializable"). The partial history only gives us the
values at the queried times, not the whole intervals. It can give us the
start time, but
Hi François,
This would indeed be a nice addition. It would require storing more data
in the state system compared to what we have now (and I'm not sure if it
would "partializable", probably but we would have to check for corner
cases).
We did an experiment about this a couple weeks back, it's a
> The structure could look like this :
>
> Process #1 : 25% total
> -> CPU0 : 20%
> -> CPU1 : 5%
I suppose that you first need to compute the CPU usage per process while
building the state history, summing it up each time it is scheduled out. The
usage up to t0 then becomes the sum at t0 (
Hi Michel,
Thanks for the contribution!
I have pushed your 2 patches to Eclipse's Gerrit for review:
https://git.eclipse.org/r/#/c/9540/
https://git.eclipse.org/r/#/c/9541/
We use Gerrit for code review, so in the future you could push proposed
patches directly there, it would make it more simpl
Hi Xavier,
Probably not, because that interface will no longer exist in 2.0, so the
change wouldn't show up in any linuxtools release.
Patrick
On Mon, Dec 3, 2012 at 11:45 AM, Xavier Raynaud wrote:
> **
> Ok, thanks.
>
> Do you think it can be useful to enhance the current getAdapter() method,
Ok, thanks.
Do you think it can be useful to enhance the current getAdapter()
method, like this ?
/* (non-Javadoc)
* @see org.eclipse.ui.part.WorkbenchPart#getAdapter(java.lang.Class)
*/
@SuppressWarnings("rawtypes")
@Override
public Object getAdapter(Class adapter) {
Hi Xavier,
I didn't think it would be even possible so your code is not crappy but
rather ingenious ;)
In 2.0 this is being refactored because the listener/provider solution
wasn't working well: if your listener was created after the trace was
already opened, it would be too late to receive the T
1 - 100 of 127 matches
Mail list logo
