[04:34] <RAOF> Oh, _that_ makes more sense.
[05:38] <RAOF> Ohhai std::system_error. You're like boost::errinfo(errno), except actually useful!
[07:31] <anpok> hi
[08:32] <alan_g> alf__: do you want to wait for greyback's vote on https://code.launchpad.net/~afrantzis/mir/scene-elements/+merge/223822?
[09:25] <anpok> alan_g: https://code.launchpad.net/~andreas-pokorny/mir/split-main-loop-and-fix-races/+merge/220571/comments/537389
[09:25] <alan_g> anpok: looking...
[09:25] <anpok> what do you refer to in the last paragrah
[09:25] <anpok> +p
[09:27] <alan_g> Splitting our event dispatching into two classes
[09:37] <anpok> alan_g: because we get another thread?
[09:38] <anpok> or because those things should all be treated as "events" and hence handlers of those should all be registered at the same instance?
[09:39] <anpok> the reason for splitting was about only doing those things in the main loop that need to be handled sequentially
[09:41] <anpok> but it isnt about EventLoop then - ok
[09:42] <anpok> alan_g: will renaming to EventLoop resolve the issues for the first MP, then we could discuss scheduler being the right pick for the second mp?
[09:43] <alan_g> anpok: I'm not saying it is wrong. Just that I've not been convinced by the approach. But that could be that I'm still tying to work out why any of it is needed.
[09:46] <anpok> understood.. I think a better (in terms of flexibility) approach would be to have all (apart from signals I guess) scheduling capability in a single class and deciding which component gets access to which thread event dispatcher..
[09:47] <anpok> .. deciding insider default server configuration ..
[09:47] <anpok> *inside
[09:47] <anpok> args
[09:48] <anpok> but I dont think that is needed yet
[09:49] <anpok> the split addresses the concern that we do to much within main loop and might delay timers..
[10:16] <anpok> alan_g: I am still unsure if renaming it to EventLoop really satifies you here
[10:16] <anpok> no objections against the name
[10:19] <alf__> alan_g: (@Gerry's feedback: no, we discussed the approach on Friday in IRC)
[10:23] <alan_g> anpok: there's a lot of code churn over this series of MPs and that leads to e.g. questions about the names. Better names make it easier to work out what's going on. I don't know if my suggestions are better names as I'm suggesting names in the hope of figuring out what motivates all this work. Somewhere, several MPs away is an interface that dandrader wants to use but the path getting there doesn't seem clear to me.
[10:25] <alan_g> anpok: I'm just finishing off the easier MS to review and I'll come back to this.
[10:27] <anpok> I could make that path shorter - the only thing I needed whas unregistering fd handlers. The rest was to address concerns along the path..
[12:19] <dandrader> anpok, so you're working on making an mp that keeps input_sender API but that has "minimal" changes to mir bowels?
[12:22] <anpok> hm no not at the moment .. my wifi was flaky.. I just wanted to say that the stack of MPs got bigger while addressing concerns/findings
[12:22] <anpok> or rather because of
[14:47] <alan_g> anpok: you're saying that you don't need split-main-loop-and-fix-races and move-loops-to-scheduler-namespace to land for something functionally equivalent to input-sender?
[14:57] <anpok> alan_g: I only need the unregister fd part
[15:00] <alf__> anpok: alan_g: Aren't some of the other changes needed for correctness of unregistering fds?
[15:01] <alan_g> anpok: "the unregister fd part" (wherever that ends alf__) sounds like a sensible size for an MP. ;)
[15:02] <anpok> alf__: yes but splitting caused naming discussions..
[15:03] <alan_g> Why is splitting needed for correctness?
[15:04] <anpok> alan_g: they are not - I wanted to say that I did not expect those to happen hence added them
[16:04] <Nothing_Much> Hi, how do I report a bug for XMir?
[16:10] <alan_g> Nothing_Much: https://bugs.launchpad.net/xmir
[16:15] <Nothing_Much> Sorry, had a kernel panic
[16:15] <Nothing_Much> How do I report a bug for XMir?
[16:15] <alan_g> Nothing_Much: https://bugs.launchpad.net/xmir
[16:28] <kgunn> AlbertA: so davmor2 is gonna test the powerd/usc display blank silo
[16:28] <AlbertA> kgunn: cool
[16:29] <davmor2> kgunn, AlbertA: Any preference on device?
[16:29] <AlbertA> davmor2: I've been testing on nexus4, so I guess nexus7 should be good
[16:31] <davmor2> no worries
[16:46] <davmor2> kgunn: shouldn't there be a brightness slider in the battery indicator?
[16:47] <AlbertA> davmor2: yes above the wifi control
[16:49] <davmor2> AlbertA: I meant in the indicator not in the settings app
[16:49] <kgunn> davmor2: interesting...i thot there used to be as well
[16:50] <kgunn> i mean it is there in settings tho
[16:50] <AlbertA> davmor2: in doesn't show there for me on a virgin image
[16:50] <davmor2> kgunn: yeap I see it in the settings app for brightness and in the battery indicator.
[16:51] <davmor2> AlbertA: Yeah I'm not saying it is a fault with the ppa it was more just a question as to whether it should be there
[16:53] <kgunn> davmor2: the ui is driven by the "data from the backend" so wondering if maybe thostr's team dropped that
[16:53] <kgunn> ...and its possible design said to do so
[16:53] <kgunn> i'll poke around
[16:53] <davmor2> could be
[16:53] <davmor2> thanks
[16:54] <kgunn> AlbertA: btw, n4 looked really good...i focused on phone calls/proximity sensor mainly
[16:55] <kgunn> i'll do n10 after lunch
[16:55] <AlbertA> kgunn: thanks for testing!
[16:59] <kgunn> davmor2: fix on its way for that
[16:59] <kgunn> http://bazaar.launchpad.net/~indicator-applet-developers/indicator-power/trunk.14.10/revision/244
[17:00] <davmor2> AlbertA, kgunn: So far music from the scope stops on screen blank and dim occurs before that, Music from the music player continues past screen blank and there is a dim before screen blank, Music video doesn't dim or screen blank while playing it does however on completion.  Need to test paused
[17:01] <davmor2> excellent so dims and blanks on pause too :)
[17:04] <kgunn> davmor2: right so music from scope is grooveshark right ?
[17:04] <kgunn> so its all behaving as expected
[17:04] <kgunn> e.g. groovesharked isn't white listed but music player is
[17:04] <davmor2> kgunn: no,  if you click on music from the carousel there is a play button on the scope
[17:05] <kgunn> going for run bbiab
[17:06] <davmor2> kgunn: currently I think it isn't whitelisted either so it's expected but I think it should be whitelisted as it is a nice way to play a single track
[17:12] <davmor2> screen reblanks on sms and calls and unblanks to display them \o/
[17:24] <AlbertA> davmor2: cool, so everything fine so far?
[17:25] <davmor2> AlbertA: seems to be so far yeap
[18:09] <kdub_> just fyi, usc has a medium-sized abi break with the SceneElement change
[18:29] <AlbertA> kdub_: I guess we should bump ABI now
[18:29] <AlbertA> camako: ^
[18:30] <kdub_> AlbertA, yep
[18:30] <davmor2> AlbertA, kgunn: okay so I've tested everything I can think of to do with time outs on n4 and n7 both look good
[18:30] <kdub_> AlbertA, with the power changes, will powerd-cli still work?
[18:30] <AlbertA> kdub_: yes
[18:30] <kdub_> great
[18:30] <AlbertA> only the keep display on part
[18:31] <AlbertA> davmor2: great thanks!
[18:33] <kdub_> AlbertA, meaning, 'powerd-cli display bright' won't work?
[18:33] <AlbertA> kdub_: yeah it will, it ignores everything after display basically
[18:34] <AlbertA> kdub_: so it will just keep the display on
[18:34] <kdub_> okay
[18:55] <Nothing_Much> Question, would Source engine games from Steam having problems with XMir have to be reported to launchpad?
[19:00] <kgunn> Nothing_Much: question for you, did you "disable" xmir and see if the same problem existed ?
[19:00] <kgunn> steam games should run in the traditional xstack unawares of the xmir config
[19:00] <kgunn> think x stack is your user session running on top of the system compositor xmir
[19:01] <Nothing_Much> kgunn: Yes I did, I removed xmir from my system and all was running well back on standard xorg
[19:02] <kgunn> Nothing_Much: in that instance, yeah, you could log a bug
[19:02] <Nothing_Much> By the way, I got a 10fps boost in the games :)
[19:02] <kgunn> cool
[19:02] <Nothing_Much> It just stutters every 5~20 seconds making the game annoying to play
[19:05] <kgunn> kdub_: so you gonna bump the server so name ?
[19:06] <kgunn> you could had an mp for that, make it a prereq to sceneelement changes
[19:06] <kdub_> I can, although I'm just the one who noticed :)
[19:07] <kgunn> kdub_: who's changes are they ?
[19:07] <kgunn> e.g. who's breaking abi ?
[19:07] <kgunn> ...i think camako wanted folks who break abi to take care of the bump when it happens
[19:08]  * kdub_ digs around
[19:08] <kgunn> which i agree with actually
[19:08] <kdub_> although in practice, that's trickier to know when ABI is broken
[19:09] <kgunn> kdub_: granted, builds will continue...but people should realize/know when they touch a public header...and just ask themselves, could i have possibly broken abi ?
[19:09] <kgunn> imho
[19:10] <kdub_> kgunn, yeah, I agree, but it would be nice if jenkins whined about it when we fail to notice :)
[19:10] <kgunn> true
[19:10] <AlbertA> kgunn: kdub_: yeah I was thinking about this the other day....
[19:11] <AlbertA> to have an automated abi check, kinda like android does with checkapi for the java apis
[19:11] <kgunn> AlbertA: mmm, not a bad idea...
[19:11] <AlbertA> kgunn: we could possibly generate a manifest as it its stand currently
[19:11] <kgunn> AlbertA:  a simple library that tests every func....
[19:12] <AlbertA> kgunn: maybe with some llvm tools...but in the worst case, manually
[19:12] <kdub_> kgunn, I think the new functions are racarr_'s and alf__'s on ms::Scene?
[19:12] <kgunn> kdub_: thanks...
[19:13] <kgunn> hey racarr_ ^ mind bumping server so for the abi break ?
[19:13] <AlbertA> basically have a map of interfaces that will need abi bumps
[19:13] <AlbertA> and a map of public apis
[19:13] <AlbertA> then with some script/tool magic diff that against the current mp/mr
[19:14] <kgunn> AlbertA: ...and make it part of CI ? ...to catch it in the mp submission ?
[19:14] <AlbertA> or for start it could at least be a script we can run manually
[19:14] <kgunn> i'd like that
[19:14] <AlbertA> but eventually yeah, in CI
[19:15] <AlbertA> I keep thinking there must be some tooling in llvm that can allows us to automate this
[19:16] <kdub_> oh kgunn, racarr_ sorry, misread, looks like its just the looks like alf__'s change
[19:16] <kgunn> racarr_: nevermind....we'll ask alf__ to do it :)
[19:17] <AlbertA> oh cool an abi/api checker: http://ispras.linuxbase.org/index.php/ABI_compliance_checker
[19:17] <kdub_> AlbertA, yeah I feel like I'm pretty prone to mis-step on 'bump the abi', a tool would help
[19:17] <kdub_> I guess I can build the stack semi-quickly now, maybe i'll just check with that
[19:18] <kgunn> kdub_: yeah!...give that tool a go
[19:18] <AlbertA> and it's already a debian package: pt-get install abi-compliance-checker
[19:34] <racarr_> kgunn: I dont mind doing it...I guess I break abi with cursor spike phase 4 too
[19:39] <racarr_> for now lunch during chromium build!
[20:19] <kgunn> racarr_: ok, just let me know...or let alf__ know :)
[21:43] <kgunn> alberto_: any idea what i need to make this complaint go away ?
[21:43] <kgunn> CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
[21:43] <kgunn>   Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
[21:43] <kgunn> i assume i'm missing some install
[21:44] <kgunn> ....i'm on the phone trying to build a demo app
[21:46] <kdub_> pkg-config
[21:47] <kdub_> kgunn^^
[21:48] <kdub_> is this one good to go? https://code.launchpad.net/~kdub/mir/hwc-device-test-cleanup/+merge/223978
[21:49] <racarr_> ok...over the main fix all the direct conflicts and understand the changes hump with chromium :)
[21:50] <racarr_> should be able to finish today and add touch/cursor support
[21:51] <kdub_> racarr_, the touch/cursor support isn't on by default, right?
[21:52] <racarr_> kdub_: Oh I meant touch and cursor support as
[21:52] <racarr_> in for chromium
[21:52] <racarr_> while I am working on it
[21:52] <racarr_> not
[21:52] <racarr_> cursor spots for touches
[21:52] <kdub_> ah, okay
[21:52] <racarr_> which...I will be returning too after chromium lol
[21:53] <kdub_> yeah, I just want to make sure its off by default (and no invisible layers sneak in)
[21:56] <racarr_> mm definitely
[22:02] <kgunn> kdub_: thanks!...its just a junk branch so doesn't have proper debian control and all that
[22:03] <kdub_> kgunn, yep, no problem
[22:37] <Nothing_Much> Woo, bug reported!