The purpose of the converter is to analyze the log from task tracer offline and then generate a JSON-format output for our front-end, Isis.

In current implementation of Task Tracer, each task logs its information and three timestamps: 1. taskId 2. sourceEvnetId 3. sourceEventType 4. processId 5. threadId 6. actionType: ACTION_DISPATCH=0 / ACTION_START = 1 / ACTION_FINISHED=2 7. timestamp: $dispatchTime / $startTime / $endTime

As for the output in JSON format, each task object must have these properties: * taskId * sourceEventId * sourceEventType * processId * threadId * dispatch * start * end * delayTime * executionTime Some additional properties might be set based on the type of sourceEvent. For example, we have two additional properties for each touch event: * x * y

This is the first version of task tracer converter.

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #2) > As for the output in JSON format, each task object must have these > properties: > * taskId > * sourceEventId > * sourceEventType > * processId > * threadId > * dispatch > * start > * end > * delayTime > * executionTime Per discussion with Alive, we'd like to remove property 'delayTime' and 'executionTime' since they're unused in the current implementation of Isis. Besides, Alive prefers to keep all task objects in an array.

Comment on attachment 8357075 [details] [v1] example output As you can see from the attachment, a little bit of change is needed for all property names. I'm working on it and will update patch once I have done. ex. _task_id ---> taskId

Comment on attachment 8357073 [details] [diff] [review] [v1] task_tracer_converter.py For the first version, the initial values for all properties are 0.

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #1) > 1. taskId > 2. sourceEvnetId > 3. sourceEventType > 4. processId > 5. threadId > 6. actionType: ACTION_DISPATCH=0 / ACTION_START = 1 / ACTION_FINISHED=2 > 7. timestamp: $dispatchTime / $startTime / $endTime For each task, it's not necessary to write information 2. - 5. into the log repeatedly. I propose to change the log format a little bit. 3 records should be kept in the log for each task. The first record includes |taskId|, |dispatch|, |sourceEventId|, |sourceEventType|, |parentTaskId| (if possible), and custom information according to |sourceEventType|. The second record is made up of |taskId|, |start|, |processId|, |threadId|. |taskId| and |end| constitute the last record. Any comments will be highly appreciated!

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #8) > Comment on attachment 8357073 [details] [diff] [review] > [v1] task_tracer_converter.py > > For the first version, the initial values for all properties are 0. Per the discussion today, the initial value for a timestamp should be set based on the log number of the task. Note that some tasks may have incomplete logs, i.e., less than 3 records, especially at the beginning and at the end of profiling. (dispatch, start, end) ------------------------- ( V, V, V): Normal case ( V, V, missed): Set |end| to $profiler_end_timestamp ( V, missed, V): Shouldn't happen ( V, missed, missed): Set both |start| and |end| to $profiler_end_timestamp (missed, V, V): Set |dispatch| to $profiler_start_timestamp (missed, V, missed): Shouldn't happen (missed, missed, V): Set both |dispatch| and |start| to $profiler_start_timestamp (missed, missed, missed): Never happen

Per discussion with Shelly, we may want to put custom info into a separate record. So, a new format is proposed. 4 types of records to be kept: * Custom info [Create Touch Event] sourceEventId createTime x y * Dispatch taskId dispatchTime sourceEventId sourceEventType (parentTaskId) * Start taskId startTime processId threadId * End taskId endTime

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #11) > Per discussion with Shelly, we may want to put custom info into a separate > record. So, a new format is proposed. > > 4 types of records to be kept: > > * Custom info > [Create Touch Event] sourceEventId createTime x y > > * Dispatch > taskId dispatchTime sourceEventId sourceEventType (parentTaskId) > > * Start > taskId startTime processId threadId > > * End > taskId endTime Thanks Gina! This is great :)

Discussed with Thinker and Shelly, let me update the conclusion here. Four types of records to be kept in log: * CREATE: optional [0 sourceEventId createTime customInfo] * DISPATCH [1 taskId dispatchTime sourceEventId sourceEventType parentTaskId] * START [2 taskId startTime processId threadId] * END [3 taskId endTime]

X: the log is missed V: the log is successfully (DISPATCH, START, END) = (V, V, V) => Perfect! (DISPATCH, START, END) = (X, V, V) => Drop the task (DISPATCH, START, END) = (X, X, V) => Drop the task (DISPATCH, START, END) = (V, X, X) => Set both |processId| and |threadId| to null, and set |startTime| to $profiler_end_time (DISPATCH, START, END) = (V, V, X) => Set |endTime| to $profiler_end_time

Support new log format proposed in comment 13.

Gina, I've added the entry of parent task Id, please pull the latest code from my github, and let me know if anything bizarre! Thanks :D

Thanks, Shelly. I'll update my code base and retrieve new log as test data for converter.

Add new flag '-c' for checking parentTaskId if possible. If '-c' is enabled, we create a database and insert tasks into a table for querying parentTaskId. Remove setter and getter in Task and manipulate properties directly. Ignore tasks which had been created before profiling. Besides, if the task was created but hadn't been started yet, the start time and the end time will be assigned to the end time of profiling. If the task was created and was still running at the end of profiling, it's end time will be assigned to the end time of profiling.

New types are coming. * CREATE: optional [0 sourceEventId createTime customInfo] * DISPATCH [1 taskId dispatchTime sourceEventId sourceEventType parentTaskId] * START [2 taskId startTime processId threadId] * END [3 taskId endTime] * LABEL [4 taskId "label"] * VTABLE [5 taskId address]

Firefox OS is not being worked on