[00:03] <sturmflut> kdub: How will window decorations be handled in Mir? Server-side or client-side?
[00:18] <kdub> sturmflut, current thinking is client-side, but its still up in the air... your thoughts welcome
[00:21] <robert_ancell> kdub, good point. thomi, can you set up ci and automatic PPA building for lp:qmir into lp:mir-team/staging?
[00:38] <sh4rm4> so mir uses C++ and boost, right ?
[00:39] <RAOF> Indeed.
[00:40] <sh4rm4> ah. i heard someone saying that boost apps are very slow to compile and templates will expand to a lot of code
[00:40] <sh4rm4> in other words, bloat
[00:40] <sh4rm4> is that correct ?
[00:43] <sh4rm4> also, he said something about massive ram usage. he said that i possibly want be able to rebuild mir on a netbook with 512MB RAM
[00:43] <sh4rm4> *won't
[00:44] <RAOF> He probably wouldn't want te rebuild mir on a netbook with 512MB of ram, no.
[00:45] <RAOF> But that's more because a netbook with 512MB of ram is terribly, horribly underpowered, and won't build *anything* well :)
[00:45] <sh4rm4> because of the compilation times ?
[00:45] <sh4rm4> well i built an entire linux distro in 3 days on an efika mx
[00:45] <sh4rm4> 800 mhz, 512MB RAM
[00:46] <sh4rm4> about 300 packages
[00:46] <RAOF> You would no longer be able to do that :)
[00:46] <sh4rm4> :(
[00:47] <RAOF> You couldn't do that for Ubuntu *now*; firefox and libreoffice (at least) would trigger the OOM killer.
[00:47] <sturmflut> kdub: Personally I think server-side decorations are better because they provide a unified look for all windows regardless of the toolkit and the controls (minimize/maximize/close) would still work if the client freezes. Also the decoration theme developers would have to rewrite their themes for every toolkit and all applications not relying on the latest version of one of the big toolkits would use different decorations,
[00:47] <sturmflut>  resulting in chaos. Client-side decorations may offer more flexibility but I think the negative sides outweigh the positive ones.
[00:48] <sturmflut> RAOF: I agree, I've seen single gcc instances using more than 1 GB of RAM
[00:48] <sh4rm4> btw: why was CMAKE chosen as a build system ? in the eyes of a packager, it's horrible - doesnt even support DESTDIR
[00:49] <RAOF> sh4rm4: Mir's build is much lighter than that; I can have 5 parallel g++ processes in 4GB of ram, so you'll be able to build in under a GB of ram easy.
[00:49] <sh4rm4> RAOF, even with debug info ?
[00:49] <RAOF> sh4rm4: Because all build systems suck, and the person who did the initial build system thought cmake sucked the least.
[00:50] <RAOF> It's not terrible, and we've got plenty of cmake packages working fine.
[00:50] <RAOF> sh4rm4: Indeed with debug info
[00:51] <sh4rm4> well, autoconf *can* at least be used sanely, and it's at least freestanding and straightforward to use: ./configure --prefix=/ --enable-feature && make -j2
[00:51] <RAOF> cmake can be used just as sanely.
[00:51] <RAOF> *I'd* prefer autotools, but that's because I've got a huge amount of experience with their utter terribleness.
[00:51] <sh4rm4> whereas invoking cmake requires a ton of options, cmake calls back into itself, and needs a C++ compiler to begin with
[00:53] <sturmflut> sh4rm4: cmake does support DESTDIR
[00:53] <sh4rm4> example of a build script for a cmake-using app (mysql) https://github.com/rofl0r/sabotage/blob/master/pkg/mysql#L19
[00:53] <sh4rm4> in comparison, postgresql: https://github.com/rofl0r/sabotage/blob/master/pkg/postgresql
[00:54] <sh4rm4> sturmflut, oh ? how is it being passed ?
[00:54] <sturmflut> sh4rm4: You pass it to the "make install" command
[00:54] <sh4rm4> hmm i wonder why that doesnt work with mysql
[00:55] <sturmflut> I just tried it with mir and it worked
[00:55] <RAOF> sh4rm4: Eh; fix your tools. http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/debian/rules is a much nicer package build ☺
[01:05] <sh4rm4> btw, doesn't the usage of C++ objects, which are usually dynamically allocated, lead to much higher mem consumption and slow speed due to repeated malloc calls ?
[01:06] <sh4rm4> according to the mir overview page, one of the design goals is speed
[01:07] <sh4rm4> thinking along the lines of this paper:  http://domino.watson.ibm.com/comm/research_people.nsf/pages/nickmitchell.pubs.html/$FILE/oopsla2007-bloat.pdf
[01:08] <RAOF> sh4rm4: Only if you repeatedly create objects? You can do that in C, too.
[01:09] <sh4rm4> right, but that's not idiomatic C
[01:09] <sh4rm4> whereas it's idiomatic OOP
[01:09] <RAOF> It's *totally* idiomatic C!
[01:10] <sh4rm4> this here is OOP style: if(string("xxx:xxx:xxx").split(":").elements(2) == "xxx") { ... }
[01:10] <sh4rm4> you got 4 dynamic allocs in that line
[01:10] <sh4rm4> in C you would deal with a buffer on stack
[01:12] <RAOF> That's not particularly "OOP style"; that's just a bad interface.
[01:12] <RAOF> Also, that paper appears to be all about the overhead of Java objects, which C++ doesn't have?
[01:12] <sh4rm4> aren't java and C++ objects quite similar ?
[01:12] <RAOF> No.
[01:13] <sh4rm4> maybe C++ objects are even worse because they have a vtable
[01:13] <RAOF> Java uses a VM; there's a certain amount of overhead involved in that.
[01:13] <sh4rm4> that's at least one pointer overhead for each object
[01:14] <RAOF> A C++ object only has a vtable if it's got a virtual member; and that's *exactly* what you'd do with a C struct.
[01:14] <sh4rm4> you mean a C struct with function pointers ?
[01:14] <RAOF> Indeed
[01:14] <sh4rm4> you wouldnt do that
[01:14] <RAOF> Perhaps you've not read much C? You do that _all the time_
[01:15] <sh4rm4> that's a pretty bad style
[01:15] <RAOF> I don't think you'll find any non-trivial C program that _doesn't_ use that style.
[01:16] <sh4rm4> i've written about 50, and only one uses that style, because its a straight translation from actionscript code
[01:16] <duflu> RAOF: It's "common", but not common to most non-trivial C, I think
[01:17] <RAOF> duflu: It might just be the areas I deal with; X, mesa, the kernel, anything using glib, …
[01:18] <duflu> RAOF: Yeah I know it's common in those areas. Those are the first things I thought of. But then... nothing else
[01:19] <sh4rm4> well, glib is C that tries to be C++, so no surprise there
[01:20] <RAOF> I'm can't think of any non-trivial C code which doesn't have at least one struct with function pointers in it, but I guess there could be areas of the C-verse I've not explored :)
[01:20] <duflu> Welcome to the multiverse
[01:21] <sturmflut> C structs with function pointers are pretty standard I would say
[01:22] <sh4rm4> when you need to stick a function pointer into a struct, you should rethink your design, because bets are high you're about to do something stupid
[01:27] <duflu> sh4rm4: I agree. It's high risk and should be avoided in C /if/ there is an alternative procedural approach
[01:28] <duflu> Well, medium risk...
[01:28] <duflu> You can shoot yourself in the foot many other ways
[01:29] <sh4rm4> ;)
[01:31] <duflu> You reduce the risk if you don't expose the object structure in any public APIs. Users just see "myapi_foo_init()" and it populates the vtable.
[01:31] <sh4rm4> yeah, but as soon as you deal with callbacks, the code starts getting messy
[01:32] <duflu> Yeah, no implicit "this" parameter is a constant headache
[01:32] <duflu> Though there's a good argument that anything implicit is dangerous
[02:20] <duflu> robert_ancell: https://bugs.launchpad.net/mir/+bug/1136938
[02:20] <ubot5> Launchpad bug 1136938 in Mir "mirserver.pc is empty/incomplete" [High,New]
[02:39] <robert_ancell> duflu, turned out to be the fricking CMake cache being stupid
[02:39] <robert_ancell> delete the cache and it works
[02:40] <duflu> robert_ancell: Yes "make clean" is never enough. You should regularly "rm -rf build"
[02:40] <robert_ancell> what is the point of a cache if it doesn't work...
[02:40] <RAOF> Indeed.\
[02:40] <RAOF> MIR_GCC_VERSION is in the same boat; you can't change it once it's been set. And you can't change it in ccmake *until* it's been set!
[02:41] <robert_ancell> well, there goes 3 hours of time wasting
[02:42] <robert_ancell> as I side effect. I learnt a lot more about cmake. And lost a lot of respect for it
[02:47] <RAOF> You clearly had more respect for it than I did ;)
[02:52] <robert_ancell> people say it works well for them. I think they all must have Stockholm syndrome
[02:54] <RAOF> *I* say autotools works well for me :)
[02:54] <RAOF> Sure, it's horrible in basically every way, but it's explicably horrible. Except where it isn't  :)
[02:59] <robert_ancell> RAOF, at least autotools has the excuse of being old
[03:08] <tehcloud> nothing beats a hand-crafted makefile
[03:21] <TheMuso> Even autotools beats a hand-crafted makefile. :)
[03:22] <duflu> I love GNU Make. However it totally fails for complex projects with cross-directory dependencies
[03:22] <duflu> CMake does that very well
[03:22] <duflu> So I use CMake, but don't *like* it
[03:52] <robert_ancell> duflu, do you know the rationale for this wait handle stuff? Can't we just do something like http://paste.ubuntu.com/5612673/?
[03:55] <RAOF> We could do that (although I'd change mir_connect_sync to return a MirConnection rather than void)
[03:55] <robert_ancell> RAOF, sure, in that case when there's only one thing to return
[03:56]  * RAOF is still rooting for the foo_begin/foo_end/foo pattern.
[03:56] <robert_ancell> The only case I can see for the wait handle is to be able to cancel the request
[03:56] <robert_ancell> I really like the way GLib did it, though it uses a generic type for the callbacks which I'd avoid
[03:57] <RAOF> The wait handle is there so you can wait until it's done, not so you can cancel it.
[03:57] <robert_ancell> RAOF, yeah, though we need some sort of cancelling mechanism and that seems the right place to put it
[03:58] <duflu> RAOF: I proposed such a solution already and it was disapproved on the basis of multiple functions doing the same thing
[03:58] <robert_ancell> RAOF, who disapproved it?
[03:58] <RAOF> duflu: I know :(
[03:58] <robert_ancell> duflu, i mean
[03:58]  * duflu looks
[03:58] <RAOF> robert_ancell: Do we need a cancellation mechanism? With what porpoise?
[03:59] <robert_ancell> RAOF, if you register a callback and then need to delete the object you have to cancel the callback
[03:59] <duflu> robert_ancell: alan_g disapproved that too: https://code.launchpad.net/~vanvugt/mir/simple-connect/+merge/147305
[03:59] <RAOF> robert_ancell: Ah, yeah. Fair call.
[04:02] <robert_ancell> duflu, do you have the previous proposal you reference handy?
[04:02] <duflu> robert_ancell: That was an earlier version of the current "optional-callbacks" branch
[04:02] <duflu> Oh, no
[04:02] <duflu> That was "remove callbacks"
[04:03] <duflu> robert_ancell: https://code.launchpad.net/~vanvugt/mir/remove-callbacks-mir_connect/+merge/147056
[04:03] <duflu> Now all 3 proposals to simplify the client API have been disapproved
[04:03] <duflu> I'm becoming slightly dismayed for the future of Mir development
[04:04] <RAOF> robert_ancell: And bug #1112195
[04:04] <ubot5> Error: Launchpad bug 1112195 could not be found
[04:05]  * duflu goes to the store and whip up lunch
[04:05] <RAOF> duflu: Did you deliberately refrain from making that bug public?
[04:06] <duflu> RAOF: I only forgot to make "closed" bugs public
[04:06] <duflu> You can do so if you like
[04:06] <RAOF> Publicified.
[04:06]  * duflu goes to play in the rain and kitchen
[04:06] <duflu> RAIN!
[04:06] <RAOF> Dear lord. In Perth?!
[04:07] <robert_ancell> bug #1112195
[04:07] <ubot5> bug 1112195 in Mir "Mir client API lacks simple synchronous interface" [High,Opinion] https://launchpad.net/bugs/1112195
[04:07] <robert_ancell> RAOF, yeah, we've stolen all Australia's good weather at the moment. But we'd quite like the rain back now
[04:09] <robert_ancell> Reading that bug report. When anyone says "With templates" I get a shudder down my spine
[04:24] <RAOF> robert_ancell: What's a harmless bit of template metaprogramming between friends? ☺
[04:26] <RAOF> The begin/end approach doesn't require metaprogramming, at the cost of needing to define an extra two-line function for each begin/end pair.
[04:29] <robert_ancell> yes, I agree
[04:29] <robert_ancell> I'm going to send this to the mailing list as I think most people are thinking along the same lines
=== robert_ancell is now known as robert_ancell|di
[05:41] <RAOF> You know what would be awesome? If we could build Mir with clang and get sensible goddamned compiler errors.
[05:43] <duflu> RAOF: Yeah a few people have started trying and logged bugs about the problems
[05:44] <RAOF> We'd also want to stop our brain-dead MIR_GCC_VERSION thingy.
[05:44] <duflu> I was going to address one of them today but it may turn out that I continue having to work on the old surface-types
=== robert_ancell|di is now known as robert_ancell
[07:02] <RAOF> robert_ancell: Are you planning to take bug #1112195 to the list?
[07:02] <ubot5> bug 1112195 in Mir "Mir client API lacks simple synchronous interface" [High,Opinion] https://launchpad.net/bugs/1112195
[07:03] <robert_ancell> RAOF, I've written a draft, was thinking on it
[07:03] <robert_ancell> I don't want us to fall into design by committe
[07:04] <RAOF> Cool. I shall wait until you've posted it before commenting further.
[07:04] <RAOF> Actually, we really need to get the toolkit-patching stakeholders in; they're the so-far somewhat mythical “common use case” we're currently optimised for.
[07:05] <tvoss> RAOF, you should grab loicm in, he is the one with the deepest understanding of Qt's platform abstraction layer
[07:12] <tvoss> alf_, the Jenkins VM build seems to be unstable for some time now. Are you aware of that?
[07:15] <robert_ancell> duflu, still around?
[07:18] <alf_> tvoss: Yes, but I haven't had time to deeply look into it. I'll try to take a look soon, but from what I saw its a timeout issue that's related to the test code, not something actually wrong with the main code.
[07:18] <duflu> robert_ancell: I think so. Have not combusted yet
[07:18] <duflu> More to the point... why are you still around?
[07:19] <robert_ancell> duflu, I stay up late on Thursdays to talk to the Europeans
[07:20] <duflu> robert_ancell: That's not a euphemism is it?
[07:21] <robert_ancell> uh, I'm struggling to work out what it would be a euphemism for...
[07:21] <tvoss> alf_, ack and thanks
=== duflu_ is now known as duflu
=== yofel_ is now known as yofel
=== mmrazik is now known as mmrazik|lunch
=== mmrazik|lunch is now known as mmrazik
[12:44] <sturmflut> Can you already estimate when basic input handling and window management will be implemented in Mir? I am waiting for the moment when I can start the demo clients and move the windows around
[13:49] <tvoss> sturmflut, racarr is busy working on the input bits, you might want to ping him when he comes online. He is on the US west coast
=== jono is now known as Guest54570
[14:01] <sturmflut> tvoss: What about window management? I saw that window decorations are still a TODO, so how would one interact with Mir at the moment? Without window decorations there are no window borders and controls for maximizing/minimizing, moving, closing etc.
[14:04] <tvoss> sturmflut, those are left to do right now, the window decorations will be provided by the shell/Unity
=== mmrazik is now known as mmrazik|afk
[15:06] <kdub> good morning folks, status, working on the server constructing the android display differently depending on the environment the server is ran (start of hwc work)
[15:15] <alan_g> Hello kdub
[15:16] <alan_g> I've started on the refactoring of frontend we discussed earlier in the week and on mir-devel
[15:44] <alan_g> alf_: kdub racarr - there seem to be varying thoughts about how the shell hooks into mir. Shall we plan a hangout this afternoon/morning?
[15:45]  * alan_g thought it was all clear after the London sprint
[15:48] <alf_> alan_g: I am in
[15:51] <alan_g> alf_: kdub - let's give racarr an hour in which to appear. Hangout at 17:00 UTC
[15:53] <kdub> alan_g, sounds good
[16:10] <racarr> I am appeared
[16:10] <racarr> hangout at 17:00 would be best though. still digesting
=== mmrazik|afk is now known as mmrazik
=== zAo^_ is now known as zAo^
[17:01] <alan_g> alf_: kdub racarr - https://plus.google.com/hangouts/_/73bee7c67b692d0a384d6cc18448029c47205a49?authuser=0&hl=en-GB#
[17:07] <racarr> alan_g: alf_: kdub: Says no one is there
[17:07] <racarr> maybe someone could send me an invite through teh interface?
[17:07] <racarr> the*
[17:57] <racarr> thanks for the updates to prepare-to-send-clients input btw :)
[18:01] <alan_g> sometimes its easier just to write the code
=== alan_g is now known as alan_g|life
=== mmrazik is now known as mmrazik|afk
=== dpm is now known as dpm-afk
=== mmrazik|afk is now known as mmrazik
=== kdub is now known as kdub^lunch
[22:06] <racarr> Following up on prepare-sessions-for-input-focus, using this SessionManager::create_surface_for approach, the test I want to write is TEST(SessionManager, create_surface_for_session_forwards_and_then_focuses_session)
[22:06] <racarr> but I can't set an expectation on the session because it's the real SessionManager, which doesn't use a factory to construct Session implementations
[22:07] <racarr> I am trying to decide if this is evidence that the SessionContainer is also a SessionFactory (or some such)
[22:08] <racarr> or if it's just not a compelling change, if there is no other real motivation for it, here it's just easy to set the expectation on the surface factory instead
[22:08] <racarr> but it kind of seems like it might be correct *shrug*
=== kdub^lunch is now known as kdub