| RAOF | I'm *sure* I've added close() to drm_fd_handler before... | 00:17 |
|---|---|---|
| RAOF | Interesting: http://kentonv.github.com/capnproto/index.html | 00:43 |
| duflu | kgunn: Isn't your day long enough already? :) | 01:57 |
| duflu | robert_ancell: Can we please have milestones and code on the same series? https://launchpad.net/mir | 03:01 |
| duflu | ... one way or the other | 03:01 |
| robert_ancell | duflu, as kgunn said, Launchpad won't let us delete the 13.05 milestone. I did manage to delete the 14.04 series by moving the milestone | 03:04 |
| robert_ancell | duflu, I've set the 13.05 milestone to inactive, so that seems to workaround LP being confused | 03:06 |
| robert_ancell | duflu, solved? | 03:06 |
| duflu | robert_ancell: OK, ta. Still need an active milestone > 0.0.2 to link our Fix Committed bugs to | 03:07 |
| robert_ancell | duflu, ok, I'll open a 0.0.3 | 03:07 |
| robert_ancell | duflu, done | 03:08 |
| robert_ancell | brb | 03:08 |
| tvoss | RAOF, cap'n'proto is indeed interesting, but I have had difficulties figuring out if it's done, yet | 05:10 |
| smspillaz | tvoss: oh yeah, I was going to mention that one to you | 05:13 |
| smspillaz | saw it on reddit the other day | 05:13 |
| RAOF | tvoss: It's not done yet. | 05:33 |
| tvoss | RAOF, that's what I thought, too. However, it looks pretty promising. Do we know the author? | 05:33 |
| RAOF | I don't, except that he's also the primary author of Google Protobuf | 05:34 |
| RAOF | racarr: There doesn't seem to be anything in the EGL specification that prohibits the behaviour your inprocess-egl patch introduces (which is good ☺). I'll check that it doesn't indirectly break something. | 06:11 |
| tvoss | RAOF, do we have a video of racarr's in process egl work, yet? | 06:26 |
| RAOF | tvoss: not afaik | 06:31 |
| duflu | mmrazik: Looks like Mir no longer needs -DMIR_DISABLE_INPUT=ON for clang. And we're about to remove that option too. Can we update CI? | 08:24 |
| mmrazik | duflu: sure. removing it.... | 08:25 |
| duflu | mmrazik: Thanks | 08:26 |
| mmrazik | duflu: done | 08:26 |
| * tvoss thinks that the CI jobs should do twitter, too :) | 08:26 | |
| duflu | Well, CI output is useful. Twitter is not usually used for useful things... | 08:27 |
| duflu | I suppose it could be | 08:27 |
| tvoss | duflu, but given jenkins' karma on launchpad, it might be considered a conscious being, and nowadays it's tweeto ergo sum :) | 08:28 |
| duflu | Codito ergo sum | 08:28 |
| tvoss | duflu, ;9 | 08:28 |
| tvoss | probaro ergo sum | 08:29 |
| smspillaz | duflu: thanks for updating the other mps :) | 08:29 |
| duflu | smspillaz: No problem. Accurate MPs and bugs are useful | 08:30 |
| smspillaz | alan_g: tvoss: question about unique_ptr. Is doing something like std::unique_ptr <Derived> d (new Derived); std::unique_ptr <Base> b (d); known to work ? | 08:30 |
| tvoss | smspillaz, at least, d would need to be moved to b | 08:31 |
| smspillaz | tvoss: does that need to happen explicitly? eg std::move () ? | 08:31 |
| alan_g | smspillaz: give or take a std::move, yes | 08:32 |
| smspillaz | I'm getting this weird problem where even if I do std::unique_ptr <Derived> d (new Derived); std::unique_ptr <Base> const &b (d); seems to not work either and tries to just move it | 08:32 |
| smspillaz | which fails | 08:32 |
| tvoss | smspillaz, yes, a move has to be explicit | 08:33 |
| tvoss | smspillaz, it would need to be std::unique_ptr <Base> b(std::move(d)); | 08:33 |
| smspillaz | hm | 08:33 |
| smspillaz | well, I guess my main problem at the moment is that I can't take a const ref either, and I thought it was something to do with the fact that moving wasn't supported | 08:34 |
| smspillaz | hmm, seems to work if I use std::move although that certainly feels wrong | 08:35 |
| RAOF | Why does that feel wrong? | 08:38 |
| smspillaz | std::unique_ptr <MockFoo> mock; | 08:39 |
| smspillaz | * set some expectations | 08:39 |
| smspillaz | bar (std::move (mock)) <- expects a std::unique_ptr <Foo> const & | 08:40 |
| smspillaz | * how do you set more expectations ? | 08:40 |
| smspillaz | the function wants a non-owning reference to the pointer, yet you have to give it the whole pointer | 08:40 |
| RAOF | Start with a std::shared_ptr<MockFoo>? | 08:42 |
| RAOF | I mean, if you're going to hand references out to it, it's not a unique_ptr. | 08:42 |
| RAOF | Oh, whoops. | 08:43 |
| duflu | Surely that's why you can only "swap" unique_ptrs. If you could assign them (or even copy by initializer), they'd no longer be unique | 08:43 |
| smspillaz | RAOF: well, I don't want shared *ownership* | 08:43 |
| smspillaz | duflu: you can move them | 08:43 |
| smspillaz | which is effectively like swapping | 08:43 |
| duflu | Fairy nuff | 08:43 |
| smspillaz | the point is that I don't want to copy or move it | 08:43 |
| smspillaz | I want to give a reference to its base | 08:43 |
| RAOF | Get a raw pointer out of it and send that? | 08:44 |
| duflu | RAOF: That's violating the uniqueness too | 08:44 |
| smspillaz | duflu: I want a const & | 08:44 |
| alan_g | smspillaz: a reference to base is spelt "Base const&" not "std::unique_ptr <Base> const &" | 08:44 |
| smspillaz | alan_g: reference to the unique pointer to the base | 08:45 |
| smspillaz | so I should be able to go from | 08:45 |
| smspillaz | std::unique_ptr <Derived> d (new Derived) | 08:45 |
| smspillaz | to std::unique_ptr <Base> const &b | 08:45 |
| smspillaz | because you can do that with shared pointers and it doesn't give out any new ownership | 08:46 |
| alan_g | smspillaz: not within the language rules - smart pointers to different types cannont be covarient | 08:46 |
| * smspillaz wonders why it worked with boost | 08:46 | |
| alan_g | or contravarient | 08:46 |
| smspillaz | ... probably because there was an implicit copy | 08:46 |
| alan_g | smspillaz: c++03 doesn't have move semantics | 08:50 |
| alan_g | alf_: Looking at enable-inprocess-egl again got me wondering how(if) we are managing dependencies on bespoke mesa. Should we be ensuring that mesa patches are in the ppa before landing branches that need them? | 09:20 |
| alf_ | alan_g: I would say the other way around, since mesa depends on the mir API and there is a chance it won't build if we land the mesa change first | 09:23 |
| alf_ | alan_g: (depends on the details of the change, of course) | 09:24 |
| alan_g | alf_: Yeah. Why can't things be simple. ;) | 09:24 |
| * alan_g wishes for one big source tree with everything in it . (That also builds quickly.) | 09:26 | |
| duflu | Hey lp:omniverse doesn't exist yet ;) | 10:00 |
| smspillaz | alan_g: hmm, I guess the best option then is to just pass the object by const reference | 10:18 |
| smspillaz | and don't make any functions that want a reference to the object a const ref to the unique_ptr | 10:18 |
| * smspillaz wishes C++ had rust-like pointers | 10:18 | |
| === ubot5` is now known as ubot5 | ||
| === mmrazik is now known as mmrazik|lunch | ||
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g| | ||
| === alan_g| is now known as alan_g | ||
| === mmrazik|lunch is now known as mmrazik | ||
| tvoss | alan_g, ping | 11:27 |
| alan_g | tvoss: pong | 11:30 |
| === alan_g is now known as alan_g|lunch | ||
| kgunn | alf_: reading you control loop thread again...was thinking, would rotate be an event? (think phone/tablet) | 12:46 |
| kgunn | alf_: its sort of like a display reconfig event | 12:47 |
| kgunn | anyway....more arguments/use cases for your idea | 12:48 |
| alf_ | kgunn: thanks, it could be... it depends on how we need to react to it. Perhaps it is just part of the reconfiguration process as you said, but I haven't thought this through. | 12:49 |
| === alan_g|lunch is now known as alan_g | ||
| === alan_g is now known as alan_g|tea | ||
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| kdub | morning | 15:10 |
| tvoss | kdub, good morning :) | 15:10 |
| alan_g|tea | kdub: morning | 15:11 |
| === alan_g|tea is now known as alan_g | ||
| * alan_g remembers to change nick | 15:11 | |
| alf_ | status: Thinking about main loop, working on a main loop prototype (see message in mir-devel thread), reviewing | 15:53 |
| kdub | oh yeah, statuses! your nexus 4's now work :) working still on the framebuffer native window type, improving things in the core as I go | 15:57 |
| kdub | so if something weird now happens on the nexus4, file a bug about it (in case its been getting a pass on funny functionality until now) | 15:58 |
| tvoss | kdub, \o/ | 15:59 |
| alf_ | kdub: now that you mention it, using the latest lp:mir I don't get any screen updates on the nexus 4 :/ I see only the first frame | 16:04 |
| alf_ | kdub: I will file a bug | 16:06 |
| kdub | alf_, thats a good bug :) let me see if i can reproduce | 16:06 |
| kdub | alf_, if you remember, put the version of the phablet image you're using | 16:06 |
| alf_ | kdub: hmm, perhaps I should update to the latest image first and try again? | 16:07 |
| kdub | alf_, the other thing is, make sure surfaceflinger is not running... its very aggressive about restarting | 16:08 |
| kgunn | kdub: not if you rename it :) | 16:13 |
| kgunn | its your trick....and fool proof | 16:13 |
| alan_g | status: reviewing, trying to understand enough bits to spike "hardware cursor" | 16:14 |
| racarr | Morning | 16:19 |
| alf_ | alan_g: @hardware cursor, anything I can help with? | 16:28 |
| alan_g | alf_: can we hangout in the morning? | 16:29 |
| alf_ | alan_g: sure | 16:29 |
| racarr | alan_g: Pushed some updates to receive-input-in-client (r622, r623) | 16:49 |
| kdub | alf_, i just tried with ubuntu-touch-image 56 (latest build i could find) and lp:mir. seems ok to me | 16:49 |
| alan_g | racarr: looking... | 16:50 |
| kdub | alf_, actually, i see render_surfaces being weird, but the server seems ok to me. i'll file a bug on that | 16:54 |
| racarr | kdub: Processed your comments on inprocess-egl will wok on them later today (maybe we can talk some about names, etc...) | 16:54 |
| kdub | racarr, sure, before you set down to change the names, lets figure out what they should be... its annoying to change 2x | 16:55 |
| * kdub has been wanting to improve 'inprocess egl' as a name for a while | 16:55 | |
| kdub | all egl is in a process! :P | 16:55 |
| racarr | Except for the great cosmic background EGL that surrounds and binds us all | 16:56 |
| racarr | (All praise *3 quick bows*) | 16:56 |
| === alan_g is now known as alan_g|EOD | ||
| alan_g|EOD | Goodbye all! | 16:58 |
| racarr | Good Evening :) | 16:58 |
| kgunn | evnin' | 17:01 |
| alf_ | alan_g|EOD: goodbye | 17:02 |
| alf_ | kdub: I am still getting the problem with latest image, will check more tomorrow | 17:02 |
| kdub | racarr, with input enabled on android, do these errors look sensible for the state of the code? https://pastebin.canonical.com/88338/ | 17:04 |
| racarr | kdub: Those errors are pretty good yeah | 17:54 |
| racarr | I want to work on reporting for droidinput but it's | 17:55 |
| racarr | difficult | 17:55 |
| racarr | We need a different pattern | 17:55 |
| racarr | the Reporter interface for say EventHub alone | 17:55 |
| racarr | would have like | 17:55 |
| racarr | 40 methods | 17:55 |
| racarr | status: Doing a final self review round, etc on receive-input-in-client | 17:57 |
| racarr | so hopefully it can land this afternoon? | 17:57 |
| racarr | Can someone approve https://code.launchpad.net/~robertcarr/mir/dedupe-null-input-managers/+merge/156645 | 18:06 |
| racarr | so I can approve https://code.launchpad.net/~robertcarr/mir/remove-mir-disable-input/+merge/156696 | 18:07 |
| racarr | so I can avoid | 18:07 |
| racarr | merging it in to remove-mir-disable-input | 18:07 |
| racarr | or a merge conflict later | 18:07 |
| racarr | well not a conflict actually | 18:07 |
| racarr | just something we have to remember to fix XD | 18:07 |
| * kdub is unaware of a rule that you can't tick to approve, granted all the review comments are addressed and you have an approve with no blocking reviews | 18:18 | |
| kdub | surfaceflinger's rendering portions sometimes looks like a big switch statement based on hwc version | 18:23 |
| kgunn | kdub: was just thinking about yesterday - you were wanting to look into resize | 19:18 |
| kgunn | i was looking at the bp for mir-phone-iteration-0 | 19:18 |
| kgunn | seems duflu is doing "client initiated maximize/fullscreen" | 19:19 |
| kgunn | might want to ping him or g+ hangout w him later and see what he's up to exactly | 19:19 |
| kdub | kgunn, one can be a dependency of the other | 19:20 |
| kdub | i'd imagine that task is more negotiating the request over ipc | 19:20 |
| kdub | and then the other half is doing the allocation/deallocation on the server side | 19:21 |
| kgunn | kdub: agreed its a subset...just worthy of a 2 minute chat | 19:21 |
| kdub | kgunn, sure.. maybe before the mir2 meeting? | 19:24 |
| kgunn | kdub: might be early for him | 19:31 |
| === francisco is now known as Guest66331 | ||
| kdub | i kinda want to write a doc explaining the sometimes-annoying display infrastructure that android has... should that go in our doc/ folder or somewhere else? | 20:46 |
| kgunn | our docs, in so far as our implementation accounts for it | 20:50 |
| thomi | Hi everyone... Is there an alternative to switching to VT1 to run mir? That's reasonably difficult to automate in a jenkins slave | 20:54 |
| thomi | if I don't care that my X session will die afterwards, is there some other way? | 20:54 |
| robert_ancell | kgunn, are you meeting today? | 21:02 |
| kgunn | kdub: is this that hybris branch https://code.launchpad.net/~rocket-scientists/aal+/ubuntu-platform-api_replace_hybris_hardcoded_path | 21:45 |
| kdub | kgunn, https://code.launchpad.net/~kdub/aal+/shared-pthread-poc | 21:46 |
| kgunn | kdub: thanks... | 21:46 |
| kdub | but we shouldn't be pointing people to it i think, its not really production quality | 21:46 |
| kdub | in public docs, i'd say | 21:47 |
| kgunn | kdub: right...i was going to pester pat's team :) just needed the stick to poke with | 21:47 |
| RAOF | racarr: Ok, EGL. Are you sure that all your changes are necessary? Specifically - the change to src/egl/main/egldriver.c seems both unnecessary and results in a leak. | 22:21 |
| RAOF | racarr: Alternatively, could you point me to code that I could test in-process-egl against? | 22:25 |
| RAOF | Ok. The fact that our unit-tests now terminate part-way through more often than not is getting annoying. | 23:12 |
| kdub | RAOF, what unit tests? | 23:14 |
| RAOF | The unit-tests binary. | 23:14 |
| kdub | sure :) i mean, which test, within the unit-tests binary is causing trouble? | 23:15 |
| RAOF | It's not deterministic; it often crashes between ‘[==========] 361 tests from 79 test cases ran. (443 ms total)’ and listing the total number of passed tests. | 23:16 |
| RAOF | I suspect this might be related to why clang-built unit-tests die immediately. | 23:16 |
| kdub | hmm, very strange... i haven't seen that behavior on android (yet) | 23:17 |
| RAOF | It's almost certainly going to be something thread related. | 23:17 |
| RAOF | And, obviously, gtest makes it hard to find because it's a sub-process dying | 23:19 |
| RAOF | After I finish addressing these merge reviews I'll see if I can hunt down why clang-built unittests die, and whether fixing that fixes this annoyance. | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!