Skip to main content
Jump to: navigation, search

Difference between revisions of "Trace Compass/Project Meetings/2016-06-10"

 
Line 1: Line 1:
= Hangout link =
+
= Attendees =
  
URL of the meeting: https://hangouts.google.com/call/pdvvzqxbmvhwfe5lw6wq26shdye
+
* Alexandre Montplaisir (EfficiOS)
 +
* Jonathan Rajotte (EfficiOS)
 +
* Jérémie Galarneau (EfficiOS)
 +
* Bernd Hufmann (Ericsson)
 +
* Patrick Tassé (Ericsson)
 +
* Matthew Khouzam (Ericsson)
 +
* Marc-André Laperle (Ericsson)
 +
* Jean-Christian Kouamé (Ericsson)
 +
* Geneviève Bastien (Polytechnique)
 +
* Loïc Prieur-Drevon (Polytechnique)
  
= Agenda =
+
= Minutes =
 +
 
 +
== Final Neon build is ready ==
 +
 
 +
A Trace Compass Neon RC4 build was provided, short of blocker bugs, this should become the final Neon build.
  
 
== Presentation of the Time Graph View refactoring proposal ==
 
== Presentation of the Time Graph View refactoring proposal ==
 +
 +
Alex presented a proposal of refactoring time graph views into separate model + view elements. The full document was sent to the committers beforehand, but since going through all of it could take time, it was decided to schedule a separate online meeting just for that.
 +
 +
(Note, we are waiting for the confirmation from the sponsors before sharing said design document publicly.)
 +
 +
Some high-level comments were provided:
 +
 +
* The proposal mentions removing the Tree from the Control Flow View to avoid some bugs. A tree-like structure could still be implemented without using a SWT Tree, like is done in the Resource View.
 +
** The removal of the tree is a design decision, the avoidance of bugs it causes is just a nice side-effect.
 +
* Same thing with columns, they could be painted manually on top of the time graph.
 +
** Interesting to keep in mind, but again, removal of columns is a design decision.
 +
* The proposal mentions making the trace the parent item. That was already implemented in the mean time.
 +
* Keep parent/child organization as an option.
 +
** Several organizations options could be available: flat, organize by threads, organize by parent/child, etc.
 +
** We should only keep those that are actually useful, not just do things "because we can".
 +
* Generating a complete render may take some time. Would it be possible to have a series of partial renders, so that the view can update more smoothly.
 +
** Ideally a Render should be "atomic", but we will have to see what the UX feels like. This could be an option.
 +
** Render (pre)caching could also help with this.
 +
* View model for other data backends?
 +
** As mentioned in the document, the current proposal targets only state system backends. But it is definitely a possibility to add another interface to extend it to different data backends in the future.
 +
* Approach to integrate the feature, separate code paths, etc.
  
 
== Tweak to the next/previous buttons in time graph views ==
 
== Tweak to the next/previous buttons in time graph views ==
  
Go to the next/previous event for that thread, cpu, etc. instead of the next state change.
+
Another item that Efficios is planning to work on is to change the "Go to the next/previous" buttons in time graph views to go to the next '''event''' for that thread, cpu, etc. instead of the next '''state change'''.
 +
 
 +
* Feedback from several users deemed this action more useful.
 +
 
 +
* Will it handle UST events?
 +
** The idea is to use the TID aspect to determine what is the next event. So if the TID is available for the UST event (through an analysis, context, etc.), it should work automatically!
 +
 
 +
* We could merge all the different next/previous into the same buttons with a drop-down.
 +
** Semantically, the drop-down of back/forward buttons are usually used to list the possible back/forward items, not different ways of doing back/fowards (see browser back/forward buttons). We'll have to be careful.
 +
** Again, only the useful options should be made available, not all imaginable ones.
  
 
== Presentation of the Logging prototype for Control Flow View responsiveness ==
 
== Presentation of the Logging prototype for Control Flow View responsiveness ==
  
Use of JUL logging to add tracepoints at different places in the code, here in the time graph view threads and state system queries.
+
Geneviève presented a prototype of adding JUL logpoints to the Trace Compass code base, extracting the traces as text files. Using a custom text parser and custom XML analysis, this could display the behaviour of the time graph view threads into a time graph view itself!
 +
 
 +
* Attempts have been made to make JUL use the [http://lttng.org/docs/#doc-jul LTTng-UST Java Agent], but it seems Eclipse/Equinox and its class loading is causing some problems. Investigation ongoing.
  
 
== Committers' discussion on governance and maintenance ? ==
 
== Committers' discussion on governance and maintenance ? ==
 +
 +
Since time is running short, this point was also deferred to a standalone meeting. This is a rather important discussion, so an in-person meeting is preferable.
 +
 +
= Action items =
 +
 +
* Alex: Provide the large list of UI improvements suggested by end users (if possible)
 +
* Alex: Plan online meeting to discuss the CFV proposal. Tentative date: next Tuesday, 1 PM
 +
* Geneviève: Plan in-person meeting about project governance. Tentative date: Monday 20th

Latest revision as of 13:39, 13 June 2016

Attendees

  • Alexandre Montplaisir (EfficiOS)
  • Jonathan Rajotte (EfficiOS)
  • Jérémie Galarneau (EfficiOS)
  • Bernd Hufmann (Ericsson)
  • Patrick Tassé (Ericsson)
  • Matthew Khouzam (Ericsson)
  • Marc-André Laperle (Ericsson)
  • Jean-Christian Kouamé (Ericsson)
  • Geneviève Bastien (Polytechnique)
  • Loïc Prieur-Drevon (Polytechnique)

Minutes

Final Neon build is ready

A Trace Compass Neon RC4 build was provided, short of blocker bugs, this should become the final Neon build.

Presentation of the Time Graph View refactoring proposal

Alex presented a proposal of refactoring time graph views into separate model + view elements. The full document was sent to the committers beforehand, but since going through all of it could take time, it was decided to schedule a separate online meeting just for that.

(Note, we are waiting for the confirmation from the sponsors before sharing said design document publicly.)

Some high-level comments were provided:

  • The proposal mentions removing the Tree from the Control Flow View to avoid some bugs. A tree-like structure could still be implemented without using a SWT Tree, like is done in the Resource View.
    • The removal of the tree is a design decision, the avoidance of bugs it causes is just a nice side-effect.
  • Same thing with columns, they could be painted manually on top of the time graph.
    • Interesting to keep in mind, but again, removal of columns is a design decision.
  • The proposal mentions making the trace the parent item. That was already implemented in the mean time.
  • Keep parent/child organization as an option.
    • Several organizations options could be available: flat, organize by threads, organize by parent/child, etc.
    • We should only keep those that are actually useful, not just do things "because we can".
  • Generating a complete render may take some time. Would it be possible to have a series of partial renders, so that the view can update more smoothly.
    • Ideally a Render should be "atomic", but we will have to see what the UX feels like. This could be an option.
    • Render (pre)caching could also help with this.
  • View model for other data backends?
    • As mentioned in the document, the current proposal targets only state system backends. But it is definitely a possibility to add another interface to extend it to different data backends in the future.
  • Approach to integrate the feature, separate code paths, etc.

Tweak to the next/previous buttons in time graph views

Another item that Efficios is planning to work on is to change the "Go to the next/previous" buttons in time graph views to go to the next event for that thread, cpu, etc. instead of the next state change.

  • Feedback from several users deemed this action more useful.
  • Will it handle UST events?
    • The idea is to use the TID aspect to determine what is the next event. So if the TID is available for the UST event (through an analysis, context, etc.), it should work automatically!
  • We could merge all the different next/previous into the same buttons with a drop-down.
    • Semantically, the drop-down of back/forward buttons are usually used to list the possible back/forward items, not different ways of doing back/fowards (see browser back/forward buttons). We'll have to be careful.
    • Again, only the useful options should be made available, not all imaginable ones.

Presentation of the Logging prototype for Control Flow View responsiveness

Geneviève presented a prototype of adding JUL logpoints to the Trace Compass code base, extracting the traces as text files. Using a custom text parser and custom XML analysis, this could display the behaviour of the time graph view threads into a time graph view itself!

  • Attempts have been made to make JUL use the LTTng-UST Java Agent, but it seems Eclipse/Equinox and its class loading is causing some problems. Investigation ongoing.

Committers' discussion on governance and maintenance ?

Since time is running short, this point was also deferred to a standalone meeting. This is a rather important discussion, so an in-person meeting is preferable.

Action items

  • Alex: Provide the large list of UI improvements suggested by end users (if possible)
  • Alex: Plan online meeting to discuss the CFV proposal. Tentative date: next Tuesday, 1 PM
  • Geneviève: Plan in-person meeting about project governance. Tentative date: Monday 20th

Back to the top