[00:07] <racarr_> I dunno...I dont understand enough about the problem to think of anything better than DispatchableFactory I guess
[00:07] <racarr_> arranger/provider/source etc none really seem to add anything
[00:07] <RAOF> I think I'm going for Dispatcher vs Dispatchable.
[00:09] <racarr_> mm. Despite it being a subject of some debate I'm in to -er suffixes ;)
[00:47] <racarr_> I've still never understood the point of this
[00:47] <racarr_> auto foo(int bar) -> return_type
[00:47] <racarr_> pattern
[00:49] <RAOF> As far as I'm aware it's only vaguely interesting when you're doing crazy stuff.
[00:50] <RAOF> *Or* when you don't want to have to specify namespaces.
[00:50] <RAOF> (As the -> return_type is implicitly namespaced by whatever scope foo is in)
[00:50] <RAOF> I don't know why we use it, because I don't think we ever use either of those properties.
[00:50] <RAOF> AFAIK we just use it as a confusing alternate syntax :)
[00:52] <racarr_> I wish we wouldn't
[00:52] <racarr_> do things like that :/
[00:52] <racarr_> lol
[00:52] <RAOF> Yeah, we might want to put it in the style guide.
[00:52] <racarr_> Seems you are right and that all the uses come around....
[00:52] <racarr_> yeah mostly crazy stuff...when the return type is templated
[00:52] <racarr_> or dependent on template parameters I guess
[00:52] <racarr_> like auto foo (T a, T b) -> decltype(a + b)
[00:53] <racarr_> is apparently
[00:53] <racarr_> a thing
[00:53] <RAOF> Right.
[00:53] <RAOF> :)
[00:55] <racarr_> approaching EOD :)
[00:59] <racarr_> p.s. buffer stream done but I want to manualyl test screencast, etc
[00:59] <racarr_> which...I didn't quite get too today
[01:00] <RAOF> Woot!
[01:00] <RAOF> Please subscribe me to that when you submit it.
[01:00] <RAOF> I'd like to see what my suggestion hath wrought.
[01:01] <RAOF> ♪ Let the moonlight / take the lid / off your dreams ♫
[01:01] <racarr_> :)
[01:51] <RAOF> Hm.
[01:51] <RAOF> std::shared_ptr<std::shared_ptr<std::vector<std::shared_ptr<>>>> is appearing in my code.
[02:57] <duflu> RAOF: That looks suboptimal
[02:57] <duflu> For human readers
[02:58] <duflu> Although part of the problem is just verbosity in the language. sp<sp<vector<sp>> would be slightly better
[06:15] <RAOF> There will come a time when I don't have to merge trunk into the platform probing branches more than once a day.
[06:30] <duflu> RAOF: Been there. Sometimes on the same branch every day for many months :P
[06:30] <RAOF> duflu: If you can work out some way to use rpath that *doesn't* involve having somewhat-fragile code in libmirserver/libmirclient (or something they link to) go ahead :)
[06:31] <duflu> RAOF: One last request: Sanity check again that our parallel version installs won't break
[06:31] <duflu> We don't want to regress on that one
[06:31] <RAOF> Already done so.
[06:32] <duflu> Jolly good. Enjoy your evening
[09:25] <alan_g> duflu: alf__ should we commit lp:~vanvugt/mir/fix-1401365 directly to help clear CI?
[09:25] <duflu> alan_g: I would think so
[09:26] <alan_g> OK, I'll do it
[09:30] <duflu> Ta
[09:43] <alf__> alan_g: duflu: There is also https://bugs.launchpad.net/mir/+bug/1401364
[09:43] <alf__> alan_g: duflu: It's not clear if the leak is an effect or the cause. Like duflu, I can't reproduce it locally.
[09:44] <duflu> Yay. Kind of hard to bisect if only Jenkins can reproduce it
[09:44] <alan_g> alf__: yes. But you'd grabbed it so I wasn't duplicating effort (yet)
[09:56] <alf__> alan_g: Do you know if adding noexcept to a method is an ABI break?
[09:57] <alan_g> Hmm.
[09:59] <alan_g> ABI isn't directly mentioned in the standard. But it IIRC noexcept isn't part of the type (i.e. one can assign function pointers) so the implication is "no".
[10:09] <alan_g> alf__: @lp:1401364 it looks as though the "leak" is irrelevant - we get leaks in the forked processes because we call exit() to prevent them continuing to run the tests.
[10:15] <alan_g> alf__: @lp:1401364 looking at the tests that fail it is suggestive that the exit code from the client is based on the valgrind error, when it should be the the exit code we return from the client. (There was some magic incantation about this - maybe that is what broke...)
[10:18] <alf__> alan_g: Locally, when running the tests I don't get any "definitely lost" leaks, even though the forked processes still call exit() the same way
[10:23] <alan_g> alf__: FWIW I find the same.
[10:28] <mlankhorst> can I mix mir_surface_get_current_buffer with eglSwapBuffers?
[10:28] <mlankhorst> on android
[10:33] <alf__> mlankhorst: I think so. Better ask kdub later in the day.
[10:33] <alf__> mlankhorst: to make sure
[10:35] <mlankhorst> ok
[10:35] <mlankhorst> i'm trying to get rid of the glitching on android
[10:40] <alan_g> alf__: I can reproduce using valgrind --error-exitcode=1 --trace-children=yes --leak-check=full --show-leak-kinds=definite --errors-for-leak-kinds=definite bin/mir_acceptance_tests --gtest_filter=ClientLibraryErrors*:ClientLibraryThread*
[10:48] <alf__> alan_g: Nice! In particular it seems that ClientLibraryErrorsDeathTest* messes up things somehow
[10:50] <alan_g> alf__: I'm happy toback off now and let you investigate. Or should I did deeper?
[10:52] <alf__> alan_g: I have a lead to follow now. If I get stuck I will let you know, thanks.
[10:52] <alan_g> yw
[10:56] <mlankhorst> alf__: but on android should eglSwapBuffers in a mir application block?
[10:59] <alf__> mlankhorst: eglSwapBuffers with a mir EGLSurface needs to contact the server, so it can block until the server gives it another frame back
[11:03] <Saviq> hey all, we've been getting random usc crashes on vivid, it's starting to look android-input-related: bug #1401488
[11:05] <mlankhorst> alf__: yeah, but I was still getting some glitches, do I need additional sync on android if I move my swapbuffers to a separate thread?
[11:41] <alan_g> Saviq: it looks corrupt heap related. The fact that android-input is allocating memory at the time doesn't make it the cause (or exonerate it).
[11:42]  * alan_g tries to remember how to run USC under valgrind
[11:42] <Saviq> alan_g, if it matters, it always happened for me when interacting with the screen
[11:42] <Saviq> and yeah, it's not easily reproducible, it's not rare, but totally random
[11:47] <alan_g> USC won't be doing much memory management when you're not interacting with the screen
[11:52] <Saviq> alf__, hey, so I have the desktop-next iso working under VMWare, can I somehow control the screen size?
[11:56] <alf__> Saviq: I don't know if the KMS driver exports any other modes besides the default one. Could you try the mirout utility to see if there are other modes available?
[11:57] <Saviq> alf__, hmm "could not connect to a display server", should I run as root or something?
[11:58] <Saviq> alf__, ah, got it, connected to usc
[11:58] <Saviq> alf__, yeah, there's plenty modes
[11:58] <alf__> Saviq: can you pastebin them please
[11:58]  * Saviq tries
[12:02] <alf__> alan_g: https://code.launchpad.net/~afrantzis/mir/fix-1401364-death-test-leaks/+merge/244414
[12:04] <Saviq> alf__, http://paste.ubuntu.com/9475199/
[12:05] <alan_g> alf__: looking
[12:07] <alf__> Saviq: so VMware tells us that the recommended/native mode is 800x600@60 so we choose that. I don't know what would happen if we chose a different mode (i.e., if the modes are actually supported).
[12:08] <Saviq> alf__, ah, I can change the resolution in the VM settings, /me tries
[12:09] <alf__> Saviq: one thing to try is to run mir_demo_server_shell and use mir_demo_client_display_config to change the mode to see if it can actually be changed.
[12:09] <alf__> Saviq: this won't help with USC but it will let us know if the modes are actually supported
[12:09] <Saviq> alf__, I'll try and have a look
[12:11] <alan_g> alf__: I don't see any change in behaviour
[12:11] <Saviq> alf__, FWIW, changing the VM settings didn't change much
[12:15] <alf__> alan_g: What did you try? When running the command you pasted before without the fix I get leaks in ClientLibraryThread* tests. With the fix I don't. (Leaks in ClientLibraryErrorDeathTest are normal and expected for the forked processes).
[12:17] <alan_g> alf__: exactly that
[12:20] <alan_g> And I still see the test failures
[12:25] <alan_g> And yes I do have the changes and saw the recompile
[12:31] <alf__> alan_g: Is this a clean build of the proposed branch, or did you apply the changes to an older branch?
[12:31] <alan_g> Just merged it to an existing copy of trunk
[12:43] <tsdgeos> guys, what is responsible of calling frame_posted in the client? is it eglSwapBuffers? if so in which part of mir does it "hook" that call?
[12:44] <alf__> alan_g: Hmm, not sure what's going on then. I built again from scratch (clean trunk no existing build directory, merged fix branch, cmake .. -Duse_debflags=true), it works with the fix and it breaks if I revert the fix.
[12:45] <alf__> alan_g: Let's see what CI thinks of it.
[12:45] <alan_g> alf__: I'm approacing lunch  - I'll wait and see what CI does.
[13:47] <alan_g> alf__: FWIW I left a clean build running over lunch - and still see the failures. Weird
[13:54] <alf__> alan_g: indeed... and s-jenkins isn't accessible to get an early peek at how the CI build is going
[13:57]  * alan_g broke his tablet by trying to debug USC (and now it goes into a reboot loop)
[13:59] <kdub> alan_g, you can ubuntu-device-flash --bootstrap from the bootloader screen
[14:00] <alan_g> kdub: yeah. I know. But I'd rather be able to boot to a command line and revert config edits
[15:15] <greyback_> alan_g: hey, could I get you to merge qtmir trunk into your refactor-after-migrate-to-mir-Server-API branch?
[15:15] <alan_g> greyback_: you could
[15:16] <greyback_> alan_g: branch is not under a team, but your username
[15:27] <alan_g> greyback_: pushed
[15:27] <greyback_> alan_g: thank you
[18:32] <mibofra> kdub, hi. So I've arrived at the conclusion that the compositor stops after a while the server is running.
[18:32] <mibofra> (I think the _render_to_fb demo uses another mechanism as it works fine)
[18:33] <kdub> well, the render_to_fb is a subsystem
[18:33] <mibofra> kdub, ok, but has it got its compositor?
[18:34] <kdub> not the same one as the server
[18:34] <mibofra> kdub, so it starts it internally in another way than the other servers
[18:35] <mibofra> or I can't explain that the same thing woks in a case and in the others no.
[18:35] <kdub> right, maybe a backtrace from where it hangs or crashes would help
[18:37] <racarr_> greyback_: Just checked out lp:qtmir to build it and getting problems about no FindGMock...have you run in to this? Did we miss some files or something?
[18:44] <mibofra> kdub, installing the debug symbols packages
[18:45] <mibofra> kdub, anyway really I don't get errors on the server with gdb when the compositor stop
[18:45] <kdub> right, it could be hung
[18:46] <racarr_> Anyone have a branch of qtmir that works with lp:mir?
[20:03] <mibofra> kdub, do you want a strace of the server?
[20:05] <kdub> mibofra, maybe not, unless you see something interesting
[20:06] <mibofra> not really
[22:47] <mibofra> kdub, any ideas?
[23:08] <mibofra> kdub, if you have any idea or remember some particular debug process to see why the compositor stops, let me now
[23:08] <mibofra> *know
[23:08] <mibofra> I'm here