[00:42] <racarr__> RAOF: Ok so I am trying to send you the xmir changes on github...the thing is I had some issue with vladmir and the intel driver and you werent around so I ended up basing them just on the packaging source
[00:42] <racarr__> so now I am trying to port them to vladimir, well there isnt much to do, but anyway I think thats done
[00:42] <RAOF> racarr__: Ah, cool.
[00:43] <racarr__> but how ... should I build it lol
[00:43] <racarr__> i.e. what are some reasonable ./configure options
[00:43] <racarr__> because there is no deb dir in vladimir
[00:44] <RAOF> Hm. That's dropped out of my zsh history ;)
[00:44] <racarr__> oh no
[00:44] <racarr__> we will have to consult the sage atop X11 mountain.
[00:45] <RAOF> racarr__: But I'd just build it with --enable-xmir as a first go.
[00:45] <racarr__> ahahha ok
[00:45] <racarr__> I tried config.log and got ./configure --prefix=/usr --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --build=x86_64-linux-gnu lt_cv_prog_compiler_static_works=no lt_cv_prog_compiler_static_works=no --disable-silent-rules --disable-static --without-dtrace --disable-strict-compilation --enable-debug --enable-unit-tests --with-int10=x86emu --with-extra-module-dir=/usr/lib/x86_64-
[00:46] <racarr__> but it doesnt work
[00:46] <racarr__> presumably because of quotes but I havent found where to put them all yet
[00:46] <racarr__> lol
[00:48] <racarr__> hmm
[00:49] <racarr__> RAOF: I need a new xtrans presumably I need to update
[00:49] <racarr__> to utopic?
[00:54] <RAOF> racarr__: Hm, dunno, seems to work for me (on utopic) :)
[00:55] <racarr__> ok well enter the unicorn after meeting
[02:00] <racarr__> RAOF: Ok I am making a beeline for food then will send you patch that I expect to ork on vladmir and you can try it out
[02:01] <RAOF> Wickedcool.
[02:01] <RAOF> TO THE COFFEEOTRON!
[06:30] <RAOF> Are we going to be using EXPECT_THAT for all test expectations, rather than all of the various EXPECT_{GE,TRUE,WHATEVER} specialisations that exist?
[06:40] <duflu> RAOF: I hope not. Sometimes the latter is much clearer
[06:41] <duflu> Although people seem to be converting everything to the former
[06:44] <RAOF> Yeah. I'm not sure why EXPECT_THAT(foo(), Eq(true)) is any clearer than EXPECT_TRUE(foo()).
[06:49] <duflu> RAOF: Coming soon: Lots of EXPECT_DEATH in some of my new tests :)
[06:49] <duflu> and EXPECT_EXIT
[06:49]  * RAOF is a fan of EXPECT_DEATH
[06:49] <duflu> lol
[08:26] <anpok> hm seems like due to a change in initialization order the session manager gets an added surface before the input targeter / input registrar hence it complains that it cannot set the focs to that surface
[08:26] <anpok> (on one of my cleanup branches)
[08:32] <anpok> hm i think it happens in a different thread have to look again
[08:35] <alan_g> anpok: the SurfaceCoordinator ought to be coordinating the surface addition. (Although I was interrupted in that doing cleanup)
[08:37] <anpok> hm
[08:37] <anpok> the issue is actually different again
[08:38] <anpok> the moment I now register the input registrar (great names) as observer to the scene, at that moment nobody holds a strong reference to the scene yet
[08:39] <anpok> oh scene is not even part of the DisplayServer::Private
[08:40] <anpok> input dispatcher conf had one
[08:43] <anpok> should i make a small mp for DisplayServer::Private to hold the_scene() early in the initialization?
[08:44] <anpok> yes, mir::compositor::Scene seems to be wrong.. but that would be another (bigger?) change?
[08:45] <anpok> i wanted to say - we should have  mir::scene::Scene and it should look different..
[08:50] <alan_g> anpok: if you're writing something that needs the scene then why isn't that keeping a reference?
[08:51] <alan_g> It seems wrong to rely on "someone else" holding ownership for you
[08:51] <anpok> well it does not necissarily need the scene - it is something that is bridging information between the scene and what the droidinput::InputDispatcher sees
[08:51] <anpok> thats true
[08:52] <anpok> i find the entities that we store in DisplayServer::Private rather arbitrary
[08:52] <anpok> at the moment the objects there are objects that need to be informed about stop / start / pause
[08:53] <alan_g> They're the ones that the DS needs to start/pause/resume/stop
[08:53] <alan_g> That's not arbitrary
[08:53] <anpok> we could also make an abstraction for that .. a system state observer .. yes inverting that.. and react on state changes in the components
[09:00] <alan_g> anpok: does that help your current lifetime management issue?
[09:01] <anpok> no it might unveil further issue
[09:01] <anpok> *issues
[09:02] <anpok> i hestitated to add the scene to the registrar, because the interface of scene requires a shared ptr to register..
[09:02] <anpok> so I would have to do something odd like shared_from_this or well rely on the caller to register - just like before
[09:03] <anpok> with my statement above I wanted to stress that ownership (as a keep alive concept) and observation of changes should be somehow separate
[09:04] <anpok> and we could redefine the role of starting and stopping as something that needs subsrcription to a state change
[09:04] <anpok> and then we would have to define ownership separately and make it more explicit
[09:04] <anpok> and more fine grained...
[09:05] <alan_g> OK  I agree that if scene owns registrar then registrar can't also own scene
[09:06] <anpok> this is not a solution (explicit ownership) - just another problem :)
[09:06] <alan_g> But registrar could have a pointer to scene - as scene is guaranteed to outlive it
[09:06] <anpok> pointer?
[09:07] <alan_g> "SomeType*"
[09:07] <alan_g> registrar-scene(this)
[09:07] <alan_g> registrar->scene(this)
[09:11] <alan_g> Or just passing this to the function(s) that need it
[09:11] <alan_g> *"this"
[09:12] <anpok> then scene needs to know registrar - which it shouldnt since it is only an impementation detail introduced for droidinput inputdispatcher
[09:13] <anpok> yes, before the scene observer we had that reference to registrar inside the scene
[09:13] <alan_g> "the interface of scene requires a shared ptr to register"
[09:14] <anpok> to register an observer
[09:14] <anpok> not to the registrar (tm)
[09:15] <alan_g> Oh I misunderstood
[09:15] <duflu> Anyone else notice gdb crashes a lot now
[09:16] <duflu> It's really annoying
[09:16] <duflu> (?)
[09:16] <duflu> I just trying gdb gdb and it just shows a stack overflow (and no symbols)
[09:16] <alan_g> So there's the problem: registrar shouldn't implement Observer
[09:16] <alan_g> duflu: no
[09:17] <anpok> duflu: no gdb worked great recently
[09:17] <alan_g> It should "own" scene and register a distinct observer type
[09:17] <duflu> Hmm, RAOF was reporting the same problems...
[09:18] <anpok> havent updated... like at least for a week or so
[09:18] <anpok> alan_g: ok that would solve it
[09:19] <anpok> (just have to check who owns registrar)
[09:19] <alan_g> It also keeps to the single responsibility principle
[09:19] <anpok> hm ok the enumerator
[09:19] <anpok> which is then owned by the droidinput InputDispatcher
[09:20] <anpok> which is then owned by the mia::AndroidInputDispatcher..
[09:20] <duflu> Oh, it seems to be program-specific:
[09:20] <duflu>  mir_unit_tests --gtest_filter="FatalTest.*"
[09:20] <duflu> Gah
[09:20] <anpok> and then we are at DIsplayServer
[09:20] <anpok> ok
[09:20] <duflu> I mean:
[09:20] <duflu> Reading symbols from bin/mir_unit_tests...Segmentation fault (core dumped)
[09:20] <anpok> bbiab
[09:20]  * alan_g wonders if we could generate an "ownership" DAG for Mir
[09:20] <anpok> duflu: too many symbols - running out or memory? or broken memory?
[09:21] <anpok> alan_g: we could trace constructor calls in CachedPtr
[09:21] <anpok> with the symbol name underneath
[09:21] <anpok> or maybe it can be extracted from the symbol name of the functor somehow
[09:24] <duflu> alan_g: I've always thought DAG enforcement should be part of a super-shared_ptr
[09:24] <duflu> mir::sp::FTW
[09:24]  * alan_g was thinking build time, not runtime. And adding to the generated docs
[09:32] <anpok> libclang \o/ - now i am gone
[15:32] <greyback> Crazy idea, but is there a way to run mir in such a way that it doesn't connect to the hardware or composite anything, but clients could connect to it and make surface and stuff?
[15:33] <greyback> would be handy for testing IMO
[15:40] <anpok> greyback: there should be an offscreen option
[15:41] <alan_g> greyback: it isn't crazy - it is handy for testing
[15:43] <anpok> you could also disable input then the hosting server would not open any devices.. but it would also disable the dispatch of input hmm
[15:43] <anpok> what was the intention of the --enable-input option?
[15:44] <anpok> to not open input devices, or to not deal with input events of any source ...
[15:47] <greyback> anpok: alan_g: offscreen option on my desktop still tries to twiddle the VTs
[15:47] <greyback> mir_demo_server_shell --offscreen  =>  std::exception::what: Failed to find the current VT
[15:49] <alan_g> alf_: you're responsible for the offsceen option aren't you? ^^
[15:52] <alf_> greyback: alan_g: the offscreen support is rough still (proof of concept mostly, we were waiting from feedback from interested parties that never came)
[15:52]  * alan_g thinks we have a new "interested party"
[15:54] <anpok> and feedback
[15:54] <greyback> alf_: yeah, I'd like to have that ability for proper integration testing of unity-mir with mir
[15:54] <greyback> so in a test env, I can launch & stop apps
[15:54] <greyback> not a major request mind, but would be nice to have
[15:55] <alf_> greyback: ok, so what can we assume about the test environment in terms of display support (e.g. drivers with Mesa/GBM)?
[15:56] <alf_> greyback: also do you want to be able to get visual output e.g. through screencasting?
[15:58] <greyback> alf_: I guess my initial thought was a null display driver, so nothing gets drawn anywhere
[15:59] <anpok> greyback: and do you want it to open input devices / not open any devices but allow the dispatch of synthetic input events?
[16:00] <greyback> anpok: the latter option would be preferred
[16:01] <alf_> greyback: perhaps offscreen is not what you are looking for, but an even leaner dumb server (like the ones we use in the mir integration/acceptance tests)?
[16:01] <anpok> there is an option --enable-input that does the former, we could add one for the latter..
[16:01] <greyback> alf_: ah, what dumb server is this?
[16:02] <anpok> or what alf says - that one does what you want wrt to input testing
[16:03] <alf_> greyback: it's not an executable, it's a server configuration with the major components stubbed which we used to instantiate our various test server instances
[16:03] <alf_> greyback: tests/mir_test_framework/stubbed_server_configuration.cpp
[16:04] <greyback> alf_: sounds handy. Let me play with it. If I find it useful, I might request a package containing it so unity-mir's integration/acceptance tests can use it
[16:06] <greyback> alf_: anpok: thanks guys!
[16:06] <alf_> greyback: yw
[17:03] <anpok> greyback: or look at InputTestingServerConfiguration i believe it is the same plus a fake event hub plus the common input dispatching stuff
[17:04] <greyback> anpok: ah nice, thanks
[19:41] <racarr__> kdub_: Hey I replied to your comments on cursor-spike btw...fixed the style one...I think shared_ptr really is appropriate though
[19:41] <racarr__> because the idea is, surfaces will share ownership of the loaded cursor images
[19:42] <racarr__> so, if no one is interested in the magnifying glass image it goes away and on the other hand everyone has the same instance of the default image
[19:42] <racarr__> of course the loader can also implement caching by keeping its own strong references
[19:43] <kdub_> racarr__, I guess my thought was though that its strange that an observer gets ownership
[19:43] <kdub_> like, having the surface have ownership makes sense to me
[19:43] <racarr__> oh...for the observer! Aha maybe I misread your comment sorry...
[19:44] <kdub_> right
[19:44] <racarr__> Hmm.
[19:44] <racarr__> ok I think you are right
[19:45] <racarr__> will fix it up
[19:45] <racarr__> sometimes...im not sure what to do in these situations
[19:45] <racarr__> because just using shared_ptr EVERYWHERE can get costly
[19:45] <racarr__> but whenever I use a reference to something managed by a shared_ptr elsewhere
[19:45] <racarr__> I feel like I am laying a trap lol
[19:48] <racarr__> ok brb lunch
[19:48] <racarr__> ...I cant believe its 92 degrees
[19:48] <kdub_> racarr__, yeah, hot down here too, 100 tomorrow
[19:49] <bschaefer> racarr__, its 82 here :(, i want rain
[19:57] <racarr__> Yesterday it kind of made me like woozy and tired
[19:57] <racarr__> but today ive been drinking iced coffee all day
[19:57] <racarr__> and really like it
[20:00] <bschaefer> iced coffee....must ... get some now....
[21:50] <racarr__> the error message when you only pass 8 arguments to a mock that expects 9 can be quite
[21:50] <racarr__> fabulous
[21:51] <racarr__> I dont understand what ipc factory is for
[21:51] <racarr__> in order to add a new argument to session mediator constructor
[21:51] <racarr__> you have to change literally over 10 call sites/declarations
[21:52] <kgunn> anyone...i think i'm an over-user of clean (lots of scar tissue from symbian days...using reallyclean), whats kind of your rule of thumb do you make clean ?
[21:54] <racarr__> basically never
[21:54] <racarr__> I recenetly cleaned over 40 gigs of mir build dirs all at once though
[21:54] <racarr__> :p
[21:55] <racarr__> the only time I make clean is with qmake because...I have had several issues with it lol
[21:55] <racarr__> kdub_: Ok passing references in cursor phase 3 now
[22:01] <kdub_> racarr__, ack
[22:02] <racarr__> phase 4 incoming!
[22:02] <racarr__> lol
[22:02] <kdub_> yknow, i should start naming my branches 'phases'
[22:02] <kdub_> one less thing to name :)
[22:03] <racarr__> kdub_: http://xkcd.com/1296/
[22:03] <racarr__> MY HANDS ARE TYPING WORDS
[22:05] <kdub_> racarr__, lol, yeah
[22:07] <racarr__> kgunn: So if we were to wait on cursor API for 0.2 there is no point in waiting past phase 4 because at that point
[22:07] <racarr__> clients could use it etc
[22:08] <racarr__> still no themed image loaders, but they can request the images, disable the cursor, etc...it can be tested and once we add the image loader will all just work
[22:08] <racarr__> again im really not sure its worth waiting though if we release again in a week or something
[22:09] <racarr__> I dont think we really profit much from trying to get certain things
[22:09] <racarr__> in certain releases
[22:09] <racarr__> and it might be better to just have consistent fast releases
[22:35] <rsalveti> kdub_: interesting bug for you: bug 1319582
[22:35] <rsalveti> kdub_: basically, eglDestroySurface never gets called when starting/closing apps with ubuntu touch
[22:36] <rsalveti> and as a side effect, the window surface never gets released when running it on the emulator
[22:36] <rsalveti> as it allocates a host side gl window surface, and waits that call to happen for it to release it
[22:37] <rsalveti> kdub_: we're not calling eglDestroySurface because the app is just normally killed, without any special clean-up
[22:37] <kdub_> rsalveti, hmm
[22:37] <rsalveti> any idea on how this could be solved on the client side?
[22:38] <kdub_> make sure to clean up resources? :)
[22:38] <rsalveti> right, but which component should take care of that?
[22:38] <rsalveti> the system-compositor?
[22:39] <kdub_> which egl context is the one that's leaking?
[22:39] <rsalveti> when you open an app, it creates a surface and a color buffer
[22:39] <rsalveti> the color buffer is released just fine, but the surface never gets released
[22:41] <kdub_> I guess I don't know the brew of components in play well enough to reason to a solution...
[22:42] <rsalveti> tvoss: maybe you have an idea ^
[22:42] <kdub_> the emulator is running a mir instance, like usc+unity8, right?
[22:42] <rsalveti> kdub_: yeah, exactly as we have on a nexus device
[22:42] <rsalveti> but the egl/gles driver is a translator that uses your host gl
[22:42] <kdub_> and there's probably some sort of pass-through driver
[22:43] <kdub_> right
[22:43] <kdub_> but the translator is an android window surface, right?
[22:43] <rsalveti> https://code-review.phablet.ubuntu.com/gitweb?p=CyanogenMod/android_sdk.git;a=blob;f=emulator/opengl/DESIGN;hb=refs/heads/phablet-trusty
[22:44] <rsalveti> right, when you ask for a surface, it sends the message to your host, via qemu pipe, that then creates the surface
[22:44] <rsalveti> but for the client this is just a normal android surface
[23:39] <racarr__> OHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
[23:39] <racarr__> RAOF: Email incoming in 1 minute lol
[23:39] <RAOF> Wooot!
[23:42] <racarr__> RAOF: ok 0001-input.patch is a completely untested integration of it in to vladimir
[23:43] <racarr__> I mean not even compiled or really looked at lol, but who knows
[23:43] <racarr__> and then xmir-deb
[23:43] <racarr__> is the working xmir directory from my
[23:43] <racarr__> ubuntu xserver patched to work with it
[23:43] <racarr__> um.
[23:43] <racarr__> I did have to delete my input drivers to test it
[23:44] <RAOF> Bitchn'
[23:47] <racarr__> als o make sure to replace your xinput driver before rebooting, it can be really disorienting