=== chihchun_afk is now known as chihchun
[04:03] <RAOF> duflu_: I only use the mu:: shorthand in the implementation file of mir::udev::, everywhere else I use the full mir::udev:: namespace specifier. You'd prefer it if I used the full mir::udev:: specifier in the implementation file, too?
[04:05] <duflu_> RAOF: No, there are two possible ways to avoid mentioning the namespace in the implementation. I'd prefer either of them :)
=== duflu_ is now known as duflu
[04:07] <duflu> *to avoid repeating the namespace
[07:29] <didrocks> duflu: hey! tell me when you have some time for a chat on the new process (hangout I guess)
[07:30] <duflu> didrocks: Sorry, it seems I'm possibly tied up for the rest of the day (sabdfl) in other meetings
[07:31] <didrocks> duflu: ok, do you think you will have time tomorrow or let's wait for Monday?
[07:31] <duflu> didrocks: Tomorrow is OK AFAIK
[07:31] <didrocks> duflu: sounds ok. there are consequences btw, we need to have a lander for unity-mir (I think you won't land every release for it) and another one for qtubuntu/platform-api
[07:31] <didrocks> as they are linked to those landing, we need to clear that out
[07:32] <didrocks> kgunn: I was thinking about greyback for unity-mir, thoughts?
[07:33] <greyback> didrocks: count me in
[07:36] <didrocks> sweet!
[07:36] <didrocks> so, we need to find a victim for qtubuntu/platform-api ;)
[07:45] <kgunn> didrocks: thats ricmm_
[07:45] <kgunn> who is in a mtng w me right now
[07:46] <didrocks> kgunn: ok, I'll send an email to sum that up
[07:46] <didrocks> thanks!
=== chihchun is now known as chihchun_afk
=== pete-woods is now known as pete-woods|posti
[11:49] <anpok_> are there any rules of thumb in using lttng - should one avoid string outputs.. keep them short .. just do not core, and make the trace points as descriptive as possible..
[11:51] <tvoss> anpok_, I think there are no strong rules, but the longer the name, the more data to store
[11:51] <tvoss> anpok_, I would think that limiting the scope with something mir::comp::event might make sense
=== mlankhor1t is now known as mlankhorst
=== pete-woods|posti is now known as pete-woods
[12:10] <tvoss> anpok_, thoughts?
=== alan_g is now known as alan_g|afk
[12:35] <anpok_> re
[12:36] <anpok_> tvoss: thought about parameters .. i.e there is now a report that is meant to produce the selected egl configuration.. and does so by dumping each configuration attribute line by line
[12:36] <anpok_> " [ name_of_the_attribute ] : <EGLInt value>"
[12:37] <tvoss> anpok_, okay, can you produce a single line out of that? we can selectively _not_ record that
[12:37] <anpok_> sure
=== ricmm_ is now known as ricmm
=== alan_g|afk is now known as alan_g
[13:40] <alan_g> anpok_: there's no reason that every reporting interface should be implemented for lttng (or glog, or log, or...)
[13:45] <anpok_> hm why not?
[13:47] <alan_g> lack of need
[13:52] <anpok_> so you mean no further lttng report implementations are needed?
[13:54] <alan_g> When we need them we write them - or even a (hypothetical) http status monitor
[13:54] <tvoss> alan_g, I disagree. duflu's reporters are evaluated manually by parsing text output
[13:54] <tvoss> alan_g, I think those are perfect candidates for lttng report implementations
[13:56] <alan_g> tvoss: I don't know what "duflu's reporters" means, so I can't disagree that some more lttng reports are needed
[13:56] <tvoss> alan_g, duflu did quite some work on reporters recently for input latency and such
[13:57] <alan_g> But there's no reason to say "here's a reporting interface, therefore do an lttng implementation"
[13:58] <alan_g> But what you're saying is we have a timing report requirement on *some* report interfaces - therefore do an lttng implementation. Which is fine.
[13:58] <tvoss> alan_g, fair
[13:58] <alan_g> But there are too many sentences starting "But"
[13:59] <anpok_> But you can continue like that
[14:00] <alan_g> But "a report that is meant to produce the selected egl configuration" doesn't beg for an lttng version
[14:05] <anpok_> so you would be fine with leaving out certain report method calls?
[14:10] <alan_g> Sure, just implement the simplest thing that satisfies a need we have now.
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
=== dandrader is now known as dandrader|afk
[16:48] <kdub> alan_g, i like the second suggestion in ~kdub/mir/db-optimize
[16:48] <alan_g> kdub: yw
[17:08] <fginther> tsdgeos, going back to 1269485. You don't want a VM do you, you want to run this on a touch device, right?
[17:08] <fginther> https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1269485
[17:08] <ubot5> Ubuntu bug 1269485 in Ubuntu CI Services "Create CI step for unity-mir tests" [Undecided,New]
[17:15] <tsdgeos> fginther: yes, device is cool
=== dandrader|afk is now known as dandrader
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader