| kgunn | RAOF: good point... | 01:23 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| RAOF | Mah, memcheck tests. Why take so long, do you? | 05:02 |
| duflu | <memcheck> Because I have to virtualize every memory access as well as instructions :) | 05:07 |
| RAOF | And there we go. When you don't branch on uninitialised values, the memcheck tests pass. Astounding! | 05:50 |
| 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 | 05:51 |
| alf_ | duflu: it does if you can the select the resulting reality that you prefer ;) | 06:07 |
| duflu | alf_: Ah. So I'm running it on the wrong platform. Requires multiverse | 06:08 |
| alf_ | lol | 06:08 |
| racarr__ | Morning alf :) | 06:13 |
| alf_ | racarr__: Good night :) | 06:14 |
| racarr__ | aha any minute now... | 06:15 |
| 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:16 |
| * RAOF should really file a bug about gdb SIGSEGVing everytime I try to dereference a shared_ptr<> | 06:19 | |
| 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:22 |
| 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:23 |
| racarr__ | its a disaster of a button event. | 06:24 |
| racarr__ | lol that was un fair...but it does have room for improvement ;) | 06:43 |
| RAOF | racarr__: I think that all our events need to have some pretty drastic surgery done on them. | 07:13 |
| anpok | yes | 07:14 |
| RAOF | They manage to be simultaneously verbose and not expressive enough. | 07:14 |
| 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:15 |
| 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? | 07:17 |
| alf_ | duflu: alan_g: @1317370, is this under valgrind? | 08:02 |
| alan_g | alf_: no | 08:02 |
| 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:05 |
| 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:06 |
| 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:07 |
| duflu | That's a bit curious that variation | 08:08 |
| * alan_g is suspicious of "unit" tests that take more than milliseconds | 08:11 | |
| duflu | alf_: Yes it happens in isolation too. Up to 25.5 sec | 08:12 |
| 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:13 |
| duflu | alf_: Maybe you need more speed to make it race or something? | 08:14 |
| 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:15 |
| 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:16 |
| duflu | i7-4770 does it too | 08:17 |
| anpok | the BufferQueueTest.stress test usually takes about 2.6 seconds | 08:17 |
| 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:18 |
| 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:19 |
| duflu | and helgrind says?... surely something helpful | 08:20 |
| duflu | But I must look away for now | 08:20 |
| anpok | hm there were some intersting talks about haswells performance and compiler optimizations in going native 2013 | 08:23 |
| anpok | release binary is wors | 08:24 |
| anpok | e | 08:24 |
| anpok | 30 seconds | 08:24 |
| anpok | and 38s .. | 08:25 |
| anpok | enough testing bbiab | 08:25 |
| * alan_g puts on list to look at later // gives other people the chance to look first and save me from it | 08:31 | |
| 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:37 |
| alan_g | duflu: that is plausible (needs testing of course) | 08:39 |
| duflu | Hah. One of those days when the algorithm was right first time and it took me hours to understand the problem thereafter | 08:52 |
| === irsol_ is now known as irsol | ||
| === alan_g is now known as alan_g|lunch | ||
| anpok | alan_g|lunch: yup it worked. | 13:01 |
| === alan_g|lunch is now known as alan_g | ||
| alan_g | anpok: I like it when we can fix overcomplicated code. \o/ | 13:02 |
| anpok | me too | 13:02 |
| 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:24 |
| alan_g | anpok: or both? | 13:49 |
| alan_g | anpok: re-reviewed. Just nits to fix AFAICS | 13:50 |
| 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:54 |
| kgunn | just tried with sudo and got "Failed to create Mir surface!" | 13:56 |
| alf__ | kgunn: let me try | 13:57 |
| alf__ | kgunn: so devel-proposed? | 13:58 |
| kgunn | alf__: yep | 13:58 |
| alan_g | kgunn: Tried setting $MIR_SERVER to the endpoint? (No need for sudo for it to be the same then) | 13:59 |
| alan_g | Oh, and starting the Mir server. ;) | 14:00 |
| * alan_g is being nagged to reboot. BRB | 14:08 | |
| kgunn | alf__: ah-ha...i think the screen was blanked | 14:13 |
| kgunn | working now | 14:14 |
| alf__ | kgunn: :) | 14:14 |
| AlbertA | mterry: ping | 14:15 |
| 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:16 |
| === alan_g is now known as alan_g|tea | ||
| 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:17 |
| AlbertA | mterry: ok so the other session shows through as the screen slides? | 14:19 |
| mterry | AlbertA, exactly | 14:19 |
| AlbertA | mterry: ok thanks! | 14:20 |
| AlbertA | mterry: so right now the surface it uses is fullscreen with transparent background? | 14:22 |
| mterry | AlbertA, yeah | 14:22 |
| AlbertA | mterry: ok... just trying to figure out how to fix the mir GLRenderer | 14:23 |
| === alan_g|tea is now known as alan_g | ||
| 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:32 |
| alan_g | I'll take another look before standup | 14:33 |
| alf__ | alan_g: thanks | 14:38 |
| 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:40 |
| === dandrader is now known as dandrader|afk | ||
| alan_g | alf__: done. Are you happy with passing-out-client-fds now? | 14:59 |
| anpok | alan_g: all addressed - apart from compositor::Scene | 15:01 |
| alf__ | alan_g: yes, approved | 15:01 |
| === dandrader|afk is now known as dandrader | ||
| 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:16 |
| 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:17 |
| alan_g | It's -r 1609 on devel | 15:18 |
| dednick | alan_g: ah. ok, i'll take a look | 15:23 |
| alan_g | dednick: if it helps I've just sync'd the branch with devel. | 15:32 |
| dednick | alan_g: got it working thanks | 15:33 |
| dednick | alan_g: could probably do with a rpc report for new_fds_for_trusted_clients | 15:36 |
| 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 | 15:37 |
| === chihchun is now known as chihchun_afk | ||
| 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:13 |
| dednick | alan_g: hm. ok. is it normal that they're always the same when i run an app? | 16:27 |
| 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:28 |
| 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:29 |
| dednick | alan_g: but if they're the same accoss clients, then how does another client connect to the fd? | 16:44 |
| alan_g | dednick: child processes inherit their environment from the parent. Including (with various provisos) FDs | 16:45 |
| dednick | alan_g: ah. ok | 16:45 |
| dednick | alan_g: when i call new_fds_for_trusted_clients, i get a SessionAuthorizer::connection_is_allowed for the mir server process. | 16:49 |
| alan_g | dednick: that's decribed in bug 1314574 | 16:50 |
| ubot5 | bug 1314574 in Mir "The client process is identified when the socket connects, not when the client connects to Mir" [Undecided,New] https://launchpad.net/bugs/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:50 |
| alan_g | dednick: it is the process that created the socket | 16:51 |
| 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:52 |
| dednick | s/session/connection | 16:53 |
| alan_g | yes. And (until I fix the bug) that pid will get propagated to the session too. | 16:54 |
| alan_g | dednick: I'm getting to EOD - is there anything more you need? | 16:59 |
| dednick | alan_g: think i'm good for now thanks | 17:00 |
| === alan_g is now known as alan_g|EOD | ||
| anpok | alf__: hm wrt WaitObject WatchDog .. | 17:05 |
| 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:06 |
| === dandrader is now known as dandrader|lunch | ||
| AlbertA | anpok: there are some cases where you can just use auto_unblock_thread instead of watchdog | 17:07 |
| AlbertA | anpok: RAOF said they were equivalent: https://code.launchpad.net/~albaguirre/mir/cleanup-switching-bundle-unit-tests/+merge/217534/comments/517495 | 17:10 |
| AlbertA | anpok: so perhaps just change it to AutoUnblockThread and/or AutoJoinThread instead? | 17:11 |
| anpok | ack | 17:14 |
| === dandrader|lunch is now known as dandrader | ||
| dandrader | are there environment variables to enable debug logging on a mir client? | 19:17 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| RAOF | anpok: I'm removing WatchDog from the 1Hz-rendering branch. | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!