[04:39] Was any Mir API reverted from vivid? I'm trying to work out how XMir compiled using mir_buffer_stream_release_sync but libmirclient-dev doesn't contain this (trunk does) [04:43] I don't think mir_buffer_stream made it into vivid? [04:44] robert_ancell: Yeah, Maarten was developing against trunk, not vivid. [04:44] RAOF, but the PPA built somehow and it doesn't contain a newer version of Mir. So I guess he had a newer version of Mir at some point in there?! [04:45] robert_ancell: Maybe? That PPA doesn't have a dependency on one of the Mir landing PPAs, does it? [04:45] RAOF, oh, where would show that? [04:45] What's the PPA address? [04:46] https://launchpad.net/~mlankhorst/+archive/ubuntu/ppa [04:46] I can't see any dependency there [04:50] robert_ancell: Looks like the mir_buffer_stream calls are conditionally built. [04:50] robert_ancell: So the PPA would have built without cursor change support. [04:51] RAOF, but the condition only checks the existence of mir_toolkit/mir_buffer_stream.h, it doesn't know it doesn't have the API [04:51] I'm rebuilding it here (with debugging symbols) and it's failing to build [04:52] robert_ancell: I see it #ifdef based on MIR_TOOLKIT_MIR_BUFFER_STREAM_H_? [04:53] RAOF, yes. And that is defined in the vivid header [04:53] Really? [04:53] grep MIR_TOOLKIT_MIR_BUFFER_STREAM_H_ /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h [04:53] #ifndef MIR_TOOLKIT_MIR_BUFFER_STREAM_H_ [04:53] #define MIR_TOOLKIT_MIR_BUFFER_STREAM_H_ [04:53] #endif // MIR_TOOLKIT_MIR_BUFFER_STREAM_H_ [04:54] You have a locally installed mir_buffer_stream.h [04:54] ? [04:54] /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h is *not* in the vivid libmirclient-dev [04:56] Oh. I have silo0 installed. It must have come in with that. [04:56] That explains things... [06:24] Wow, bypass can hold buffers almost two frames. That should not be surprising as it is === mibofra is now known as Guest60005 === Guest60005 is now known as mibofra === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [14:30] alf_: why do you use a weak_ptr to the promise in ::start? [14:34] anpok_: I want to ensure that after we leave start() (i.e. the promise value has been set by the enqueued action), any exceptions will not try to set_exception() on it [14:35] anpok_: it's invalid to try to set the value/exception of a promise twice and there is no direct way to check if the promise is set [14:35] ah now i see that [14:35] anpok_: so I resorted to this [14:37] * racarr yawns [14:37] Good morning [14:39] oh hi racarr :D [14:50] anpok_: racarr - guys, can you think of anything changed in input for 0.13 that might explain AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping failing in the silo build? https://launchpadlibrarian.net/205655685/buildlog_ubuntu-vivid-armhf.mir_0.13.0%2B15.04.20150505.1-0ubuntu1_BUILDING.txt.gz [14:54] alan_g: No. that test is actually relatively isolated iirc [14:55] e.g. really depends just on a few classes [14:55] my guess is its really just a race/slowness [14:56] racarr: The odd thing is that the failing line is EXPECT_GT(duration, 1ms); - which I wouldn't expect slowness to trigger [14:57] Or am I reading it wrong? [15:01] alan_g: It looks like what it depends on [15:01] alan_g: Is that the motion event, wont be reported when things are made dispatchable at [15:01] l265 [15:01] because its too new so it stays batched [15:01] so the difference between start and is > 1 ms [15:01] because we [15:01] slept for some amount of tiome [15:02] waiting for an event to become ready [15:02] however if "auto start = high_resolution_clock::now()" [15:02] well if we get there too late [15:02] then the motion obviously wont be too new right [15:02] and it has to do with the [15:02] static time stuff in the input receiver [15:02] Yeah, the whole premise is dubious [15:02] and is like 15-16ms or something [15:02] I [15:03] am a long standing proponent that this test doesn't make sense :p [15:03] um [15:03] woops standup [15:03] I'll join you on that [15:04] racarr: BTW, we should be using steady_clock not high_resolution_clock [15:05] that's the least of the problems [15:16] camako: If you cant use non x input on non x graphics then maybe just them being in the same library is a good solution [15:17] alan_g: Well, a few years ago this led to a week of frustrating debugging because the device used in CI changed the clock during start-up. Not saying it's the same here, but there is no reason to risk going through this again :) === dandrader is now known as dandrader|lunch === marcusto_ is now known as marcustomlinson === dandrader|lunch is now known as dandrader === alan_g is now known as alan_g|EOD [22:36] I made you guys some mps