| RAOF | robert_ancell: Not really opposed, but I think it should be low priority (and so not shown by default on install). If someone adds the PPA, they probably want the system compository. | 00:02 |
|---|---|---|
| thomi | hmm, so in the last three days something changed in mir, and now I once again get file handle leaks, which prevent the mir-stress tests from running. | 00:13 |
| thomi | robert_ancell: got a second? | 01:57 |
| robert_ancell | thomi, sure | 01:58 |
| thomi | robert_ancell: I think that, even in it's uncompleted state, mir-stress is useful enough to be run on merge proposals. To achieve this, I need to get it merged into trunk. Do you see any issues with me merging it into lp:mir and continuing to work on it from there? (i.e.- after it's run on all MPs?) | 01:58 |
| robert_ancell | thomi, as long as it works fine it should be good to start merging | 01:59 |
| thomi | well, As of today, it would fail MPs, but that's because mir leaks FDs again | 01:59 |
| thomi | which seems to be a recurring problem | 01:59 |
| thomi | so it might cause you some grief, but in a good way :) | 02:00 |
| thomi | robert_ancell: the other thing is that from next Monday (the 10th), I'm on holiday for 2 weeks, so perhps it's better to wait until I get back.. or maybe we pick a strategy so even if it causes problems it won't be too disruptive | 02:01 |
| * thomi shrugs | 02:01 | |
| robert_ancell | thomi, worth proposing now, so it can get reviewed early | 02:01 |
| thomi | ok | 02:01 |
| robert_ancell | thomi, is lp:lightdm-trunk-packaging supposed to contain all the lightdm project files? I need to add a new build-dep, not sure what the correct way to update this branch is | 03:53 |
| robert_ancell | I mean lp:~lightdm-team/lightdm/trunk-packaging | 03:53 |
| thomi | that sounds like the "old" way distro used to do packaging. | 03:54 |
| thomi | I'll investigate, one sec | 03:54 |
| thomi | robert_ancell: yeah, in time we should probably regenerate that, but I believe you should be abel to update the build-dep in that branch fine | 03:55 |
| thomi | just ignore all the other files :) | 03:56 |
| robert_ancell | thomi, ok, cheers | 03:56 |
| robert_ancell | I just push directly right? i.e. no MP | 03:56 |
| thomi | robert_ancell: yep | 03:56 |
| robert_ancell | thomi, and I don't need to update debian/changelog? | 03:57 |
| thomi | robert_ancell: ideally we'd have inline packaging, but I understand why that's not an option here | 03:57 |
| thomi | robert_ancell: nope, shouldn't need to | 03:57 |
| robert_ancell | yeah, I've been trying to think of a better method, but ultimately there will be some Ubuntu specific things that would have to diverge | 03:57 |
| thomi | yeah | 03:57 |
| thomi | you could perhaps still make upstream release tarballs without the debian/ directory? | 03:58 |
| robert_ancell | I could (and would) | 03:58 |
| robert_ancell | RAOF, do you know of any other method to communicate the Mir socket to clients other than via a MIR_SOCKET env variable? | 04:53 |
| robert_ancell | I guess in theory we could give the socket the shell and it could pass it on via some clever method but it seems it would make things overly difficult | 04:54 |
| RAOF | I'm still partial to “the shell opens a mir connection before spawning the client, and when it is spawned fd 3 is ready to connect to Mir” | 04:55 |
| RAOF | Failing that, it's an environment variable, or possibly just $RUN/user/mir/socket | 04:56 |
| robert_ancell | RAOF, is there a potential case of having more than one Mir server to connect to? | 04:58 |
| RAOF | I can't think of any reason why a user would want more than one Mir session active at one time. | 04:59 |
| robert_ancell | RAOF, the problem with option 1, is you can't run an app from a terminal ever (unless we make some clever opt-in API to the shell) | 04:59 |
| robert_ancell | I'm working on LightDM support for Mir sessions, but given they only exist in theory it's kind of hard to write test cases for :) | 04:59 |
| RAOF | Eh, we write “mir-run” which is a trivial wrapper around a shell DBus API to get an app spawned. | 05:00 |
| robert_ancell | Also, I guess even in case 1 you would have to pass an env variable to the app to give it the fd number | 05:00 |
| RAOF | No? | 05:01 |
| robert_ancell | I'm assuming at the moment that whatever the solution there will be an env variable set - and I can base tests off that variable (and make the daemon set it) | 05:01 |
| robert_ancell | hard code 3=mir socket? | 05:01 |
| robert_ancell | you can't introspect fds in any way can you? | 05:01 |
| RAOF | fd 3 would always be the mir socket, in the same way that fd 0-2 are always stdout, sterr, stdin. | 05:01 |
| robert_ancell | unless we screw something up and another fd gets inserver | 05:02 |
| robert_ancell | inserted | 05:02 |
| RAOF | Correct. | 05:02 |
| RAOF | But then that'd be a problem with sending the fd number as an environment variable anyway. | 05:02 |
| robert_ancell | I couldn't think of a problem.. | 05:03 |
| RAOF | Well, it's the same sort of problem as “what if we leave another fd open as fd 3”, right? | 05:04 |
| RAOF | “What happens if we screw up and the fd number we set in the environment doesn't match the actual fd?” | 05:05 |
| RAOF | You know, we could also get this over dbus. | 05:06 |
| RAOF | But that's probably overthinking it. | 05:08 |
| robert_ancell | RAOF, ok, a specific case would be if an app was launching another app and had to pass on the fd - the next fd available might not be 3 | 05:09 |
| RAOF | robert_ancell: It could fork(), close(3), then open the mir connection, which should then be fd 3? | 05:10 |
| robert_ancell | RAOF, 3 might be something else that it does need to pass on, e.g. some pipe for something | 05:10 |
| robert_ancell | I guess you could dup and close, but it seems nicer to just be explicit | 05:11 |
| RAOF | Yeah, I guess. | 05:11 |
| RAOF | I suspect that we'll probably end up with $XDG_RUNTIME_DIR/mir/socket, or whatever $MIR_SOCKET points to if that's set. | 05:12 |
| robert_ancell | yeah, that | 05:12 |
| robert_ancell | 's what I'm hoping | 05:12 |
| robert_ancell | RAOF, is that still what Wayland is doing afayk? | 05:13 |
| RAOF | I think so, yes. | 05:13 |
| RAOF | The well-known-fd option is cool, but probably overkill ;) | 05:14 |
| robert_ancell | RAOF, pff, I don't even trust stderr to be 2, I use STDERR_FILENO | 05:17 |
| === dpm-afk is now known as dpm | ||
| === greyback|away is now known as greyback | ||
| alan_g | alf_: looking at client-rpc-report-lttng - and wondering (without thinking too deeply) that it would be nice to avoid having different client & server shared libs for lttng support. Would that require reworking the TRACEPOINT_* magic? | 10:22 |
| alf_ | alan_g: thinking... | 10:23 |
| alf_ | alan_g: I think this is doable. We would need to create a single SO containing the tracepoint provider sources (*_tp.*) from both client and server. This means that server produces mirserverlttng.a, the client produces mirclientlttng.a, and at some point (in shared?) we create a libmirlttng.so from these two. | 10:37 |
| alf_ | alan_g: However, it does create some complications in terms of packaging, and also it couples the client and the server object-file-wise. | 10:38 |
| alan_g | alf_: thanks for thinking it through - I don't think that would be worth doing. | 10:38 |
| alan_g | I was more thinking of removing the direct dependencies on lttng - not the program specific stuff generated | 10:39 |
| * alan_g will be offline for a few minutes while he moves to the garden "office" | 10:42 | |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === mmrazik is now known as mmrazik|otp | ||
| === mmrazik|otp is now known as mmrazik | ||
| racarr | Morning | 15:12 |
| alan_g | Afternoon | 15:15 |
| kgunn | alf_: ping | 15:23 |
| alf_ | kgunn: pong | 15:23 |
| === mmrazik is now known as mmrazik|afk | ||
| racarr | "Finished" new platform API mirserver. Coffee break! | 16:52 |
| === alan_g is now known as alan_g|life | ||
| racarr | lol... | 17:18 |
| racarr | tried not drinking caffeine for a while this morning to see what would happen | 17:18 |
| racarr | now halfway through coffee...*twitch* | 17:18 |
| racarr | I think | 17:23 |
| racarr | I don't know when exactly. | 17:24 |
| racarr | But we should adopt | 17:24 |
| racarr | ubuntu::Event as MirEvent | 17:24 |
| racarr | The current codepath on the client is kind of embarasing: | 17:25 |
| racarr | read droidinput::InputMessage off the wire. Copy to droidinput::InputEvent, copy to MirEvent, send to platorm API, copy to Ubuntu event (99% identical with mir event...but not memcpy identical XD), send to toolkit, copy to QEvent | 17:26 |
| racarr | Elegance: ^ | 17:26 |
| racarr | kdub_: An interesting point about the C->C++ layer in the client library and the lack of testing | 17:28 |
| racarr | the same problems | 17:28 |
| racarr | prevent platorm-api-mirclient from having good unit tests | 17:29 |
| racarr | because you can't meaningfully mock the machinery of the client library, so you would have to mock the whole server, or just run a server or whatever. | 17:29 |
| kdub_ | right, its like oblique testing | 17:29 |
| kdub_ | and there are some oblique data paths that have popped up | 17:29 |
| racarr | Ignoring for second the idea of getting rid of mirclient | 17:30 |
| racarr | it could be made more testable. | 17:30 |
| racarr | i.e. | 17:30 |
| racarr | we introduce a "ClientConfiguration" which lets you mock the machinery (i.e. MirConnection) etc. | 17:30 |
| racarr | and there is private API like | 17:30 |
| racarr | mir_connect_with_configuration | 17:30 |
| racarr | (mir_connect calls this with default_configuration) | 17:31 |
| racarr | though I don't even know what I want to test here and if that helps me ;) | 17:32 |
| kdub_ | i thought we had one of those | 17:34 |
| kdub_ | src/client/default_connection_configuration.cpp | 17:35 |
| racarr | kdub_: I don't have that file ;) | 17:39 |
| racarr | are you sure you didn't write it today | 17:40 |
| racarr | uint32_t ua_ui_display_query_horizontal_res | 17:48 |
| racarr | I wonder if someone will hate us for that in a decade | 17:49 |
| racarr | "Unity crashes when I enable by second 2147483648 | 17:49 |
| racarr | pixel monitor" | 17:49 |
| racarr | ...feels pretty unlikely | 17:50 |
| kdub_ | racarr, its a newer file... http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/client/default_connection_configuration.h | 17:51 |
| kdub_ | maybe a merge will bring it in | 17:51 |
| racarr | lol, it requires over 256 exabytes per second of bandwidth to drive a monitor that overflows 32 bit resolution | 17:51 |
| racarr | with 32 bit color depth | 17:51 |
| racarr | that | 17:51 |
| racarr | cant be true | 17:52 |
| racarr | anyway enough of that | 17:52 |
| racarr | kdub_: Ohhh | 17:52 |
| racarr | beautiul | 17:52 |
| racarr | it came in alfs stuff | 17:52 |
| racarr | I guess | 17:52 |
| === Cimi_ is now known as Cimi | ||
| === Cheery_ is now known as Cheery | ||
| === olli__ is now known as olli | ||
| === mmrazik|afk is now known as mmraazik | ||
| === mmraazik is now known as mmrazik | ||
| === Stskeepz is now known as Stskeeps | ||
| kgunn | racarr: kdub_ does the android input stack support pretty much any evdev device ? | 20:17 |
| kdub_ | my understanding is yes, but i'll for racarr to confirm | 20:17 |
| kgunn | kdub_: mind joining #ubuntu-unity | 20:41 |
| kdub_ | oh sure.. .should add that one to my autojoin channels too! | 20:42 |
| racarr | kgunn: Merr. Sorry. Comcast strikes again. | 21:43 |
| racarr | Yes pretty much any evdev device seems to be the case | 21:43 |
| racarr | there are all sorts of weird defines for like ...the right pedal axis, or the left rudder lol. | 21:44 |
| racarr | *stretches* platform API server/client 2.0 are "finished" save for a sensors enabled hybris build, that's just one last bit of wiring for tomorrow though | 23:28 |
| racarr | I think I just wrote roughly 100 3-4 line functions *cringe* | 23:29 |
| === csslayer_ is now known as csslayer | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!