| duflu | Mir 0.8.0 is now tagged and released. | 02:38 |
|---|---|---|
| duflu | Mir 0.9 already underway :) | 02:38 |
| anpok_ | ah | 07:17 |
| anpok_ | the issue i had yesterday .. | 07:17 |
| 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:19 |
| duflu | anpok_, yay | 07:28 |
| duflu | anpok_: Hey were you expecting i915 to work in that latest Mesa? My i945 doesn't | 07:29 |
| duflu | ... still | 07:29 |
| anpok_ | no not yet | 07:39 |
| 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:50 |
| duflu | anpok_: OK, I was confused. Looks like Ubuntu's getting Mesa fixes in non-chronological order | 07:55 |
| duflu | Maybe not | 07:55 |
| anpok_ | hm the last update was a fix of mir egl platform | 07:56 |
| duflu | anpok_: Yes, which is much newer than your i915 fix :) | 07:58 |
| alan_g | alf__: @a-simpler-server-setup any thoughts on L257? | 09:09 |
| alf__ | alan_g: looking | 09:09 |
| alf__ | alan_g: Better to throw IMO | 09:10 |
| alan_g | OK | 09:11 |
| 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:33 |
| 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:35 |
| * 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:36 |
| alf__ | duflu: alan_g: Actually perhaps we should just get rid of all the classes and use std::future | 09:38 |
| 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:39 |
| 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:43 |
| alan_g | Sorry, thinko | 09:44 |
| alan_g | mt::Barrier is similar too. | 09:45 |
| alan_g | alf__: I think there are three relevant idioms "latch", "barrier" and "future". WaitCondition, WaitObject & Signal all look like latches to me. | 10:19 |
| 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:24 |
| 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:48 |
| alan_g | alf__: ak | 10:49 |
| * alan_g rediscovers the joy of pre-processor macros | 10:56 | |
| 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:08 |
| greyback | alan_g: here's my notes: https://docs.google.com/document/d/1d0Djaz0T9OXJVK1wNToj4eYIgkd2N-68T-p7EPZYZJo/edit - the problem is mentioned there | 11:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| greyback | I've spent too long fighting qmake over this, so think most sensible option is indeed cmake | 11:15 |
| greyback | ok, that's a good enough solution for me, thanks alan_g | 11:16 |
| alan_g | greyback: yw | 11:16 |
| === MacSlow is now known as MacSlow|lunch | ||
| 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:10 |
| === dandrader is now known as dandrader|afk | ||
| alan_g | mardy: lp:1377968 | 12:33 |
| mardy | alan_g: oh, that was quick! Thanks! :-) | 12:38 |
| === dandrader|afk is now known as dandrader | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === mpt_ is now known as mpt | ||
| === dandrader_ is now known as dandrader|lunch | ||
| === alan_g is now known as alan_g|EOD | ||
| robotfuel | https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1365673 kgunn can we bump the priority of this bug to critical? | 17:42 |
| ubot5 | Ubuntu bug 1365673 in unity8 (Ubuntu) "/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene:6:qt_message_fatal:QMessageLogger::fatal:UbuntuClientIntegration::UbuntuClientIntegration:UbuntuMirClientIntegrationPlugin::create:loadIntegration" [High,Triaged] | 17:42 |
| robotfuel | kgunn: it's a top crasher every day | 17:42 |
| === dandrader__ is now known as dandrader | ||
| robotfuel | kgunn: we thought that fixing 20141008.1 would fix the issue but it did not | 17:43 |
| robotfuel | oops | 17:43 |
| robotfuel | kgunn: we thought that fixing bug #1368101 would fix the issue but it did not | 17:44 |
| ubot5 | bug 1368101 in qtmir (Ubuntu) "Stopped apps don't restart when launched from another app" [Critical,Fix committed] https://launchpad.net/bugs/1368101 | 17:44 |
| kgunn | robotfuel: per pmcgowan & jfunk in managers channel they want to address the OOM killer issues first | 18:05 |
| 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:06 |
| 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 | 18:11 |
| === dandrader_ is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| RAOF | alf__: I (unsurprisingly, as I chose the name originally ☺) vote Signal. Unlike duflu, I'm aware of signal, the noun :) | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!