| === chihchun_afk is now known as chihchun | ||
| alan_g | duflu_: are the many autolanding failures over the weekend accounted for? Or is there more to fix? | 09:30 |
|---|---|---|
| duflu_ | alan_g: There are a few. Fixed one on trunk so far. More unresolved on armhf (valgrind). Working on getting logs of those and backporting the first fix to 0.12 | 09:31 |
| duflu_ | So much broken | 09:31 |
| alan_g | Do you have it in hand - or can I jump in somewhere? (Where?) | 09:32 |
| duflu_ | alan_g: I'm running out of day time. I expect I can hand this over soon. Just need to attach detailed logs: https://bugs.launchpad.net/mir/+bug/1435186 | 09:34 |
| ubot5 | Ubuntu bug 1435186 in Mir "valgrind on armhf fails with with many errors" [High,New] | 09:34 |
| duflu_ | alan_g: Or is it just a mistake that we expect valgrind to work on armhf? | 09:34 |
| alan_g | We got optimistic after alf_ generated some suppression files. | 09:35 |
| alan_g | It *ought* to work. But seems too much work. | 09:35 |
| duflu_ | alan_g: I mean, did it ever work? | 09:36 |
| duflu_ | I don't remember | 09:36 |
| === duflu_ is now known as duflu | ||
| alan_g | It did, but we had to suppress errors in libraries we don't own (IIRC libc). That's fragile. | 09:37 |
| * duflu checks the suppressions again | 09:40 | |
| duflu | alan_g: Yep, we just need more suppressions for system libraries. | 09:40 |
| duflu | alan_g: Handover: https://bugs.launchpad.net/mir/+bug/1435186 | 09:41 |
| ubot5 | Ubuntu bug 1435186 in Mir "valgrind on armhf fails with with many errors" [High,New] | 09:41 |
| alan_g | ack | 09:41 |
| alf_ | duflu: alan_g: the integration tests have a lot of hopefully false memory errors | 09:49 |
| alf_ | duflu: alan_g: a single variable that valgrind thinks is uninitialized causing a cascade of memory errors? | 09:50 |
| duflu | alf_: Don't know. The rabbit's hole is too deep for this evening | 09:51 |
| duflu | alf_: P.S. I updated the 0.12 branch with one fix | 09:52 |
| alf_ | duflu: great, thanks | 09:52 |
| alan_g | alf_: plausible. Got a fix? | 09:55 |
| alf_ | alan_g: no, just a theory | 09:56 |
| * alan_g finally gets mako talking to ubuntu-device-flash again | 10:19 | |
| alf_ | alan_g: part of the problem may be https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1284653 , but it's possible we will need to update our own custo suppression files too | 10:36 |
| ubot5 | Ubuntu bug 1284653 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.19)" [Undecided,Fix released] | 10:36 |
| alf_ | alan_g: oops, that's the old bug, the new one is: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1435261 | 10:36 |
| ubot5 | Ubuntu bug 1435261 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.21)" [Undecided,New] | 10:36 |
| alan_g | alf_: That could be | 10:37 |
| alan_g | so it might sort itself out when that hits archive. Maybe we should just disable valgrind? | 10:42 |
| alf_ | alan_g: That's one option. Alternative, we could temporarily provide a 2.21 version of the default suppressions in Mir. I will push an MP for this, to see if it makes any difference with CI. | 10:50 |
| alf_ | *alternatively | 10:50 |
| alan_g | alf_: OK, thanks | 10:54 |
| alan_g | alf_: if your valgrind fix works in CI we should push it straight to trunk. Agreed? | 12:27 |
| alf_ | alan_g: sure | 12:35 |
| === alan_g is now known as alan_g|lunch | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | kdub: are you likely to finish off lp:~kdub/mir/demo-titlebars today? (Or shall I?) | 15:38 |
| kdub | alan_g, I can try to today | 15:39 |
| * alan_g is trying to get all the "polish" to CanonicalWindowManager landed before trying to move it to libmirserver | 15:40 | |
| alan_g | racarr: @lp:~kdub/mir/demo-titlebars Do you think there's a better way that's already supported? Otherwise, I think we're better to land something (in the examples) that demonstrates the pain caused by the existing API. (And use it to justify improvements to the API to clean it up.) | 16:06 |
| === dandrader is now known as dandrader|lunch | ||
| racarr | alan_g: That's fine too I guess...I kind of had the thought that its not | 16:35 |
| racarr | doing enough yet to be realistic | 16:35 |
| kdub | have to start somewhere :) | 16:38 |
| alan_g | What we need to get to is it being easy for users to do useful stuff. At least this demonstrates is that it is possible to do something. | 16:38 |
| racarr | well obviously neither of those points can be argued with ;) | 16:42 |
| racarr | I am fine with it | 16:46 |
| racarr | I think my comment wasjust coming from | 16:46 |
| racarr | the fact that I expect dealing with resize etc from the observer | 16:47 |
| racarr | will be the "difficult bit" | 16:47 |
| alan_g | who wants to do it from the observer? Just do it from the controller. | 16:47 |
| alan_g | I.e. the WM policy knows it is resizing the window, it can easily resize the decorations. | 16:49 |
| alan_g | The observer is just to let the "views" know a change has happened. | 16:50 |
| racarr | yes sorry thought-typo | 16:51 |
| racarr | thats still the difficult bit to do | 16:52 |
| racarr | e.g. how do you make it atomic? | 16:52 |
| alan_g | The controller is the only thing that updates the model, it already serializes updates. | 16:53 |
| racarr | alan_g: Really? | 16:55 |
| racarr | I am talking about hte case where say the compositor chooses to render inbetween | 16:56 |
| racarr | updating the surface and decoration surface | 16:56 |
| alan_g | OK, that's not been tackled | 16:56 |
| alan_g | I intend to do some rework on scene locking though | 16:58 |
| racarr | mm | 16:58 |
| racarr | I dunno if its a locking rework or a | 16:59 |
| anpok_ | hm this could be resolved by some sort of batch processing of requests/events | 16:59 |
| racarr | changeset/modifications API | 16:59 |
| racarr | yeah | 16:59 |
| anpok_ | or yes.. explicit locks.. but this feels complicated | 16:59 |
| anpok_ | for the batch thing you would already serialize all notifications or requests that might cause changes to the scene | 17:00 |
| alan_g | with C++14 we can have shared mutexes and only the shell grabs exclusive access | 17:00 |
| racarr | I guess in my mind | 17:00 |
| racarr | and we see here I have runaway with unjustified thoughts | 17:00 |
| racarr | but | 17:01 |
| racarr | the solution to this to avoid exposing synchronization | 17:01 |
| racarr | primitives | 17:01 |
| racarr | was to add | 17:01 |
| racarr | hierarchy to | 17:01 |
| racarr | the surface stack | 17:01 |
| racarr | so that the decoration and surface are for example part of a window element which acts as a container | 17:01 |
| racarr | and I guess, yeah is also a surface (though not a window...though really there are a few ways we can shove around this terminology) | 17:02 |
| racarr | so anyway you resize or move the parent | 17:02 |
| racarr | and the children behave appropos | 17:02 |
| anpok_ | why would adding hierachy avoid the need to expose synchronization primitives? | 17:04 |
| racarr | Because you just call | 17:05 |
| racarr | parent_surface->resize | 17:05 |
| racarr | and the scene internally | 17:05 |
| racarr | lock() | 17:05 |
| racarr | resize1() | 17:05 |
| racarr | resize2() | 17:05 |
| alan_g | The window manager needs to be in charge anyway - because it can change the decorations "appropriately". | 17:05 |
| racarr | Maybe | 17:06 |
| alan_g | We don't need too much intelligence in the scene - it is just there for the views to observe. | 17:07 |
| racarr | I kind of have this other idea...but am struggling to articulate it | 17:07 |
| racarr | but for like effects...e.g. window expose and other animations | 17:07 |
| racarr | it seems kind ofcumbersome to only have | 17:08 |
| racarr | the decoration assosciation in the controller | 17:08 |
| racarr | eh | 17:09 |
| racarr | maybe just a model im mentally attached to rather than anything important | 17:10 |
| alan_g | Rule of thumb: if you can't name two components that care about it it should not go in the scene, it should go in the component that cares. | 17:12 |
| racarr | alan_g: Hmm thats a nice idea | 17:15 |
| racarr | I guess Im yet to think of the shell as a single component though | 17:15 |
| racarr | a.k.a. the thing that does the window spread animations and | 17:16 |
| alan_g | That's because it got mixed up in scene (and is only partially extracted even now) | 17:16 |
| racarr | the frontend window management controller | 17:16 |
| racarr | may not really be the same component right... | 17:16 |
| racarr | hmm | 17:16 |
| === dandrader|lunch is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| anpok_ | racarr: hm I believe not only for rendering, also for each kind of change operation on the scene.. system behavior will be harder to reason about if anything can change between micro steps.. | 19:14 |
| racarr | yeah thats a good point to think about too | 19:20 |
| anpok_ | i am all in favor of queueing the operations into batches.. i.e. at the start of processing you could define whatever is currently in the queue as you current workload | 19:22 |
| anpok_ | and when that is done, redraw may happen .. | 19:22 |
| anpok_ | every change that comes in later .. comes later.. | 19:23 |
| anpok_ | as a start | 19:23 |
| anpok_ | one might want to refine that and differ between changes caused by external triggers or changes that are transitively required due to changes of the initial workload | 19:24 |
| === dandrader is now known as dandrader|afk | ||
| === olli_ is now known as olli | ||
| racarr | http://git-man-page-generator.lokaltog.net/ | 21:21 |
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!