[01:23] <kgunn> RAOF: good point...
[05:02] <RAOF> Mah, memcheck tests. Why take so long, do you?
 Because I have to virtualize every memory access as well as instructions :)
[05:50] <RAOF> And there we go. When you don't branch on uninitialised values, the memcheck tests pass. Astounding!
[05:51] <racarr__> Sure but if you dont branch on unitialized values then what fun is left in coding.
[05:51]  * duflu writes that down
[05:51] <racarr__> lol
[05:51] <duflu> I thought that if non-determinism works for the wider universe it must be the right way to code
[06:07] <alf_> duflu: it does if you can the select the resulting reality that you prefer ;)
[06:08] <duflu> alf_: Ah. So I'm running it on the wrong platform. Requires multiverse
[06:08] <alf_> lol
[06:13] <racarr__> Morning alf :)
[06:14] <alf_> racarr__: Good night :)
[06:15] <racarr__> aha any minute now...
[06:16] <racarr__> debugging a chromium crash while I wait for the daily show to appear...on...my legal video streaming site *nods*
[06:16] <racarr__> actually right now im just waiting for GDB to load symbols...
[06:16] <racarr__> THEN sleep
[06:19]  * RAOF should really file a bug about gdb SIGSEGVing everytime I try to dereference a shared_ptr<>
[06:22] <racarr__> I think our button events
[06:22] <racarr__> could be improved
[06:22] <racarr__> the thing is you get "current button state"
[06:22] <racarr__> plus is this an up or down event
[06:23] <racarr__> so everyone has to keep track of
[06:23] <racarr__> button states
[06:23] <racarr__> well in particular, what X and chromium want is "this button up/down" not "new button state"
[06:23] <racarr__> so the adapter layer has to keep track of button state
[06:23] <racarr__> and
[06:23] <racarr__> we only have a few buttons and
[06:24] <racarr__> its a disaster of a button event.
[06:43] <racarr__> lol that was un fair...but it does have room for improvement ;)
[07:13] <RAOF> racarr__: I think that all our events need to have some pretty drastic surgery done on them.
[07:14] <anpok> yes
[07:14] <RAOF> They manage to be simultaneously verbose and not expressive enough.
[07:15] <anpok> and not capturing everything needed
[07:15] <RAOF> Right (not expressive enough)
[07:15] <anpok> oh
[07:15] <anpok> meant expressive in terms of making clear what is going on -> hint: MirEvent.motion.action & FunkyMask
[07:17] <RAOF> Oh, that too.
[07:17] <RAOF> Hm. What happened to lp:mir/devel r1544.52.1?
[07:17] <RAOF> Specifically, why can't I list its history?
[08:02] <alf_> duflu: alan_g: @1317370, is this under valgrind?
[08:02] <alan_g> alf_: no
[08:05] <duflu> alan_g: Might be a better idea to leave more specific bugs open and fix them individually. The older one would take more effort to resolve entirely. Also 1317370 is only new in v0.2.0
[08:06] <alf_> duflu: on what hardward does it take 10 seconds?
[08:06] <alan_g> duflu: I wouldn't object to that provided there are adequate cross-references
[08:06] <duflu> alf_: Haswell i7 quad core desktop :)
[08:06] <duflu> up to 20 seconds
[08:07] <alf_> duflu: hmm, on my i5 laptop it takes 3-4 max
[08:07] <duflu> Weird. Lemme check if it's a side-effect of previous ones
[08:07] <alan_g> I've seen a lot of variation in the time for that one
[08:08] <duflu> That's a bit curious that variation
[08:11]  * alan_g is suspicious of "unit" tests that take more than milliseconds
[08:12] <duflu> alf_: Yes it happens in isolation too. Up to 25.5 sec
[08:13] <duflu> Only that test BufferQueueTest.compositor_never_owns_client_buffers
[08:13] <alf_> duflu: alan_g: actually, for me, the whole BufferQueue test suite takes 3-4 secs, BufferQueueTest.compositor_never_owns_client_buffers takes about 150ms...
[08:14] <duflu> alf_: Maybe you need more speed to make it race or something?
[08:15] <alf_> alan_g: can you reproduce the slow test runtime?
[08:15] <alf_> anpok: ^^ ?
[08:15] <anpok> 10 secs to 15 secs
[08:15] <duflu> alf_: It's not a big deal. If it's just me I'll look into it later
[08:15] <alf_> anpok: what hardware?
[08:16] <alf_> duflu: I am just curious about the difference...
[08:16] <duflu> Sounds like a race. But I'm exercising discipline and not looking into it myself
[08:16] <alf_> duflu: hmm, my test builds are not optimized I see, let me try with "Release"
[08:16] <anpok> i7 quad core .. 4750
[08:17] <duflu> i7-4770 does it too
[08:17] <anpok> the BufferQueueTest.stress test usually takes about 2.6 seconds
[08:18] <alf_> anpok: is 10-15 seconds the time for the whole BufferQueueTest.* run or just for BufferQueueTest.compositor_never_owns_client_buffers ?
[08:18] <alan_g> Running repeatedly I got:
[08:18] <alan_g> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::logic_error> >'
[08:18] <alan_g>   what():  unexpected release: buffer was not given to compositor
[08:18] <anpok> just for the never_owns_client_buffers
[08:18] <anpok> but 15 secs is like the rare max .. and 10 is the avarage
[08:19] <alan_g> Suggests there's racy code
[08:19] <duflu> alan_g: Yeah, never look too hard. You'll always find more bugs
[08:19] <alan_g> Yep
[08:20] <duflu> and helgrind says?... surely something helpful
[08:20] <duflu> But I must look away for now
[08:23] <anpok> hm there were some intersting talks about haswells performance and compiler optimizations in going native 2013
[08:24] <anpok> release binary is wors
[08:24] <anpok> e
[08:24] <anpok> 30 seconds
[08:25] <anpok> and 38s ..
[08:25] <anpok> enough testing bbiab
[08:31]  * alan_g puts on list to look at later // gives other people the chance to look first and save me from it
[08:37] <duflu> alan_g: I'm working roughly in the same area. Notice this reference looks racy (potentially used unlocked):
[08:37] <duflu>     auto const& acquired_buffer = buffer_for(current_compositor_buffer, buffers);
[08:37] <duflu>     if (buffer_to_release)
[08:37] <duflu>         release(buffer_to_release, std::move(lock));
[08:37] <duflu>     return acquired_buffer;
[08:37] <duflu> That would result in the exception you saw, I think
[08:39] <alan_g> duflu: that is plausible (needs testing of course)
[08:52] <duflu> Hah. One of those days when the algorithm was right first time and it took me hours to understand the problem thereafter
[13:01] <anpok> alan_g|lunch: yup it worked.
[13:02] <alan_g> anpok: I like it when we can fix overcomplicated code. \o/
[13:02] <anpok> me too
[13:24] <anpok> hm if no test needs a stub header..
[13:24] <anpok> should it exist then
[13:24] <anpok> or is it a warning sign that we are lacking a test
[13:49] <alan_g> anpok: or both?
[13:50] <alan_g> anpok: re-reviewed. Just nits to fix AFAICS
[13:54] <kgunn> alf__: ok, i feel goofy...i'm doing something wrong, i flashed a fresh image, installed glmark2 debs (manually) from staging ppa, did 'stop unity8', made mir socket 777 and ran glmark2-es2-mir...but got "Couldn't connect to the Mir display server"
[13:56] <kgunn> just tried with sudo and got "Failed to create Mir surface!"
[13:57] <alf__> kgunn: let me try
[13:58] <alf__> kgunn: so devel-proposed?
[13:58] <kgunn> alf__: yep
[13:59] <alan_g> kgunn: Tried setting $MIR_SERVER to the endpoint? (No need for sudo for it to be the same then)
[14:00] <alan_g> Oh, and starting the Mir server. ;)
[14:08]  * alan_g is being nagged to reboot. BRB
[14:13] <kgunn> alf__: ah-ha...i think the screen was blanked
[14:14] <kgunn> working now
[14:14] <alf__> kgunn: :)
[14:15] <AlbertA> mterry: ping
[14:16] <mterry> AlbertA, hello
[14:16] <AlbertA> mterry: got a question for the split greeter
[14:16] <AlbertA> mterry: does it only require global alpha support? not per-pixel?
[14:17] <AlbertA> mterry: I would assume global only (i.e. surface->alpha())
[14:17] <mterry> AlbertA, I'm not sure I follow the question, but it has it's background be full alpha, then it has a sliding screen on top of that
[14:19] <AlbertA> mterry: ok so the other session shows through as the screen slides?
[14:19] <mterry> AlbertA, exactly
[14:20] <AlbertA> mterry: ok thanks!
[14:22] <AlbertA> mterry: so right now the surface it uses is fullscreen with transparent background?
[14:22] <mterry> AlbertA, yeah
[14:23] <AlbertA> mterry: ok... just trying to figure out how to fix the mir GLRenderer
[14:32] <alf__> alan_g: any more thoughts on main-loop-post-actions?
[14:32] <alan_g> alf__: not yet.
[14:32] <alf__> alan_g: ok
[14:33] <alan_g> I'll take another look before standup
[14:38] <alf__> alan_g: thanks
[14:40] <alan_g> dednick: does this have everything you need from it? https://code.launchpad.net/~alan-griffiths/mir/spike-passing-out-client-fds/+merge/218629
[14:59] <alan_g> alf__: done. Are you happy with passing-out-client-fds now?
[15:01] <anpok> alan_g: all addressed - apart from compositor::Scene
[15:01] <alf__> alan_g: yes, approved
[15:16] <dednick> alan_g: seems to. i'm just trying it out now with my branch; but i'm having some linking issues
[15:16] <dednick> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[15:16] <dednick>   what():  /usr/lib/arm-linux-gnueabihf/mir/platformgraphics/android/libmirplatformgraphics.so: undefined symbol: _ZN3mir8graphics9GLProgramD1Ev
[15:17] <alan_g> dednick: that *sounds* like a problem AlbertA fixed on devel yesterday.
[15:17] <alan_g> You ought to be able to "cherry pick"
[15:18] <alan_g> It's -r 1609 on devel
[15:23] <dednick> alan_g: ah. ok, i'll take a look
[15:32] <alan_g> dednick: if it helps I've just sync'd the branch with devel.
[15:33] <dednick> alan_g: got it working thanks
[15:36] <dednick> alan_g: could probably do with a rpc report for new_fds_for_trusted_clients
[15:37] <dednick> alan_g: as the one i asked for in the client is returning fd=0 which sounds a bit dubious.
[15:37] <alan_g> dednick: hmm
[15:37] <dednick> alan_g: it's probably my code
[16:13] <alan_g> dednick: sorry (got distracted)
[16:13] <alan_g> $ MIR_CLIENT_RPC_REPORT=log bin/mir_acceptance_tests --gtest_filter=TrustSessionHelper.gets_fds_for_trusted_clients
[16:13] <alan_g> ...
[16:13] <alan_g> [1399565480.978169] (DD) rpc: File descriptors received: 24 25 26
[16:13] <alan_g> ...
[16:13] <alan_g> Looks sane to me
[16:27] <dednick> alan_g: hm. ok. is it normal that they're always the same when i run an app?
[16:28] <dednick> no idea how it works
[16:28] <alan_g> well, typically fds are allocated in numerical order
[16:28] <alan_g> Within the process that is
[16:29] <alan_g> So if you your clients always have the same number of files open when you run you'll see the same number
[16:44] <dednick> alan_g: but if they're the same accoss clients, then how does another client connect to the fd?
[16:45] <alan_g> dednick: child processes inherit their environment from the parent. Including (with various provisos) FDs
[16:45] <dednick> alan_g: ah. ok
[16:49] <dednick> alan_g: when i call new_fds_for_trusted_clients, i get a SessionAuthorizer::connection_is_allowed for the mir server process.
[16:50] <alan_g> dednick: that's decribed in bug 1314574
[16:50] <dednick> ah. i thought it would be the process that created the socket.
[16:50] <alan_g> Which reminds me to update the status (as I've started on it)
[16:51] <alan_g> dednick: it is the process that created the socket
[16:52] <alan_g> The socket is created on the server and then migrated to the trust helper and inherited by the client
[16:52] <alan_g> Really simple if you don't think about it. ;^)
[16:52] <dednick> presumably i have to authorise the session though :)
[16:53] <dednick> s/session/connection
[16:54] <alan_g> yes. And (until I fix the bug) that pid will get propagated to the session too.
[16:59] <alan_g> dednick: I'm getting to EOD - is there anything more you need?
[17:00] <dednick> alan_g: think i'm good for now thanks
[17:05] <anpok> alf__: hm wrt WaitObject WatchDog ..
[17:06] <anpok> when I remove the WaitObject parts from WatchDog.. can I still call it WatchDog?
[17:06] <anpok> or is WatchDog IS A WaitObject the solution hmm
[17:07] <AlbertA> anpok: there are some cases where you can just use auto_unblock_thread instead of watchdog
[17:10] <AlbertA> anpok: RAOF said they were equivalent: https://code.launchpad.net/~albaguirre/mir/cleanup-switching-bundle-unit-tests/+merge/217534/comments/517495
[17:11] <AlbertA> anpok: so perhaps just change it to AutoUnblockThread and/or AutoJoinThread instead?
[17:14] <anpok> ack
[19:17] <dandrader> are there environment variables to enable debug logging on a mir client?
[23:43] <RAOF> anpok: I'm removing WatchDog from the 1Hz-rendering branch.