| RAOF | Urgh. Have I broken CI again? | 04:14 |
|---|---|---|
| RAOF | The test-build worked, damnit! | 04:14 |
| RAOF | ON CI! | 04:14 |
| === LockeAnarchist- is now known as LockeAnarchist | ||
| RAOF | OOOOooooooooh! | 05:25 |
| RAOF | I have become the destroyer of CI! | 05:37 |
| * RAOF should not work in branches where the default push is to the default CI runner. | 05:45 | |
| RAOF | Alright! | 06:14 |
| RAOF | CI should really, really work now you guys. | 06:14 |
| RAOF | FOR REALZ! | 06:14 |
| * RAOF goes to pick up his car. | 06:14 | |
| RAOF | Ok. Now CI's just messing with me. | 07:27 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| === yofel_ is now known as yofel | ||
| anpok | yay renaming functions with the c-preprocessor is great | 09:24 |
| alan_g | It is a powerful technique - and should be used responsibly (i.e. rarely) | 09:27 |
| anpok | here it was used to link to archives together that use a lot of copied code | 09:28 |
| anpok | *two | 09:28 |
| anpok | hence one is built with a header full of #definef func old_func .. | 09:28 |
| === davmor2_ is now known as davmor2 | ||
| alf_ | alan_g: Hi! Could you please elaborate on "Indeed wouldn't placing a cache implementation directly in the configuration object be sufficient?". Do you mean that the configuration object should have something like: std::shared_ptr<SharedLibrary> the_platform_library() ? | 11:22 |
| alan_g | alf_: I was thinking of a data member SharedLibraryCache with a load_library member. | 11:24 |
| alan_g | But I guess we only ever load the one, so a std::shared_ptr<SharedLibrary> platform_library member would do. | 11:26 |
| alf_ | alan_g: The SharedLibraryCache needs to be shared/survive across configurations and MirConnections, so I am not sure how a SharedLibraryCache as data member would work. | 11:28 |
| alan_g | alf_: OK, that answers my "needs info". | 11:28 |
| === alan_g is now known as alan_g|lunch | ||
| === Saviq_ is now known as Saviq | ||
| eanyx | hi | 12:19 |
| eanyx | Does someone has metrics for 2D/3D throuput of mir? | 12:22 |
| eanyx | throughput | 12:23 |
| kdub | there's a glmark built for mir | 12:24 |
| eanyx | Does the performance are good compared to legacy X? | 12:24 |
| kdub | sure | 12:26 |
| eanyx | In what proportion? | 12:26 |
| kdub | too vague questions | 12:34 |
| eanyx | I'm wanting to write a 2D game, and wanting to know what is the blitter speed ? | 12:36 |
| kdub | with the in-game stuff, thats up to you... for mir at least | 12:38 |
| kdub | we bypass fullscreen on mesa | 12:38 |
| kdub | and use the overlay path on android | 12:38 |
| kdub | could everyone take a look at https://code.launchpad.net/~kdub/mir/frontend-tracking/+merge/232123 | 12:41 |
| kdub | and indicate which of the two exchange_buffer messages are preferable? | 12:41 |
| === alan_g|lunch is now known as alan_g | ||
| eanyx | is there some vsync for smooth animation? | 13:08 |
| alan_g | kdub: I've looked and don't have a preference | 13:09 |
| kdub | thanks alan_g | 13:10 |
| eanyx | have to leave you, have a nive day/evening. | 13:42 |
| alf_ | kdub: fine with both, although I wonder if allowing the client to indicate surf_id could be used maliciously. Of course we already trust the client library to give us correct info in general, so perhaps this is a non-issue. | 14:01 |
| kdub | alf_, yeah, agree | 14:02 |
| kdub | at any rate, i'll be on later than normal tonight, so I'll just chat it over with RAOF then | 14:03 |
| dandrader | a gmock question: is using MOCK_METHODX(....) any good when I want to check a complex parameter of a method? | 15:09 |
| dandrader | I have a parameter like this "const QList<struct QWindowSystemInterface::TouchPoint> &points" | 15:09 |
| dandrader | so I wanna iterate the list and check the values of the TouchPoint structure, etc | 15:09 |
| dandrader | I wonder if using the gmock magic stuff (like declaring the method with MOCK_METHOD() and using things like EXPECT_CALL()... in the test) will be of any use in this case | 15:11 |
| dandrader | or if I'm better of doing the mock implementation manually | 15:11 |
| * dandrader was told mir developers were the local gmock experts | 15:11 | |
| tvoss | dandrader, you might want to look into MATCHER_P | 15:11 |
| tvoss | dandrader, so yes, gmock is quite useful in your scenario, and you can just describe your matching logic in MATCHER_P | 15:12 |
| * dandrader googles for MATCHER_P | 15:13 | |
| kdub | there are also some container matchers | 15:13 |
| kdub | https://code.google.com/p/googlemock/wiki/CheatSheet#Container_Matchers | 15:13 |
| kdub | that might be helpful | 15:13 |
| dandrader | tvoss, kdub, ok, thanks for the tips. will look into those | 15:14 |
| === chihchun is now known as chihchun_afk | ||
| josharenson | greyback__ when I build qtmir, it keeps failing on a mir header file, even though the file exists... | 16:40 |
| greyback__ | josharenson: can I see the build output please? How are you building? | 16:40 |
| greyback__ | josharenson: if you're building manually on the phone, you need this: qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9" | 16:41 |
| josharenson | as per the readme.. mk-build-deps, qmake, make (getting a pastebin of the output) | 16:41 |
| greyback__ | ah, I better update the readme - the 4.9 thing is annoying | 16:41 |
| josharenson | i was going to update it when I got it working :-p | 16:41 |
| josharenson | http://pastebin.ubuntu.com/8151394/ | 16:42 |
| greyback__ | josharenson: so libmirserver-dev is installed? In that case, I'd clean all & try again (qmake not good at seeing dependencies changing): bzr clean-tree && bzr clean-tree --ignore | 16:44 |
| greyback__ | then try the qmake command again | 16:44 |
| josharenson | greyback__ I had libmirserver-dev installed, but cleaning the tree seems to have fixed whatever was wrong... | 16:55 |
| greyback__ | josharenson: glad to hear it. Usually that happens to me if I run qmake before having all the dependencies installed. Running qmake again after often does not pick up the new header/lib directories | 16:56 |
| josharenson | greyback__ good to know, thanks | 16:56 |
| greyback__ | full clean and retry is my usual fix | 16:56 |
| greyback__ | np | 16:56 |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === DalekSec_ is now known as DalekSec | ||
| rsalveti | AlbertA2: hey, while I agree that it's good to hold a lock during a voicecall, this same issue will happen next time we have an app using the proximity sensor | 22:54 |
| rsalveti | checking https://code.launchpad.net/~albaguirre/powerd/avoid-suspend-during-call/+merge/232290 | 22:54 |
| Saviq | camako, is there an actual reason why we need the bump of qtmir dep to > 0.7.0? if not, we should just go for a no-change rebuild? | 23:01 |
| Saviq | camako, although the -gles dep should definitely be bumped to actually be in sync with the non-gles one, but in general unless there's API breaks we don't bump the -dev dependency, it will still build with the latest available | 23:02 |
| camako | Saviq we broke the ABI.. So I just updated the dependency | 23:02 |
| Saviq | camako, right, so we only need a no-change rebuild against the new -dev, debian/control deps should generally reflect the truth (as in what's the minimal mir version with which qtmir will build) | 23:03 |
| camako | Saviq, do you mean, for instance, if there is no client API break then leave the client dependency alone? | 23:03 |
| Saviq | camako, basically if there's no code changes required | 23:03 |
| Saviq | camako, there's no need to touch the deps | 23:03 |
| camako | Saviq, but we definitely broke the ABI on the server side... client side perhaps I should leave it alone | 23:04 |
| Saviq | camako, sure, but that will sort itself out through a no-change rebuild | 23:05 |
| Saviq | camako, the build system will select the highest -dev version during the build anyway, and then encode the real versioned dependency in the runtime dependencies | 23:05 |
| Saviq | camako, basically, qtmir can build with 0.6.0 still, can it not? | 23:06 |
| camako | Saviq, Oh I see what you mean... I dunno if it can actually.. | 23:07 |
| Saviq | camako, if you only bumped the debian/control version and it still builds, sounds like it can :) | 23:07 |
| camako | Saviq, you're right... If mir hasn't changed actual code qtmir (or others) depend on then no need to do what I did | 23:08 |
| Saviq | camako, dependencies (especially versioned ones) in debian/control should be "the least required" | 23:08 |
| * Saviq comments on the MP then | 23:09 | |
| camako | Saviq, I see... so how do we do a no change rebuild in the silo? | 23:09 |
| Saviq | camako, you just need an empty (--unchanged) commit in the MP | 23:09 |
| Saviq | camako, for the -gles counterpart you still need to sync the version number (and silo) | 23:10 |
| camako | Saviq, yes Iit's just prelim at this moment | 23:11 |
| Saviq | camako, yup | 23:11 |
| camako | Saviq, thanks man... every time I talked to you I'm illuminated :-) | 23:12 |
| Saviq | camako, always | 23:12 |
| Saviq | camako, for fast development like we do now it isn't as important, but once Mir becomes part of the default distro, LTS and such, it pays off to not bump deps unnecessarily so that you're not forced to unnecessarily build a chain of dependencies | 23:14 |
| Saviq | when someone wants to build on an older distro, that is | 23:14 |
| camako | Saviq, makes total sense... | 23:14 |
| === dandrader|afk is now known as dandrader | ||
| Saviq | camako, one thing to note (when not bumping -dev deps), when you build things in silo, you need to make sure of the order things build in the right order | 23:20 |
| Saviq | camako, because if you just build mir and qtmir in parallel, qtmir will actually build against the distro version | 23:20 |
| camako | Saviq, ok.. and putting mir MP in the front doesn't help with that right? | 23:20 |
| Saviq | camako, no, they all get pushed to the PPA at the same time | 23:20 |
| Saviq | camako, you just need to run the build job with just "mir" first | 23:21 |
| Saviq | or whatever comes first for real | 23:21 |
| camako | Saviq, ok got it | 23:21 |
| Saviq | camako, I think there's a circular dependency between papi and mir still, which means you might actually need to build papi, mir, then papi again or something similar | 23:22 |
| RAOF | kdub_: Yo! | 23:22 |
| camako | Saviq, yeah I've encountered that before and I look out for it | 23:22 |
| Saviq | camako, ideally this should be resolved if at all possible | 23:23 |
| Saviq | camako, that would require splitting papi, though | 23:27 |
| camako | Saviq, yeah it's a nuisance | 23:27 |
| Saviq | camako, the circular dep might lead into a difficult situation if in a single landing you'll have papi depending on new mir api and mir on new papi, neither will build without the other | 23:27 |
| Saviq | oh and there's even one with mesa too bug #1239037 | 23:28 |
| ubot5 | bug 1239037 in mir (Ubuntu) "circular build-dependency between mesa, mir" [Medium,Triaged] https://launchpad.net/bugs/1239037 | 23:28 |
| Saviq | I thought I filed one for papi, mir, will do so now | 23:29 |
| camako | Saviq, yeah I guess we change only one first, build the other then we change the other and build the first.. if that makes sense) | 23:29 |
| Saviq | camako, sure, that makes sense, but might mean you have to do the changes in stages unnecessarily | 23:30 |
| camako | Saviq, right can't do in one silo... would have to split the landing | 23:30 |
| camako | which would be an even bigger PITA than it already is | 23:31 |
| camako | Saviq, so it'll look like this right? https://code.launchpad.net/~mir-team/qtmir/devel-mir-next/+merge/232329 | 23:35 |
| Saviq | camako, yes, approved | 23:41 |
| Saviq | camako, btw, looks like the papi/mir loop was resolved in the end, it's only the mesa one that remains | 23:42 |
| Saviq | camako, i.e. mir does not build-depend on anything produced out of platform-api AFAICT | 23:42 |
| camako | Saviq, I see | 23:42 |
| Saviq | camako, btw, in theory it should be possible to pull lp:qtmir into lp:qtmir/devel-mir-next instead of merging (is what we do with the gles-sync branch) | 23:44 |
| Saviq | well, not any more, because there were merges and such, but maybe we could make it happen again by overwriting devel-mir-next with trunk at the next landing | 23:45 |
| Saviq | this way trunk and devel-mir-next actually maintain the same history | 23:45 |
| camako | Saviq, I see what you mean | 23:45 |
| camako | Saviq, good idea | 23:45 |
| * Saviq tries to verify | 23:45 | |
| camako | Saviq, this actually occured to me but I was a chicken to try | 23:46 |
| Saviq | camako, so yeah, as long as there's no commit *more* on devel than on trunk, you can pull | 23:47 |
| * camako will do it next time | 23:48 | |
| camako | Saviq another nice thing with the empty commit option is now the MPs will be approved by Jenkins (before they always failed because Jenkins didn't know anything abt the new release before it happened) | 23:50 |
| Saviq | camako, sure, assuming they will actually build ;) | 23:51 |
| Saviq | camako, and well. sure, jenkins approved, but with old mir, so not really something you wanted | 23:51 |
| camako | Saviq, yea I'm hungry so who knows what I did | 23:51 |
| Saviq | camako, so yeah, even now, if you uncommit your last commit to devel-mir-next, you can just pull from trunk, so yeah, just after the next qtmir landing, pull into devel-mir-next and you'll have history nice & clean | 23:52 |
| camako | Saviq, yeah but at least we won't see a failure | 23:52 |
| camako | Saviq, yeah.. same thing with USC and papi | 23:52 |
| Saviq | camako, yup | 23:52 |
| Saviq | camako, so yeah, until devel-mir-next has actual source changes, jenkins should be happy - if it stops being happy is when you should actually bump the build dependencies appropriately | 23:53 |
| camako | Saviq, yea.. it's sort of one extra checkpoint | 23:54 |
| Saviq | camako, yup | 23:54 |
| Saviq | o/ | 23:56 |
| * Saviq sleepy time | 23:57 | |
| camako | Hey Saviq, really thanks man.. good night | 23:57 |
| Saviq | camako, right back at you | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!