[01:34] <RAOF> Oh, my.
[01:34] <RAOF> “make test ARGS=-j9”
[01:51] <duflu> Why is freenode timing out so much this week?
[01:52] <RAOF> Is your internet being terrible again? :)
[01:55] <duflu> Apparently I'm still connected at full speed. It's only IRC that's weird
[04:38] <robotfuel> duflu: ping
[04:43] <duflu> robotfuel: pong
[04:46] <robotfuel> duflu: I thought I needed the project(<name>) in the cmake file to name and publish an executable, will everything work the same without it?
[04:50] <duflu> robotfuel: Yeah should work without it, from memory
[04:50] <robotfuel> duflu: I was just following this http://www.cmake.org/cmake/help/cmake_tutorial.html when I modified the cmake file for this MP https://code.launchpad.net/~chris.gagnon/mir/development-branch-no-valgrind-on-arm-unit-tests/+merge/196406
[04:51] <duflu> robotfuel: Because it already falls under the mir project
[04:51] <robotfuel> ah ok, I'll remove it then.
[07:01] <RAOF> Alright. That's me for the day. See you all in London.
[07:04] <duflu> RAOF: Happy travels
[07:55] <tvoss> RAOF, see you in London :)
[11:06] <alf_> tvoss_: can you remind me why we have the test discovery logic in mir, instead of adding the test directly?
[11:07] <tvoss_> alf_, iirc, people wanted one executable per test class (unit/integration/acceptance) but more fine-grained output in the output of "make test"
[11:08] <alf_> tvoss_: ok, and I guess the usual gtest output (which is fine grained) is supressed when running with make test / ctest
[11:09] <tvoss_> alf_, exactly
[11:12] <alf_> tvoss_: thanks, I am trying to streamline our testing infrastructure and remove hardcoded assumptions (e.g. ANDROID==armhf==cross-compilation)
[11:14] <tvoss_> alf_, yup :) I'm not opposed to getting rid of the test discovery in general
[11:15] <alf_> tvoss_: ... and also remove hardcoded CI specific logic from our build system, instead exposing it as options. As a first step I am trying to figure out what the requirements are from all sides.
[11:16] <alf_> tvoss_: anyway, to be continued after lunch :)
[11:16] <tvoss_> alf_, yup :)
[11:30] <alan_g> alf_: IIRC it was a workaround for a lack of any test output from CI. But we now see output from failed tests, so I think it unnecessary.
[14:23] <alan_g> alf_: got a moment to talk design?
[14:24] <alf_> alan_g: sure, hangout or IRC?
[14:24] <alan_g> shall we start here?
[14:24] <alf_> alan_g: sounds good
[14:24] <alan_g> This is about buffer handles
[14:25] <alan_g> I've been working through the consequences of a single owner handle passed out by BufferBundle
[14:25] <alan_g> And come across the fact that these would be needed for the in-process clients
[14:26] <alan_g> Which means that the handles would need to be in shared - to be available for platformgraphics
[14:26] <alan_g> And I think putting part of (what is logically) compositor there seems distinctly odd
[14:27] <alan_g> thoughts?
[14:27] <alf_> alan_g: I don't understand why they need to be in 'shared'. Did you mean libmirplatform?
[14:28] <alan_g> I did
[14:28] <alan_g> I meant mirplatformgraphics
[14:29] <alan_g> The "gbm" or "android" libraries
[14:30] <alf_> alan_g: ok, let me process this for a moment (and check the code)
[14:31] <alan_g> alf_: e.g. include/platform/mir/graphics/internal_surface.h
[14:37] <alan_g> alf_: the alternative design is to use a raw pointer - and at this point it seems like a more elegant approach.
[14:42] <alf_> alan_g: ok, so the problem is solved this way by InternalSurface not needing the implementation of the buffer handle, and just calling swap/release on the underlying surface
[14:43] <alf_> alan_g: and unique_ptr is cumbersome because of the need for an explicit deleter signature...
[14:47] <alan_g> alf_: well I was writing my own handle type, but there's still a need for type information
[14:53] <alf_> alan_g: right, I meant that if we wanted to use unique_ptr instead it would be cumbersome. What I think would work is a shared header only implementation of a generic unique pointer handle that is more like a shared_ptr in terms of deleter encapsulation.
[14:55] <alan_g> Possible. But brutal
[14:56] <alf_> alan_g: I am not necessarily saying that this would be preferable to the raw pointer (and swap/release) approach :)
[14:56] <alan_g> ack. ;)
[14:57] <alan_g> We don't actually need release() for the current functionality
[14:57] <alan_g> Just because of the way some tests are designed
[14:58] <alan_g> (We don't leak resources or anything)
[15:00] <alf_> alan_g: What about the buffer bundle returning a normal unique_ptr to an mg::Buffer that knows how to destroy itself?
[15:00] <alf_> alan_g: (i.e. a decorated mg::Buffer)
[15:02] <alan_g> As in with the default destructor. Yes, it could be done but like the current design we're creating an unnecessary object every time we pass out a buffer
[15:05] <alan_g> The thing is we're not really passing out ownership - so smart pointers are at best misleading
[15:12] <alf_> alan_g: OK then. I think we can start with the raw pointer approach, and if we see that it leads to issues we can reconsider. My original concern was related to your last statement; when using smart pointers there is an expectation that they knows how to clean themselves up, not so with raw pointers.
[15:13] <alan_g> alf_: agreed a raw pointer says "this one", not "you own this"
[15:16] <alan_g> alf_: thanks
[15:20] <alf_> alan_g: You are welcome. Going off on a tangent, I would like, in general, to have a smart ptr ala shared_ptr with unique semantics in the C++ arsenal :)
[15:22] <alan_g> alf_: If you want it in the standard library you'll probably have to write a proposal for WG21
[15:23] <alan_g> (It isn't hard to implement, but standardising it...)
[15:30] <ricmm> greyback: ping
[15:30] <greyback> ricmm: pong
[15:31] <ricmm> greyback: I just replied to the screenshotting thread
[15:31] <ricmm> I believe the scope is too broad for what the actual requirement is, which is to get QA back to where they were before
[15:32] <greyback> ricmm: you're not wrong
[15:37] <tvoss_> ricmm, the one thing we should avoid is investing too much work into the screenshotting solution
[15:38] <ricmm> I said 30 minutes
[15:38] <ricmm> with 30 minuts you can have a dbus interface that screenshots something and saves to /tmp/unity8/screenshots//formatted-name.png or whatever
[15:39] <ricmm> greyback: +1/-1 ? I'll do the MR and just ping thomi to see if hes happy with it
[15:39] <ricmm> thats already days of discussions without unblocking them
[15:39] <ricmm> which was the real req
[15:39] <ricmm> tvoss_: ^
[15:39] <greyback> ricmm: I'm +1.
[15:39] <ricmm> ok
[15:39]  * ricmm branches
[15:43] <tvoss_> ricmm, see Saviq's answer
[15:44] <Saviq> ricmm, they can't do nothing with screenshots, it's screencasting that they need
[15:44] <tvoss_> Saviq, did they have screencasting with surfaceflinger?
[15:44] <Saviq> tvoss_, no
[15:45] <ricmm> so it has nothing to do with going back to where we were before
[15:45] <ricmm> nvm then
[15:45] <tvoss_> Saviq, ricmm +1, it seems to be a mid-term requirement then
[15:58] <popey> Saviq: tvoss_ when you guys are considering screenshot / screencast, can you also please consider remote desktop? ☻
[15:59] <tvoss_> popey, one step after the other :)
[15:59] <popey> indeed
[15:59] <popey> they're all related though
[15:59] <Saviq> popey, I think nothing we've talked about until now precludes
[15:59] <tvoss_> popey, agreed
[15:59] <Saviq> popey, https://lists.ubuntu.com/archives/mir-devel/2013-November/000511.html
[16:22] <truebattleaxe> GOOOOOOOOOOOOD morning
[16:39] <alan_g> kdub: over on #ubuntu-ci-eng Saviq is volunteering to test your GNexus fix
[16:39] <Saviq> alan_g, kdub yeah, gonna take some build time, but I will
[16:40] <ogra_> just a little hint for the future ... ask the bug submitter to test it ;)
[16:44] <kdub> Saviq, thanks
[16:44] <kdub> what i was seeing yesterday on the stock image was it  was working intermittently