[08:40] <anpok> Avagetto: hi
[08:40] <Avagetto> hi
[08:41] <Avagetto> copy questiom here from enother chanel?
[08:41] <anpok> i think the mir team is in all of the channels
[08:41] <anpok> hmm what kernel are you using?
[08:41] <anpok> and which drivers do you want to use?
[08:42] <anpok> rk3288 is something with vivante?
[08:42] <anpok> or mali?
[08:43] <Avagetto> mali
[08:43] <Avagetto> please wait one sminute
[08:46] <Avagetto> We talked with you before, if you want I strip off you log a conversation
[08:46] <Avagetto> i use kernel 3.10
[08:46] <mlankhorst> RAOF: ping
[08:47] <anpok> Avagetto: ah I remember
[08:50] <Avagetto> I tried to install ubuntu touch but at boot it would hang when I didn't have access to the console.
[08:51] <Avagetto> now i try use ubuntu-desktop-next packages
[09:04] <anpok> Avagetto: to get unity8 + mir running on that gpu you need a the mir android graphics platform which relies on a working libhyrbris EGL/GL
[09:04] <anpok> and that one needs the android userspace gpu drivers..
[09:05] <anpok> Avagetto: i am not sure what you installed there so far?
[09:13] <anpok> mlankhorst: he might still have flaky connectivity - yesterday he said that he might be best reached by mail..
[09:14] <mlankhorst> ok
[09:21] <Avagetto> anpok: I tried, but apparently somewhere made a mistake. now I sit and more carefully reread ubuntu touch porting guide. Then try to repeat the installation on the device. Now I don't want to distract You . Today or tomorrow I will write about the results or ask for more detailed information. Thank you very much.
[09:21] <anpok> cool!
[09:22] <anpok> Avagetto: i cant help you much with porting part.. but good that you keep on fighting
[11:30] <alf_> alan_g: What's your concern about switching from high_resolution to steady? That is, where do you think high_resolution would be useful?
[11:32] <alan_g> alf_: I don't have specific evidence we need it, but that isn't evidence it isn't needed.
[11:34] <alan_g> Have you been through all the code that uses mir::Clock?
[11:37] <alf_> alan_g: My rationale for removing it is: 1. HR isn't safe to time intervals with (unless it happens to be steady, but there is no guarantee) 2. it's not useful for wall clock time since there is no guarantee that it is the system_clock
[11:40] <alan_g> I think we have three scenarios for use of "clock":
[11:41] <alan_g> 1. To timestamp logs. For that "wall clock" is an appropriate metaphor
[11:41] <alf_> alan_g: @been through code that uses mir::Clock, yes, we only use it for relative timings
[11:41] <alan_g> 2. To measure elapsed time
[11:42] <alan_g> 3. to timestamp event
[11:42] <alf_> alan_g: I agree we should have different clock abstractions, but didn't want to introduce them here
[11:44] <alf_> alan_g: e.g. different interfaces for a MonotonicClock and a RealTimeClock
[11:44] <alan_g> alf_: OK given the above I don't object to steady clock
[11:45] <alan_g> OTOH we could have one interface and three implementations
[11:46] <alan_g> (Admittedly we couldn't just use the boost types for Timestamp and Duration then)
[11:48] <alf_> alan_g: What I don't like about one interface is that different clocks provide different guarantees and it would be better to encode that guarantee in the type to avoid e.g. passing a system clock to a class that really needs to measure elapsed time
[11:50] <alan_g> alf_: yeah. Was mostly speculating. If as you say we're only calculating intervals we don't need it yet.
[11:53] <alan_g> anpok: did you discover why the USC tests were commented out?
[11:54] <alf_> alan_g: as for not exposing the underlying std clock type, I wonder if we could make something like "using Timestamp = std::chrono::timestamp<mir::time::Clock,std::chrono::nanoseconds>" work, didn't try that...
[11:55] <alan_g> alf_: there are lots of solutions but it is more complexity than we need now.
[12:16] <anpok> alan_g: i guess by accident .. i.e. issues with sbuild .. maybe ..
[12:16]  * alan_g takes that as a "no"
[12:16] <anpok> :)
[12:17] <anpok> i could rule out "oh, tests are failing, hmm how can i solve that"
[12:21] <anpok> it happened with revision 166 http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/revision/166
[12:32] <alan_g> Looks accidental -anyway I've MP'd a fix
[12:44] <anpok> ok would have done the same .. since i was refactoring some things to get it testable
[12:50] <alan_g> It is in dire need of refactoring - as I found out getting to work with mir::Server.
[12:52] <anpok> i only do low level refactorings .. nothing that changes the big picture
[12:53]  * alan_g suspects the big picture needs a re-write
[12:53] <anpok> yes
[12:54] <alan_g> If only there were some good acceptance tests. ;)
[12:54] <anpok> the responsibilities are strangely distributed...
[12:54] <alan_g> And WTF is Qt doing in there anyway?
[12:54] <anpok> somebody should switch it to dbuscpp ..
[12:55] <alan_g> /rant off
[12:55] <anpok> need to grab kids.. brb
[14:29] <alan_g> alf_: happy now? https://code.launchpad.net/~raof/mir/touch-all-the-things/+merge/240394
[14:34] <alf_> alan_g: yes, top-approved
[17:41] <alan_g> AlbertA: it was your change in -c 166 that commented out the tests. Any reason not to restore them? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/uncomment-tests/+merge/240560
[17:44] <AlbertA> alan_g: wtf.... totally missed that in code review
[17:44] <AlbertA> alan_g: yeah that should not have made it in...
[17:45] <AlbertA> that was just my local branch which I disabled tests to get it to cross-compile with the cross-compile scripts...
[17:46] <alan_g> AlbertA: I guessed it was something like that. (Which is why we have code reviews...)