/srv/irclogs.ubuntu.com/2015/05/05/#ubuntu-mir.txt

robert_ancellWas 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:39
RAOFI don't think mir_buffer_stream made it into vivid?04:43
RAOFrobert_ancell: Yeah, Maarten was developing against trunk, not vivid.04:44
robert_ancellRAOF, 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:44
RAOFrobert_ancell: Maybe? That PPA doesn't have a dependency on one of the Mir landing PPAs, does it?04:45
robert_ancellRAOF, oh, where would show that?04:45
RAOFWhat's the PPA address?04:45
robert_ancellhttps://launchpad.net/~mlankhorst/+archive/ubuntu/ppa04:46
robert_ancellI can't see any dependency there04:46
RAOFrobert_ancell: Looks like the mir_buffer_stream calls are conditionally built.04:50
RAOFrobert_ancell: So the PPA would have built without cursor change support.04:50
robert_ancellRAOF, but the condition only checks the existence of mir_toolkit/mir_buffer_stream.h, it doesn't know it doesn't have the API04:51
robert_ancellI'm rebuilding it here (with debugging symbols) and it's failing to build04:51
RAOFrobert_ancell: I see it #ifdef based on MIR_TOOLKIT_MIR_BUFFER_STREAM_H_?04:52
robert_ancellRAOF, yes. And that is defined in the vivid header04:53
RAOFReally?04:53
robert_ancell grep MIR_TOOLKIT_MIR_BUFFER_STREAM_H_  /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h04: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:53
RAOFYou have a locally installed mir_buffer_stream.h04:54
robert_ancell?04:54
RAOF/usr/include/mirclient/mir_toolkit/mir_buffer_stream.h is *not* in the vivid libmirclient-dev04:54
robert_ancellOh. I have silo0 installed. It must have come in with that.04:56
robert_ancellThat explains things...04:56
dufluWow, bypass can hold buffers almost two frames. That should not be surprising as it is06:24
=== 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
anpok_alf_: why do you use a weak_ptr to the promise in ::start?14:30
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 it14:34
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 set14:35
anpok_ah now i see that14:35
alf_anpok_: so I resorted to this14:35
* racarr yawns 14:37
racarrGood morning14:37
mibofraoh hi racarr :D14:39
alan_ganpok_: 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.gz14:50
racarralan_g: No. that test is actually relatively isolated iirc14:54
racarre.g. really depends just on a few classes14:55
racarrmy guess is its really just a race/slowness14:55
alan_gracarr: The odd thing is that the failing line is EXPECT_GT(duration, 1ms); - which I wouldn't expect slowness to trigger14:56
alan_gOr am I reading it wrong?14:57
racarralan_g: It looks like what it depends on15:01
racarralan_g: Is that the motion event, wont be reported when things are made dispatchable at15:01
racarrl26515:01
racarrbecause its too new so it stays batched15:01
racarrso the difference between start and is > 1 ms15:01
racarrbecause we15:01
racarrslept for some amount of tiome15:01
racarrwaiting for an event to become ready15:02
racarrhowever if "auto start = high_resolution_clock::now()"15:02
racarrwell if we get there too late15:02
racarrthen the motion obviously wont be too new right15:02
racarrand it has to do with the15:02
racarrstatic time stuff in the input receiver15:02
alan_gYeah, the whole premise is dubious15:02
racarrand is like 15-16ms or something15:02
racarrI15:02
racarram a long standing proponent that this test doesn't make sense :p15:03
racarrum15:03
racarrwoops standup15:03
alan_gI'll join you on that15:03
alf_racarr: BTW, we should be using steady_clock not high_resolution_clock15:04
alan_gthat's the least of the problems15:05
racarrcamako: If you cant use non x input on non x graphics then maybe just them being in the same library is a good solution15:16
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 :)15:17
=== 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
racarrI made you guys some mps22:36

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!