| RAOF | Dear clang: thank you for catching the spelling mistake in "mark_as_sumbitted" that g++ ICEs on. | 01:07 |
|---|---|---|
| RAOF | Much love, Chris. | 01:07 |
| RAOF | Less love because your build of the unit-tests segfaults, but that may well be our problem. | 01:10 |
| * xnox is actively learning C++ and I'm using clang++ cause otherwise I'd be stuck learning gcc codebase instead. | 01:48 | |
| duflu | xnox: Clang is really useful in telling you what mistakes you've made, regardless of skill level. Keep in mind however that Mir is not yet functional when built with clang++. And it might not be for a long time. | 02:07 |
| RAOF | Ok. What the hell? | 05:47 |
| RAOF | This: http://paste.ubuntu.com/5633273/ patch makes MirClientSurfaceTest.client_buffer_created_on_next_buffer segfault. | 05:51 |
| RAOF | But MirClientSurfaceTest doesn't *use* AgingBuffer, nor do any of its dependencies! | 05:51 |
| duflu | RAOF: Side effects... Maybe try: valgrind bin/unit-tests | 05:53 |
| * duflu tries to ignore the circus going on in Canberra | 05:53 | |
| RAOF | duflu: I did, but it wasn't very helpful; just an invalid read, which I knew about because reading 0x16 | 05:53 |
| RAOF | was what was causing the segfauult. | 05:54 |
| RAOF | HAH! | 05:54 |
| RAOF | That's a trick for the uninitiated - test_aging_buffer.cpp and test_client_mir_surface.cpp are both built into unit-tests, and have differing class definitions for mir::test::MockBuffer | 05:55 |
| RAOF | I have no idea why that's not either (a) a compile time error, or (b) supposed to work. | 05:56 |
| RAOF | This suggests that our tests are quite fragile - we've got a number of definitions of mir::test::MockBuffer lying around in various .cpp files which just happen to be identical. | 05:57 |
| duflu | RAOF: The linker always chooses and keeps one copy of a symbol. It's only a problem if the multiple copies are different :) | 05:58 |
| duflu | RAOF: Sorry, I mean it chooses and keeps one of each unit name. By default an object is a unit, but you can make single functions/methods separate units | 06:00 |
| tvoss | RAOF, can this be connected to -Bsymbolic_functions? | 06:01 |
| RAOF | tvoss: Maybe? | 06:03 |
| * RAOF -> baby | 06:04 | |
| tvoss | RAOF, have fun :) | 06:04 |
| duflu | tvoss: -Bsymbolic* flags are usually only needed in large plugin-based systems (like two of my previous projects). If you're not dynamically loading plugins then -Bsymbolic is usually a mistake that should have been solved with moving source code around. And/or better namespaces. | 06:09 |
| tvoss | duflu, -Bsymbolic is one of the default flags set during package builds | 06:09 |
| duflu | tvoss: Sure, it's safe to turn on. But in non-plugin systems you don't need it | 06:10 |
| duflu | In plugin systems you need to to get around the problem of controlling which template instantiation the runtime linker binds to | 06:10 |
| duflu | "need it to" | 06:10 |
| tvoss | duflu, I do agree with you, no question about that. But the ubuntu packaging setup pulls it by default | 06:11 |
| duflu | Hmm, it's only a few characters, and probably doesn't hurt anyone | 06:12 |
| duflu | I'm sure there are use-cases for not having Bsymbolic but don't recall any | 06:13 |
| duflu | Oh, yes I do. You want to avoid Bsymbolic when you have important data stored in static members of a class. To ensure everyone is looking at the same copy of the static member | 06:14 |
| tvoss | duflu, yup, that was one of the use-cases that was breaking for us in one of the test-cases, but I cannot recall which one | 06:16 |
| duflu | tvoss: You can avoid all these problems if you're careful to explicitly instantiate templates in a single location. And mark them as "extern" in your headers. | 06:17 |
| duflu | Assuming it's a template | 06:17 |
| tvoss | duflu, it wasn't a template, I think it came down to a static object taking care of the google protobuf initialization | 06:18 |
| duflu | Ugh | 06:18 |
| tvoss | duflu, the approach is perfectly fine, but the cpp was compiled into multiple so's | 06:19 |
| tvoss | duflu, and normally the linker should have made it one symbol, but with -Bsymbolic, every so got its own instance | 06:19 |
| duflu | tvoss: Technically Bsymbolic does not affect or reduce duplicate symbols in your binaries. It only defines the rule for which one to point to at runtime. | 06:20 |
| duflu | If there are duplicate symbols, then that's something to fix in the source code/makefiles | 06:21 |
| tvoss | duflu, I do disagree. Looking at the definition of static in C++, the expected behavior even if the _same_ cpp is compiled into multiple so's that all get loaded at runtime, the symbol should be unique | 06:22 |
| duflu | tvoss: Sure, if you're smart about creating the ideal compiler (which does not exist). I'm just talking about how to handle real-world compilers | 06:22 |
| tvoss | duflu, well, gcc without -Bsymbolic actually works :) | 06:23 |
| tvoss | duflu, so close to ideal | 06:23 |
| duflu | Ideal until you put in in a plugin system, load plugin A then B, and unload plugin A. You're left with B pointing to symbols in A that are no longer mapped in memory | 06:24 |
| duflu | "put it in" | 06:24 |
| tvoss | duflu, @plugin system: agreed, but I was referring to implicitly loaded so's | 06:25 |
| duflu | Yup. Just covering all the bases. All options have a use-case somewhere | 06:25 |
| tvoss | duflu, yup | 06:26 |
| * tvoss wants to have GNUInstallDirs as offered by cmake 2.8.10 :) | 06:36 | |
| RAOF | Why not have it? | 06:38 |
| RAOF | apt-cache policy cmake | 06:38 |
| RAOF | cmake: | 06:38 |
| RAOF | Installed: 2.8.10.1-0ubuntu6 | 06:38 |
| RAOF | :) | 06:38 |
| alf_ | duflu: lp:1158120, have you started looking into it? I noticed this in vm ci builds, and I was planning to investigate. | 07:37 |
| alf_ | lp 1158120 | 07:37 |
| ubot5 | Launchpad bug 1158120 in Mir "acceptance-tests.BespokeDisplayServerTestFixture is failing randomly (approx 10% of the time)" [High,New] https://launchpad.net/bugs/1158120 | 07:37 |
| duflu | alf_: No not working on it | 07:37 |
| alf_ | duflu: ok, I will take a look today then | 07:37 |
| robert_ancell | alf_, I'm still not resolving QtPlatformSupport/private/qgenericunixfontdatabase_p.h, in fact I don't have any private/ dir under /usr/include/qt5/QtPlatformSupport/ | 07:59 |
| robert_ancell | qthybris is using similar stuff, but I seem to have all the build-depends | 07:59 |
| alf_ | robert_ancell: there are some qt -private packages | 08:01 |
| robert_ancell | alf_, not in raring it seems, are they from a PPA? | 08:02 |
| alf_ | robert_ancell: no, I am not using the PPA anymore, switched to the archive | 08:02 |
| alf_ | robert_ancell: e.g. qtbase5-private-dev | 08:02 |
| robert_ancell | alf_, aha! Cheers | 08:03 |
| tvoss | robert_ancell, best to ask loicm :) | 08:04 |
| robert_ancell | tvoss, did he write some of this? | 08:04 |
| robert_ancell | bzr says no | 08:04 |
| tvoss | robert_ancell, I think the project is called qtubuntu now, and yeah, he wrote almost all of it | 08:05 |
| * alf_ managed to delete his vim config files... to the backup! | 08:05 | |
| * robert_ancell bzr branches | 08:06 | |
| === mmrazik is now known as mmrazik|crappy_i | ||
| === mmrazik|crappy_i is now known as mmrazik | ||
| === vibhav is now known as IdleBat | ||
| === IdleBat is now known as vibhav | ||
| robert_ancell | tvoss, oh, I've had my Loics confused. Thank makes more sense :) | 08:31 |
| tvoss | robert_ancell, I do keep confusing them, too :) let's call them french1 and french2 | 08:33 |
| tvoss | robert_ancell, as, according to tedg, there are approximately only 5 people living in France & Germany, enumerating them should be easy | 08:33 |
| robert_ancell | tvoss, I'm sure they would be supportive of the idea. We could get them all F1-F5 t-shirts for conferences too | 08:34 |
| tvoss | robert_ancell, yeah ... but hell breaks loose if they start exchanging shirts :) | 08:34 |
| robert_ancell | those crazy French! | 08:35 |
| === alan_g is now known as alan_g|afk | ||
| * tvoss is scared of people eating frogs :) | 08:35 | |
| === alan_g|afk is now known as alan_g | ||
| alan_g | alf_: looking at https://code.launchpad.net/~raof/mir/client-side-buffer-age/+merge/151869 ... | 09:42 |
| alan_g | I can't see why TEST(MirClientAgingBufferTest, buffer_age_starts_at_zero) passes, surely AgingBuffer default initializes buffer_age - which for a POD is an unspecified value. Am I missing something? Or should there should be a constructor that initializes buffer_age to 0. | 09:42 |
| alf_ | alan_g: looking... | 09:43 |
| alf_ | alan_g: I don't think TEST(MirClientAgingBufferTest, buffer_age_starts_at_zero) makes any sense at all, since we are testing the return value of a mock object. It passes because no expectation is set on age(), and googlemock just returns a default value (0). | 09:45 |
| alf_ | alan_g: hmm, wait, let me look more closely | 09:46 |
| alan_g | alf_: that's a different problem - it isn't a mock of AgingBuffer | 09:46 |
| alf_ | alan_g: you are right, got carried away by the name | 09:47 |
| alf_ | alan_g: does make_shared value-initializes the created object? | 09:49 |
| alan_g | alf_: investigating | 09:50 |
| alan_g | alf_: seems so | 09:52 |
| alan_g | If I change it to use new, the test fails | 09:53 |
| * alan_g shudders | 09:53 | |
| === yofel_ is now known as yofel | ||
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| alan_g | Anyone read this? http://pragprog.com/book/lotdd/modern-c-programming-with-test-driven-development | 12:33 |
| === alan_g is now known as alan_g|lunch | ||
| tvoss | alan_g|lunch, nope, haven't read that one | 12:38 |
| tvoss | alan_g|lunch, shall we share a copy, it's drm-free if I understand it correctly | 12:39 |
| === mmrazik_ is now known as mmrazik | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | tvoss: I still like paper. (And I'd like to hear opinions before spending time reading it.) | 13:43 |
| === mmrazik is now known as mmrazik|afk | ||
| smspillaz | alan_g: looks interesting | 13:49 |
| alan_g | smspillaz: it could well be. (But so are more books than I have time to read.) | 13:50 |
| smspillaz | alan_g: anything in particular in that book that makes it worth reading though | 13:51 |
| smspillaz | it kinda feels a lot like most other books I've read ("inject all the dependnencies, write all the tests!" | 13:51 |
| smspillaz | ) | 13:51 |
| alan_g | smspillaz: That's what I teach too - it really is as simple as deciding to do it. | 13:52 |
| smspillaz | I guess the only stuff I'm interested at this point is "how to write effective tests that actually test all the cases" | 13:53 |
| alan_g | You've read GOOS? | 13:53 |
| smspillaz | a bit | 13:53 |
| alan_g | It's the best book I know on the subject by some margin. | 13:54 |
| alan_g | But then I drink beer with Nat & Steve. | 13:54 |
| smspillaz | heh | 13:54 |
| smspillaz | alan_g: heh, so the extracts from this book feel like "here is how to use google test ... the way you already use it" | 14:05 |
| alan_g | smspillaz: it may be the way *you* use it. But there are a lot of wrong ways out there | 14:07 |
| smspillaz | alan_g: of course, I'm sure there some bits I haven't considered in there | 14:08 |
| Braggart | kdub: Just read your latest entry on Ubuntu Planet. One thing you did not discuss is the prospect of Wayland compositor using Android drivers. | 14:54 |
| Braggart | Do ping me when you're around and reply, otherwise I myself would forget that I left this question. | 14:56 |
| kdub | Braggart, can't talk about everything at once :) | 14:58 |
| kdub | hello folks! status today, working on landing that android display branch, moving on to hwc work | 14:58 |
| Braggart | Nothing wrong with that. Asking since you mentioned I can ask. :) | 14:58 |
| Braggart | kdub...? | 15:01 |
| kdub | if they can get it to work too, more power to them i guess :) | 15:04 |
| kdub | also all, i'm back from san jose today, back to my normal day :) | 15:04 |
| smspillaz | Braggart: my understanding is that pq got it working by hacking wayland to work on top of bionic, and then got it to the point where the compositor ran, but there was no graphics buffer sharing (as that was implemented through wl_drm which implemented wl_buffer) | 15:05 |
| alf_ | kdub: Hi! Question: I get some flickering when I use render-surfaces on nexus 4. Is this because the vsync work is not finished there yet? | 15:05 |
| kdub | alf_, yep | 15:05 |
| alf_ | kdub: ok | 15:05 |
| kdub | smspillaz, Braggart that's my understanding as well, just the framebuffer was accelerated | 15:06 |
| kdub | alf_, that's what I plan on working on today actually :) | 15:06 |
| alf_ | kdub: great :) | 15:07 |
| Braggart | Not possible to do a separate graphics buffer sharing bionic? | 15:07 |
| Braggart | *sharing implementation for bionic? | 15:07 |
| smspillaz | Braggart: bionic isn't really the problem, I think it was just more of a case of it being not implemented yet | 15:09 |
| === alan_g is now known as alan_g|tea | ||
| Braggart | So instead of the said hypothetical implementation, we get a new compositor. | 15:12 |
| Braggart | Right that answers all my questions, thank you. | 15:12 |
| Braggart | smspillaz: Thanks for all the hard work. | 15:12 |
| smspillaz | *shrug* | 15:12 |
| smspillaz | maybe I shouldn't talk to people, I seem to make them upset :( | 15:13 |
| === alan_g|tea is now known as alan_g | ||
| alan_g | smspillaz: I don't see anything in what you said. (Some people just want a pretext to be upset.) | 15:23 |
| smspillaz | alan_g: heh, I've been in both positions before | 15:29 |
| smspillaz | with young age comes immaturity at times I guess | 15:30 |
| alan_g | The young have no patent on immaturity | 15:30 |
| smspillaz | prior art ? | 15:31 |
| smspillaz | I suppose the seemingly limitless immaturity demonstrated by the "elder" Simon Crean in Australia today pretty much proves that point | 15:32 |
| smspillaz | (dunno if you saw, but there were a series of very dramatic events in australia today that pretty much put the nail in the coffin for current government come the september election) | 15:33 |
| alf_ | alan_g: kdub: MultiThreadedCompositor needs an interface through which to learn when something in the surface configuration changes (i.e. to register a callback with). A couple of names I have thought so far: CompositingState(Notification), RenderStateChangeNotification. Of course, we could also extend RenderView, with the rationale that it is the interface through which the compositor subsystem in general accesses the surface stack, but this w | 15:33 |
| alf_ | alan_g: kdub: Thoughts? | 15:33 |
| === mmrazik|afk is now known as mmrazik | ||
| alan_g | alf_: I think it is likely "CompositingContext" not "CompositingState" | 15:35 |
| alan_g | alf_: but I think I prefer adding callbacks to RenderView. | 15:36 |
| === rsalveti_ is now known as rsalveti | ||
| alan_g | Callbacks on a view seem to be a sensible mechanism | 15:37 |
| kdub | yes, a callback seems sensible | 15:38 |
| kdub | alf_, "when something in the surface configuration changes", whats an example of what you're thinking? | 15:40 |
| kdub | an example of what changes, i mean | 15:40 |
| alan_g | yes, that's a point, the compositor isn't caching state - it submits code to be applied to the view. | 15:43 |
| alf_ | alan_g: Conceptually a change callback fits in RenderView, and it's how I have it in my local code right now. On the other hand, RenderView is used by two different (but related) components for two different purposes, hence my concern. | 15:43 |
| alan_g | Then it might be that RenderView should be two related dependency interfaces | 15:44 |
| alf_ | kdub: the idea is that the compositor will only composite when it needs to, which means when any surface changes state (position etc) or contents (a new buffer is pushed) | 15:44 |
| alan_g | alf_: that makes a lot of sense | 15:45 |
| alan_g | so it would be like notify_changes(area, callback) | 15:46 |
| === gema_ is now known as gema | ||
| kdub | alf_: ah, okay... when i was thinking about that problem a while back, a callback made sense like that made sense to me too | 15:47 |
| alf_ | alan_g: in the first iteration it will just be notify_changes(callback), i.e., redraw everything when anything changes, but it surely makes sense to add the area later | 15:50 |
| alan_g | alf_: the callback could be passed an affected area and the decision taken there | 15:51 |
| alan_g | alf_: but I agree that's for later | 15:51 |
| kdub | alf_, we should always have a 'redraw all' even if can only redraw certain areas | 15:52 |
| kdub | drivers sometimes -_- | 15:53 |
| alf_ | alan_g: kdub: I was thinking about the area mostly in terms of which output is affected. At least for now, we don't support redrawing only part of an output; we recomposite the whole output every time. | 15:57 |
| alan_g | alf_: sure | 15:57 |
| alf_ | alan_g: kdub: ok, for now I will keep the callback in RenderView. We can reconsider later. | 16:00 |
| alf_ | alan_g: kdub: callback => callback registration mechanism | 16:01 |
| alf_ | thanks | 16:01 |
| alan_g | alf_: ack. But this discussion makes me wonder if RenderView should be RenderModel | 16:01 |
| * alan_g ducks | 16:02 | |
| === alan_g is now known as alan_g|coding | ||
| alf_ | alan_g|coding: could be, let's see how the code feel in the MP, and I am happy to discuss further and amend | 16:03 |
| ogra_ | kdub, hmm, your blog post seems slightly wrong, or do you actually plan to teach the android GLES drivers to do actual openGL ? | 16:15 |
| kdub | ogra_, gp. no :) all opengles | 16:15 |
| ogra_ | ..."when you run mir inside of an Ubuntu Touch phone/tablet, you use the android platform to get full OpenGL acceleration" | 16:16 |
| * alf_ is unhappy about ICEs he has been getting lately | 16:17 | |
| racarr | Morning :) | 16:50 |
| kdub | morning racarr | 16:51 |
| racarr | sorry to be a little late :) | 16:52 |
| racarr | I seem to have acquired always moving at ten million miles an hour syndrome these last few weeks | 16:52 |
| racarr | Did anyone have a chance to look at the... | 16:54 |
| racarr | "something" issue in send-input-to-clients requiring the dynamic cast | 16:54 |
| racarr | this GCC crashing on all nontrivial template errors | 17:05 |
| racarr | is starting to become a timesink -.- | 17:05 |
| === kgunn is now known as kgunnAFK | ||
| tvoss | kdub, could you fix your blog post regarding opengl vs. gles? | 17:18 |
| kdub | tvoss, yes, ogra_ had a good pt | 17:18 |
| tvoss | kdub, thx :) | 17:18 |
| ogra_ | :) | 17:19 |
| kdub | done | 17:20 |
| tvoss | kdub, thx again | 17:20 |
| racarr | I had a dream last night | 17:21 |
| racarr | where we had a code review tool where while reviewing the code you could suggest minor fixes inline | 17:21 |
| kdub | gerrit does that | 17:21 |
| racarr | and the person could accept or reject them easily | 17:21 |
| racarr | it was a nice dream | 17:21 |
| racarr | kdub: Is it useful? It sounds like it would be really useful if done right... | 17:22 |
| kdub | i liked gerrit a lot, but its aimed towards git | 17:22 |
| racarr | mm | 17:23 |
| racarr | alan_g|coding: Updated send-input-to-clients and prepare-for-inprocess-egl but no hurry | 17:23 |
| racarr | Does anyone have any thing they would like me to work on /review/help with | 17:35 |
| racarr | or should I jump in to receive-input-in-client | 17:35 |
| === alan_g|coding is now known as alan_g | ||
| alan_g | racarr: could you check https://code.launchpad.net/~vanvugt/mir/surface-types/+merge/154261 please? | 17:39 |
| alan_g | racarr: will look at send-input-to-clients and prepare-for-inprocess-egl now | 17:40 |
| racarr | alan_g: Great thanks | 17:40 |
| racarr | will look now | 17:40 |
| racarr | alan_g: Would be interested to know what you think about the need for the dynamic cast in send-input-to-clients (SessionManager::set_focus_to) | 17:41 |
| racarr | it's quite difficult to find a refactoring that works ... | 17:41 |
| alan_g | racarr: the first thing I see on lp is "Text conflict in include/server/mir/shell/application_session.h" | 17:49 |
| alan_g | racarr: I guess you need either a dynamic cast or a lookup mechanism (hashmap?) | 17:53 |
| racarr | alan_g: It seems so right...without some sort of heavier | 17:56 |
| racarr | refactoring | 17:56 |
| racarr | alan_g: One sort of possibility | 17:56 |
| racarr | is that actually | 17:56 |
| racarr | eh well. | 17:56 |
| racarr | if it worked in terms of IDs like Surface | 17:57 |
| racarr | then you could keep track of the bits as msh::Surface inside the session manager, and return mf::Session from mf::SessionStore and msh::Session from msh::SessionManager | 17:57 |
| racarr | and it works because of covariant return types | 17:57 |
| racarr | (as opposed to the "covariant arguments" that you would need now) | 17:58 |
| racarr | but it seems strange to store IDs like that because the only client of open/close session | 17:58 |
| racarr | is the session mediator which only uses one session per instance | 17:58 |
| racarr | so its kind of just an obfuscation | 17:58 |
| racarr | from that perspective | 17:58 |
| alan_g | Hmm smart pointers are not covariant | 17:58 |
| alan_g | anyway, I'm not bothered about the cast | 17:59 |
| alan_g | Even if it does suggest a bit of tension in the deswign | 17:59 |
| racarr | Yeah it's always correct and clearly so by suggestion | 17:59 |
| racarr | but it feels like it is | 17:59 |
| racarr | a bug in our type system | 17:59 |
| racarr | haha | 17:59 |
| racarr | s/suggestion/inspection | 17:59 |
| racarr | "Correct by suggestion" hmm | 17:59 |
| racarr | reviewed surface-types | 18:02 |
| === rafalm_ is now known as rafalm | ||
| racarr | if prepare-for-inprocess-egl is ready to land we should wait to switch to approved | 18:03 |
| racarr | until I can sync up with RAOF later and land the | 18:03 |
| racarr | mesa changes concurrently | 18:04 |
| racarr | merging trunk in to send-clients-input now | 18:04 |
| racarr | lol... | 18:05 |
| racarr | the deletion of trailing whitespace in application_session.h | 18:05 |
| alan_g | racarr: both branches need conflicts sorting out | 18:05 |
| racarr | conflicted with my addition of a metho | 18:05 |
| racarr | alan_g: Just pushed fixed conflicts on send-input-to-clients | 18:05 |
| alan_g | racarr: just "went home" | 18:06 |
| === alan_g is now known as alan_g|life | ||
| racarr | and prepare-for-inprocess-egl-clients :) | 18:07 |
| racarr | alan_g|life: Sounds good :) have a good evening | 18:07 |
| racarr | brb in 15 | 18:09 |
| === mmrazik is now known as mmrazik|afk | ||
| racarr | Anyone have time to give a final round of review | 18:47 |
| racarr | to prepare-for-inprocess-egl? | 18:48 |
| racarr | Well no rush | 18:48 |
| === kgunnAFK is now known as kgunn | ||
| tvoss | alf_, you still around? | 19:05 |
| === mmrazik|afk is now known as mmrazik | ||
| === kgunn is now known as kgunnAFK | ||
| RAOF | racarr: What do you need from mesa? | 22:40 |
| RAOF | racarr: If the android input stack wasn't a steaming pile of won't-build-with-clang you could use that :). Yeah, g++ ICEing on any gmock error is getting really old. | 22:42 |
| kdub | thomi, are you able to add a 'deb' line to the sources.list of the mir CI pbuilder on jenkins? | 23:14 |
| racarr | RAOF: I didn't have the ICE problem until | 23:28 |
| racarr | a recent dist-upgrade... | 23:28 |
| racarr | it's super frustrating | 23:28 |
| racarr | like I just wrote a whole new acceptance test file and tried to compile it | 23:29 |
| racarr | ICE! XD | 23:29 |
| racarr | RAOF: From mesa! prepare-for-inprocess-egl-clients is basically ready to land | 23:29 |
| racarr | so we need to land the mesa changes concurrently | 23:29 |
| racarr | the stuff for the NativeDisplay with | 23:29 |
| racarr | callbacks | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!