| === 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 | ||
| anpok | alan_g: regarding the include "../lttng/*_report.h" - i could move the code from logging/default_configuration.cpp to src/server/default_server_configuration.cpp | 09:40 |
|---|---|---|
| alan_g | anpok: it would still be a cross-component include | 09:41 |
| alan_g | I'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 |
| anpok | as in putting lttng and logging together? | 09:44 |
| anpok | or moving them into a report/lttng report/logging structure? | 09:44 |
| anpok | the only reason we need that is that because whe have to provide a the_..._report() method | 09:45 |
| anpok | if we could split that one up, we would never have to care about it | 09:45 |
| anpok | I thought about reigstering the different types somewhere | 09:46 |
| alan_g | anpok: True - there could be lttng and log report factories | 09:46 |
| anpok | or we could use something generic like: http://code.google.com/p/hypodermic | 09:46 |
| alan_g | alf_: opinion? ^^ | 09:48 |
| anpok | that would dissolve most of default_configuration | 09:48 |
| anpok | we could wire the program_options with that one - or something like that - havent looked on what it needs and how it is done | 09:49 |
| alan_g | I'm not sure we need anything that generic | 09:49 |
| alf_ | alan_g: looking | 09:50 |
| alan_g | Just "return LttngReportBuilder(...).foo_report();" | 09:51 |
| anpok | it 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 times | 09: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_g | alf_: 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 structure | 09:58 |
| alan_g | Agreed | 09:58 |
| anpok | the 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_g | I'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 |
| anpok | yes. | 10:10 |
| alan_g | Hmm. 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 |
| anpok | reshuffling into another container - would that also add a namespace? | 10:11 |
| anpok | s/container/folder | 10:11 |
| alan_g | What 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 |
| anpok | ok then agreed | 10:17 |
| alan_g | alf_: ? | 10:23 |
| alf_ | alan_g: anpok: Why not hide that behind and interface and expose it through the_lttng_report_factory? | 10:24 |
| alan_g | It 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 better | 10:28 | |
| alf_ | alan_g: anpok: But it does introduce a potential "hidden" dependency between lttng and other components | 10:29 |
| alf_ | alan_g: anpok: I think that for our current purposes the report/lttng,report/logging structure would be more straightforward | 10:30 |
| alan_g | alf_: isn't that orthogonal? | 10:32 |
| alan_g | I mean something needs to provide assess to private report implementations in report/lttng and report/logging | 10:33 |
| alan_g | *access | 10:34 |
| 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 |
| alf_ | s/too/to | 10:37 |
| alan_g | alf_: we only have "public" and "component private" so yes, it was going to be public | 10:38 |
| === yofel_ is now known as yofel | ||
| alan_g | alf_: @"but we could just use the internal subcomponent classes directly." that isn't how I've understood our rules | 10:45 |
| alan_g | Otherwise default_server_configuration.cpp could just access everyone's privates | 10: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_g | whereas I would give the classes prefixes and put them all in report | 10:49 |
| alf_ | alan_g: That's an implementation detail ;) | 10:50 |
| alan_g | anpok: have you decided we're mad yet? | 10:51 |
| alan_g | alf_: did you get stuff working on android? Today I find that I've got an unresolved protobuf symbol when I try to run things | 12:02 |
| alf_ | alan_g: haven't tried today, but it was working yesterday | 12:02 |
| alan_g | alf_: thanks | 12:03 |
| alan_g | \o/ zapping everything in sight and starting over worked | 12:13 |
| dandrader | alan_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" story | 12:22 |
| dandrader | s/if that/of that | 12:23 |
| alan_g | dandrader: I understand the problem. Not sure of the best solution - thinking... | 12:25 |
| alan_g | dandrader: yes. Adding that directory to include/mirclient seems to be the best answer. Want to log a bug for me to fix? | 12:39 |
| dandrader | alan_g, sure | 12:39 |
| dandrader | alan_g, https://bugs.launchpad.net/mir/+bug/1276565 | 12:42 |
| ubot5 | Launchpad bug 1276565 in Mir "libmirclient user cannot "#include <mir/client/private.h>"" [Undecided,New] | 12:42 |
| alan_g | dandrader: thanks. Am on it | 12:43 |
| anpok | alan_g: was preparing lunch | 12:48 |
| anpok | alan_g: let me check on madness | 12:48 |
| anpok | ..processing.. | 12:49 |
| anpok | i think yes | 12:50 |
| alan_g | dandrader: https://code.launchpad.net/~alan-griffiths/mir/fix-1276565/+merge/204899 | 12:55 |
| kgunn | sil2100: i see "problems with unit test" on mir landing...what's up ? | 13:08 |
| sil2100 | kgunn: where? | 13:09 |
| sil2100 | kgunn: are you sure you're looking at the right landing? | 13:09 |
| kgunn | sil2100: ooo i better look again | 13:09 |
| kgunn | sorry :) sil2100 | 13:09 |
| * kgunn should really wait for coffee before trying to read stuff | 13:10 | |
| sil2100 | kgunn: no problem ;) We need to wait until we are unblocked from the location-service bug before proceeding thouhj | 13:10 |
| sil2100 | *though | 13:10 |
| mlankhorst | and xorg-server testing was broken anyway due to protobuf abi break :P | 13:11 |
| === alan_g is now known as alan_g|lunch | ||
| dandrader | alan_g|lunch, solve the problem! I would approve it but launchpad seems to be down at the moment. | 13:16 |
| dandrader | solves | 13:16 |
| === mardy_ is now known as mardy | ||
| === alan_g|lunch is now known as alan_g | ||
| rsalveti | kgunn: alf_: bug 1276621 needs to be fixed as well to enable the android backend by default | 13:58 |
| ubot5 | bug 1276621 in Mir "Android backend unit-tests FTBS on amd64" [Undecided,New] https://launchpad.net/bugs/1276621 | 13:58 |
| rsalveti | atm I'm just trying to push a custom mir package that defaults to the android backend | 13:58 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| anpok | alf_: alan_g whats the idea behind the separation of ServerConfiguration and DefaultServerConfiguration? | 15:27 |
| anpok | i.e. the_logger is introduced at DSC | 15:27 |
| alf_ | anpok: ServerConfiguration is the interface used by DisplayServer | 15:27 |
| alan_g | ServerConfiguration is what DisplayServer needs. DefaultServerConfiguration is a default implementation | 15:27 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| dandrader | alan_g, protobuf question: do I have to keep my service stub alive until I get a reply from the service? | 16:18 |
| alan_g | dandrader: yes | 16:19 |
| dandrader | alan_g, hmm, looks like they're just thin wrappers around the given rpc_channel.... | 16:25 |
| dandrader | eg: http://paste.ubuntu.com/6879913/ | 16:25 |
| alan_g | yeah, they are mostly a level of indirection | 16:27 |
| dandrader | the thing is that by default they delete the channel when you delete the stub | 16:28 |
| kdub | do we have to ping someone about that protobuf mismatch problem with CI? | 16:29 |
| alan_g | kdub: no it sorted itself out. | 16:30 |
| kdub | alan_g, okay, cool | 16:30 |
| alan_g | Depending what's in your partial chroot and the image you use you may see the same thing (I did). | 16:31 |
| alan_g | But the latest versions are OK | 16:31 |
| alan_g | dandrader: they certainly don't separate concerns in a way that feels natural to me. | 16:33 |
| anpok | whats the legacy of legacy input report? | 16:43 |
| alan_g | IIRC that's the intercept of the original logging in the android input code | 16:46 |
| anpok | ok so it is not legacy in itself | 16:48 |
| alan_g | Well the idea was (is?) that we'd replace it with something better integrated into our reporting | 16:50 |
| anpok | hm I first thought it was legacy and hence did not do anything about it | 16:51 |
| anpok | i would first incorporate it into my current rework to not violate component boundaries | 16:51 |
| anpok | and then in a further step I would turn the log() interface into something more report-like? | 16:52 |
| alan_g | anpok: I'm not sure that's the best use of time | 16:53 |
| anpok | further .. as in .. further down the road | 16:55 |
| === dandrader is now known as dandrader|lunch | ||
| anpok | ... not this week | 16:56 |
| anpok | just stumbled across it since I was able to remove input_report from the public interface entirely | 16:56 |
| alan_g | :) | 17:01 |
| greyback | hey folks, I really need a reliable way of getting the PID of a Session | 17:06 |
| anpok | alan_g: i meant not with this mp | 17:10 |
| alan_g | greyback: I don't think it is kept after passing to connection_is_allowed() - I guess that's a feature request. | 17:14 |
| greyback | alan_g: I've logged it anyway, how could I push for it https://bugs.launchpad.net/mir/+bug/1276704 | 17:16 |
| ubot5 | Launchpad bug 1276704 in Mir "Need way of getting PID of Session" [Undecided,New] | 17:16 |
| greyback | kgunn: 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 request | 17:19 |
| alan_g | greyback: that's the way. ;) | 17:19 |
| greyback | :D | 17:19 |
| kgunn | alan_g: are you volunteering by speaking :) | 17:20 |
| * alan_g shats up | 17:21 | |
| alan_g | *shuts | 17:21 |
| kgunn | lol | 17:21 |
| kgunn | well..you could shat too...but well | 17:21 |
| alan_g | kgunn: I won't get to it today. But if you want I can look tomorrow. | 17:22 |
| kgunn | alan_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 |
| kgunn | greyback: is this for the sidestage flicker ? or some other ? | 17:26 |
| greyback | kgunn: other problem: rapid launching of apps confuses unity-mir - ppl do that to test mzanetti's work | 17:26 |
| alan_g | greyback: 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 |
| greyback | alan_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 me | 17:31 |
| greyback | (I need PID to verify with upstart the process' app_id) | 17:32 |
| alan_g | greyback: PID is fine for us - but as I didn't know what you wanted it for I thought you might want something more generic | 17:33 |
| greyback | alan_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!