/srv/irclogs.ubuntu.com/2014/12/11/#ubuntu-mir.txt

racarr_I dunno...I dont understand enough about the problem to think of anything better than DispatchableFactory I guess00:07
racarr_arranger/provider/source etc none really seem to add anything00:07
RAOFI think I'm going for Dispatcher vs Dispatchable.00:07
racarr_mm. Despite it being a subject of some debate I'm in to -er suffixes ;)00:09
racarr_I've still never understood the point of this00:47
racarr_auto foo(int bar) -> return_type00:47
racarr_pattern00:47
RAOFAs far as I'm aware it's only vaguely interesting when you're doing crazy stuff.00:49
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
RAOFI don't know why we use it, because I don't think we ever use either of those properties.00:50
RAOFAFAIK we just use it as a confusing alternate syntax :)00:50
racarr_I wish we wouldn't00:52
racarr_do things like that :/00:52
racarr_lol00:52
RAOFYeah, 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 templated00:52
racarr_or dependent on template parameters I guess00:52
racarr_like auto foo (T a, T b) -> decltype(a + b)00:52
racarr_is apparently00:53
racarr_a thing00:53
RAOFRight.00:53
RAOF:)00:53
racarr_approaching EOD :)00:55
racarr_p.s. buffer stream done but I want to manualyl test screencast, etc00:59
racarr_which...I didn't quite get too today00:59
RAOFWoot!01:00
RAOFPlease subscribe me to that when you submit it.01:00
RAOFI'd like to see what my suggestion hath wrought.01:00
RAOF♪ Let the moonlight / take the lid / off your dreams ♫01:01
racarr_:)01:01
RAOFHm.01:51
RAOFstd::shared_ptr<std::shared_ptr<std::vector<std::shared_ptr<>>>> is appearing in my code.01:51
dufluRAOF: That looks suboptimal02:57
dufluFor human readers02:57
dufluAlthough part of the problem is just verbosity in the language. sp<sp<vector<sp>> would be slightly better02:58
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
RAOFThere will come a time when I don't have to merge trunk into the platform probing branches more than once a day.06:15
dufluRAOF: Been there. Sometimes on the same branch every day for many months :P06:30
RAOFduflu: 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:30
dufluRAOF: One last request: Sanity check again that our parallel version installs won't break06:31
dufluWe don't want to regress on that one06:31
RAOFAlready done so.06:31
dufluJolly good. Enjoy your evening06:32
alan_gduflu: alf__ should we commit lp:~vanvugt/mir/fix-1401365 directly to help clear CI?09:25
duflualan_g: I would think so09:25
alan_gOK, I'll do it09:26
dufluTa09:30
alf__alan_g: duflu: There is also https://bugs.launchpad.net/mir/+bug/140136409:43
ubot5Launchpad bug 1401364 in Mir "CI test failure in multiple tests" [High,In progress]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:43
dufluYay. Kind of hard to bisect if only Jenkins can reproduce it09:44
alan_galf__: yes. But you'd grabbed it so I wasn't duplicating effort (yet)09:44
=== dandrader is now known as dandrader|afk
alf__alan_g: Do you know if adding noexcept to a method is an ABI break?09:56
alan_gHmm.09:57
alan_gABI 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".09:59
alan_galf__: @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:09
alan_galf__: @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:15
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 way10:18
=== dandrader|afk is now known as dandrader
alan_galf__: FWIW I find the same.10:23
mlankhorstcan I mix mir_surface_get_current_buffer with eglSwapBuffers?10:28
mlankhorston android10:28
alf__mlankhorst: I think so. Better ask kdub later in the day.10:33
alf__mlankhorst: to make sure10:33
mlankhorstok10:35
mlankhorsti'm trying to get rid of the glitching on android10:35
alan_galf__: 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:40
alf__alan_g: Nice! In particular it seems that ClientLibraryErrorsDeathTest* messes up things somehow10:48
alan_galf__: I'm happy toback off now and let you investigate. Or should I did deeper?10:50
alf__alan_g: I have a lead to follow now. If I get stuck I will let you know, thanks.10:52
alan_gyw10:52
mlankhorstalf__: but on android should eglSwapBuffers in a mir application block?10:56
alf__mlankhorst: eglSwapBuffers with a mir EGLSurface needs to contact the server, so it can block until the server gives it another frame back10:59
Saviqhey all, we've been getting random usc crashes on vivid, it's starting to look android-input-related: bug #140148811:03
ubot5bug 1401488 in unity-system-compositor (Ubuntu) "unity-system-compositor assert failure: *** Error in `unity-system-compositor': corrupted double-linked list: 0xaa817808 ***" [Undecided,New] https://launchpad.net/bugs/140148811:03
mlankhorstalf__: 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:05
alan_gSaviq: 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:41
* alan_g tries to remember how to run USC under valgrind11:42
Saviqalan_g, if it matters, it always happened for me when interacting with the screen11:42
Saviqand yeah, it's not easily reproducible, it's not rare, but totally random11:42
alan_gUSC won't be doing much memory management when you're not interacting with the screen11:47
Saviqalf__, hey, so I have the desktop-next iso working under VMWare, can I somehow control the screen size?11:52
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:56
Saviqalf__, hmm "could not connect to a display server", should I run as root or something?11:57
Saviqalf__, ah, got it, connected to usc11:58
Saviqalf__, yeah, there's plenty modes11:58
alf__Saviq: can you pastebin them please11:58
* Saviq tries11:58
alf__alan_g: https://code.launchpad.net/~afrantzis/mir/fix-1401364-death-test-leaks/+merge/24441412:02
Saviqalf__, http://paste.ubuntu.com/9475199/12:04
alan_galf__: looking12:05
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:07
Saviqalf__, ah, I can change the resolution in the VM settings, /me tries12:08
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 supported12:09
Saviqalf__, I'll try and have a look12:09
alan_galf__: I don't see any change in behaviour12:11
Saviqalf__, FWIW, changing the VM settings didn't change much12:11
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:15
alan_galf__: exactly that12:17
alan_gAnd I still see the test failures12:20
alan_gAnd yes I do have the changes and saw the recompile12:25
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_gJust merged it to an existing copy of trunk12:31
tsdgeosguys, 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:43
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:44
alf__alan_g: Let's see what CI thinks of it.12:45
alan_galf__: I'm approacing lunch  - I'll wait and see what CI does.12:45
=== 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
alan_galf__: FWIW I left a clean build running over lunch - and still see the failures. Weird13:47
alf__alan_g: indeed... and s-jenkins isn't accessible to get an early peek at how the CI build is going13:54
* alan_g broke his tablet by trying to debug USC (and now it goes into a reboot loop)13:57
kdubalan_g, you can ubuntu-device-flash --bootstrap from the bootloader screen13:59
alan_gkdub: yeah. I know. But I'd rather be able to boot to a command line and revert config edits14:00
=== chihchun is now known as chihchun_afk
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_ggreyback_: you could15:15
greyback_alan_g: branch is not under a team, but your username15:16
alan_ggreyback_: pushed15:27
greyback_alan_g: thank you15:27
=== alan_g is now known as alan_g|EOD
mibofrakdub, 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:32
kdubwell, the render_to_fb is a subsystem18:33
mibofrakdub, ok, but has it got its compositor?18:33
kdubnot the same one as the server18:34
mibofrakdub, so it starts it internally in another way than the other servers18:34
mibofraor I can't explain that the same thing woks in a case and in the others no.18:35
kdubright, maybe a backtrace from where it hangs or crashes would help18:35
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:37
mibofrakdub, installing the debug symbols packages18:44
mibofrakdub, anyway really I don't get errors on the server with gdb when the compositor stop18:45
kdubright, it could be hung18:45
racarr_Anyone have a branch of qtmir that works with lp:mir?18:46
mibofrakdub, do you want a strace of the server?20:03
kdubmibofra, maybe not, unless you see something interesting20:05
mibofranot really20:06
mibofrakdub, any ideas?22:47
=== LockeAnarchist- is now known as LockeAnarchist
mibofrakdub, if you have any idea or remember some particular debug process to see why the compositor stops, let me now23:08
mibofra*know23:08
mibofraI'm here23:08

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