| racarr_ | ...has anyone ever felt the desire to lay out code horizontally | 01:35 |
|---|---|---|
| racarr_ | I have this big stub class...and for a second I was imagining laying out all the functions in a grid | 01:36 |
| racarr_ | then remembered how code works lol | 01:36 |
| RAOF | Hah | 01:37 |
| racarr_ | it would be nice though | 01:40 |
| racarr_ | lol | 01:40 |
| racarr_ | in other news mi::InputTargets -> mi::Scene | 01:40 |
| RAOF | It might be nice to code as the AST. There's no particular reason that a big string of text should be the canonical representation for the program. | 01:47 |
| racarr_ | lol...one day im not going to be able to use emacs anymore :( | 02:11 |
| duflu | racarr_: Only a few days ago I was commenting on that. At some point in the past decade or so a trend of horizontal coding (long identifiers, long lines) started to become quite visible in some circles like ours. | 03:04 |
| duflu | Previously people read code vertically, the most obvious origin being assembly | 03:04 |
| duflu | I say in some circles because other projects like the kernel, vertical structure dominates and 80 character lines are still enforced | 03:06 |
| * duflu recalls the most extreme case in Compiz where Sam wrote several functions whose names exceeded 80, even 100 characters | 03:08 | |
| duflu | RAOF: Come to think of it, yes there is a reason for code to be linear. It reduces the ease with which you can create spaghetti | 03:13 |
| duflu | P.S. Go rest | 03:13 |
| racarr_ | duflu: Lol. I don't just mean...long lines though | 03:42 |
| racarr_ | I mean like what if you could have two functions next to eachother | 03:42 |
| duflu | racarr_: Yeah OK. Like windows without windows | 03:42 |
| racarr_ | yeah | 03:42 |
| racarr_ | window management | 03:42 |
| racarr_ | for source code | 03:42 |
| racarr_ | lol | 03:42 |
| * duflu 's head explodes | 03:42 | |
| duflu | Whee, ssh works again on phablets. Life just got easier | 03:44 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Man there's a *lot* of faffing involved in adding logging to our stuff. | 05:23 |
| RAOF | Which would be why we have abysmal logging. | 05:23 |
| duflu | RAOF: I've counted 3 logging systems in Mir recently | 05:35 |
| duflu | :) | 05:35 |
| RAOF | Oh, really? | 05:35 |
| RAOF | But mostly contained to 3rd_party, right? | 05:36 |
| * duflu checks | 05:36 | |
| RAOF | We've got the *_report thing for our own code. I can't think of a separate logging mechanism in pure-mir code. | 05:36 |
| RAOF | The android code has some different logging. | 05:37 |
| racarr_ | I agree on the report interfaces | 05:37 |
| racarr_ | and I think thats | 05:37 |
| racarr_ | err, not sure how to phrase it.. it's quite late | 05:37 |
| racarr_ | but when we discussed lttng in malta | 05:37 |
| racarr_ | I mean lttng isnt an alternative implementation of logging right | 05:37 |
| racarr_ | and its not useful as such | 05:37 |
| racarr_ | you want the probes in different sort of points | 05:37 |
| racarr_ | rather than trying to use it as a low overhead printf | 05:37 |
| racarr_ | so | 05:38 |
| racarr_ | one of the main drives of using reporting interfaces is gone there. | 05:38 |
| racarr_ | and then I think...well...if some logging really is REQUIRED | 05:38 |
| racarr_ | perhaps it can be in a reporting interface and tested lol | 05:38 |
| racarr_ | but I love logs | 05:38 |
| racarr_ | I love logs | 05:38 |
| racarr_ | so much | 05:38 |
| racarr_ | I love logs of everything | 05:38 |
| duflu | (1) Android ALOGx() macros which call (2) mir::write_to_log() which is a stub; and (3) The cleaner logging in src/shared/logging used in reports | 05:39 |
| racarr_ | so I would rather have lots of adhoc logging | 05:39 |
| duflu | I think everything should funnel back to (3) | 05:39 |
| racarr_ | than tested reports :p | 05:39 |
| duflu | racarr_: I mean we should merge the underlying log function of them all | 05:39 |
| duflu | ... er both., | 05:39 |
| RAOF | I don't mind everything going through reports, but if that's what we want, then we need (a) lots more reports, (b) lots more functions in the reports, and (c) for the output of those reports to go somewhere by default. | 05:40 |
| RAOF | We should, by default, log on the order of 500 lines for standard start up. | 05:40 |
| duflu | The Report pattern is nice (yes I think so now) because you can do expensive reporting that's disabled by default | 05:40 |
| racarr_ | duflu: That too :p | 05:40 |
| duflu | That's different to always-on log messages | 05:41 |
| racarr_ | that could be | 05:41 |
| duflu | Both are good | 05:41 |
| racarr_ | log domains... | 05:41 |
| racarr_ | i.e. the cateogires could be prefined | 05:41 |
| racarr_ | I think its more pain than its worth to have a method on a report interface for each kind of method | 05:42 |
| racarr_ | I mean not only is it a pain but its often useful to log implementation details of classes | 05:42 |
| duflu | I like include/shared/mir/logging/logger.h more than the others, but it can all be improved | 05:42 |
| racarr_ | which may not line up with some sort of generic report... | 05:42 |
| racarr_ | lalala | 05:43 |
| duflu | I think "Logger" is a bad abstraction. It should be a "Log" interface to which you "write" | 05:43 |
| duflu | #define MIR_LOGGING_LOGGER_H_ http://www.youtube.com/watch?v=mL7n5mEmXJo | 05:45 |
| RAOF | To the mailing list? :) | 05:47 |
| duflu | RAOF: Sure. Happy to see some unification. So long as we keep the nice timestamps and formatting of the src/shared logger | 05:47 |
| RAOF | Oh, we'd totally do that. | 05:47 |
| duflu | Which I recall I copied from Xorg to some extent | 05:48 |
| duflu | Or the kernel? | 05:48 |
| duflu | RAOF: Erm, actually just assign mir::write_to_log = &my_new_function_that_writes_to_Logger | 05:49 |
| duflu | And then they're unified :) | 05:50 |
| RAOF | I think both, actually. | 05:50 |
| RAOF | IIRC Xorg copied that logger from the kernel :) | 05:50 |
| alf_ | alan_g: Hi! @fix-libmircommon, What was the problem with the MIR_COMMON_LIBRARIES approach? | 08:48 |
| alan_g | alf_: try doing "nm libmircommon.so" ;) | 08:49 |
| alf_ | alan_g: That's quite unexpected... What's the rationale behind cmake not linking in the static libraries into the shared library? | 09:06 |
| alan_g | I don't know. If you *just* force them all to be linked then the android-input archive causes problem. | 09:08 |
| alan_g | Having discovered that I decided there wasn't much point to the individual archives | 09:08 |
| === shuduo is now known as shuduo_afk | ||
| duflu | alan_g: The subordinate modules of mircommon should be "add_library(foo OBJECT ...)" so they don't produce archives and are guaranteed to be fully included in the final shared library | 09:44 |
| duflu | It would be quite nice to not have those *.a lingering in the lib/ directory | 09:45 |
| duflu | alan_g: I might do that this evening if you're not | 09:46 |
| alan_g | duflu: that's a cmake incantation I've no come across. Is there an example of how to use it? | 09:46 |
| duflu | alan_g: It's newish: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:add_library | 09:47 |
| duflu | Designed for making bundles of objects to put into some other library later | 09:47 |
| duflu | And without needing fancy linker flags to force inclusion of all symbols | 09:47 |
| alan_g | Yeah, that felt ugly | 09:48 |
| duflu | Well, it was right for the functionality we had before | 09:48 |
| duflu | But CMake has improved on it | 09:48 |
| groot_ | racarr_, I've installed 14.10 on desktop :). If you're available, can you tell me what packages should I install to compile mir ? | 10:40 |
| alan_g | groot_: look in the doc directory for building_source_for_pc.md it has the incantations you need | 10:45 |
| groot_ | alan_g, I'm building for android. So I checked build_source_for_android.md and installed the dependencies from root directory of mir. | 10:50 |
| groot_ | how to build now? It says to pass config to cmake | 10:50 |
| groot_ | in the doc | 10:50 |
| alan_g | groot_: you're intending to cross compile? | 10:51 |
| groot_ | alan_g, yes. | 10:51 |
| alan_g | groot_: does "sudo apt-get download gcc:armhf" work? | 10:53 |
| groot_ | alan_g, I think so. It outputs "Fetched 5,300 B in 1s (4,861 B/s) " | 10:54 |
| alan_g | So you should be good to go with ./cross-compile-chroot.sh | 10:55 |
| groot_ | alan_g, all right. I'll let you know what happens. | 10:56 |
| duflu | Whee... input lag of 3ms! | 11:05 |
| duflu | More tweaking | 11:05 |
| duflu | (compared to the current 13) | 11:06 |
| alan_g | duflu: sounds worthwhile | 11:07 |
| duflu | alan_g: Yes, it's the difference between meeting and missing the frame deadline | 11:08 |
| === chihchun is now known as chihchun_afk | ||
| alan_g | duflu: FWIW add_library(... OBJECT helps simplify things. Good suggestion - thanks | 11:10 |
| duflu | alan_g: Glad to help | 11:10 |
| === alan_g is now known as alan_g|lunch | ||
| greyback | anpok_: running tests suites with qtomp+your mir patch, everything seems to be working great! | 12:34 |
| greyback | thank you for delving into that | 12:34 |
| === alan_g|lunch is now known as alan_g | ||
| tedg | So, looking for a good way to debug a Mir connection. | 13:16 |
| tedg | Getting the error from QtUbuntu that it can't create an application, but doesn't say why. | 13:17 |
| tedg | Why can't I know why? | 13:17 |
| kdub | we've been meaning to remove mir::Secrets for a while now... | 13:21 |
| anpok | but people havent complained enough yet | 13:22 |
| tedg | The Illuminati keep rejecting the MR? | 13:22 |
| kdub | tedg, but --session-mediator-report might help | 13:22 |
| ogra_ | no more secrets !!! | 13:22 |
| alan_g | tedg: does --connector-report log (on server command line) help? | 13:22 |
| kdub | also --msg-processor-report might help | 13:22 |
| tedg | Which command lines are those? The unity8 one? | 13:22 |
| alan_g | Or MIR_CLIENT_RPC_REPORT=log in the client environment | 13:23 |
| kdub | tedg, probably easiest to use an environment variable | 13:23 |
| kdub | right, like alan_g suggests :) | 13:23 |
| tedg | K, cool. I'll do that and see what I get. I can add the env var easily. | 13:23 |
| alan_g | A.k.a. MIR_SERVER_CONNECTOR_REPORT=log (in server environment) help? | 13:24 |
| tedg | Hmm, adding MIR_CLIENT_RPC_REPORT didn't seem to print anything. Is it a stdout thing or should the log be somewhere? | 13:25 |
| kdub | that should work on the client side, and it should go whereever stdout would go | 13:26 |
| tedg | Hmm, okay. /me checks for typos | 13:27 |
| === pete-woods is now known as pete-woods|lunch | ||
| tedg | Going to grab an strace to see if there's information there. | 13:30 |
| === pete-woods|lunch is now known as pete-woods | ||
| anpok | alf_, alan_g: could you have a look at https://code.launchpad.net/~andreas-pokorny/mir/fix-1346952/+merge/227993 | 14:17 |
| alan_g | anpok: sure - after a cup of tea | 14:17 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| alan_g | camako: This should stop the test CI jobs installing mir-doc and a load of -dev package: https://code.launchpad.net/~alan-griffiths/mir/fix-1297100/+merge/228123 (I wonder how long that has been taking) | 16:17 |
| * camako checks | 16:18 | |
| camako | alan_g, ack... So the CI team doesn't have to do anything... | 16:19 |
| alan_g | camako: I just want some timestamps | 16:20 |
| camako | alan_g, isn't this about installation, though? How does it affect build? | 16:20 |
| camako | alan_g, https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1322202 | 16:21 |
| ubot5 | Launchpad bug 1322202 in Ubuntu CI Services "Jenkins logs need timestamps" [Undecided,New] | 16:21 |
| camako | alan_g, feel free to put your thoughts in there | 16:21 |
| anpok | alf_, AlbertA: just updated.. | 16:21 |
| alan_g | camako: if you look at the test runner (e.g. http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-mako/) you'll see it installs the test packages using dpkg | 16:23 |
| tedg | So it looks like what happening is that someone is setting up an epoll. And adding FDs to it. | 16:27 |
| tedg | When it gets to the FD that is the Mir socket, epollctrl fails with EBADF. | 16:27 |
| tedg | epoll_ctl | 16:27 |
| alan_g | tedg: how are you passing the FD to the process? (The actual FD not the fd number in the parent process) | 16:30 |
| tedg | alan_g, Via a dbus message | 16:30 |
| alan_g | tedg: can you check the FD is valid at the point of receiving that message? | 16:31 |
| * alan_g tries to remember a suitable incantation...fails | 16:32 | |
| tedg | alan_g, In theory, what's the best way to do that? | 16:32 |
| alan_g | racarr_: you once gave me an incantation to check a FD. ^ | 16:32 |
| alan_g | tedg: try fcntl(fd, F_GETFD) - it shouldn't set errno if the FD's OK | 16:34 |
| tedg | K | 16:35 |
| anpok | alf_: bbiab, would be cool if I get your opinion before you eod | 16:38 |
| racarr_ | I think it was fcntl F_GETFD yes. | 16:38 |
| racarr_ | oh wow almost 10 already... | 16:39 |
| groot_ | hello | 16:45 |
| groot_ | racarr_, after many hours of downloading, compilation failed with some error. | 16:46 |
| groot_ | can you take a look please http://paste.ubuntu.com/7848515/ | 16:46 |
| racarr_ | oh no | 16:46 |
| racarr_ | groot_: Hehe lookslike kdub made a typo in his little hack for you | 16:47 |
| racarr_ | if you do to that file src/platform/graphics/android/framebuffers.cpp | 16:47 |
| racarr_ | around l74, find that function and just | 16:47 |
| racarr_ | in the first line add | 16:47 |
| racarr_ | (void) hwc_device; | 16:47 |
| racarr_ | it should build | 16:47 |
| racarr_ | its just a warning about an unused variable :) | 16:47 |
| groot_ | racarr_: you mean in here, std::pair<geom::Size, double> determine_hwc11_size_and_rate( std::shared_ptr<hwc_composer_device_1> const& (void) hwc_device) | 16:51 |
| racarr_ | groot_: No leave the declaration alone | 16:51 |
| racarr_ | groot_: I mean in the body of the funcftion | 16:51 |
| racarr_ | after { :) | 16:51 |
| racarr_ | and you need the ; | 16:52 |
| groot_ | racarr_: the body has only return statement "return {{480,854}, 60.0f};" | 16:52 |
| racarr_ | groot_: Yes so add a line before the return line | 16:53 |
| racarr_ | (void) hwc_device; | 16:53 |
| racarr_ | its just a no-op statement that lets the compiler know you are using the variable | 16:53 |
| racarr_ | normally this function queries the size from the hwc device, but kdubs little workaround hardcoded the size for your device | 16:54 |
| racarr_ | leaving the hwc_device variable unused, ala compile error because we have pedantic warnings | 16:54 |
| racarr_ | :) | 16:54 |
| groot_ | racarr_, ohh alright, trying again now :) | 16:55 |
| racarr_ | :D | 16:55 |
| tedg | Well, on the plus side that didn't return an error. On the negative side, I still don't know why. | 16:55 |
| alan_g | tedg: At least you know the problem comes after that. ;) | 16:57 |
| alan_g | can you print the FD at that point and the connection string you're passing to Mir? | 16:57 |
| kdub | groot_, you could also bzr pull from the branch, corrected the problem yesterday | 16:57 |
| tedg | Yeah, I am doing that. It's 8, and fd://8 | 16:58 |
| tedg | Wonder if it's getting a close on exec set. | 16:59 |
| groot_ | kdub, I'm no good with c++ :P | 17:00 |
| alan_g | tedg: presumably the exec happens before the dbuss call? | 17:01 |
| tedg | alan_g, Well, there's a chain of execs :-) But there is one between the dbus call and the exec to the process that is connecting to Mir. | 17:01 |
| alan_g | tedg: so the intention is for the process that connects to Mir to inherit the FD from its parent? | 17:03 |
| tedg | Correct | 17:03 |
| tedg | Hmm, that did a bunch more. | 17:03 |
| tedg | Woot! I think that was definitely a step in the right direction. | 17:04 |
| alan_g | OK I understood your original response to mean that it got if from dbus | 17:04 |
| alan_g | *it | 17:04 |
| tedg | alan_g, I have a "mir-connection-demangler" that gets it from dbus, and then it calls the app that is the prompt-handler. | 17:04 |
| alan_g | So can you check the FD at the top of main()? | 17:05 |
| tedg | Yeah, so it seems that it was set to close on exec. Seems gdbus did that for me. | 17:06 |
| * alan_g goes while there's some little success happening | 17:07 | |
| === alan_g is now known as alan_g|EOD | ||
| tedg | Heh | 17:07 |
| tedg | Thanks for your help alan_g|EOD | 17:09 |
| alan_g|EOD | ;) | 17:09 |
| groot_ | racarr_, yay build completed :D. Now I should connect my phone and when it gets stuck at boot, I run deploy-and-test.sh ? | 17:10 |
| racarr_ | Err did you end up building on desktop | 17:12 |
| racarr_ | or phone? I thought you were bnuilding on phone | 17:12 |
| groot_ | nope, installed 14.10 on desktop today :) | 17:12 |
| racarr_ | ah | 17:12 |
| racarr_ | sounds right then! | 17:12 |
| racarr_ | you may ened to | 17:12 |
| racarr_ | after it gets stuck | 17:13 |
| racarr_ | adb shell | 17:13 |
| racarr_ | in and run | 17:13 |
| racarr_ | "stop lightdm" | 17:13 |
| racarr_ | oh I guess it crashed already and thats your problem | 17:13 |
| racarr_ | so probably not :p | 17:13 |
| racarr_ | once you've done that (will be interesting to see if tests run) | 17:13 |
| racarr_ | the next thing is to copy build-android-arm/bin/mir_demo_server_shell over to the device | 17:13 |
| racarr_ | and see if we can run that | 17:13 |
| groot_ | racarr_, I see that deploy-and-test.sh has lines to push all the binaries to the phone. So just running it will do the all the work ? | 17:15 |
| racarr_ | Yep | 17:23 |
| racarr_ | oh I newver realized it copies the demo servers too :) | 17:23 |
| racarr_ | brb lunch | 17:31 |
| groot_ | racarr_, you still here ? | 17:39 |
| groot_ | kdub: I ran the tests, some of them failed. Can you please take a look http://paste.ubuntu.com/7848753/ | 17:42 |
| kdub | okay, the unit tests passed | 17:43 |
| dandrader_ | kdub, AlbertA can we get this one top-approved? | 17:45 |
| dandrader_ | https://code.launchpad.net/~andreas-pokorny/mir/fix-1346952/+merge/227993 ^ | 17:45 |
| dandrader_ | it's has already 2 approvals :) | 17:45 |
| kdub | its okay by me | 17:46 |
| dandrader_ | kdub, then can you do it? what's the process? | 17:47 |
| kdub | oh sure | 17:47 |
| dandrader_ | kdub, thanks! | 17:48 |
| kdub | you just top approve it, and jenkins picks it up, rejects it, top approve again, and then its in | 17:48 |
| kdub | ;) | 17:48 |
| greyback | can someone also look at https://code.launchpad.net/~andreas-pokorny/mir/fix-1346952-0.5/+merge/228098 | 17:48 |
| greyback | it's just the backport of that patch | 17:49 |
| * kdub doesn't know the rules around the backport process | 17:51 | |
| dandrader_ | greyback, just backport the approvals :) | 17:51 |
| === dandrader_ is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| groot_ | kdub, so what to do now ? Also, some of the test failed, is that ok ? | 17:59 |
| groot_ | specially the test that reported my display size is 180, 1010101 | 18:01 |
| kdub | groot_, just stub test values | 18:02 |
| kdub | groot_, does the mir_demo_standalone_render_to_fb work? | 18:02 |
| racarr_ | back | 18:06 |
| groot_ | kdub, I rebooted the device. I'll try and let you know. | 18:06 |
| groot_ | kdub, mir_demo_standalone_render_to_fb failed with "Segmentation fault (core dumped)" | 18:13 |
| racarr_ | backtrace? | 18:16 |
| groot_ | racarr_, here http://paste.ubuntu.com/7848940/ | 18:17 |
| kdub | so, the driver is looking malformed or something | 18:19 |
| kdub | is it being pulled through hybris? | 18:19 |
| groot_ | kdub, how can I test ? | 18:21 |
| kdub | you can try the tests from hybris | 18:21 |
| * kdub forgets the package name | 18:22 | |
| groot_ | kdub, tell me when you remember :) | 18:24 |
| === dandrader|afk is now known as dandrader | ||
| josharenson | let me see oy | 18:41 |
| === renato is now known as Guest26054 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!