[00:00] <RAOF> Who'd object to a little helper class for passing std::funcition<> as a function pointer? :)
[00:02] <RAOF> Only slightly terrifying.
[02:15] <robert_ancell> RAOF, did you upload glmark2 directly to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004?
[02:17] <RAOF> robert_ancell: I did, yes.
[02:17] <robert_ancell> ok, cool
[02:18] <robert_ancell> RAOF, and the vivid package goes to the overlay PPA when this landing is accepted?
[02:18] <RAOF> Yeah, that's my understanding.
[02:19] <robert_ancell> RAOF, so I just pushed the updated xmir in xorg-server into this PPA. What does this mean for the git branch for xorg-server?
[02:20] <RAOF> robert_ancell: You should update the wily branch in git. And probably create a vivid-overlay branch, unless you've just uploaded the wily xorg to vivid.
[02:21] <robert_ancell> RAOF, well, I can't upload this to wily because we don't have the new Mir there yet
[02:21] <RAOF> But the landing PPA will be syncd to wily...
[02:21] <RAOF> Maybe ask tjaalton what he'd like, though.
[02:25] <robert_ancell> I was requested to put xorg-server in the landing. Don't know why we need it there..
[02:26] <RAOF> I think we bumped client ABI, so it needs a rebuild at least.
[02:26] <robert_ancell> yeah, but it would be easier to just do it post hitting wily
[02:28] <RAOF> Yeah, but then untested code is hitting wily!!!!111111
[02:58] <RAOF> Ah.
[02:59] <RAOF> It's always helpful when exceptions are silently discarded, and the only visible result is that everything locks up...
[03:00] <RAOF> *Of course* wayland buffer stride is in pixels, mir buffer stride is in bytes.
[03:48] <duflu_> RAOF: I had a similar issue yesterday. Found a way for my client to make the server segfault but it was hidden. That's a regression of bug 1237332 that Alan intentionally made :(
[03:48] <duflu_> Well, related bug
[03:49] <duflu_> The problem is the "fix" for bug 1285084. We should not have fixed it at all.
[04:33] <anpok_> hm could you also upload that for vivid?
[04:33] <anpok_> robert_ancell: ^ that = xorg-server
[04:33] <anpok_> or is the version different?
[04:34] <robert_ancell> anpok_, I have been trying to but it keeps rejecting the upload. I think we have to give it a special version number so it doesn't complain about two versions.
[04:35] <RAOF> Yeah, you can't upload the same thing to two different series.
[04:48] <robert_ancell> ok, uploaded as 2:1.17.1-0ubuntu5~vivid
[05:02] <duflu> If only there was a way to make libmirclient8 and libmirclient9 both official at the same time. Then most downstreams would not need updating immediately
[05:03] <duflu> You can have both installed at once. Just not both in the distro at once, kind of, except for the release!=proposed period
[05:15]  * RAOF wants to set fire to GLibMainLoop.
[05:15] <RAOF> But will instead head to the shops.
[06:20] <anpok_> hm we still could resurrect the asio loop
[06:21] <RAOF> It's not *that* bad :)
[06:21] <anpok_> duflu: scroll down.. there is predictive user input! http://blog.mattbierner.com/stupid-template-tricks-super-template-tetris/
[06:22] <anpok_> well .. picking up idle tasks from dead instances..
[06:22] <anpok_> provoking fancy invalid instruction crashes ..
[06:22] <RAOF> Heh.
[06:23] <anpok_> asio only has face palms and odd hand wavings..

[06:25] <duflu> asio is a four letter word. But seriously, I've never seen asio do anything worth using in production. It's generally terrible.
[06:25] <duflu> Way over-complicated and not even documented in a way that makes it comprehendable
[06:26] <duflu> My first encounter with asio was its regex library (which compiled to multiple megabytes and caused some compilers grief). So I replaced it with something 10kb in size
[06:26] <duflu> Thus, asio is often and generally a joke
[06:27] <duflu> A bad joke people keep telling
[06:27] <RAOF> Anyone feel like adding some utility code for turning a std::function into a raw function pointer?
[06:28]  * duflu needs to see the outside world for a little while at least once today
[06:29] <anpok_> asio has no regex but .. i guess you mean xpressive .. which is very expressive..
[06:29] <anpok_> RAOF: hm how raw?
[06:29] <RAOF> anpok_: Passable-to-C raw.
[06:29] <RAOF> It's perfectly possible if you don't mind generating the trampolines.
[06:29] <anpok_> so .. void call_it(void*) ?
[06:29] <duflu> anpok_: Sorry I meant boost is generally terrible. Asio is part of boost, no?
[06:30]  * RAOF would just *really* like to be able to pass some bound member functions to a C interface.
[06:30] <duflu> But asio is worse than the boost average even
[06:30] <anpok_> hm it is simpler if you dont use std::function in between..
[06:31] <RAOF> anpok_: Hm. Howso?
[06:32] <anpok_> hm .. ok nah doesnt matter much because you have to pass in objects anyhow..
[06:32] <anpok_> i just thought you could get away with encoding everything inside the type
[06:32] <RAOF> I... don't think so?
[07:02] <anpok_> ah you cannot move it
[07:10] <anpok_> RAOF: http://paste.ubuntu.com/11814229/ something like that?
[07:11] <anpok_> one could do it fancier if I knew how to extract the signature from a lambda
[07:12] <anpok_> ... i.e. avoid the functio.. but on the other hand the c code does not take ownership of the function<..> so the creator needs to keep it alive.. and for that function seems to be a good pick
[07:16] <RAOF> anpok_: Na, something more like http://paste.ubuntu.com/11814245/
[07:18] <RAOF> Was what I was thinking of, but your simpler thing might be enough for what I'm considering.
[07:18] <RAOF> And involves less runtime codepatching.
[07:19] <anpok_> hm but you need the address somwhere.. unless of course if you squeeze the adress of the functio<>  into a symbol with external..
[07:19] <anpok_> then it can be a template param..
[07:19] <anpok_> *external linkage
[07:21] <RAOF> No, no. It's simple. You have a static thunk with a placeholder guard value; you copy the code into memory your trampoline object owns, adjust the guard value to point to the std::function<> that your trampoline object owns, and then return that :)
[07:21] <anpok_> hehe yeah simple
[07:22] <RAOF> Not portable, of course, but the number of segmented memory architectures we care about can be counted on the fingers of one fish.
[07:22] <anpok_> thats what encoding the address of the function into a template param would do..
[07:22] <anpok_> function<>
[07:24] <RAOF> Hm. How could you do that?
[07:25] <RAOF> Or, at least do that in a way that doesn't require a type+external singleton per trampoline?
[07:25]  * RAOF goes to get some fish.
[08:02] <anpok_> RAOF: http://paste.ubuntu.com/11814351/ .. enough fun..
[11:57] <greyback_> anpok_: ping
[11:58] <anpok_> pong
[12:03] <greyback_> anpok_: hey, need your help testing usc with your mir overrideorientation work. Can you check out lp:~unity-team/unity-system-compositor/toggle-cursor2/ please
[12:04] <greyback_> I'm running it, and wanting to test the dbus method
[12:04] <greyback_> (install qdbus-qt5)
[12:05] <greyback_>  sudo qdbus --system  com.canonical.Unity.Screen / com.canonical.Unity.Screen.overrideOrientation 0 2
[12:05] <greyback_> is the call I'm using. The first param is the display id, the second is the desired orientation
[12:06] <greyback_> anpok_: aha, I'm an idiot
[12:06] <greyback_> ignore me
[13:21] <anpok_> greyback_: which channel do you use as a basis for silo-000
[13:22] <greyback_> anpok_: rc-proposed
[13:24] <anpok_> i guess I have to reflash
[13:24] <anpok_> it is just getting hot while showing the logo
[13:25] <ogra_> anpok_, MX4 ?
[13:25] <anpok_> n4
[13:25] <ogra_> oh
[13:26] <anpok_> i guess it was my fault
[13:26] <anpok_> .. dist-upgrade instead of citrain script .. or installing  them individually
[13:27] <ogra_> yeah, the citrain script turns off access to the archive
[13:27] <ogra_> so you only get PPA contents
[13:27] <ogra_> if you do a normal dist-upgrade you will get archive bits along