[01:22] <RAOF> Who wants to help me work out an exciting gmock weirdness? http://paste.ubuntu.com/5615354/ generates http://paste.ubuntu.com/5615358/
[01:39] <duflu> RAOF: Maybe you're missing a .WillOnce(Return(x)); or similar on the end of your EXPECT_CALL(*mock_buffer_factory, create_buffer_rv(_,_,_))
[01:39] <RAOF> Aha! DoOnce overrides the default behaviour, which means that I wasn't returning.
[01:39] <RAOF> duflu: Correct!
[01:39] <duflu> Whee
[01:40] <duflu> Gmock is weird like that. "EXPECT_CALL" does more than expect something. It actually determines the behaviour :P
[01:40] <RAOF> Even worse, while you can WillOnce(DoDefault()), you can't WillOnce(DoAll(Something(), DoDefault())
[01:44] <RAOF> Man, I wonder what clang's error messages would look like.
[01:46] <RAOF> Woot! It compiles!
[01:46] <RAOF> Now, to make it additionally _link_.
[02:08] <RAOF> And only one failing test. Time to heat luncheon pizza.
[03:22]  * duflu is jealous of luncheon pizza
[03:22] <duflu> or generally anyone who can eat regular pizza :/
[05:41] <duflu> RAOF: See also https://bugs.launchpad.net/mir/+bug/1110115
[05:41] <ubot5> Launchpad bug 1110115 in Mir "PixelFormat is in namespace "geometry"" [Medium,New]
=== mmrazik is now known as mmrazik|afk
[06:19] <RAOF> Well, that has to be one of the stupider reasons for failing a test: asserting the expectations *after* the call that satisfies them.
[06:19] <RAOF> BAH
=== mmrazik|afk is now known as mmrazik
[06:49] <duflu> RAOF: Asynchronous expectations! <insert poorly informed quantum mechanics joke>
[06:52] <tvoss> RAOF, happens to all of us :)
[07:41] <tvoss> mmrazik, ping
[07:41] <mmrazik> tvoss: pong
[07:41] <tvoss> mmrazik, http://unity.ubuntu.com/mir/ is accessible now, can you adjust the jobs or do we need thomi for that?
[07:42] <mmrazik> tvoss: I should be able to do it. Is there any info from the ticket (like what user to use to scp)?
[07:42] <mmrazik> let me check the autopilot job to see what I need
[07:42] <tvoss> mmrazik, don't know :)
[07:43] <mmrazik> tvoss: mhm... I guess we will need to figure out. Autopilot is using autopilot-sync.. so let me first try to guess mir-sync
[07:45] <mmrazik> tvoss: I guess I'm out of luck. In matter of fact it looks like autopilot-sync stopped to work too (permission denied)
[07:45] <mmrazik> tvoss: do you have the ticket # at hand?
[07:48] <tvoss> mmrazik, forwarded you the mail
[07:51] <RAOF> Macros like EXPECT_THROW: measurably worse than Hitler. :(
[07:52] <RAOF> It couldn't possibly say “you've removed the header that was implicitly including <stdexcept>, so I now don't know what std::logic_error is”. Oh, no.
[08:01] <duflu> RAOF: I have clang building Mir now. It's messy and needs some cleaning up yet
[08:01] <RAOF> Woot!
[08:01] <duflu> But the errors are phenomenally better than gcc
[08:02] <duflu> And numerous :P
[08:02] <RAOF> And we'll always have the jenkins autotests to tell us when we've used something that doesn't work in gcc :)
[08:48] <tvoss> mmrazik, any luck with the mir-sync stuff?
[08:48] <mmrazik> tvoss: nope. I was on a call
[08:48] <tvoss> mmrazik, ack
[08:48] <mmrazik> tvoss: and I think there is something broken even for autopilot
[08:52] <mmrazik> tvoss: it looks like few bytes are transfered and then the connection is lost
[08:52] <mmrazik> tvoss: will need to follow up on #is
[08:52] <tvoss> mmrazik, thx
[08:52] <tvoss> mmrazik, can you cc me on the ticket please?
[08:54] <mmrazik> tvoss: I'm just trying irc first
[08:56] <tvoss> mmrazik, ack
[08:57] <mmrazik> tvoss: btw. what should be actually copied? /usr/share/doc/mir-doc/html/* ?
[09:13] <tvoss> mmrazik, yup
[09:26] <alf_> duflu: alan_g: @surface-types, configure() at RPC level, I understand your concern about the pain of adding new RPC methods. My suggestion was based on having a limited and relatively stable number of surface attributes. Is this not the case?
[09:27] <duflu> alf_: It's not the case right now. I will have a couple soon and keep thinking of more such attributes that clients will eventually need to be able to set
[09:27] <alan_g> alf_: duflu even if we multiplex different data over an rpc call we can demultiplex at the server boundary
[09:28] <alan_g> It doesn't have to propagate frontend => shell => surfacers
[09:28] <duflu> alan_g: If you do it too close to the boundary (frontend) then same problem. Too many classes will be changing all the time
[09:29] <duflu> alan_g: If you think you can safely move the boundary without cursing future development to extraneous effort then I suggest proposing a proof of concept branch
[09:30] <alan_g> duflu: well, I was answering alf_ - you know I don't think these attributes should ever go beyond shell anyway
[09:31] <duflu> alan_g: Most other attributes have to. For example "state" changes the server into an "unredirected" rendering mode for example.
[09:31] <duflu> And "hidden" directly affects a surfaces::Surface
[09:31] <duflu> It's only "type" that can stop at the shell layer
[09:32] <alan_g> duflu: "hidden" maps to Surface::hide()/show()
[09:32] <alan_g> And that can happen by shell decoding an attribute
[09:33] <duflu> alan_g: Consider also width/height. Attributes or not, such messages from the client will end up reaching surfaces::Surface
[09:33] <alan_g> duflu: but not as shell related attributes (I believe)
[09:33] <mmrazik> tvoss: srry... one more question... do you want http://unity.ubuntu.com/mir or http://unity.ubuntu.com/mir/api asi thomi was suggesting (the later requires some mkdir-ing for me and moving things aournd; but not a big deal)
[09:34] <alan_g> mmrazik: http://unity.ubuntu.com/mir
[09:34]  * mmrazik is just uploading stuff to http://unity.ubuntu/mir/
[09:34] <tvoss> alf_, ^ any thoughts?
[09:35] <alf_> alan_g: duflu: I think I would prefer to do the demultiplexing in the Mediator, the attrib,value pair (or any other method we use) is a communications detail that may change, not need to propagate it further down
[09:35] <duflu> I really wish people raised these concerns 2 weeks ago...
[09:35] <alan_g> alf_: I'm not so sure - I think the shell is what interprets attributes
[09:35] <duflu> Please put your comments in the merge proposal so I can review them next week
[09:36] <alan_g> duflu: I wish we'd discussed the design before the MP appearede
[09:36] <alf_> tvoss: mmrazik: Yes, http://unity.ubuntu.com/mir is good as we have a main page
[09:36] <duflu> alan_g: Too much room for misunderstanding in English. C++ is clearer :)
[09:37] <alan_g> duflu: more precise, not necessarily clearer
[09:37] <alan_g> duflu: I have design discussions with everyone else on the team. It works for us.
[09:38] <alan_g> duflu: alf_ does too
[09:38] <duflu> alan_g: Yes we can and do discuss a lot. But some/most problems and disagreements are not foreseeable.
=== yofel_ is now known as yofel
[09:39] <alan_g> duflu: some are not. some are easily prevented.
[09:39] <duflu> Please put your concerns in the merge proposal. I really don't want arguments ruining my weekend
[09:40] <alan_g> duflu: let's try a either a hangout or pair-programming when you're back. MP/review isn't working - it is just frustrating.
[09:40] <duflu> alan_g: Although I suggest waiting until there are multiple attributes and then decide if we're demuxing in the right location
[09:41] <alan_g> duflu: I agree with that bit
[09:41] <duflu> MP/review works very well. It's formal and clearly documented. Unlike IRC where you lost track of a conversation
[09:41] <duflu> -lost +lose
[09:42] <alan_g> duflu: your idea of working is "I've now been working on this branch for a month and it's been under review for two weeks. It has worked perfectly without bugs for the entire duration. Remember we're only arguing about style issues that can be fixed later."
[09:42] <mmrazik> tvoss et al: Enjoy: http://unity.ubuntu.com/mir/ !
[09:42] <tvoss> mmrazik, thanks :)
[09:42] <alan_g> mmrazik: \o/
[09:42] <duflu> alan_g: I am happy to address all your concerns in the formal environment of a merge proposal. My frustrations aside, let's use Launchpad as intended
[09:43]  * alan_g shrugs
[09:43] <duflu> Forgive me. But if any further code change is required along the lines of what's being discussed then it's much too large for me to do in the few minutes I have left
[09:45] <alan_g> duflu: I don't expect a rewrite in a few minutes, just something different in the next two weeks
[09:48] <alan_g> duflu: have a good weekend! "See" you next week.
[09:50] <duflu> alan_g: If you have a solid suggestion and the time, please propose a branch to mine. Keep in mind we don't want per-attribute interfaces leaking into the reporting system, amongst other things
[09:50] <alan_g> duflu: ack
[09:52] <alf_> duflu: alan_g: @solid suggestion, I think too many conflicting solid suggestions are delaying us here, instead of a discussion through which we can find reasonable compromises
[09:53] <alf_> duflu: alan_g: problem is that the communication latency for MPs and launchpad is very high, thus the need for more direct communication
[09:54] <alan_g> alf_: I'm all for discussion - I'd rather have a half hour conversation than spend a day recoding
[09:54]  * tvoss paints on the wall: Be reasonable, agile and "Done is better than perfect"
[09:55] <alan_g> alf_: as you've more overlap time with duflu than I have, how about you try pair programming with him when he gets back?
[09:56] <duflu> alan_g, alf_: We're all perfectly capable of communicating in writing. And I have addressed every concern raised so far. If you have more concerns, please put them in writing and I'll work to resolve them as always
[09:57] <duflu> The greatest hurdle so far has been trying to understand the design rationale for much of the Mir code, but I believe I'm making good progress in understanding the intention of what's there...
[10:01] <duflu> tvoss: Yes we do seem to iterate a lot in seek of perfection. Although that's often feasible, it is harder with differing views of "perfection" :)
[10:01] <duflu> Umm, "in search of"
[10:02] <tvoss> duflu, I'm just saying that perfection is the enemy of good enough, and alf_ was pointing out that compromises might be a better way to move forward and achieve clarity
[10:03] <alf_> alan_g: duflu: sure, but I think I prefer a three-way discussion at this point (since all three of us have differing opinions at this point)
[10:04] <alan_g> and I'm saying a "face-to-face" conversation is the best way to refine a resolution
[10:04] <alan_g> alf_: I'm sure I could live with anything you and duflu are both happy with.
[10:05] <duflu> alan_g: That may well be true. But it's not feasible on the weekend. We'll save some time if you write down ideas for what you think needs to change and I can have something ready before you wake up on Tue.
[10:09] <alan_g> duflu: could you also see if you can get hangouts set up - for if we still need to talk.
[10:09] <duflu> alan_g: That's feasible. It used to work fine with 2 people. Just died with more :P
[10:10] <alf_> duflu: do you have the latest binaries from google?
[10:11] <duflu> alf_: Probably not
[10:12] <alf_> duflu: what happens for me is that every once in a while hangouts break in some way, and upgrading the binaries usually improves the situation
[10:14] <alf_> alan_g: duflu:  @"Although I suggest waiting until there are multiple attributes and then decide if we're demuxing in the right location", so let's merge what we have and refactor later ?
[10:16] <alan_g> alf_: I don't think that's the blocker. Let me review the latest version.
[10:20] <duflu> alf_: I was thinking the same, but thought it would be rude of me as author to suggest it
[10:20] <duflu> Especially as I am willing to make changes myself and am willing to do all the work still
[10:26] <duflu> Here, have clang support.
[10:27] <duflu> And happy (grand prix) weekend :)
[10:27] <alf_> duflu: have fun!
[11:21] <alan_g> alf_: had a chance to look at https://code.launchpad.net/~alan-griffiths/mir/refactor-frontend-cleanup/+merge/153386 yet?
[11:21] <alf_> alan_g: not yet, will do shortly
[11:59] <alf_> alan_g: commented
[12:00] <alan_g> alf_: looking...
[12:04] <tvoss> alan_g, alf_ can you give https://wiki.ubuntu.com/Mir/GetInvolved a spin? Feel free to edit in place
[12:07] <alf_> tvoss: sure, so what's the plan with wiki + project-page coexistence?
[12:08] <tvoss> alf_, we can have both, but I want to have a simple landing page where people are welcomed and introduced to the project
[12:09] <tvoss> alf_, that page should be quite static and dispatch to the up-to-date documentation as generated from the source tree
[12:09] <tvoss> makes sense?
[12:10] <alf_> tvoss: Sounds good. Any luck finding a better theme for the doxygen docs?
[12:10] <alf_> tvoss: or perhaps asking design for one...
[12:28] <tvoss> alf_, not yet
=== tvoss is now known as tvoss|lunch
=== mmrazik is now known as mmrazik|lunch
=== mmrazik|lunch is now known as mmrazik
=== tvoss|lunch is now known as tvoss
[15:15] <kdub> morning folks! status, ported over the android framebuffer type (lessening hybris dependency, solving some alloc issues), working on android display selection
[15:18] <alan_g> kdub: morning. Don't forget to review a few MPs
[15:19] <tvoss> morning kdub
[15:19] <alan_g> status: unblocked glog, Proposed refactorings we've discussed.
[15:26] <kdub> alan_g, i might have to ping someone to get libgoogle-glog0 into quantal
[15:26] <alan_g> kdub: quantal?
[15:27] <kdub> phablet builds are still quantal, last I downloaded :)
[15:27] <kdub> i don't think we have to block the glog branch on it
[15:27] <kdub> rsalveti, are the phablet builds still quantal? i heard rumblings about transitioning to raring
[15:28] <tvoss> kdub, glog should be in universe in quantal iirc
[15:28] <rsalveti> kdub: still quantal, raring transition kind of going in place
[15:28] <kdub> thanks
[15:29] <kdub> rsalveti, while i've bothered you... here's how i get the demo to run with mir underneath... lp:~kdub/aal+/ubuntu-platform-mir
[15:31] <rsalveti> lemme see
=== rsalveti_ is now known as rsalveti
[16:30] <alan_g> kdub: re add-glog-logging - is there anything I need do, or are you handling it.
[16:30] <kdub> alan_g, i'll handle it
[16:30] <alan_g> kdub: cool
[16:34] <alf_> alan_g: @add-glog-logging, do we need to make it explicit to the users that we are using glog? I would think this is an implementation detail.
[16:35] <alf_> alan_g: (mostly referring to the command line options)
[16:36] <alan_g> alf_: Probably not, but I'd prefer to address that when we've covered some other reporting scenarios
[16:38] <alf_> alan_g: I am fine with that (i.e. that there is the prospect of hiding the details)
[17:16] <alan_g> kdub: want to review refactor-frontend-cleanup before I decide to land it?
[17:17] <kdub> alan_g, let me scan it for red flags... 5 minutes :)
[17:17] <kdub> lots of branches lately! :)
[17:18] <alan_g> kdub: I want them all to land before the weekend, so we can have a good start next week.
[17:19] <racarr> alan_g: Removed the .orig here https://code.launchpad.net/~robertcarr/mir/prepare-shell-for-input-focus/+merge/153483
[17:19] <racarr> if you have time to take a look another look
[17:20] <alan_g> racarr: looking...
[17:20] <kdub> alan_g, +1'd. lots of sed :)
[17:21] <alan_g> kdub: you know my secret!
[17:21] <racarr> alan_g: Thanks
[17:21] <racarr> not sure what to do with prepare-to-send-clients-input will talk to daniel my afternoon
[17:21] <racarr> oh no I wont its his saturday
[17:23] <racarr> fixed header here https://code.launchpad.net/~rocket-scientists/mir/prepare-for-inprocess-egl-clients/+merge/150379 as well
[17:25] <kgunn> kdub: thanks for unblocking alf
[17:26] <kgunn> understand its still an open task
[17:26] <alan_g> racarr: I think you get what votes you can and then take this as advice: https://code.launchpad.net/~robertcarr/mir/prepare-to-send-clients-input/+merge/152100/comments/333969
[17:27] <alan_g> kgunn: are you able to give an opinion? (Read the comments) https://code.launchpad.net/~robertcarr/mir/prepare-to-send-clients-input/+merge/152100
[17:27] <alan_g> racarr: approved
[17:27] <kgunn> ^ reading
[17:30] <alan_g> alf_: racarr any review comments for https://code.launchpad.net/~alan-griffiths/mir/refactor-surfaces-cleanup/+merge/153431 ?
[17:36] <alf_> alan_g: why does surfaces need a deleter ctor parameter?
[17:38] <alan_g> alf_: It inherits two use cases - one with a null deleter and one that deletes from the surface stack. I didn't feel it should be fixed by this MP but could be pursuaded
[17:39] <racarr> thinking about refactor-surfaces-cleanup
[17:40] <racarr> as for the multi channel stuff..I dunno I actually have the impression that some issues
[17:40] <racarr> are easier to solve with split channels and timestamps
[17:40] <racarr> and Ir emember I came to this conclusion when reading the why X is not our ideal windowing system paper in Lexington
[17:40] <racarr> but I can't remember why
[17:40] <racarr> so I will try and read it again and come back :)
[17:42] <racarr> Hmm
[17:42] <racarr> i think the deleter is fine
[17:43] <racarr> except at 510-512 and 524-526 it seems kind of strange
[17:43] <racarr> because the contents of the deleter are in the test
[17:44] <racarr> so if the implementation is modified to not pass a surface_stack.destroy_surface deleter
[17:44] <racarr> the test still passes right?
[17:44] <racarr> alan_g: ^
[17:44] <racarr> So maybe there should be like
[17:44] <racarr> static msh::Surface::create_within(surface_stack, params)
[17:47] <alan_g> racarr: I guess another option would be to provide a Deleter class. Or to rework the interaction between shell and surfaces.
[17:49] <alan_g> mmrazik: jenkins problem? "/tmp/cckobwIf.s: Fatal error: can't close CMakeFiles/unit-tests.dir/graphics/test_gl_renderer.cpp.o: No space left on device"
[17:49] <mmrazik> alan_g: just added a comment and reapproved
[17:49] <mmrazik> alan_g: but to answer your question -- yes, jenkins problem
[17:50] <alan_g> mmrazik: thanks
[17:52] <kdub> kgunn, no problem. i forgot to mention, but in that blueprint, i almost see 'display integration' as 'vsync timings + display mode selection'
[17:52] <kdub> i guess we can leave it there for now
[17:52] <kgunn> kdub: feel free to reword
[17:52] <kgunn> no prob
[17:53] <racarr> alan_g: Hmm. I am not sure. A deleter class doesn't sound particularly compelling
[17:54] <alan_g> racarr: In that case I prefer to untangle the shell/surfaces interaction. Either in this MP or a future one.
[17:55] <racarr> I am not sure I see how to do it right now...
[17:56] <alan_g> racarr: it isn't obvious to me now. But I'm sure after a bit of thought it will simple.
[17:57] <racarr> another thought, which is kind of similar to a deleter class but slightly more appealing to me
[17:57] <racarr> or maybe this is what you meant...
[17:58] <racarr> is like SurfaceController implements...SurfaceOwner? or something, with destroy surface
[17:58] <racarr> so the call .destroy_surfaces moves to shell::Surface dtor
[17:59] <racarr> because the only case for a null deleter is in tests right?
[17:59] <racarr> So they should just supply a stub
[17:59] <racarr> maybe even just ignore the additional interface.
[18:00] <alan_g> racarr: Part of fixing it is to work out what we really need from those tests.
[18:01] <racarr> that is why I liked
[18:01] <racarr> the static method, because then you can express what we want from both of those tests now with one idea..i.e.
[18:01] <racarr> TEST(Surface, create_with_returns_surface_managed_through_controller)
[18:01] <racarr> or something
[18:02] <racarr> which I think sounds like what we want
[18:03] <racarr> the @ makes me feel like I am yelling
[18:03] <alan_g> racarr: It needs more cleanup in that area anyway - the shell shouldn't be updating the SurfaceStackModel directly. So I guess I'll rework on Monday
[18:04] <racarr> Hmm ok.
[18:04] <alan_g> Is my EOD so I'll try to forget it for the weekend.
[18:04] <racarr> I am thinking though, the current branch
[18:04] <racarr> I don't know if it's any worse and the naming is definitely better
[18:05] <alan_g> Fine. Land it and I'll propose rework MP on Monday. (Unless you do it today)
[18:05] <racarr> Ok. Sounds good
[18:06] <racarr> I probably wont today unless I have any ideas
[18:06] <Cheery> how are the Mir-nvidia -negotiations going on?
[18:06] <racarr> I generated a big list of minor little refactorings yesterday
[18:06] <racarr> that I want to get through once
[18:06] <racarr> the risk of conflicts is a little lower
[18:06] <alan_g> Is it ever?
[18:06] <Cheery> http://hardware.slashdot.org/story/13/03/15/1254210/nvidia-walked-away-from-ps4-hardware-negotiations
[18:06] <racarr> eh
[18:06] <Cheery> that is particularly interesting
[18:06] <racarr> friday afternoon I should be safe from
[18:06] <racarr> too much
[18:08] <racarr> alan_g: Ok well have a good weekend!
[18:08] <alan_g> racarr: In that case, land as much as you can this morning.
=== alan_g is now known as alan_g|life
[18:09] <alan_g|life> Cheery: I don't know anything to tell you
[18:10] <Cheery> alan_g|life: why is it important, should you know it?
[18:11] <Cheery> I mean I'd have understood "I can't tell you"
[18:11] <racarr> Cheery: re: nvidia.
[18:11] <racarr> I think "well" is the best answer I can give right now ;)
[18:13] <Cheery> I sort of see nvidia is probably getting to this. but I'd like to know when it happens.
[18:14] <Cheery> it'd be nice to know if it goes public in 10 days or in 2 months, or by the end of this year.. or...
[18:18] <racarr> :)
[18:18] <racarr> It's all based on the phases of the moon and alignments of the planets
[18:19] <Cheery> easy stuff then.
[18:31] <racarr> hehe
[18:33] <racarr> alf_: kdub: Can we wait to turn
[18:33] <racarr> refactor-surfaces-cleanup to approved until after I land
[18:33] <racarr> prepare-to-send-clients input
[18:33] <racarr> p.s. do either of you want to review that
[18:34] <racarr> I will sort out the conflicts either way but I think it will be less conflicts this way
[18:34] <racarr> alf_: Oh and could you look
[18:34] <kdub> racarr, thats fine by me
[18:34] <racarr> at prepare-for-inprocess-egl-clients agian?
[18:34] <racarr> your last comment is the dissaprove from before we decided to remove those tests
[18:34] <racarr> kdub: Thanks :)
[18:35] <racarr> XD next week all my branches get to be like send-clients-input inprocess-egl-clients, etc...I wonder if the week after that it will just be
[18:35] <racarr> prepare-to-refactor-sending-clients-input
[18:35] <racarr> and I get stuck in a loop
[18:36] <kgunn> racarr: alan_g|life got waylayed by mgmt discusion
[18:36] <kgunn> racarr: i read duflus comment
[18:37] <kgunn> i tend to agree about the secondary channel
[18:37] <kgunn> but i don't why you couldn't just use a surf id like he suggested
[18:38] <racarr> Because the android code is nontrivially dependent on (through leaky abstraction Is uppose)
[18:38] <racarr> and implements
[18:38] <racarr> the secondary channel method
[18:39] <racarr> so to do it now, sets back progress a week or so
[18:39] <racarr> which in the face of not really seeing the concrete problem I am not so disposed to do
[18:39] <racarr> and I am inclined to think that android had a pretty good reason for structuring it the way they do now
[18:39] <kgunn> racarr: don't get me wrong
[18:40] <racarr> for example a client with an input thread and a display thread, display thread will be at most at say 60hz but input thread is easily processing events at 120 hz
[18:40] <kgunn> i think duflu was pointing out potential race conditions that are legit
[18:40] <racarr> so the display thread.
[18:40] <kgunn> but solvable with the id
[18:40] <racarr> is hung up on synchronously on rendering which is fine because it can go a little slow
[18:41] <racarr> but the input thread should still be able to handle events at a fast rate, because it's a two way negotiation with the server (i.e. the client has to explicitly handle-or-not-handle events)
[18:41] <racarr> and if the client falls behind events start to become batched and then interpolated
[18:41] <racarr> I dunno I have the idea that on the seperate channel with the idea of a dedicated input receiver thread
[18:42] <racarr> we will have more predictable performance characteristics
[18:42] <kgunn> ironically one of the unity guys was having this exact race condition problem with a test on autopilot
[18:42] <kgunn> click was for a button(surface) that wasn't present
[18:43] <kgunn> so click got lost
[18:43] <racarr> In X though it's hard to do the synchronization
[18:43] <racarr> based on just comparing timestamps or something because
[18:44] <racarr> it's a three way race between the client the compositor/window manager and the server
[18:44] <racarr> I am just thinking about daniel's example...
[18:44] <racarr> I had convinced myself yesterday it would work fine but let me think again before I say something dumb :p
[18:44] <tvoss> racarr, ping
[18:44] <racarr> tvoss: Pong!
[18:45] <racarr> I didn't do it
[18:45] <racarr> I promise
[18:48] <racarr> I mean, so an input event is in the dispatcher.
[18:48] <racarr> the dispatcher looks at a snapshot or locked view of the surface stack and says
[18:49] <racarr> ok B is on top so I send it to B
[18:49] <racarr> then B closes inbetween that
[18:49] <racarr> decision and B handling
[18:49] <racarr> the event
[18:49] <racarr> how is it that A gets the events that were targeted at B?
[18:51] <racarr> I mean it doesn't
[18:51] <tvoss> racarr, it cannot happen as changes to the surface stack is transactional
[18:51] <racarr> That's what I think :)
[18:51] <tvoss> the worst thing that can happen is that B receives an event for a surface that does not exist anymore
[18:51] <racarr> in fact, it's even better than that. You can then go once you are notified that B did not respond
[18:51] <tvoss> but that's fine from, the behavior is consistent from the server's perspective
[18:51] <racarr> you can look at the timestamp
[18:51] <racarr> err...
[18:52] <racarr> ok nvm this isn't fully coherent yet
[18:52] <racarr> I think there are some cases where you might want to redispatch to A
[18:52] <racarr> would be like the "pixel perfect behavior"
[18:52] <racarr> I'm not sure
[18:52] <racarr> but the worst case is yeah, this B receives an event but the surface doesn't exist
[18:52] <racarr> no one receives events they shouldn't
[18:52] <racarr> well, from other surfaces*
[18:52] <racarr> *shrug*
[19:03] <kgunn> racarr: ....i'm tempted to say cool
[19:03] <kgunn> racarr: lunatic fringe question....what about B has 2 surfaces...1 disappears?
[19:04] <kgunn> could B be fooled into handling event for surface 2 when it was meant for surface 1 ?
[19:04] <tvoss> kgunn, an event is always targeted towards a surface
[19:04] <racarr> no because it's a seperate
[19:04] <racarr> channel per surface not per client
[19:04] <kgunn> ah
[19:04] <kgunn> then "cool"
[19:06] <kgunn> racarr: tvoss so duflu was on crack from the beginning :)
[19:06] <tvoss> kgunn, duflu might have a valid point, but we will find out and then we iterate
[19:06] <racarr> It's definitely a concern (even if I don't think this race scenario is)
[19:06]  * tvoss paints "perfection is a journey, not a destination" on the channel wall
[19:07] <racarr> but there are more complex cases like menus, etc.
[19:07] <racarr> that I don't fully understand yet.
[19:07] <kgunn> i guess the base question is...why would a surface go away
[19:08] <kgunn> that'll determine what you'd do with the input
[19:08] <racarr> I think while two channels sounds like a lot more potential for racing...
[19:08] <racarr> my thought is that, if you have two seperate channels of control, one handling display messages all with valid timestamps, and one handling input messages all with valid timestamps, and all changes to the surface stack are transactional
[19:09] <racarr> I unno
[19:09] <racarr> I can't imagine a race right now
[19:09] <tvoss> racarr, just go ahead and let's complete one iteration :)
[19:09] <racarr> its because the removal of
[19:09] <racarr> the surface and the change of focus
[19:09] <racarr> is a transactional operation
[19:09] <racarr> as opposed to in X where it has to go through the window manager
[19:10] <racarr> and becomes another race point
[19:10] <kgunn> racarr: i think tvoss is right
[19:10] <kgunn> implement
[19:10] <racarr> *shrug*
[19:10] <racarr> ITERATION 1 GO!
[19:10] <kgunn> and then tweak frequencies if you want
[19:10] <racarr> *nods*
[19:10] <kgunn> and see if you can generate one
[19:10] <kgunn> a race that it
[19:10] <kgunn> damn/it/is
[19:11] <racarr> ok I am changing prepare-to-send-clients-input to approved then
[19:11] <racarr> and https://code.launchpad.net/~robertcarr/mir/prepare-shell-for-input-focus/+merge/153483
[19:11] <racarr> (thanks for review btw kdub :))
[19:12] <kdub> racarr, sure!
[21:09] <racarr> kgunn: Reading your weekly update
[21:09] <racarr> wonder if we should send weekly updates to
[21:09] <racarr> public list as well?
[21:15] <kgunn> racarr: yeah, good idea
[21:15] <kgunn> you mean mir-devel
[21:15] <kgunn> ?
[21:15] <poseidon> Anybody here set up mir on archlinux?
[21:22] <racarr> kgunn: Yes
[22:29] <racarr> More merge conflicts! Wheeeeeeeeeeeeee