[00:01] <racarr_> Yes sounds good
[00:14] <mterry> racarr_, it still seems fine without the unity-mir change...  It may still be a good change to make.  But the screen doesn't seem to come on at least even without it
[00:16] <racarr_> mterry: -.- ok well I will see if I can come up with a theory
[00:16] <racarr_> on that
[00:17] <racarr_> yay testing :D
[02:14] <RAOF> duflu: Actually, I think sequence numbers would be a superior solution all 'round.
[02:15] <RAOF> Also, how did operation: All The Documents go? :)
[02:15] <duflu> RAOF: Yeah, possibly. You need to have a good story for wrapping though
[02:15] <RAOF> My story for wrapping is uint64_t.
[02:16] <duflu> RAOF: Heh, I have thought the same before
[02:17] <duflu> RAOF: All the documents only turned out to be half the work I expected. And keeping a discussion in google doc comments helps to keep everyone on the same page (literally)
[02:17] <RAOF> That means you need to care about wrap around in ~30,000 milenia, given a client that makes 1000 requests/sec.
[02:19] <duflu> RAOF: I'm concerned that also assumes Mir won't be around when the next major jumps in computing power arrive
[02:19] <RAOF> In what way?
[02:20] <duflu> RAOF: The wrap around could still feasibly happen if someone runs the same code on a super machine 10 years from now
[02:20] <duflu> 10 years isn't much
[02:20] <RAOF> I don't think that's true.
[02:20] <duflu> But it does defer the problem nicely
[02:21] <duflu> Hah. We could just move to 128-bit numbers between now and then
[02:21] <RAOF> If a client makes 1×10⁶ requests/sec, wraparound is still in 30,000 years.
[02:21] <duflu> RAOF: You said 10^3 before
[02:21] <duflu> oh
[02:21] <duflu> years not millenia
[02:21] <RAOF> Yeah.
[02:22] <RAOF> And 1×10⁹ is wraparound in ~30 years.
[02:22] <duflu> We will need to build a pyramid to store the code and the computer in. They last kind of well
[02:24] <duflu> RAOF: There is a validation problem with 64-bit ints still. You need to know which values are valid handles. So to avoid the known set of valid handles growing unbounded you need to break the client API and introduce explicit handle destruction
[02:24] <RAOF> Why do you need to know which values are valid handles?
[02:25] <duflu> RAOF: Error checking so someone can't accidentally wait on an invalid one?
[02:25] <duflu> Also, you never know how many waits there will be on the same handle.
[02:25] <RAOF> It's not a handle now.
[02:26] <RAOF> I'm not sure that we need to validate wait handles; it'd be nice, sure, but it'd be a pretty obvious code bug.
[02:26] <duflu> RAOF: Each one still needs some state (signalled or not), even in the single-threaded waiter case. Otherwise you'd be racing waiter against signaller
[02:26] <RAOF> Ah, sorry. Let me clarify:
[02:27] <RAOF> mir_{connection,surface,whatever}_wait_sync_point(thing, sync);
[02:27] <RAOF> Needs no state other than a single integer in the object.
[02:28] <RAOF> It's signalled iff sync <= last_seen_seqnum.
[02:28] <RAOF> And MirSurface/MirConnection/MirWhatever can maintain the last_seen_seqnum internally.
[02:29] <RAOF> We don't even need to change protocol (although this does assume things about our protocol; namely that requests are processed in-order)
[02:31] <duflu> RAOF: That appears to only work for objects that are signalled in order. In reality you don't know the order they will be signalled in so need to store state with each one
[02:31] <duflu> Oh, the state is in MirSurface/MirConnection etc
[02:31] <RAOF> What objects are not signalled in order?
[02:32] <RAOF> Yeah. At the moment the state could be solely in MirConnection, but I think we'll want to have at least two request streams at some point, so they might as well be in the objects of interest.
[02:32] <duflu> RAOF: I'm thinking about a generic wait handle system. I guess there's no good reason why mirclient could not become explicitly ordered
[02:33] <duflu> RAOF: So actually each MirWaitHandle just gets its own counter
[02:33] <duflu> Or not.
[02:33] <duflu> Anyway, this is consuming my morning.
[02:33] <RAOF> :)
[02:34] <duflu> Jolly good luck improving all the things
[06:22] <RAOF> Dear valgrind: If you're going to exit claiming an error, it's polite if you make some attempt to inform me what the goddamned error is!
[06:50] <duflu> RAOF: I feel your pain from here
[06:50] <RAOF> I _think_ I've finally got _all_ the errors ironed out.
[06:51] <RAOF> Some by fixing honest leaks in our tests, some by adding more suppressions, and some by telling glib not to confuse valgrind with its memory management.
[07:00] <duflu> RAOF: Ah glib. It would be nice if we didn't have hard dependencies on big pieces like that
[07:02] <RAOF> Only the tests do.
[07:06] <duflu> RAOF: Indirectly from *umockdev* right?
[07:07] <duflu> That's a build-dep only
[07:07] <RAOF> Right
[07:16] <duflu> RAOF, mlankhorst: I notice some time in the past few months intel drm likes randomly losing vsync and tearing. Anyone else seen that?
[07:17] <duflu> -likes +"has started"
[07:17] <mlankhorst> nope :s
[07:17] <mlankhorst> think there might be a bug ab out it though
[07:18] <duflu> AFAIK, the page flip scheduling Mir uses should mean that Mir can't be responsible for causing it... (?)
[07:42] <hikiko> hello
[07:42] <RAOF> Hey!
[07:42] <hikiko> hi RAOF :)
[07:43] <RAOF> Has someone managed to figure out your nouveau problem yet?
[07:43] <hikiko> no :/
[07:44] <hikiko> but no prob, I had to remove nouveau anyway to debug something else with the proprietary driver
[07:45] <hikiko> btw could you tell me where I could find the most recent instructions on how to build mir and unity8 on the phone?
[07:45] <hikiko> (is nexus galaxy still supported?)
[07:46] <RAOF> I think it still works.
[07:46] <hikiko> cool :D
[07:47] <hikiko> so, are there any instructions on how to build everything on android?
[07:47] <RAOF> As for building for the phone, I always use cross-compile-chroot.sh in the Mir source tree to build Mir; I've not yet had to do a unity8 build, though.
[07:48] <hikiko> I'd like to test brandon's branch (an sdl demo), maybe I don't really need unity8
[07:49] <hikiko> but I'd probably need to do a fresh ubuntu installation
[07:50] <anpok> hikiko: AlbertA recently added a cross-compile-chroot.sh to unity-mir - which fixes the Qt cmake configuration files. I believe with that script unity8 should also build, when you update the build dependencies..
[07:50] <anpok> hmm .. maybe you also have to change some of the cmake library variables used from discovered build dependencies
[07:51] <hikiko> anpok, if I just follow these steps: https://wiki.ubuntu.com/Touch/Install
[07:51] <hikiko> I will only have unity8 and not mir?
[07:52] <anpok> both
[07:53] <hikiko> then since my phone is totally outdated I can "just" follow the instructions? I mean they are recent isn't it?
[07:55] <anpok> hm dunno, I tend to have all kinds of fun due broken usb cables
[07:57] <hikiko> haha :)
[07:58] <hikiko> let's confirm it in #ubuntu-touch then
[08:05] <duflu> hikiko, RAOF: Is that just Mir on nouveau? I can dig up a video card or two and test fairly easily
[08:08] <hikiko> duflu, I have a GeForce GT 440 with nouveau
[08:09] <duflu> hikiko: I should still have a couple of Nvidia cards around. But what am I testing?
[08:09] <hikiko> duflu, when I run the mir server basic or shell
[08:09]  * duflu also wants to see nouveau *still works*
[08:10] <hikiko> everything gets stuck (cant switch tty) and I get a message that gbm cant load the nouveau driver
[08:10] <hikiko> and this happens right after i start it so I dont have enough time to attach the process to gdb from ssh
[08:10] <hikiko> I ve seen that the error comes from mesa
[08:10] <hikiko> libgbm
[08:11] <hikiko> when we create the device
[08:11] <hikiko> but didn't search further
[08:11] <duflu> hikiko: OK, I'll try to test some cards soon.
[08:11] <hikiko> thanks duflu
[08:12] <duflu> hikiko: Got a bug number yet?
[08:13] <hikiko> no I will fill a bug report
[08:15] <hikiko> https://bugs.launchpad.net/mir/+bug/1210646 <- this might be relevant
[08:15] <ubot5> Ubuntu bug 1210646 in Mir "XMir doesn't work with Nouveau" [Medium,Incomplete]
[08:16] <hikiko> although in his case mir detects the driver
[08:18] <duflu> hikiko: I'm not sure that would be the same issue. Please log a new one: https://bugs.launchpad.net/mir/+filebug
[08:27] <hikiko> https://bugs.launchpad.net/mir/+bug/1291851 duflu
[08:27] <ubot5> Ubuntu bug 1291851 in Mir "Mir server can't load the nouveau driver when it's starts." [Undecided,New]
[08:27] <duflu> hikiko: Cool, thanks
[09:07] <RAOF> How much do we care that the memcheck test is garbage on the CI hardware?
[09:07] <RAOF> (As in: the test always passes, because the command is malformed)
[09:08] <alf__> RAOF: How do you mean? We know we don't catch leaks, but at least memory errors were reported.
[09:08] <duflu> RAOF: Depends if we can actually make it pass. For armhf that may be nontrivial
[09:09] <alf__> RAOF: (don't catch leak = don't fail on leaks)
[09:09] <RAOF> alf__: I mean that “3/9 Test #3: memcheck-test .......................   Passed    0.01 sec” passes because the command is malformed.
[09:09] <RAOF> The test of our memchecker :)
[09:10] <alf__> RAOF: We care :) How is it malformed?
[09:11] <RAOF> alf__: Build locally, enable memcheck and disable gtest detection. The test log will show that valgrind doesn't run, because the commandline is malformed. But, happily, we're checking for failure, so that passes.
[09:12] <RAOF> duflu: Also, https://code.launchpad.net/~raof/mir/udevify-eventhub/+merge/210348 shows that we _can_ make it pass on armhf with fail-on-leak. :)
[09:16] <RAOF> alf__: See http://paste2.org/6UP8wzIY
[09:18] <alf__> RAOF: Hmm, where does all this come from? Changes by a CI script?
[09:19] <alf__> RAOF: (probably judging by /home/chris/...)
[09:19] <RAOF> alf__: It comes from cmake/MirCommon.cmake, mir_add_memcheck_test() being broken
[09:20] <RAOF> Specifically, because CMake's variable handling is a legion of fail.
[09:21] <RAOF> ${VALGRIND_ARGS} is a list, which expands to a semicolon-delimited list in some circumstances, such as when we're trying to pass them to sh -c.
[09:21] <alf__> RAOF: We don't have many of the options from that output in our pristine codebase in VALGRIND_ARGS
[09:21] <RAOF> It works in the other codepath because it's cmake interpreting the list, and it does it correctly.
[09:21] <RAOF> Oh, that's true.
[09:22] <RAOF> I think we have enough options to trigger the problem though. Let me check!
[09:22] <alf__> RAOF: that's why I think it's probably some CI script changing something
[09:24] <alf__> RAOF: but yeah, I think you are right, we do have that problem even with just our own options
[09:25] <alf__> RAOF: how can cmake be so broken...
[09:26] <RAOF> Buildsystems.
[09:27] <RAOF> Mess with people's brains.
[09:27] <alf__> RAOF: please file a bug then and I can take a look if you don't have a solution yet
[09:27] <RAOF> alf__: Sure. I've bashed my head on this one enough I think :/
[09:29] <anpok> hm in one case VALGRIND_ARGS is meant to be a list is, in the other case we want it to be have as a string
[09:29] <RAOF> Yes.
[09:29] <anpok> -is
[09:31] <anpok> so string (REPLACE ";" " " VALGRIND_ARGS_AS_STRING "${VALGRIND_ARGS}")
[09:31] <anpok> should work
[09:32] <anpok> of course only when the args dont have ; inside :)
[09:32] <RAOF> :)
[09:35] <RAOF> alf__, anpok: Enjoy 1291876
[09:36] <RAOF> Or even bug# 1291876
[09:36] <RAOF> bug #1291876
[09:36] <ubot5> bug 1291876 in Mir "memcheck-test doesn't test anything when DISABLED_GTEST_DISCOVERY is enabled" [Undecided,New] https://launchpad.net/bugs/1291876
[09:40] <alf__> RAOF: anpok: cmake => "string types ought to be enough for everybody" (but let's hack lists in them too!)
[09:41] <RAOF> Well, either string types or lists would be fine.
[09:42] <anpok> hm internally I believe they treat them as separate types..
[09:42] <RAOF> But they've managed to make it so that ADD_TEST(foo "String of stuff") doesn't work, because "String of stuff" is attempted to be run as an executable verbatim, and you can't trivially escape "s.
[09:43] <RAOF> (For some absolutely bizzare reason, when I tried "\\\"" it ended up in the CTest file as "/""
[09:43] <anpok> hehe
[09:44] <alf__> anpok: I don't know: "In CMake all variables are of the type string. Nevertheless CMake can deal also with lists. If a string contains semicolons, these semicolons can be interpreted as separators of string values. "
[09:44] <anpok> ah
[09:44] <RAOF> Oh!
[09:44] <RAOF> You know how we could fix this?
[09:45] <RAOF> By not trying to use cmake here!
[09:47] <anpok> the issue is only on armhf, because append items to the string?
[09:48] <RAOF> No, the issue is everywhere.
[09:52] <RAOF> Ok.
[09:52] <RAOF> I think I know what to do.
[09:53] <RAOF> I'll take Zoe out to the park for a bit, come back, and see if I really do.
[09:56] <anpok> hm why dont I see leak-check=full
[09:58] <anpok> have fun
[09:58]  * anpok crawls back into his cave
[12:48] <RAOF> YES! I (finally) win a CI run of udevify-eventhub that would fail on leaks but doesn't, because we don't leak. And passes on all our architectures. And doesn't have glib confuse valgrind seven ways to Sunday.
[13:07] <mlankhorst> or are you certain of that?
[13:08] <mlankhorst> you probably sneaked a 'void *malloc(size_t sz) { static char buf[8 * 1024 * 1024]; return buf; }' in somewhere
[13:08] <mlankhorst> :P
[13:11] <RAOF> I'm surprised how much glib confuses valgrind.
=== pete-woods1 is now known as pete-woods
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader
=== TheDrums is now known as DalekSec
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader