[05:00] <AlbertA> davmor2: FYI, the fix for https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1336411 has already landed
[08:41] <duflu> alf_: So mir_demo_server_shell doesn't respond to SIGINT any more?
[08:42] <alf_> duflu: it should, are you seeing something different?
[08:42] <duflu> alf_: Yep, as of this week Ctrl+C does nothing
[08:42] <duflu> Which is fine if it's intentional
[08:43] <alf_> duflu: hmm, now that I think about it, I actually think that's old? I've always used ctrl-alt-backspace to quit
[08:44] <duflu> alf_: Yes, well I haven't tried it since May of course :)
[08:47] <alf_> duflu: so, I think this was affected by a change in the vt input mode
[08:48] <duflu> Sounds plausible. Although I'm running in ssh
[08:49] <alf_> duflu: then that should work, since you are just sending SIGINT to the process
[08:50] <duflu> alf_: Boo. That means I have to retest and log a bug
[09:57] <duflu> alf_: Oh I already reported it. Nothing new... https://bugs.launchpad.net/mir/+bug/1293965
[10:23] <dandrader> alan_g, about that "surface orientation and surface attributes" discussion: what's a surface attribute? maybe there are (or should be) read-only and read-write surface attributes (from the client point of view) and that's enough?
[10:28] <alan_g> dandrader: maybe. I've not had need to think deeply nor read the design docs that motivated them.
[10:40] <dandrader> alan_g, from my naive point of view, if you have some information regarding a surface, such that a client could go and ask "hey, what's the value of X for my surface Y?" or "hey, tell me when the value of X for my surface Y changes (i.e. and event)" then that "X" is a surface attribute. If the client has the right to change it or not it's another story.
[10:40] <alan_g> camako: I know you've other things on your stack but... I'm hoping that this will finally make it easy to write a test for your nested lifecycle logic. Let me know if there anything isn't clear. https://code.launchpad.net/~alan-griffiths/mir/more-nested-server-testing/+merge/225174
[10:41] <dandrader> alan_g, I find it odd when you are able to know when the value something changes but not its current value
[10:41] <dandrader> alan_g, or vice-versa
[10:42] <camako> alan_g, sorry the release took all my time... (too much time if you ask me :-) )
[10:42] <camako> alan_g, still need to test xserver
[10:44] <alan_g> dandrader: from my naive point of view attributes is complicated by having an ABI stable implementation (index value pairs) wrapped in an unstable API whose main benefit is that changes are routed through a "configurator". It would make more sense to me with mir_surface_get_attribute(surface, attribute)/mir_surface_set_attribute(surface, attribute, value)
[10:45] <alan_g> But things must be this way for a reason. I just don't know it.
[10:45] <alan_g> camako: np. (Agree about the time it sucks up.)
[10:47] <alan_g> dandrader: the guy to talk to about attributes is duflu - he implemented it based on some (now ancient) design docs
[10:49] <dandrader> alan_g, ah, ok. so it's about what entails when something is exposed via that attribute system (which has some limitations and expectations)
[10:58] <alan_g> dandrader: yes. It may well be that we could now come up with both better requirements and a better implementation. But I've not been involved (yet) and am not sure who the stakeholders are.
[11:04] <davmor2> AlbertA: manta fix landed and looks good :)
[11:04] <davmor2> kgunn: ^
[11:09] <alan_g> dandrader: @"I find it odd when you are able to know when the value something changes but not its current value" are you talking about orientation? doesn't mir_surface_get_orientation() do that for you?
[11:11] <dandrader> alan_g, no, that's visibility
[11:12] <dandrader> alan_g, that's an example. but I was more like saying in general. not pointing to any specific case
[11:13] <alan_g> dandrader: sure. I just wasn't aware of an example and you started by talking about orientation.
[16:41] <bregma> hey folks I started getting a segfault from Mir server code in Unity 8 (desktop) yesterday on all my machines after updating to the latest packages, reported as #1336854
[16:41] <bregma> it's not clear to me if this is a Mir bug, a Mesa bug, or what, so I'm pinging people here for some better-educated advice
[18:28] <AlbertA> ummm
[18:28] <AlbertA> my 5sec timer is firing in 6s
[18:29] <AlbertA> but std::chrono thinks it is 5s
[18:29] <AlbertA> in the phone devices
[18:38] <racarr> std::chrono thinks it is 5s?
[18:39] <racarr> I mean...technically thats allowed right :p
[18:40] <AlbertA> racarr: I mean if I measure with an external clock
[18:40] <AlbertA> it's 6s...
[18:40] <AlbertA> but std::chrono says its 5
[18:41] <AlbertA> i'm trying to see what is up
[18:41] <racarr> a non real time kernel? :p
[18:42] <racarr> I guess if it does it every time though
[18:42] <racarr> something is bad
[18:42] <AlbertA> racarr: yeah it's consistent
[18:42] <AlbertA> I would understand a few millis here and there
[18:42] <AlbertA> not a full second
[18:43] <AlbertA> I wonder if there's some time drift issue in the libstdc++ for armhf
[18:59] <AlbertA> nah...It was my inaccurate subjective external clock
[19:00] <racarr> haha wait did you really mean
[19:00] <racarr> an external clock
[19:00] <AlbertA> annotate-output is useful :)
[19:00] <racarr> Ithought you meant like C time functions or something
[19:00] <AlbertA> racarr: nah...
[19:00] <AlbertA> racarr: :)
[19:00] <racarr> lol
[19:01] <racarr> yay time still works
[19:01] <AlbertA> racarr: when I doubt I usually go to the oscilloscope but have none there :)
[19:02] <racarr> lol
[19:03] <AlbertA> racarr: maybe it was gravitational time dilation :)
[19:03] <AlbertA> given that the external clock was closer to my body and it was slower
[19:03] <AlbertA> :)
[19:03] <racarr> Haha
[19:04] <racarr> probably either that or the Ubuntu NSA backdoor for cryptographic timing attacks
[19:08] <AlbertA> racarr: heh
[20:05] <racarr> Do we have a C style guide?
[20:06] <racarr> imnot 100% sure what alan is talkingabout here https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242
[20:06] <racarr> am I being stupid and...missing something or is he just saying
[20:06] <racarr> char const *const instead of char const* const
[20:06] <racarr> which would then apparently be part of our C style guide?
[22:33] <racarr> INSTANTIATE_TEST_CASE_P makes me feel like some sort of test wizard
[22:33] <racarr> shooting multipronged branching test lightning bolts.
[22:34] <racarr> also in investigating surface attributes found a nice mix of
[22:35] <racarr> race conditions, potential deadlocks, and simple logic emissions
[22:35] <racarr> -.-
[22:35] <racarr> cest la vie