/srv/irclogs.ubuntu.com/2014/01/22/#ubuntu-mir.txt

kdubmany code reviews today01:06
RAOFmuch landing?01:17
kdubRAOF, mockable-udev looks like its gotten enough +1's :D01:23
RAOF*finally*  :)01:23
RAOFkdub: 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:37
RAOFkdub: Because I agree with the others that unity-mir has no business directly starting & stopping the compositor.01:39
duflu_RAOF: I did ask for input from the team on that before doing it. No one replied :)01:52
=== duflu_ is now known as duflu
RAOFduflu: Um, ECONTEXT01:53
dufluRAOF: When I put start/stop calls in unity-mir01:53
RAOFAh, right.01:53
dufluYeah, 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 off01:54
kdubRAOF, yeah, we'll need a new interface accessible from DefaultServerConfiguration for them to use01:56
duflukdub: No need. It can be implicit and the compositor can sleep as required ^01:57
dufluGah. Why must Haswell graphics be slower than Sandy Bridge?! This is annoying. I don't even have a smooth desktop01:58
RAOFduflu: That's really odd.01:59
RAOFduflu: *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
dufluIt's almost as if all that wonderful asynchronous triple buffering I came to know and love isn't there any more02:00
=== chihchun_afk is now known as chihchun
dufluRAOF: To be fair, I'm complaining about a saucy system so perhaps the driver isn't quite there like it is for trusty03:27
dufluAnd I can't easily boot trusty because this is one of those systems where Ubuntu images are unbootable (old bug)03:27
RAOFHm. Let's play with std::future...05:57
RAOFZoe tries, and fails, to stay awake all day...06:01
RAOFHey, is there any way to get QtCreator to do a parallel build?06:34
RAOFduflu: I'm sure you'll be particularly overjoyed about mir::X::GlobalSocketListeningServerSpawner. :)06:59
dufluRAOF: Unfortunately I can't shoot people from my desk07:00
dufluEasily07:00
dufluSorry, bad day07:01
* duflu realizes he only has a Nerf gun07:01
dufluRAOF: I suggest if you know the name is devious, then fix it instead of proposing it :)07:03
RAOFYeah, I'll do so before proposing it :P07:03
tvoss_RAOF, for your qt creator question: did you try ninja as a build system?07:16
RAOFtvoss_: Ninja doesn't support Mir, AFAIK (the 3rd_party stuff confuses it)07:17
RAOFI have tried a couple of times :){07:17
tvoss_RAOF, oh, I haven't tried ninja with mir, but might well be ...07:17
tvoss_RAOF, it's still a bit shaky in case of more complex project layouts07:18
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
alan_galf_: thoughts on https://code.launchpad.net/~alan-griffiths/mir/spike-exposing-rpc-in-frontend/+merge/202351?10:28
alf_alan_g: sorry, forgot to approve10:28
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:29
alan_galf_: not worried by the "magic numbers"?10:30
alan_galf_: no strong objection, but why? Are their clients that would only want part of the API?10:31
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:34
alan_galf_: I guess we are recapitulating the evolution of windows.h - looking forward to MIR_ASYNC_LEAN_AND_MEAN. ;)10:37
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 compatibility10:40
* alan_g was JOKING - we should learn from history and do as you suggest.10:41
mlankhorst;o10:42
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 details10:45
alan_gIs there a good reason to hide the details - I see no value in added abstraction10:48
alf_alan_g: I have approved, so you have your answer :)10:48
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:50
* alan_g imagines "std::numeric_limits<unsigned char>::max() + 1"10:55
=== 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
anpokalf_: 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 files12:52
anpokbut that also means the whole rest would prefer it12:52
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.12:57
=== 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
alan_galf_: anpok mp in dire need of (yet) another opinion: https://code.launchpad.net/~dandrader/mir/switchingBundle_lp1270964/+merge/20244613:53
alf_alan_g: looking13:54
dandraderalan_g, btw, I'm trying out a test for it that won't lock on failure or check the internal state of SwitchingBundle13:55
alan_gdandrader: excellent13:55
anpokalan_g: what do you mean with your comment https://code.launchpad.net/~dandrader/mir/switchingBundle_lp1270964/+merge/202446/comments/47233714:00
anpokah ok14:02
anpoknm14:02
* alan_g deletes reply14:02
anpokdid not comment there yet, because I have not read up on SwitchingBundle14:02
anpokyeah, good opportunity to do so now14:04
dandraderalan_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:06
alan_gdandrader: that's similar to my understanding - except snapshotting might be another case14:07
dandraderalan_g, hmm, but the snapshot feature or API there is orthogonal to that frameno parameter as far as I can tell14:09
alan_gdandrader: you may be right (this stuff keeps changing while I sleep)14:09
dandrader:)14:10
anpoksnapshot means buffer is just being rendered by a compositor thread?14:54
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 process15:00
alan_gtvoss_: got a moment for a design consultation?15:03
tvoss_alan_g, sure15:03
alan_gI'm thinking about greyback's need to make server => client calls15:04
alan_ghttp://pastebin.ubuntu.com/6797668/15:04
alan_gBut this sort of change breaks compatibility15:05
alan_gs/i/a/15:05
tvoss_alan_g, not sure why you need the wrapper15:06
alan_gOtherwise we don't know what to deserialize15:06
alan_gAt the moment server only gets Invocations, client only gets Results15:07
alan_gAnd that's already messy as Result is either a Result or some "events"15:07
alan_gAllowing it to be an Invocation too...15:08
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:16
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 this15:17
alan_galf_: that's weird! how can a new socket already be bound?!15:17
alan_gYou mean new processes?15:18
alf_alan_g: yes, e.g. running 'bin/mir_acceptance_tests --gtest_filter=DemoPrivateProtobuf.*' fails15:19
alan_gThen socketpair() is allocating a socket already bound by a process that has already exited?15:20
alan_gOr, something15:20
alan_gWeird15:20
alan_gI don't immediately have an idea. tvoss_ ^^ ?15:21
* alan_g knows sockets are weirder than he can imagine15:22
anpokalf_: when would that happen?15:25
anpokthe snapshot - but not consume?15:25
alan_ganpok: snapshots shouldn't "steal" frames from compositing15:26
alan_galf_: can you try updating in_process_server.cpp:77 to dump the boost diagnostics?15:27
=== om26er is now known as om26e
=== om26e is now known as om26er
=== dandrader is now known as dandrader|lunch
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 all15:36
alan_galf_: where's that?15:40
alf_alan_g: line 50815:40
alan_gnm just found it15:40
alf_alan_g: removing the leftover file fixes the problem, but of course this shouldn't be happening in the first place15:41
alan_galf_: ack. I'll look into it15:42
alan_gwant to file a bug?15:42
alf_alan_g: sure15:42
=== alan_g is now known as alan_g|tea
alf_alan_g|tea: https://bugs.launchpad.net/mir/+bug/127160415:48
ubot5Ubuntu bug 1271604 in Mir "Tests that use the InProcessServer bind the default socket file" [Undecided,New]15:48
=== alan_g|tea is now known as alan_g
=== chihchun is now known as chihchun_afk
=== dandrader|lunch is now known as dandrader
kdubhey anpok, could you take a 2nd look at: https://code.launchpad.net/~kdub/mir/hwc12-support/+merge/20201516:47
anpokalf_: where can I find the code that takes the snapshots - or requests filling the glpixel buffer?16:55
alf_anpok: you mean the code from the unity8 side?16:56
anpokyes16:56
alf_anpok: unity-mir/src/modules/Unity/Application/applicationscreenshotprovider.cpp17:01
anpokoh there17:02
alan_galf_:  https://code.launchpad.net/~alan-griffiths/mir/fix-1271604/+merge/20272218:00
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|bbl
=== dandrader|bbl is now known as dandrader
anpokkdub: any idea why launchpad shows changes in mock_hwc_composer_device_1.h that already landed in devel?21:20
kdubanpok, where are you seeing that?22:03
anpokhttps://code.launchpad.net/~kdub/mir/hwc-layerlist-improvements/+merge/202738 line 118 +22:19
kdubmaybe the diff was generated before the other one landed22:21
=== seb128_ is now known as seb128

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