[03:37] ah ban sowet courele coumdele coand ah cepe? di. di. sowet blak sho at weiy === marcusto_ is now known as marcustomlinson [11:06] alan_g: how do you feel about disabling UniqueModulePtrs default constructor? [11:07] anpok: haven't thought about it yet [11:07] Does it work? [11:07] well, yes.. I had to make change to enable it :) [11:07] *changes [11:08] Basically because the deleter wants to be initialized [11:08] I only saw a use for that in my test case, but I can work around that [11:09] (use for the default constructor) [11:09] anpok: give me a few minutes to refresh the MP [11:15] anpok: another option (I've not chosen, just brainstorming) would be to make make_module_ptr a friend of ModuleUniquePtr etc. [11:17] hm yes that would yield different error messages, but it requires actually writing a ModuleUniquePtr, and then we can simply omit the default constructor [11:18] (sorry for writing a but, while brainstorming is active) [11:18] Oops I meant friend of ModuleDeleter [11:19] ah [11:19] I can see it /might/ be useful to default construct a ModuleUniquePtr for later assignment [11:20] alan_g: thats what I was asking about, and what I also use inside a test case [11:20] you can work around those cases, and RAOF asked whether it would be possible to disallow a ModuleUniquePtr being default constructed [11:22] * alan_g imagines workarounds like uniaue_ptr and shudders [11:23] or optional_value> yes [11:23] The "problem" use case is the non-default construction of ModuleUniquePtr with an incorrect initialization of ModuleDeleter [11:24] ah you want to avoid that one! [11:24] good I can do that [11:26] Shall I just write that up in the MP then? [11:30] yip [12:17] alan_g: anonymous friends behave strange in gcc [12:17] ah it unveils a gcc bug [12:17] Really? [12:18] when i make make_module_ptr (which in namespace {}) friend of ModuleDeleter [12:19] clang complains that namespace { make_module_ptr } cannot access the private constructor [12:19] gcc allows it or ignores it [12:19] You have a declaration of make_module_ptr before the friend declaration? [12:20] and then the linker complains that there is no mir::make_module_ptr symbol (and it does not generate a mir::(anonymous namespace)::make_module_ptr symbol [12:20] yes [12:20] is there something in the c++ syntax I missed to be become friend of an anonymous entity? [12:21] So "friend" is injecting into the surrounding namespace and not finding the declaration. :( [12:21] removing the namespace { } works fine for both [12:21] hmm i could try turning ModuleDeleter anonymous too [12:21] which is fine as we it just forwards to the right thing [12:22] Actually, that is sort of reasonable - you don't want a friend in every anon namespace [12:23] Sorted then? [12:24] nearly [12:25] oh uncovers a clang bug too .. and yet another workaround ... [12:26] the using UniqueModulePtr = std::unique_ptr<....> gets a strange taint for clang [12:27] which makes it fail to match a extern "C" mir::UniqueModulePtr create_instance() with a matching mir::UniqueModulePtr create_instance() in the implementation file [12:27] repeating extern "C" solves it [12:28] stange taint because of the now anonymous ModuleDeleter [12:28] but that bug only happens on clang gcc is happy both ways [12:29] What a wonderful story to tell. ;) [12:31] done [12:32] With tests that "bad stuff" doesn't compile? :^| [12:36] aeh? [12:37] static_fail_to_compile [12:38] Yeah. I keep meaning to try - SFINAE ought to provide a way... [12:39] challenge accepted [12:45] * alan_g thinks that this might not be the top priority item on the backlog [12:46] seems to work [12:49] not [12:50] i'll leave that for the weekend [12:50] gcc does not care whether decltype(..) is valid, and clang does not accept invalid decltype even to do sfinae [12:51] so i need to do sfinae within decltype... [12:51] ->weekend [12:56] Hey guys I just got this in vivid and wanted to check if it was normal? http://paste.ubuntu.com/10388642/ [13:06] davmor2: hm no, there is something wrong [13:08] i get the same [13:28] davmor2: anpok: https://bugs.launchpad.net/mir/+bug/1423359 ? [13:28] Launchpad bug 1423359 in mir (Ubuntu) "taking screenshots with mirscreencast fails" [Undecided,Triaged] === alan_g is now known as alan_g|lunch [13:37] alf_: thanks === dandrader_ is now known as dandrader === dandrader is now known as dandrader|afk === alan_g|lunch is now known as alan_g === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|lunch === dandrader|lunch 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 [22:08] mircommon: Caught exception at Mir/EGL driver boundary (in setSwapInterval): /build/buildd/mir-0.11.0+15.04.20150209.1/src/client/buffer_stream.cpp(283): Throw in function virtual void mir::client::BufferStream::request_and_wait_for_configure(MirSurfaceAttrib, int) [22:08] Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEEE [22:08] std::exception::what: Attempt to set swap interval on screencast is invalid [22:09] when using phablet-screenshot on mako/latest vivid [22:09] is that known? [22:09] it worked fine though [22:23] rsalveti: Not known to me :) [22:24] tmpRAOF: great, let me open a bug for it [22:45] tmpRAOF: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1425307 [22:45] Launchpad bug 1425307 in mir (Ubuntu) "Exception when running phablet-screenshot (mako/vivid 110)" [Undecided,New] [22:47] rsalveti: It'd be convenient if you dump the backtrace of running that in gdb with ‘catch throw’ (I don't *think* we have any other expected-but-caught exceptions) :) [22:49] sure, need to install dbg symbols and family [23:09] tmpRAOF: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1425307/comments/2 [23:09] Launchpad bug 1425307 in mir (Ubuntu) "Exception when running phablet-screenshot (mako/vivid 110)" [Undecided,New] [23:09] rsalveti: Much ta. [23:12] Bah. You know what would be rad? If that backtrace didn't give up just before the frame I wanted to inspect :)