[04:39] <robert_ancell> 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] <RAOF> I don't think mir_buffer_stream made it into vivid?
[04:44] <RAOF> robert_ancell: Yeah, Maarten was developing against trunk, not vivid.
[04:44] <robert_ancell> 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] <RAOF> robert_ancell: Maybe? That PPA doesn't have a dependency on one of the Mir landing PPAs, does it?
[04:45] <robert_ancell> RAOF, oh, where would show that?
[04:45] <RAOF> What's the PPA address?
[04:46] <robert_ancell> https://launchpad.net/~mlankhorst/+archive/ubuntu/ppa
[04:46] <robert_ancell> I can't see any dependency there
[04:50] <RAOF> robert_ancell: Looks like the mir_buffer_stream calls are conditionally built.
[04:50] <RAOF> robert_ancell: So the PPA would have built without cursor change support.
[04:51] <robert_ancell> 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] <robert_ancell> I'm rebuilding it here (with debugging symbols) and it's failing to build
[04:52] <RAOF> robert_ancell: I see it #ifdef based on MIR_TOOLKIT_MIR_BUFFER_STREAM_H_?
[04:53] <robert_ancell> RAOF, yes. And that is defined in the vivid header
[04:53] <RAOF> Really?
[04:53] <robert_ancell>  grep MIR_TOOLKIT_MIR_BUFFER_STREAM_H_  /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h
[04:53] <robert_ancell> #ifndef MIR_TOOLKIT_MIR_BUFFER_STREAM_H_
[04:53] <robert_ancell> #define MIR_TOOLKIT_MIR_BUFFER_STREAM_H_
[04:53] <robert_ancell> #endif // MIR_TOOLKIT_MIR_BUFFER_STREAM_H_
[04:54] <RAOF> You have a locally installed mir_buffer_stream.h
[04:54] <robert_ancell> ?
[04:54] <RAOF> /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h is *not* in the vivid libmirclient-dev
[04:56] <robert_ancell> Oh. I have silo0 installed. It must have come in with that.
[04:56] <robert_ancell> That explains things...
[06:24] <duflu> Wow, bypass can hold buffers almost two frames. That should not be surprising as it is
[14:30] <anpok_> alf_: why do you use a weak_ptr to the promise in ::start?
[14:34] <alf_> 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] <alf_> 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] <anpok_> ah now i see that
[14:35] <alf_> anpok_: so I resorted to this
[14:37]  * racarr yawns 
[14:37] <racarr> Good morning
[14:39] <mibofra> oh hi racarr :D
[14:50] <alan_g> 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] <racarr> alan_g: No. that test is actually relatively isolated iirc
[14:55] <racarr> e.g. really depends just on a few classes
[14:55] <racarr> my guess is its really just a race/slowness
[14:56] <alan_g> racarr: The odd thing is that the failing line is EXPECT_GT(duration, 1ms); - which I wouldn't expect slowness to trigger
[14:57] <alan_g> Or am I reading it wrong?
[15:01] <racarr> alan_g: It looks like what it depends on
[15:01] <racarr> alan_g: Is that the motion event, wont be reported when things are made dispatchable at
[15:01] <racarr> l265
[15:01] <racarr> because its too new so it stays batched
[15:01] <racarr> so the difference between start and is > 1 ms
[15:01] <racarr> because we
[15:01] <racarr> slept for some amount of tiome
[15:02] <racarr> waiting for an event to become ready
[15:02] <racarr> however if "auto start = high_resolution_clock::now()"
[15:02] <racarr> well if we get there too late
[15:02] <racarr> then the motion obviously wont be too new right
[15:02] <racarr> and it has to do with the
[15:02] <racarr> static time stuff in the input receiver
[15:02] <alan_g> Yeah, the whole premise is dubious
[15:02] <racarr> and is like 15-16ms or something
[15:02] <racarr> I
[15:03] <racarr> am a long standing proponent that this test doesn't make sense :p
[15:03] <racarr> um
[15:03] <racarr> woops standup
[15:03] <alan_g> I'll join you on that
[15:04] <alf_> racarr: BTW, we should be using steady_clock not high_resolution_clock
[15:05] <alan_g> that's the least of the problems
[15:16] <racarr> 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] <alf_> 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 :)
[22:36] <racarr> I made you guys some mps