[01:06] many code reviews today [01:17] much landing? [01:23] RAOF, mockable-udev looks like its gotten enough +1's :D [01:23] *finally* :) [01:37] kdub: So, https://code.launchpad.net/~kdub/mir/compositor-double-start-stop/+merge/201242 seems reasonable to land to me, but how do we mark this as “this entire problem should be solved by removing this interface” [01:39] kdub: Because I agree with the others that unity-mir has no business directly starting & stopping the compositor. [01:52] RAOF: I did ask for input from the team on that before doing it. No one replied :) === duflu_ is now known as duflu [01:53] duflu: Um, ECONTEXT [01:53] RAOF: When I put start/stop calls in unity-mir [01:53] Ah, right. [01:54] Yeah, it might be nice to say: bool DisplayBuffer::asleep { return all outputs are asleep; } and the compositor can check that and not render to display buffers whose outputs are all off [01:56] RAOF, yeah, we'll need a new interface accessible from DefaultServerConfiguration for them to use [01:57] kdub: No need. It can be implicit and the compositor can sleep as required ^ [01:58] Gah. Why must Haswell graphics be slower than Sandy Bridge?! This is annoying. I don't even have a smooth desktop [01:59] duflu: That's really odd. [02:00] duflu: *my* Haswell is nice and fast. That said, it *does* have about twice the processing units as yours and a big shiny 128MB L4 cache on it. [02:00] It's almost as if all that wonderful asynchronous triple buffering I came to know and love isn't there any more === chihchun_afk is now known as chihchun [03:27] RAOF: To be fair, I'm complaining about a saucy system so perhaps the driver isn't quite there like it is for trusty [03:27] And I can't easily boot trusty because this is one of those systems where Ubuntu images are unbootable (old bug) [05:57] Hm. Let's play with std::future... [06:01] Zoe tries, and fails, to stay awake all day... [06:34] Hey, is there any way to get QtCreator to do a parallel build? [06:59] duflu: I'm sure you'll be particularly overjoyed about mir::X::GlobalSocketListeningServerSpawner. :) [07:00] RAOF: Unfortunately I can't shoot people from my desk [07:00] Easily [07:01] Sorry, bad day [07:01] * duflu realizes he only has a Nerf gun [07:03] RAOF: I suggest if you know the name is devious, then fix it instead of proposing it :) [07:03] Yeah, I'll do so before proposing it :P [07:16] RAOF, for your qt creator question: did you try ninja as a build system? [07:17] tvoss_: Ninja doesn't support Mir, AFAIK (the 3rd_party stuff confuses it) [07:17] I have tried a couple of times :){ [07:17] RAOF, oh, I haven't tried ninja with mir, but might well be ... [07:18] RAOF, it's still a bit shaky in case of more complex project layouts === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:28] alf_: thoughts on https://code.launchpad.net/~alan-griffiths/mir/spike-exposing-rpc-in-frontend/+merge/202351? [10:28] alan_g: sorry, forgot to approve [10:29] alan_g: anpok: What do you think about splitting mir_client_library.h into separate *.h files, which mir_client_library.h then includes (e.g. mir_client_library_connection.h, mir_client_library_surface.h) [10:30] alf_: not worried by the "magic numbers"? [10:31] alf_: no strong objection, but why? Are their clients that would only want part of the API? [10:34] alan_g: I don't expect most clients to use the output capture API, but that's not my main reason. I want to do that to make the headers files more readable and partitioned. I feel mir_client_library.h is becoming too large. [10:37] alf_: I guess we are recapitulating the evolution of windows.h - looking forward to MIR_ASYNC_LEAN_AND_MEAN. ;) [10:40] alan_g: We could make the decision to move to separate include files as the preferred way to use mir_toolkit and just keep mir_client_library.h for backwards compatibility [10:41] * alan_g was JOKING - we should learn from history and do as you suggest. [10:42] ;o [10:45] alan_g: @magic numbers, well it's reasonably obvious what is going on, but I wouldn't mind e.g. std::tie(header[0], header[1]) = bytes_of(body_size) if we want to hide the details [10:48] Is there a good reason to hide the details - I see no value in added abstraction [10:48] alan_g: I have approved, so you have your answer :) [10:50] alan_g: but having the abstraction I think would remove complaints about magic numbers (it becomes obvious what 0x100 is in the context of a bytes_of() function) [10:55] * alan_g imagines "std::numeric_limits::max() + 1" === chihchun is now known as chihchun_afk === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === chihchun_afk is now known as chihchun [12:52] alf_: I think there are a lot of people that do not read header files at all, just read the doxygen and examples, and would not appreciate structured header files [12:52] but that also means the whole rest would prefer it [12:57] anpok: I am proposing it more for our (as mir developers) benefit, than for the users of the mir libraries. But it will also help with not creating an unwieldly, concentrated header file, if we move to different #include file per API object. That's the way I am developing MirOutputCapture at least: to use it you will need to include , it will not be part of mir_client_library.h. === alan_g is now known as alan_g|lunch === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g|lunch is now known as alan_g [13:53] alf_: anpok mp in dire need of (yet) another opinion: https://code.launchpad.net/~dandrader/mir/switchingBundle_lp1270964/+merge/202446 [13:54] alan_g: looking [13:55] alan_g, btw, I'm trying out a test for it that won't lock on failure or check the internal state of SwitchingBundle [13:55] dandrader: excellent [14:00] alan_g: what do you mean with your comment https://code.launchpad.net/~dandrader/mir/switchingBundle_lp1270964/+merge/202446/comments/472337 [14:02] ah ok [14:02] nm [14:02] * alan_g deletes reply [14:02] did not comment there yet, because I have not read up on SwitchingBundle [14:04] yeah, good opportunity to do so now [14:06] alan_g, if I understood it correctly, the sole purposes of that frameno parameter in compositor_acquire is to solve the use case of two (or "n") monitors displaying the very same buffer? [14:07] dandrader: that's similar to my understanding - except snapshotting might be another case [14:09] alan_g, hmm, but the snapshot feature or API there is orthogonal to that frameno parameter as far as I can tell [14:09] dandrader: you may be right (this stuff keeps changing while I sleep) [14:10] :) [14:54] snapshot means buffer is just being rendered by a compositor thread? [15:00] anpok: it means that we need to peek a buffer in order to take a snapshot of it, we don't want to "consume" it in the process [15:03] tvoss_: got a moment for a design consultation? [15:03] alan_g, sure [15:04] I'm thinking about greyback's need to make server => client calls [15:04] http://pastebin.ubuntu.com/6797668/ [15:05] But this sort of change breaks compatibility [15:05] s/i/a/ [15:06] alan_g, not sure why you need the wrapper [15:06] Otherwise we don't know what to deserialize [15:07] At the moment server only gets Invocations, client only gets Results [15:07] And that's already messy as Result is either a Result or some "events" [15:08] Allowing it to be an Invocation too... [15:16] alan_g: Any idea why I could be getting mir/tests/mir_test_framework/in_process_server.cpp:77: Failure bind: Address already in use ? [15:17] alan_g: it started happening after a crash in a test I am making that uses the InProcessServer, but not all InProcessServer tests fail like this [15:17] alf_: that's weird! how can a new socket already be bound?! [15:18] You mean new processes? [15:19] alan_g: yes, e.g. running 'bin/mir_acceptance_tests --gtest_filter=DemoPrivateProtobuf.*' fails [15:20] Then socketpair() is allocating a socket already bound by a process that has already exited? [15:20] Or, something [15:20] Weird [15:21] I don't immediately have an idea. tvoss_ ^^ ? [15:22] * alan_g knows sockets are weirder than he can imagine [15:25] alf_: when would that happen? [15:25] the snapshot - but not consume? [15:26] anpok: snapshots shouldn't "steal" frames from compositing [15:27] alf_: can you try updating in_process_server.cpp:77 to dump the boost diagnostics? === om26er is now known as om26e === om26e is now known as om26er === dandrader is now known as dandrader|lunch [15:36] alan_g: nothing interesting there, but strace is interesting http://paste.ubuntu.com/6797795/ [15:36] alan_g: it seems we try to open a socket file after all [15:40] alf_: where's that? [15:40] alan_g: line 508 [15:40] nm just found it [15:41] alan_g: removing the leftover file fixes the problem, but of course this shouldn't be happening in the first place [15:42] alf_: ack. I'll look into it [15:42] want to file a bug? [15:42] alan_g: sure === alan_g is now known as alan_g|tea [15:48] alan_g|tea: https://bugs.launchpad.net/mir/+bug/1271604 [15:48] Ubuntu bug 1271604 in Mir "Tests that use the InProcessServer bind the default socket file" [Undecided,New] === alan_g|tea is now known as alan_g === chihchun is now known as chihchun_afk === dandrader|lunch is now known as dandrader [16:47] hey anpok, could you take a 2nd look at: https://code.launchpad.net/~kdub/mir/hwc12-support/+merge/202015 [16:55] alf_: where can I find the code that takes the snapshots - or requests filling the glpixel buffer? [16:56] anpok: you mean the code from the unity8 side? [16:56] yes [17:01] anpok: unity-mir/src/modules/Unity/Application/applicationscreenshotprovider.cpp [17:02] oh there [18:00] alf_: https://code.launchpad.net/~alan-griffiths/mir/fix-1271604/+merge/202722 === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|bbl === dandrader|bbl is now known as dandrader [21:20] kdub: any idea why launchpad shows changes in mock_hwc_composer_device_1.h that already landed in devel? [22:03] anpok, where are you seeing that? [22:19] https://code.launchpad.net/~kdub/mir/hwc-layerlist-improvements/+merge/202738 line 118 + [22:21] maybe the diff was generated before the other one landed === seb128_ is now known as seb128