[01:34] Oh, my. [01:34] “make test ARGS=-j9” === duflu_ is now known as duflu [01:51] Why is freenode timing out so much this week? [01:52] Is your internet being terrible again? :) [01:55] Apparently I'm still connected at full speed. It's only IRC that's weird === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [04:38] duflu: ping [04:43] robotfuel: pong [04:46] duflu: I thought I needed the project() in the cmake file to name and publish an executable, will everything work the same without it? [04:50] robotfuel: Yeah should work without it, from memory [04:50] 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] robotfuel: Because it already falls under the mir project [04:51] ah ok, I'll remove it then. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:01] Alright. That's me for the day. See you all in London. [07:04] RAOF: Happy travels [07:55] RAOF, see you in London :) === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:06] tvoss_: can you remind me why we have the test discovery logic in mir, instead of adding the test directly? [11:07] 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] tvoss_: ok, and I guess the usual gtest output (which is fine grained) is supressed when running with make test / ctest [11:09] alf_, exactly [11:12] tvoss_: thanks, I am trying to streamline our testing infrastructure and remove hardcoded assumptions (e.g. ANDROID==armhf==cross-compilation) [11:14] alf_, yup :) I'm not opposed to getting rid of the test discovery in general [11:15] 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] tvoss_: anyway, to be continued after lunch :) [11:16] alf_, yup :) [11:30] 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. === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|lunch === dandrader|afk is now known as dandrader === alan_g|lunch is now known as alan_g [14:23] alf_: got a moment to talk design? [14:24] alan_g: sure, hangout or IRC? [14:24] shall we start here? [14:24] alan_g: sounds good [14:24] This is about buffer handles [14:25] I've been working through the consequences of a single owner handle passed out by BufferBundle [14:25] And come across the fact that these would be needed for the in-process clients [14:26] Which means that the handles would need to be in shared - to be available for platformgraphics [14:26] And I think putting part of (what is logically) compositor there seems distinctly odd [14:27] thoughts? [14:27] alan_g: I don't understand why they need to be in 'shared'. Did you mean libmirplatform? [14:28] I did [14:28] I meant mirplatformgraphics [14:29] The "gbm" or "android" libraries [14:30] alan_g: ok, let me process this for a moment (and check the code) [14:31] alf_: e.g. include/platform/mir/graphics/internal_surface.h [14:37] alf_: the alternative design is to use a raw pointer - and at this point it seems like a more elegant approach. [14:42] 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] alan_g: and unique_ptr is cumbersome because of the need for an explicit deleter signature... [14:47] alf_: well I was writing my own handle type, but there's still a need for type information [14:53] 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] Possible. But brutal [14:56] alan_g: I am not necessarily saying that this would be preferable to the raw pointer (and swap/release) approach :) [14:56] ack. ;) [14:57] We don't actually need release() for the current functionality [14:57] Just because of the way some tests are designed [14:58] (We don't leak resources or anything) [15:00] alan_g: What about the buffer bundle returning a normal unique_ptr to an mg::Buffer that knows how to destroy itself? [15:00] alan_g: (i.e. a decorated mg::Buffer) [15:02] 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] The thing is we're not really passing out ownership - so smart pointers are at best misleading === dandrader is now known as dandrader|lunch [15:12] 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] alf_: agreed a raw pointer says "this one", not "you own this" [15:16] alf_: thanks [15:20] 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] alf_: If you want it in the standard library you'll probably have to write a proposal for WG21 [15:23] (It isn't hard to implement, but standardising it...) === alan_g is now known as alan_g|tea [15:30] greyback: ping [15:30] ricmm: pong [15:31] greyback: I just replied to the screenshotting thread [15:31] 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] ricmm: you're not wrong [15:37] ricmm, the one thing we should avoid is investing too much work into the screenshotting solution [15:38] I said 30 minutes [15:38] 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] greyback: +1/-1 ? I'll do the MR and just ping thomi to see if hes happy with it [15:39] thats already days of discussions without unblocking them [15:39] which was the real req [15:39] tvoss_: ^ [15:39] ricmm: I'm +1. [15:39] ok [15:39] * ricmm branches [15:43] ricmm, see Saviq's answer [15:44] ricmm, they can't do nothing with screenshots, it's screencasting that they need === alan_g|tea is now known as alan_g [15:44] Saviq, did they have screencasting with surfaceflinger? [15:44] tvoss_, no [15:45] so it has nothing to do with going back to where we were before [15:45] nvm then [15:45] Saviq, ricmm +1, it seems to be a mid-term requirement then [15:58] Saviq: tvoss_ when you guys are considering screenshot / screencast, can you also please consider remote desktop? ☻ [15:59] popey, one step after the other :) [15:59] indeed [15:59] they're all related though [15:59] popey, I think nothing we've talked about until now precludes [15:59] popey, agreed [15:59] popey, https://lists.ubuntu.com/archives/mir-devel/2013-November/000511.html === chihchun is now known as chihchun_afk [16:22] GOOOOOOOOOOOOD morning [16:39] kdub: over on #ubuntu-ci-eng Saviq is volunteering to test your GNexus fix [16:39] alan_g, kdub yeah, gonna take some build time, but I will [16:40] just a little hint for the future ... ask the bug submitter to test it ;) [16:44] Saviq, thanks [16:44] what i was seeing yesterday on the stock image was it was working intermittently === thomi_ is now known as thomi