=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== lool- is now known as lool
anpokalan_g: regarding the include "../lttng/*_report.h" - i could move the code from logging/default_configuration.cpp to src/server/default_server_configuration.cpp09:40
alan_ganpok: it would still  be a cross-component include09:41
alan_gI've not had a serious think about what the dependencies should be - but I'm tempted by the idea of putting all the reporting options together (that needs a few renames)09:42
anpokas in putting lttng and logging together?09:44
anpokor moving them into a report/lttng report/logging structure?09:44
anpokthe only reason we need that is that because whe have to provide a the_..._report() method09:45
anpokif we could split that one up, we would never have to care about it09:45
anpokI thought about reigstering the different types somewhere09:46
alan_ganpok: True - there could be lttng and log report factories09:46
anpokor we could use something generic like: http://code.google.com/p/hypodermic09:46
alan_galf_: opinion? ^^09:48
anpokthat would dissolve most of default_configuration09:48
anpokwe could wire the program_options with that one - or something like that - havent looked on what it needs and how it is done09:49
alan_gI'm not sure we need anything that generic09:49
alf_alan_g: looking09:50
alan_gJust "return LttngReportBuilder(...).foo_report();"09:51
anpokit would be the_foo_report() { return container.create<FooReport>() } and inside lttng/default_configuration.cpp ::register_types() { if (get_option("foo-report" == "lttng") { container.register<Foo,LttngFoo>() }09:54
anpok+Report two times09:54
alf_alan_g: anpok: (I am not sure if this is what Alan meant) how about the_foo_report() { if (lttng) the_lttng_builder().foo_report(); else the_logging_builder().foo_report(); }09:56
alan_galf_: I meant the_foo_report() { if (lttng) LttngBuilder().foo_report(); else LoggingBuilder(the_log()).foo_report(); }09:57
alf_alan_g: anpok: that being said, lttng and logging are kind of reports so I would be ok with a report/lttng,report/logging structure09:58
anpokthe generic approach above could also make our live simpler in other cases... i.e. image adding a constructor parameter somewhere, because we factor out functionality. with types registered like above, and compile time information on constructor signature, the change might not have cause further changes in test cases..10:02
alan_gI've used IOC containers in other languages and understand the attraction (and the problems). And I do realize that that we're on that road with DefaultServerConfiguration. I just don't think it is quite that simple to drop it in.10:09
alan_gHmm. Why can't I find "google::protobuf::GoogleOnceInitImpl(int*, google::protobuf::Closure*)" on the N10 today?10:11
anpok.. so what would be a good intermediate solution.10:11
anpokreshuffling into another container - would that also add a namespace?10:11
alan_gWhat I suggested above? a public class lttng::ReportFactory { shared_ptr<FooReport> foo_report() const; } in the lttng namespace that can be used by any component.10:14
anpokok then agreed10:17
alan_galf_: ?10:23
alf_alan_g: anpok: Why not hide that behind and interface and expose it through the_lttng_report_factory?10:24
alan_gIt doesn't introduce another factory function into DefaultServerConfiguration - just gets used in the implementation.10:27
* alan_g powers up N4 to see if that works any better10:28
alf_alan_g: anpok: But it does introduce a potential "hidden" dependency between lttng and other components10:29
alf_alan_g: anpok: I think that for our current purposes the report/lttng,report/logging structure would be more straightforward10:30
alan_galf_: isn't that orthogonal?10:32
alan_gI mean something needs to provide assess to private report implementations in report/lttng and report/logging10:33
alf_alan_g: anpok: If it's available only for internal (subcomponent) access, I am OK, but we could just use the internal subcomponent classes directly. However, I got the feeling that lttng::ReportFactory was going to be public for *all* components to use.10:36
alf_(not that they would have much reason too)10:37
alan_galf_: we only have "public" and "component private" so yes, it was going to be public10:38
=== yofel_ is now known as yofel
alan_galf_: @"but we could just use the internal subcomponent classes directly." that isn't how I've understood our rules10:45
alan_gOtherwise default_server_configuration.cpp could just access everyone's privates10:47
alf_alan_g: then perhaps subcomponent is not the right word. In my mind the lttng and logging are implementation details of report in this case, placed in separate internal directories.10:48
alan_gwhereas I would give the classes prefixes and put them all in report10:49
alf_alan_g: That's an implementation detail ;)10:50
alan_ganpok: have you decided we're mad yet?10:51
alan_galf_: did you get stuff working on android? Today I find that I've got an unresolved protobuf symbol when I try to run things12:02
alf_alan_g: haven't tried today, but it was working yesterday12:02
alan_galf_: thanks12:03
alan_g\o/ zapping everything in sight and starting over worked12:13
dandraderalan_g, so mirclient doesn't install include/client/mir/*, just include/client/mir_toolkit/*. Because if that a libmirclient user cannot #include <mir/client/private.h> which is needed for the "custom RPC over mir socket" story12:22
dandraders/if that/of that12:23
alan_gdandrader: I understand the problem. Not sure of the best solution - thinking...12:25
alan_gdandrader: yes. Adding that directory to include/mirclient seems to be the best answer. Want to log a bug for me to fix?12:39
dandraderalan_g, sure12:39
dandraderalan_g, https://bugs.launchpad.net/mir/+bug/127656512:42
ubot5Launchpad bug 1276565 in Mir "libmirclient user cannot "#include <mir/client/private.h>"" [Undecided,New]12:42
alan_gdandrader: thanks. Am on it12:43
anpokalan_g: was preparing lunch12:48
anpokalan_g: let me check on madness12:48
anpoki think yes12:50
alan_gdandrader: https://code.launchpad.net/~alan-griffiths/mir/fix-1276565/+merge/20489912:55
kgunnsil2100: i see "problems with unit test" on mir landing...what's up ?13:08
sil2100kgunn: where?13:09
sil2100kgunn: are you sure you're looking at the right landing?13:09
kgunnsil2100: ooo i better look again13:09
kgunnsorry :) sil210013:09
* kgunn should really wait for coffee before trying to read stuff13:10
sil2100kgunn: no problem ;) We need to wait until we are unblocked from the location-service bug before proceeding thouhj13:10
mlankhorstand xorg-server testing was broken anyway due to protobuf abi break :P13:11
=== alan_g is now known as alan_g|lunch
dandraderalan_g|lunch, solve the problem! I would approve it but launchpad seems to be down at the moment.13:16
=== mardy_ is now known as mardy
=== alan_g|lunch is now known as alan_g
rsalvetikgunn: alf_: bug 1276621 needs to be fixed as well to enable the android backend by default13:58
ubot5bug 1276621 in Mir "Android backend unit-tests FTBS on amd64" [Undecided,New] https://launchpad.net/bugs/127662113:58
rsalvetiatm I'm just trying to push a custom mir package that defaults to the android backend13:58
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
anpokalf_: alan_g whats the idea behind the separation of ServerConfiguration and DefaultServerConfiguration?15:27
anpoki.e. the_logger is introduced at DSC15:27
alf_anpok: ServerConfiguration is the interface used by DisplayServer15:27
alan_gServerConfiguration is what DisplayServer needs. DefaultServerConfiguration is a default implementation15:27
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
dandraderalan_g, protobuf question: do I have to keep my service stub alive until I get a reply from the service?16:18
alan_gdandrader: yes16:19
dandraderalan_g, hmm, looks like they're just thin wrappers around the given rpc_channel....16:25
dandradereg: http://paste.ubuntu.com/6879913/16:25
alan_gyeah, they are mostly a level of indirection16:27
dandraderthe thing is that by default they delete the channel when you delete the stub16:28
kdubdo we have to ping someone about that protobuf mismatch problem with CI?16:29
alan_gkdub: no it sorted itself out.16:30
kdubalan_g, okay, cool16:30
alan_gDepending what's in your partial chroot and the image you use you may see the same thing (I did).16:31
alan_gBut the latest versions are OK16:31
alan_gdandrader: they certainly don't separate concerns in a way that feels natural to me.16:33
anpokwhats the legacy of legacy input report?16:43
alan_gIIRC that's the intercept of the original logging in the android input code16:46
anpokok so it is not legacy in itself16:48
alan_gWell the idea was (is?) that we'd replace it with something better integrated into our reporting16:50
anpokhm I first thought it was legacy and hence did not do anything about it16:51
anpoki would first incorporate it into my current rework to not violate component boundaries16:51
anpokand then in a further step I would turn the log() interface into something more report-like?16:52
alan_ganpok: I'm not sure that's the best use of time16:53
anpokfurther .. as in .. further down the road16:55
=== dandrader is now known as dandrader|lunch
anpok... not this week16:56
anpokjust stumbled across it since I was able to remove input_report from the public interface entirely16:56
greybackhey folks, I really need a reliable way of getting the PID of a Session17:06
anpokalan_g: i meant not with this mp17:10
alan_ggreyback: I don't think it is kept after passing to connection_is_allowed() - I guess that's a feature request.17:14
greybackalan_g: I've logged it anyway, how could I push for it https://bugs.launchpad.net/mir/+bug/127670417:16
ubot5Launchpad bug 1276704 in Mir "Need way of getting PID of Session" [Undecided,New]17:16
greybackkgunn: could I push for that feature request? The workaround in unity-mir fails in some scenarios and I can't see any way to make it solid without that feature request17:19
alan_ggreyback: that's the way. ;)17:19
kgunnalan_g: are you volunteering by speaking :)17:20
* alan_g shats up17:21
kgunnwell..you could shat too...but well17:21
alan_gkgunn: I won't get to it today. But if you want I can look tomorrow.17:22
kgunnalan_g: thanks...was just looking to see if we had captured that on a bp as well...is it a specific of "cleanly abstract out application logic from the session mediator"17:23
kgunngreyback: is this for the sidestage flicker ? or some other ?17:26
greybackkgunn: other problem: rapid launching of apps confuses unity-mir - ppl do that to test mzanetti's work17:26
alan_ggreyback: is it actually the PID you want? Or would it be better to allow you to attach an object to the session when it is authorised? (I'm thinking shared_ptr<void>)17:29
greybackalan_g: well PID would be easiest. With the latter suggestion, I would create object with PID and probably app_id to attach. It's much of a muchness to me17:31
greyback(I need PID to verify with upstart the process' app_id)17:32
alan_ggreyback: PID is fine for us - but as I didn't know what you wanted it for I thought you might want something more generic17:33
greybackalan_g: gotcha. For now, PID is plenty enough. It is so that when a Session starts, I can take the PID and using upstart, match the app_id.17:35
=== dandrader|lunch is now known as dandrader
=== alan_g is now known as alan_g|EOD
=== jono is now known as Guest56083

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!