/srv/irclogs.ubuntu.com/2013/06/04/#ubuntu-mir.txt

RAOFrobert_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
thomihmm, 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
thomirobert_ancell: got a second?01:57
robert_ancellthomi, sure01:58
thomirobert_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_ancellthomi, as long as it works fine it should be good to start merging01:59
thomiwell, As of today, it would fail MPs, but that's because mir leaks FDs again01:59
thomiwhich seems to be a recurring problem01:59
thomiso it might cause you some grief, but in a good way :)02:00
thomirobert_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 disruptive02:01
* thomi shrugs02:01
robert_ancellthomi, worth proposing now, so it can get reviewed early02:01
thomiok02:01
robert_ancellthomi, 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 is03:53
robert_ancellI mean lp:~lightdm-team/lightdm/trunk-packaging03:53
thomithat sounds like the "old" way distro used to do packaging.03:54
thomiI'll investigate, one sec03:54
thomirobert_ancell: yeah, in time we should probably regenerate that, but I believe you should be abel to update the build-dep in that branch fine03:55
thomijust ignore all the other files :)03:56
robert_ancellthomi, ok, cheers03:56
robert_ancellI just push directly right? i.e. no MP03:56
thomirobert_ancell: yep03:56
robert_ancellthomi, and I don't need to update debian/changelog?03:57
thomirobert_ancell: ideally we'd have inline packaging, but I understand why that's not an option here03:57
thomirobert_ancell: nope, shouldn't need to03:57
robert_ancellyeah, I've been trying to think of a better method, but ultimately there will be some Ubuntu specific things that would have to diverge03:57
thomiyeah03:57
thomiyou could perhaps still make upstream release tarballs without the debian/ directory?03:58
robert_ancellI could (and would)03:58
robert_ancellRAOF, 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_ancellI 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 difficult04:54
RAOFI'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
RAOFFailing that, it's an environment variable, or possibly just $RUN/user/mir/socket04:56
robert_ancellRAOF, is there a potential case of having more than one Mir server to connect to?04:58
RAOFI can't think of any reason why a user would want more than one Mir session active at one time.04:59
robert_ancellRAOF, 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_ancellI'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
RAOFEh, we write “mir-run” which is a trivial wrapper around a shell DBus API to get an app spawned.05:00
robert_ancellAlso, I guess even in case 1 you would have to pass an env variable to the app to give it the fd number05:00
RAOFNo?05:01
robert_ancellI'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_ancellhard code 3=mir socket?05:01
robert_ancellyou can't introspect fds in any way can you?05:01
RAOFfd 3 would always be the mir socket, in the same way that fd 0-2 are always stdout, sterr, stdin.05:01
robert_ancellunless we screw something up and another fd gets inserver05:02
robert_ancellinserted05:02
RAOFCorrect.05:02
RAOFBut then that'd be a problem with sending the fd number as an environment variable anyway.05:02
robert_ancellI couldn't think of a problem..05:03
RAOFWell, 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
RAOFYou know, we could also get this over dbus.05:06
RAOFBut that's probably overthinking it.05:08
robert_ancellRAOF, 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 305:09
RAOFrobert_ancell: It could fork(), close(3), then open the mir connection, which should then be fd 3?05:10
robert_ancellRAOF, 3 might be something else that it does need to pass on, e.g. some pipe for something05:10
robert_ancellI guess you could dup and close, but it seems nicer to just be explicit05:11
RAOFYeah, I guess.05:11
RAOFI 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_ancellyeah, that05:12
robert_ancell's what I'm hoping05:12
robert_ancellRAOF, is that still what Wayland is doing afayk?05:13
RAOFI think so, yes.05:13
RAOFThe well-known-fd option is cool, but probably overkill ;)05:14
robert_ancellRAOF, pff, I don't even trust stderr to be 2, I use STDERR_FILENO05:17
=== dpm-afk is now known as dpm
=== greyback|away is now known as greyback
alan_galf_: 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_galf_: thanks for thinking it through - I don't think that would be worth doing.10:38
alan_gI was more thinking of removing the direct dependencies on lttng - not the program specific stuff generated10: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
racarrMorning15:12
alan_gAfternoon15:15
kgunnalf_: ping15:23
alf_kgunn: pong15: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
racarrlol...17:18
racarrtried not drinking caffeine for a while this morning to see what would happen17:18
racarrnow halfway through coffee...*twitch*17:18
racarrI think17:23
racarrI don't know when exactly.17:24
racarrBut we should adopt17:24
racarrubuntu::Event as MirEvent17:24
racarrThe current codepath on the client is kind of embarasing:17:25
racarrread 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 QEvent17:26
racarrElegance: ^17:26
racarrkdub_: An interesting point about the C->C++ layer in the client library and the lack of testing17:28
racarrthe same problems17:28
racarrprevent platorm-api-mirclient from having good unit tests17:29
racarrbecause 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 testing17:29
kdub_and there are some oblique data paths that have popped up17:29
racarrIgnoring for  second the idea of getting rid of mirclient17:30
racarrit could be made more testable.17:30
racarri.e.17:30
racarrwe introduce a "ClientConfiguration" which lets you mock the machinery (i.e. MirConnection) etc.17:30
racarrand there is private API like17:30
racarrmir_connect_with_configuration17:30
racarr(mir_connect calls this with default_configuration)17:31
racarrthough 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 those17:34
kdub_src/client/default_connection_configuration.cpp17:35
racarrkdub_: I don't have that file ;)17:39
racarrare you sure you didn't write it today17:40
racarruint32_t ua_ui_display_query_horizontal_res17:48
racarrI wonder if someone will hate us for that in a decade17:49
racarr"Unity crashes when I enable by second 214748364817:49
racarrpixel monitor"17:49
racarr...feels pretty unlikely17:50
kdub_racarr, its a newer file... http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/client/default_connection_configuration.h17:51
kdub_maybe a merge will bring it in17:51
racarrlol, it requires over 256 exabytes per second of bandwidth to drive a monitor that overflows 32 bit resolution17:51
racarrwith 32 bit color depth17:51
racarrthat17:51
racarrcant be true17:52
racarranyway enough of that17:52
racarrkdub_: Ohhh17:52
racarrbeautiul17:52
racarrit came in alfs stuff17:52
racarrI guess17: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
kgunnracarr: 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 confirm20:17
kgunnkdub_: mind joining #ubuntu-unity20:41
kdub_oh sure.. .should add that one to my autojoin channels too!20:42
racarrkgunn: Merr. Sorry. Comcast strikes again.21:43
racarrYes pretty much any evdev device seems to be the case21:43
racarrthere 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 though23:28
racarrI 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!