[02:12] <RAOF> Hm. I really need to fix keymapping before using the unity8 desktop session :)
[05:01] <Sarvatt> RAOF: you and your dvorak..
[05:02] <RAOF> :P
[06:47] <RAOF> Bah.
[06:47] <RAOF> C++, why you no map (list)?
[06:58] <duflu> RAOF: Wha/
[06:58] <duflu> ?
[06:58] <RAOF> duflu: I want to iterate over the result of applying a function elementwise to an existing iterator.
[06:59] <RAOF> Without constructing an unnecessary container.
[06:59] <RAOF> This would typically be called “map’
[06:59] <RAOF> Or possibly “apply”
[07:00] <duflu> RAOF: Temporary results in a loop you don't wish to modify to accept  an apply functor?
[07:01]  * duflu feels dirty for knowing what that means
[07:04] <RAOF> I'd like to construct a list of SharedLibraries from a directory iterator
[07:05] <RAOF> Now, I can do this by iterating over the directory, constructing the SharedLibrary, and shoving it into the list.
[07:05] <RAOF> But I'd *prefer* to just pass an iterator to the list constructor.
[07:11] <duflu> RAOF: I think most real-world problems involve picking and choosing from lists, and not a blind 1:1 mapping. As such, there's little re-use value in C++ providing that for you.
[07:11] <duflu> Besides, C++ is already massive in spec
[07:12] <RAOF> Well, that's very simple
[07:12] <RAOF> map(filter(thing, predicate), functor) :)
[07:12] <RAOF> Basically I wish iterators were substantially more powerful, because it's really awesome to be able to operate on them.
[07:13] <duflu> I wish iterators had a common base class and weren't a pure pattern
[07:14] <mzanetti> hey, anyone aware of efforts to make freeglut run on mir? I think its just the input part that uses XInput. The rest seems to be ok already.
[07:14]  * mzanetti was trying to compile VoltAir on the phone
[07:16] <duflu> mzanetti: I remember the simplicity of GLUT fondly. Would be nice but not aware of any efforts
[07:17] <mzanetti> mhm...
[07:17] <RAOF> duflu: _Yes_
[08:23] <RAOF> alan_g: No, my blocking comments weren't addressed. On the other hand,  https://code.launchpad.net/~raof/mir/fix-unnecessary-virtual-package/+merge/227862 is simple and resolves them :)
[08:24] <alan_g> RAOF: sorry. I got the incantation I used from both fginther and sil2100 so I let the majority rule.
[08:25] <RAOF> alan_g: Yeah, that's totally reasonable.
[08:25] <RAOF> I clearly need to poke sil2100 and fginther with a cluebat :)
[08:30] <alan_g> RAOF: the more I get to understand the debian/control file the more I feel we've got wrong. Is that normal?
[08:31] <RAOF> Not normal, no.
[08:31] <RAOF> Hm. Now that I look at it...
[08:34]  * alan_g goes to look at a problem he does understand
[08:35] <RAOF> Excellent plan!
[08:36]  * RAOF → dinner
[11:40] <greyback> anpok: hey just checking in, any progress with https://bugs.launchpad.net/mir/+bug/1346952
[12:06] <kdub_> hey folks
[12:15] <Saviq> alan_g|lunch, hey, I'll join you for the interview with Jawad, sit in on your part and then do mine when you'll be relieved ;)
[12:27] <anpok> greyback|lunch: debugging it - so yes reproducing the issue..
[12:57] <alan_g|lunch> Saviq: ack
[14:31] <racarr_> Good morning!
[14:44] <groot_> racarr_, evening :)
[14:44] <groot_> I need some help compiling mir
[14:45] <racarr_> groot_: ok! Lets give it a go! What are you trying so far?
[14:46] <groot_> racarr_, I'm trying to follow the cross-compile section of this http://unity.ubuntu.com/mir/building_source_for_android.html
[14:47] <groot_> just changed saucy to utopic
[14:48] <groot_> also downloaded mir tarball from here http://bazaar.launchpad.net/~mir-team/mir/0.5/revision/1792?start_revid=1792
[14:50] <groot_> hope it's ok. I'm now confused with cross-compiler. Shoul I try install g++-arm-linux-gnueabihf/utopic ?
[14:51] <racarr_> Is your desktop trusty?
[14:51] <racarr_> I'm not 100% sure you can crosscompile from trusty to utopic
[14:51] <racarr_> kdub_: ^?
[14:51] <groot_> unfortunately yes
[14:51] <racarr_> hmm
[14:51] <kdub_> doesn't work as well as you'd like it to sometimes
[14:51] <racarr_> I dunno maybe someone will say they have dsone it and it works but my guess i\s no...I didn't think you could install the utopic G++
[14:52] <racarr_> groot_: If you don't want to upgrade your system...probably building on the phone itself is your best option
[14:54] <groot_> racarr_, wouldn't that take more time ? Also how can I compile in phone (native compile?)? Cross-compile seemed easier.
[15:00] <groot_> kdub_, how can I compile now? I want to test your fix :)
[15:00] <kdub_> its more of an experiment
[15:01] <kdub_> but native on-the-phone compile is slow, but you don't have to set up cross compiling
[15:01] <racarr_> groot_: rCompile in phone../.isn't the fastest lol
[15:01] <racarr_> from the phone, you first have to apt-get build-dep mir
[15:01] <racarr_> then you just get the mir build directory and build it like normal
[15:01] <racarr_> mkdir build; cd build; cmake .. -DMIR_PLATFORM=android;
[15:01] <racarr_> make
[15:01] <racarr_> oh
[15:01] <racarr_> standup
[15:02] <groot_> racarr_, I don't have net connection in phone :(
[15:03] <greyback> racarr_: question on Mir's client buffer queue scheme: say client is starting up and Mir allocates it 3 buffers. Client draws its first frame and swaps. Does the compositor render that frame, or the 2 other yet-to-be-drawn-into frames have to be rendered first
[15:04] <racarr_> greyback: The compositor should render that frame I think
[15:04] <racarr_> the only requirement is that there is always a buffer available for the compositor
[15:04] <racarr_> groot_: Hmm presumably we can get it for you with
[15:05] <racarr_> adb or something
[15:05] <greyback> racarr_: ok ta
[15:06] <groot_> racarr_, I'll do it. Give me the commands serially :D
[15:07] <racarr_> groot_: I am just thinking...there is no obvious waya (to me) gimme just a minute...I need to listen to some other stuff too lol
[15:07] <groot_> racarr_, no problem. Take your time.
[15:13] <racarr_> groot_: I dont really know...there must be some trick to get USB networking working
[15:13] <racarr_> but I dont know it or the magic incantation to reveal it on google :p
[15:14] <racarr_> so I can't really suggest anything better than downloading the deps and copying them over to phone...
[15:14] <racarr_> you need a net connection lol
[15:14] <racarr_> No wifi? :(
[15:14] <anpok> galf_: how did you switch to 4.9 with arm-linux-gnueabihi-g++
[15:15] <anpok> alf_: ^ :)
[15:17] <alf_> anpok: added '-4.9' to cmake/LinuxCrossCompile.cmake
[15:17] <anpok> ah :)
[15:21] <groot_> racarr_, ohh :(. I don't know whether wifi is running or not. Is there a way I can access it through terminal ? I use router in my house so connecting will not be a probelm.
[15:22] <racarr_> groot_: if you run phablet-network on the host system it will copy over your
[15:22] <racarr_> wifi config to desktop
[15:22] <racarr_> if you are using that
[15:22] <racarr_> if not...you will have to use wpa_supplicant or some such to connect to wifi via terminal
[15:22] <AlbertA> greyback: right it will draw that latest ready frame
[15:22] <racarr_> connecting to wifi on desktop then using
[15:23] <racarr_> phablet-network sounds easiest
[15:23] <greyback> AlbertA: thanks for confirming
[15:23] <AlbertA> greyback: it will not wait to fill the queue
[15:29] <groot_> racarr_, I'll try now and let you know.
[15:32] <racarr_> groot_: :)
[15:32] <racarr_> lol....46 files modified for touchspots
[15:32] <racarr_> that...
[15:32] <racarr_> doesn't seem quite right
[15:37] <groot_> racarr_, I don't use wifi in my desktop, desktop has broadband connection which is connected through router. So, there'll be config, right ?
[15:50] <racarr_> groot_: Yeah...
[15:50] <racarr_> you will have to google like...connecting wifi terminal, sort of stuff :p I don't remember the exact options, etc
[15:50] <racarr_> if you have wifi encryption you will need to use
[15:50] <racarr_> wpa_supplicant
[15:50] <racarr_> its pretty easy
[15:57] <tvoss> groot_, you want nmcli
[15:58] <racarr_> oh that sounds true :p
[16:00] <groot_> tvoss, how to use it ?
[16:01] <tvoss> nmcli --help gives you an overview
[16:01] <tvoss> groot_, should be something nmcli device wifi connect WIFI_NAME
[16:02] <tedg> dednick, When I pass the FD to the helper I set MIR_SOCKET to "fd://%d", right?
[16:02] <groot_> tvoss, alright I'll give it a try.
[16:03] <tvoss> tedg, yup
[16:04] <tedg> tvoss, Hmm, okay.
[16:04] <tedg> Is there a way to get QtUbuntu to give more info than this: QUbuntu: Could not create application instance
[16:10] <groot_> tvoss, connected to wifi, but speed is slow :)
[16:11] <groot_> racarr_, how to compile mir? please give me the commands serially :)
[16:11] <dednick> tedg: passing to the trust helper? or the prompt provider?
[16:12] <tvoss> groot_, I cannot help with the speed
[16:12] <tvoss> groot_, in the mir root directory, call dpkg-buildpackage
[16:12] <tvoss> groot_, that likely will fail with a list of missing build dependencies that you have to install
[16:12] <dednick> tedg: you need to pass the trusted socket to the helper, and the new_fd_for_prompt_provider sockets to the providers.
[16:12] <tedg> dednick, Yes, to the prompt provider.
[16:13] <tedg> dednick, So passing that socket to the provider as "fd://%d"
[16:13] <dednick> tedg: yup
[16:15] <groot_> tvoss, where's the mir directory? It's not in the root directory.
[16:15] <tvoss> groot_, you have to branch mir by calling bzr branch lp:mir
[16:16] <groot_> tvoss, I've the files in pc.  Push them will do ?
[16:16] <racarr_> yeah
[16:16] <racarr_> groot_: ^
[16:17] <racarr_> then; cd <into-the-mir-source-directory>; mkdir build; cd build; cmake .. -DMIR_PLATFORM=android; make
[16:17] <racarr_> wait patiently
[16:17] <racarr_> :)
[16:19] <tedg> dednick, Good, know any reason that QtUbuntu couldn't create an application instance then?
[16:22] <groot_> racarr_, alright :)
[16:25] <groot_> racarr_, this error happened http://paste.ubuntu.com/7842738/
[16:31] <dednick> tedg: check unity8 logs?
[16:32] <dednick> anything saying rejected?
[16:32] <dednick> tedg: did you start the trust helper with trusted socket?
[16:32] <tedg> No, it's not saying rejected.
[16:33] <tedg> Think I must have the wrong number.
[16:36] <groot_> racarr_, I think I've to install 14.10 on desktop :P
[16:37] <racarr_> groot_: It looks like you forgot the apt-get build-dep mir part
[16:39] <groot_> racarr_, you're right!!! I forgot you mentioned that. I'll give this another go.
[16:42] <racarr_> brb in ~20
[16:52] <groot_> racarr_, still got error " You must put some 'source' URIs in your sources.list". List doesn't contain the package
[17:13] <racarr_> groot_: apt-get update
[17:13] <racarr_> should take care of it
[17:18] <groot_> racarr_, OK, I'll try again tomorrow. I've to go now.  Thanks for helping me.
[17:20] <AlbertA> camako: kgunn: so there's a bug that already has a fix on devel...
[17:20] <AlbertA> https://bugs.launchpad.net/mir/+bug/1347789
[17:20] <AlbertA> camako: kgunn: should that be backported to the 0.5 series?
[17:25] <kgunn> AlbertA: yep...we will need thta
[17:25] <kgunn> that
[17:41] <kdub_> here's a fun one
[17:41] <kdub_> https://bugs.launchpad.net/mir/+bug/1347828
[17:46] <racarr_> kdub_: For me that doesn't even qualify as a fun in the sense of like this is a nice hairy one bug
[17:46] <racarr_> and more of just a "off to the crying closet"
[17:46] <racarr_> type bug
[17:46] <racarr_> failed acquire CCB space
[17:46] <racarr_> lol
[17:47] <racarr_> lol
[17:47] <racarr_> not to mention ScheduleTA "didnt work properly"
[17:47] <kdub_> yes, very informative :)
[17:47] <racarr_> E/IMGSRV ( 3519): :0: KEGL_SGXDestroyRenderSurface: Timeout failed on waiting for previous render op
[17:48] <racarr_> is kind of interesting
[17:48] <racarr_> kdub_: Perhaps it has something to do with fences
[17:48] <racarr_> i.e. like
[17:48] <racarr_> surface is being destroyed
[17:48] <racarr_> before the actual rendering of the last frame
[17:48] <racarr_> finishes
[17:49] <racarr_> E/IMGSRV ( 3519): :0: FreePDSFragBuffers: PDS fragment buffer for render surface still in useE/IMGSRV ( 3519): :0: FreePDSFragBuffers: PDS fragment buffer for render surface still in use
[17:49] <kdub_> something, im' thinking some resource problem perhaps around contexts
[17:49] <kdub_> but we'll just see
[17:49] <racarr_> :)
[17:50] <racarr_> good luck :D
[17:57] <AlbertA> aahhh the good old KickTA...
[18:03] <racarr_> :( I want to write...
[18:04] <racarr_> constexpr size_t size = someMirGeometrySizeWidth*height*MIR_BYTES_PER_PIXEL(pixel_format)
[18:05] <racarr_> (where the geometry and pxiel format are constant as well)
[18:06] <racarr_> so that I can then write uint32_t pixels[pixel_size] {} and use automatic storage so that {} can be used to initialize the whole thing to black
[18:06] <racarr_> I mean...lol it's purely a matter of conveniencee
[18:06] <racarr_> but unfortunately can not use
[18:06] <racarr_> IntWrapper with
[18:06] <racarr_> constexpr
[18:06] <racarr_> because it's not a http://en.cppreference.com/w/cpp/concept/LiteralType
[18:07] <racarr_> oh maybe it coudl be though
[18:07] <racarr_> I don't really understand the deep details of constexpr lol
[18:25] <racarr_> lunnnch
[18:26] <josharenson> random question, does/will mir support SDL?
[18:26] <racarr_> josharenson: Yes!
[18:26] <josharenson> woo hoo!
[18:26] <racarr_> courtesy of bschaefer
[18:27] <racarr_> who can help with issues and such im sure.
[18:27] <racarr_> 95% sure it's SDL2 only
[18:27] <racarr_> whatcha up to?
[18:27] <josharenson> thanks, no issues, just wondering if I'll be able to play old games
[18:31] <bschaefer> josharenson, you wont be able to play SDL 1.2 atm (until some layer gets put into place)
[18:31] <bschaefer> josharenson, but anything for SDL2 will work with mir!
[18:32] <josharenson>  bschaefer thats awesome, thanks
[18:32] <bschaefer> (if you really want to mess with SDL1.2 + mir you'll need this branch: https://code.launchpad.net/~brandontschaefer/+junk/sdl1.2-mir)
[18:33] <bschaefer> they aren't accepting patches for 1.2 soo yeah
[18:33] <bschaefer> josharenson, np!
[19:22] <racarr_> kdub: How should I implement mga::Buffer::write(void*,size_t)
[19:22] <racarr_> I'm open to the idea that I shouldn't
[19:22] <racarr_> lol
[19:22] <racarr_> I just can't remember which android thing has which
[19:23] <racarr_> for the touchspots, which end up being kind of like single buffered software clients
[19:23] <racarr_>  / cursor
[19:25] <racarr_> oh I see. gralloc_module_t :)
[19:35] <kdub_> racarr_, I guess I'd want to avoid it
[19:35] <anpok> is there a way to verify expectations added to a mock at the end of a scope?
[19:36] <anpok> rather let the test fail unless expectations are met..
[19:36] <kdub_> racarr_, you mean like mg::Buffer::write()?
[19:36] <kdub_> anpok, you can verify explicitly
[19:36] <kdub_> like Mock::VerifyAndClearExpectations()
[19:43] <racarr_> kdub_: Yeah
[19:43] <racarr_> to upload cursor images in to the buffer
[19:47] <kdub_> racarr_, the pain there is all the pixel formats
[19:47] <kdub_> so like, on the client side, we have a way to map it and return the address, but spare the client side buffer the pain of regulating all the pixel format stuff
[19:49] <kdub_> like, the intention is to?
[19:50] <anpok> kdub_: hmm it never fails
[19:50] <racarr_> I guess I should look at how the client side works on android
[19:52] <kdub> racarr_, like, whats the outer loop? to write to a cursor on the server side?
[19:53] <racarr_> the outer loop?
[19:54] <kdub> like, the larger picture of what having Buffer::write would accomplish
[19:54] <racarr_> oh yes
[19:54] <racarr_> to write to a cursor on server side.
[19:55] <racarr_> write seems like a good choice because 1. they are always small buffers. 2. on mesa you can't even create GL contexts from the cursor buffer.
[19:55] <kdub> ah
[19:59] <kdub> so, its probably a little easier to structure like
[19:59] <kdub> the platform has some writer object
[20:01] <racarr_> I thought about that for a bit but coudln't think of
[20:02] <racarr_> alternate implementations, is it easier?
[20:02] <kdub> yeah, just because iirc, the mga::Buffer doesn't have access to the gralloc mapping stuff anymore
[20:03] <kdub> whereas the platform could just keep the gralloc as a singleton
[20:04] <kdub> or... even I guess that there could be a mg::Buffer::write(std::vector<Pixels>const&) and android could do a gl draw under the hood? (and mesa would just do the memcpy)
[20:05] <robotfuel> kgunn:  do you know a good person I can ask to triage this unity8 crash? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1347886
[20:07] <kdub> racarr_, I guess I'm not feeling strongly that one is better than the other :)
[20:08] <kdub> other than it probably has to be behind the platform abstraction, and we should have stronger types than void* for the pixels we want to use
[20:08]  * kdub dreams of bool mir::PixelFormat::ABGR8888::premultiplied()
[20:11] <kgunn> robotfuel: i'd like alf_ to take a look at that tomorrow....
[20:12] <kgunn> it looks like it might be mir related
[20:15] <kgunn> robotfuel: do you know which image that is/was ?
[20:16] <robotfuel> kgunn: yesterday's proposed image
[20:16] <kgunn> robotfuel: ok so something like ~143
[20:16] <kgunn> robotfuel: any chance we understand/know what the device was doing ? or was this just random monkey ?
[20:17] <robotfuel> kgunn: version_detail: ubuntu=20140722.1,device=20140717.1,version=144
[20:17] <robotfuel> kgunn: it was the random monkey :/
[20:20] <kdub> kgunn, robotfuel what about https://code.launchpad.net/~mir-team/mir/fix-1335481-0.5/+merge/227497 ?
[20:20] <kdub> seems somewhat in the same ballpark
[20:22] <robotfuel> kdub: it looks very close +1
[20:25] <racarr_> kdub: sorry lol...alt tabbed and then....distraction
[20:25] <robotfuel> kdub: I've added that to the bug, thanks
[20:26] <racarr_> yeah I was thinking maybe android could do the GL draw under the hood....its probably easiest to use some sort of writing thing I guess though...with the android platform
[20:26] <racarr_> and yeah....there are enough instances of void *pixels now
[20:26] <racarr_> ill start looking in to something better lol
[20:28] <racarr_> Hahahahahaha
[20:28] <racarr_> I just tested the touchspots on the phone in
[20:28] <racarr_> demo server shell
[20:28] <racarr_> and they have
[20:28] <racarr_> window decorations
[20:28] <racarr_> forgot about that
[20:29] <racarr_> hmm what am I going to do there
[20:33] <robotfuel> kgunn: it looks like this one is also a mir issue https://bugs.launchpad.net/ubuntu/+source/+bug/1347901
[20:35] <kgunn> robotfuel: ah crap i can't see it...
[20:35] <kgunn> robotfuel: is there something i can do to see these bugs by default
[20:36]  * kgunn vaguely remembers mail from duflu
[20:37] <robotfuel> kgunn: my copy paste glitched https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1347901
[20:37] <robotfuel> that should work
[20:38] <robotfuel> kgunn: "void mir::client::rpc::MirSocketRpcChannel::send_message(const mir::protobuf::wire::Invocation&, const mir::protobuf::wire::Invocation&)" is what I see in the trace
[20:39] <robotfuel> it doesn't look like it was able to complete the whole stack trace :/
[20:41] <kgunn> robotfuel: following the link, looks there may be enough tho... kdub that one looks like its eminating from android platform possibly ??
[20:43] <kdub> kgunn, I was looking at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1347886
[20:46] <kdub> and this one https://errors.ubuntu.com/problem/3f606cde0c8ce2787f2a2ae3ed4b1a73738d975e
[20:47] <kdub> the stack passes through the android code, but it looks like it throws somewhere around the ipc stuff, I'd say that looks like a different one
[20:47] <kdub> oh, actually, i guess if the server was asserting and failing
[20:48] <kdub> then maybe the client is just saying "wheres my server" in that stack trace
[21:32] <tedg> kgunn, Silo 6 with the QtComp doesn't seem to start for me. Does it need to be rebuilt after the gcc build?
[21:32] <kgunn> tedg: make sure you install ubuntu-touch
[21:32] <kgunn> also add proposed to your sources list
[21:33] <kgunn> tedg: i put a note at the top of the wiki....its been frustrating a lot of folks
[21:33] <kgunn> https://wiki.ubuntu.com/Unity8/QtComp
[21:33] <kgunn> i updated the instructions
[21:33] <kgunn> silo 8 is gumming up the works
[21:35] <tedg> Ah, k
[22:13] <racarr_> ok touchspots are 95% done except the fact that they receive
[22:14] <racarr_> window decoprations
[22:14] <racarr_> going outside for a little bit (been at desk since 7 lol...ordered lunch in)
[22:14] <racarr_> then will be back to work on that
[23:06] <racarr_> back
[23:24] <racarr_> thomi: Are touchspots black on orange or purple on orange or black on purple or black or
[23:24] <racarr_> red on yellow
[23:24] <racarr_> :p
[23:24] <thomi> racarr_: huh?
[23:25] <thomi> bzr diff
[23:25] <thomi> oops
[23:25] <racarr_> I mean has anyone already
[23:25] <racarr_> picked the colors
[23:25] <thomi> nope
[23:25] <thomi> something bright I guess
[23:25] <racarr_> ok
[23:25] <racarr_> ubuntu orange + black outline
[23:26] <thomi> sounds good to me
[23:26] <thomi> that'll match those fancy videos the design team produce :)