[01:06] <kdub> many code reviews today
[01:17] <RAOF> much landing?
[01:23] <kdub> RAOF, mockable-udev looks like its gotten enough +1's :D
[01:23] <RAOF> *finally*  :)
[01:37] <RAOF> 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] <RAOF> kdub: Because I agree with the others that unity-mir has no business directly starting & stopping the compositor.
[01:52] <duflu_> RAOF: I did ask for input from the team on that before doing it. No one replied :)
[01:53] <RAOF> duflu: Um, ECONTEXT
[01:53] <duflu> RAOF: When I put start/stop calls in unity-mir
[01:53] <RAOF> Ah, right.
[01:54] <duflu> 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] <kdub> RAOF, yeah, we'll need a new interface accessible from DefaultServerConfiguration for them to use
[01:57] <duflu> kdub: No need. It can be implicit and the compositor can sleep as required ^
[01:58] <duflu> Gah. Why must Haswell graphics be slower than Sandy Bridge?! This is annoying. I don't even have a smooth desktop
[01:59] <RAOF> duflu: That's really odd.
[02:00] <RAOF> 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] <duflu> It's almost as if all that wonderful asynchronous triple buffering I came to know and love isn't there any more
[03:27] <duflu> 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] <duflu> And I can't easily boot trusty because this is one of those systems where Ubuntu images are unbootable (old bug)
[05:57] <RAOF> Hm. Let's play with std::future...
[06:01] <RAOF> Zoe tries, and fails, to stay awake all day...
[06:34] <RAOF> Hey, is there any way to get QtCreator to do a parallel build?
[06:59] <RAOF> duflu: I'm sure you'll be particularly overjoyed about mir::X::GlobalSocketListeningServerSpawner. :)
[07:00] <duflu> RAOF: Unfortunately I can't shoot people from my desk
[07:00] <duflu> Easily
[07:01] <duflu> Sorry, bad day
[07:01]  * duflu realizes he only has a Nerf gun
[07:03] <duflu> RAOF: I suggest if you know the name is devious, then fix it instead of proposing it :)
[07:03] <RAOF> Yeah, I'll do so before proposing it :P
[07:16] <tvoss_> RAOF, for your qt creator question: did you try ninja as a build system?
[07:17] <RAOF> tvoss_: Ninja doesn't support Mir, AFAIK (the 3rd_party stuff confuses it)
[07:17] <RAOF> I have tried a couple of times :){
[07:17] <tvoss_> RAOF, oh, I haven't tried ninja with mir, but might well be ...
[07:18] <tvoss_> RAOF, it's still a bit shaky in case of more complex project layouts
[10:28] <alan_g> alf_: thoughts on https://code.launchpad.net/~alan-griffiths/mir/spike-exposing-rpc-in-frontend/+merge/202351?
[10:28] <alf_> alan_g: sorry, forgot to approve
[10:29] <alf_> 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] <alan_g> alf_: not worried by the "magic numbers"?
[10:31] <alan_g> alf_: no strong objection, but why? Are their clients that would only want part of the API?
[10:34] <alf_> 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] <alan_g> alf_: I guess we are recapitulating the evolution of windows.h - looking forward to MIR_ASYNC_LEAN_AND_MEAN. ;)
[10:40] <alf_> 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] <mlankhorst> ;o
[10:45] <alf_> 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] <alan_g> Is there a good reason to hide the details - I see no value in added abstraction
[10:48] <alf_> alan_g: I have approved, so you have your answer :)
[10:50] <alf_> 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<unsigned char>::max() + 1"
[12:52] <anpok> 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] <anpok> but that also means the whole rest would prefer it
[12:57] <alf_> 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 <mir_toolkit/mir_output_capture.h>, it will not be part of mir_client_library.h.
[13:53] <alan_g> alf_: anpok mp in dire need of (yet) another opinion: https://code.launchpad.net/~dandrader/mir/switchingBundle_lp1270964/+merge/202446
[13:54] <alf_> alan_g: looking
[13:55] <dandrader> 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] <alan_g> dandrader: excellent
[14:00] <anpok> alan_g: what do you mean with your comment https://code.launchpad.net/~dandrader/mir/switchingBundle_lp1270964/+merge/202446/comments/472337
[14:02] <anpok> ah ok
[14:02] <anpok> nm
[14:02]  * alan_g deletes reply
[14:02] <anpok> did not comment there yet, because I have not read up on SwitchingBundle
[14:04] <anpok> yeah, good opportunity to do so now
[14:06] <dandrader> 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] <alan_g> dandrader: that's similar to my understanding - except snapshotting might be another case
[14:09] <dandrader> alan_g, hmm, but the snapshot feature or API there is orthogonal to that frameno parameter as far as I can tell
[14:09] <alan_g> dandrader: you may be right (this stuff keeps changing while I sleep)
[14:10] <dandrader> :)
[14:54] <anpok> snapshot means buffer is just being rendered by a compositor thread?
[15:00] <alf_> 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] <alan_g> tvoss_: got a moment for a design consultation?
[15:03] <tvoss_> alan_g, sure
[15:04] <alan_g> I'm thinking about greyback's need to make server => client calls
[15:04] <alan_g> http://pastebin.ubuntu.com/6797668/
[15:05] <alan_g> But this sort of change breaks compatibility
[15:05] <alan_g> s/i/a/
[15:06] <tvoss_> alan_g, not sure why you need the wrapper
[15:06] <alan_g> Otherwise we don't know what to deserialize
[15:07] <alan_g> At the moment server only gets Invocations, client only gets Results
[15:07] <alan_g> And that's already messy as Result is either a Result or some "events"
[15:08] <alan_g> Allowing it to be an Invocation too...
[15:16] <alf_> 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] <alf_> 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] <alan_g> alf_: that's weird! how can a new socket already be bound?!
[15:18] <alan_g> You mean new processes?
[15:19] <alf_> alan_g: yes, e.g. running 'bin/mir_acceptance_tests --gtest_filter=DemoPrivateProtobuf.*' fails
[15:20] <alan_g> Then socketpair() is allocating a socket already bound by a process that has already exited?
[15:20] <alan_g> Or, something
[15:20] <alan_g> Weird
[15:21] <alan_g> I don't immediately have an idea. tvoss_ ^^ ?
[15:22]  * alan_g knows sockets are weirder than he can imagine
[15:25] <anpok> alf_: when would that happen?
[15:25] <anpok> the snapshot - but not consume?
[15:26] <alan_g> anpok: snapshots shouldn't "steal" frames from compositing
[15:27] <alan_g> alf_: can you try updating in_process_server.cpp:77 to dump the boost diagnostics?
[15:36] <alf_> alan_g: nothing interesting there, but strace is interesting http://paste.ubuntu.com/6797795/
[15:36] <alf_> alan_g: it seems we try to open a socket file after all
[15:40] <alan_g> alf_: where's that?
[15:40] <alf_> alan_g: line 508
[15:40] <alan_g> nm just found it
[15:41] <alf_> alan_g: removing the leftover file fixes the problem, but of course this shouldn't be happening in the first place
[15:42] <alan_g> alf_: ack. I'll look into it
[15:42] <alan_g> want to file a bug?
[15:42] <alf_> alan_g: sure
[15:48] <alf_> alan_g|tea: https://bugs.launchpad.net/mir/+bug/1271604
[16:47] <kdub> hey anpok, could you take a 2nd look at: https://code.launchpad.net/~kdub/mir/hwc12-support/+merge/202015
[16:55] <anpok> alf_: where can I find the code that takes the snapshots - or requests filling the glpixel buffer?
[16:56] <alf_> anpok: you mean the code from the unity8 side?
[16:56] <anpok> yes
[17:01] <alf_> anpok: unity-mir/src/modules/Unity/Application/applicationscreenshotprovider.cpp
[17:02] <anpok> oh there
[18:00] <alan_g> alf_:  https://code.launchpad.net/~alan-griffiths/mir/fix-1271604/+merge/202722
[21:20] <anpok> kdub: any idea why launchpad shows changes in mock_hwc_composer_device_1.h that already landed in devel?
[22:03] <kdub> anpok, where are you seeing that?
[22:19] <anpok> https://code.launchpad.net/~kdub/mir/hwc-layerlist-improvements/+merge/202738 line 118 +
[22:21] <kdub> maybe the diff was generated before the other one landed