From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <54D8FF55.7040602@ericsson.com> Date: Mon, 9 Feb 2015 13:41:25 -0500 From: Matthew Khouzam MIME-Version: 1.0 References: <54D53C96.8030805@ericsson.com> <1226582540.88170.1423261373714.JavaMail.zimbra@efficios.com> <54D54848.3040807@efficios.com> In-Reply-To: <54D54848.3040807@efficios.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [diamon-discuss] Parsing external datasources in trace compass for regions of interest in a trace List-Id: DiaMon diagnostic and monitoring workgroup general discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Julien Desfossez , Mathieu Desnoyers Cc: diamon-discuss@lists.linuxfoundation.org, lttng-dev@lists.lttng.org, tracecompass developer discussions Great feedback. I think for a first draft, this will work out swimmingly. Right now, I was actually finding the first group of [], splitting with "," [1], then for every timestamp, creating a bookmark. so [12:20:23 , 12:23:22] some range would give bookmark 1-> 12:20:23 -> some range start bookmark 2-> 12:23:22 -> some range end and [22:33:44 ] [key : value] [name = value] [id -> ref ] ... would parse as everything after the timestamp would be read as a string. text [22:33:44] text2 would discard text. Is this ok? [1]note, it will not work with https://github.com/lttng/lttng-analyses where dash is used. On 15-02-06 06:03 PM, Julien Desfossez wrote: > > On 15-02-06 05:22 PM, Mathieu Desnoyers wrote: >> ----- Original Message ----- >>> From: "Matthew Khouzam" >>> To: "tracecompass developer discussions" , diamon-discuss@lists.linuxfoundation.org, >>> lttng-dev@lists.lttng.org >>> Sent: Friday, February 6, 2015 5:13:42 PM >>> Subject: [diamon-discuss] Parsing external datasources in trace compass for regions of interest in a trace >>> >>> Hello, >>> >>> I am right now looking getting external datasources to supply >>> information for a trace, like a region of interest. >>> >>> Background: we can run an analysis on a trace manually, in python, excel >>> or what have you and come up with something interesting, like: around >>> 12:30pm something happened to a trace. Let's dig deeper with tracecompass. >>> >>> To make this work: we need to find a way to import the data, so we >>> should agree on a standard data standard. I personally like the LTTng >>> analysis outputs so I am picking that for now. :) >>> >>> Here are some formats that could be acceptable as regions of interest >>> * [2015-01-15 12:18:37.216484041, 2015-01-15 12:18:53.821580313] name >>> * [2015-01-15 12:18:37.216484041, 2015-01-15 12:18:53.821580313] name >>> boookmark >>> * [ 2015-01-15 12:18:37.216484041] name boookmark >>> * [12:18:37.216484041] name boookmark >>> * [ 12:18:37.216484041, 12:18:53.821580313] name boookmark >>> * [ 2014-12-12 17:29:43.802588035] name with space >>> * [ 2014-12-12 17:29:43] irrational title >>> * [17:29:43.802588035] rational title >>> * [ 17:29:43] test test test >>> * [17:29:43,17:29:44] thing >>> * [12:18:37.216484041 ] (no text) >>> >>> When there is one timestamp, we will create one bookmark. >>> When there is a range, we would create two bookmarks in a given trace, >>> the first one being appended with " start" the second with " end" >>> >>> This should allow tracecompass to marginally benefit from the lttng >>> analyses that are looking pretty nice, and later perhaps from tcp >>> analyses from tshark and syslog stuff. >>> >>> Does anyone have an objection to this way of working? >> Do you intend on supporting timestamps that appear elsewhere than >> the beginning of lines ? Do you consider all text at the right of >> the timestamp or timestamp range to be part of the naming of the >> region of interest linked to the timestamp/timestamp range ? >> >> Julien, did we want to reserve [] for only timestamp range or >> we also want them for single timestamps ? > Right now the [] are only valid with time ranges (they are not accepted > with --begin and --end). I don't mind allowing the brackets for all > timestamps (like in dmesg), we still have the "," to identify if it's a > range or not. > But for convenience, they will remain optional for --begin and --end. > > We just have to keep in mind, that [32,64] could be a range of > values/frequency and not necessarily timestamps. > > Julien