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