[02:38] <duflu> Mir 0.8.0 is now tagged and released.
[02:38] <duflu> Mir 0.9 already underway :)
[07:17] <anpok_> ah
[07:17] <anpok_> the issue i had yesterday ..
[07:19] <anpok_> i cannot connect clients to nested servers if the nested server is not running on the current vt
[07:19] <anpok_> while i can do that for none nested servers
[07:28] <duflu> anpok_, yay
[07:29] <duflu> anpok_: Hey were you expecting i915 to work in that latest Mesa? My i945 doesn't
[07:29] <duflu> ... still
[07:39] <anpok_> no not yet
[07:50] <anpok_> duflu: 10.3.1 is all i can say .. it was review about three weeks after i posted that patch..
[07:50] <anpok_> *reviewed
[07:55] <duflu> anpok_: OK, I was confused. Looks like Ubuntu's getting Mesa fixes in non-chronological order
[07:55] <duflu> Maybe not
[07:56] <anpok_> hm the last update was a fix of mir egl platform
[07:58] <duflu> anpok_: Yes, which is much newer than your i915 fix :)
[09:09] <alan_g> alf__: @a-simpler-server-setup any thoughts on L257?
[09:09] <alf__> alan_g: looking
[09:10] <alf__> alan_g: Better to throw IMO
[09:11] <alan_g> OK
[09:33] <alf__> alan_g: anpok_: duflu: RAOF: We have three test utility classes doing the same thing(WaitCondition, WaitObject, Signal). I am going to keep one of them. Please vote on which *name* you prefer (I will keep the WaitObject/Signal (same thing) implementation in any case).
[09:33] <duflu> alf__: Event ;)
[09:33] <duflu> or something
[09:35] <duflu> alf__: Well we don't have predicates like real conditions do, so not WaitCondition. Not WaitObject because "object" is too general a word for a class name. And not "Signal" because signal is a verb -- a method name really.
[09:35] <duflu> Need a new name I think
[09:36]  * alan_g goes to look what they actually do...
[09:36] <duflu> I was joking about Event, but maybe it's a good idea. Not sure and am not about to review the classes in detail
[09:38] <alf__> duflu: alan_g: Actually perhaps we should just get rid of all the classes and use std::future
[09:39] <duflu> alf__: I believe C++ should provide everything we need, one way or the other
[09:39] <duflu> Not std::future though. That's an ugly one
[09:43] <duflu> alf__: Tell you what; I will close my eyes for now because too many opinions always slow us down
[09:43] <alan_g> alf__: have you seen mt::Signal?
[09:43] <duflu> And I have work to try and finish before too long
[09:44] <alan_g> Sorry, thinko
[09:45] <alan_g> mt::Barrier is similar too.
[10:19] <alan_g> alf__: I think there are three relevant idioms "latch", "barrier" and "future". WaitCondition, WaitObject & Signal all look like latches to me.
[10:24] <alan_g> This doesn't describe a wait_for(time-out) function, but seems sane: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3666.html
[10:48] <alf__> alan_g: It could be that I am not familiar with the term 'latch' in this context, but I don't find it to be a very intuitive name for a mechanism providing inter-thread notification. When I see 'latch' I think 'flip-flop', for which the emphasis is on state storage rather than notification.
[10:49] <alan_g> alf__: ak
[10:56]  * alan_g rediscovers the joy of pre-processor macros
[11:08] <greyback> alan_g: can I pick your brain on a linker rpath issue I'm having?
[11:08] <alan_g> greyback: sure, but I'm no expert
[11:10] <greyback> alan_g: here's my notes: https://docs.google.com/document/d/1d0Djaz0T9OXJVK1wNToj4eYIgkd2N-68T-p7EPZYZJo/edit - the problem is mentioned there
[11:12] <alan_g> greyback: paraphrasing: you can set the rpath either for in-tree or for installed but have trouble handling both?
[11:12] <greyback> alan_g: essentially yes
[11:13] <greyback> alan_g: I had expected that the rpath specified in the executable would take precedence over those in the linked libraries, but it appears not
[11:14] <alan_g> I know CMake relinks stuff it installs, so maybe you can use that mechanism
[11:14]  * alan_g knoes even less about cmake
[11:14] <greyback> qmake doesn't - yet another reason to use racarr's cmake work asap
[11:14] <greyback> but that is good to know about cmake - soundsl ike it would fix this problem for me
[11:15] <greyback> I've spent too long fighting qmake over this, so think most sensible option is indeed cmake
[11:16] <greyback> ok, that's a good enough solution for me, thanks alan_g
[11:16] <alan_g> greyback: yw
[12:10] <mardy> alan_g: about that mir_connection_create_prompt_session_sync() not failing if the initiator is not a valid PID, is it on the radar? Do you have a bug for it?
[12:33] <alan_g> mardy: lp:1377968
[12:38] <mardy> alan_g: oh, that was quick! Thanks! :-)
[17:42] <robotfuel> https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1365673 kgunn can we bump the priority of this bug to critical?
[17:42] <robotfuel> kgunn: it's a top crasher every day
[17:43] <robotfuel> kgunn: we thought that fixing 20141008.1 would fix the issue but it did not
[17:43] <robotfuel> oops
[17:44] <robotfuel> kgunn: we thought that fixing bug #1368101 would fix the issue but it did not
[18:05] <kgunn> robotfuel: per pmcgowan & jfunk in managers channel they want to address the OOM killer issues first
[18:06] <robotfuel> kgunn: ok is there a bug number for that? so I can ask for the bug to be critical instead of high when that is fixed?
[18:11] <kgunn> robotfuel: according to pat & asac they don't have one yet, gonna log one
[18:11] <kgunn> i'll let you know when i know
[22:52] <RAOF> alf__: I (unsurprisingly, as I chose the name originally ☺) vote Signal. Unlike duflu, I'm aware of signal, the noun :)