[00:17] <RAOF> I'm *sure* I've added close() to drm_fd_handler before...
[00:43] <RAOF> Interesting: http://kentonv.github.com/capnproto/index.html
[01:57] <duflu> kgunn: Isn't your day long enough already? :)
[03:01] <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:04] <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:06] <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:07] <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:08] <robert_ancell> duflu, done
[03:08] <robert_ancell> brb
[05:10] <tvoss> RAOF, cap'n'proto is indeed interesting, but I have had difficulties figuring out if it's done, yet
[05:13] <smspillaz> tvoss: oh yeah, I was going to mention that one to you
[05:13] <smspillaz> saw it on reddit the other day
[05:33] <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:34] <RAOF> I don't, except that he's also the primary author of Google Protobuf
[06:11] <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:26] <tvoss> RAOF, do we have a video of racarr's in process egl work, yet?
[06:31] <RAOF> tvoss: not afaik
[08:24] <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:25] <mmrazik> duflu: sure. removing it....
[08:26] <duflu> mmrazik: Thanks
[08:26] <mmrazik> duflu: done
[08:26]  * tvoss thinks that the CI jobs should do twitter, too :)
[08:27] <duflu> Well, CI output is useful. Twitter is not usually used for useful things...
[08:27] <duflu> I suppose it could be
[08:28] <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:29] <tvoss> probaro ergo sum
[08:29] <smspillaz> duflu: thanks for updating the other mps :)
[08:30] <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:31] <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:32] <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:33] <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:34] <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:35] <smspillaz> hmm, seems to work if I use std::move although that certainly feels wrong
[08:38] <RAOF> Why does that feel wrong?
[08:39] <smspillaz> std::unique_ptr <MockFoo> mock;
[08:39] <smspillaz> * set some expectations
[08:40] <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:42] <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:43] <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:44] <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:45] <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:46] <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:50] <alan_g> smspillaz: c++03 doesn't have move semantics
[09:20] <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:23] <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:24] <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:26]  * alan_g wishes for one big source tree with everything in it . (That also builds quickly.)
[10:00] <duflu> Hey lp:omniverse doesn't exist yet ;)
[10:18] <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
[11:27] <tvoss> alan_g, ping
[11:30] <alan_g> tvoss: pong
[12:46] <kgunn> alf_: reading you control loop thread again...was thinking, would rotate be an event? (think phone/tablet)
[12:47] <kgunn> alf_: its sort of like a display reconfig event
[12:48] <kgunn> anyway....more arguments/use cases for your idea
[12:49] <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.
[15:10] <kdub> morning
[15:10] <tvoss> kdub, good morning :)
[15:11] <alan_g|tea> kdub: morning
[15:11]  * alan_g remembers to change nick
[15:53] <alf_> status: Thinking about main loop, working on a main loop prototype (see message in mir-devel thread), reviewing
[15:57] <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:58] <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:59] <tvoss> kdub, \o/
[16:04] <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:06] <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:07] <alf_> kdub: hmm, perhaps I should update to the latest image first and try again?
[16:08] <kdub> alf_, the other thing is, make sure surfaceflinger is not running... its very aggressive about restarting
[16:13] <kgunn> kdub: not if you rename it :)
[16:13] <kgunn> its your trick....and fool proof
[16:14] <alan_g> status: reviewing, trying to understand enough bits to spike "hardware cursor"
[16:19] <racarr> Morning
[16:28] <alf_> alan_g: @hardware cursor, anything I can help with?
[16:29] <alan_g> alf_: can we hangout in the morning?
[16:29] <alf_> alan_g: sure
[16:49] <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:50] <alan_g> racarr: looking...
[16:54] <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:55] <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:56] <racarr> Except for the great cosmic background EGL that surrounds and binds us all
[16:56] <racarr> (All praise *3 quick bows*)
[16:58] <alan_g|EOD> Goodbye all!
[16:58] <racarr> Good Evening :)
[17:01] <kgunn> evnin'
[17:02] <alf_> alan_g|EOD: goodbye
[17:02] <alf_> kdub: I am still getting the problem with latest image, will check more tomorrow
[17:04] <kdub> racarr, with input enabled on android, do these errors look sensible for the state of the code? https://pastebin.canonical.com/88338/
[17:54] <racarr> kdub: Those errors are pretty good yeah
[17:55] <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:57] <racarr> status: Doing a final self review round, etc on receive-input-in-client
[17:57] <racarr> so hopefully it can land this afternoon?
[18:06] <racarr> Can someone approve https://code.launchpad.net/~robertcarr/mir/dedupe-null-input-managers/+merge/156645
[18:07] <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:18]  * 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:23] <kdub> surfaceflinger's rendering portions sometimes looks like a big switch statement based on hwc version
[19:18] <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:19] <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:20] <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:21] <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:24] <kdub> kgunn, sure.. maybe before the mir2 meeting?
[19:31] <kgunn> kdub: might be early for him
[20:46] <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:50] <kgunn> our docs, in so far as our implementation accounts for it
[20:54] <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?
[21:02] <robert_ancell> kgunn, are you meeting today?
[21:45] <kgunn> kdub: is this that hybris branch https://code.launchpad.net/~rocket-scientists/aal+/ubuntu-platform-api_replace_hybris_hardcoded_path
[21:46] <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:47] <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
[22:21] <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:25] <RAOF> racarr: Alternatively, could you point me to code that I could test in-process-egl against?
[23:12] <RAOF> Ok. The fact that our unit-tests now terminate part-way through more often than not is getting annoying.
[23:14] <kdub> RAOF, what unit tests?
[23:14] <RAOF> The unit-tests binary.
[23:15] <kdub> sure :) i mean, which test, within the unit-tests binary is causing trouble?
[23:16] <RAOF> It's not deterministic; it often crashes between ‘[[23:16] <RAOF> I suspect this might be related to why clang-built unit-tests die immediately.
[23:17] <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:19] <RAOF> And, obviously, gtest makes it hard to find because it's a sub-process dying
[23:22] <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.