/srv/irclogs.ubuntu.com/2015/05/04/#ubuntu-mir.txt

dufluRAOF: 'make test' is now very terse. Is that what the fans want?02:03
RAOF“make test” has been very terse where it matters for *ages*02:04
RAOFThe fans want make ptest, anyway.02:04
dufluRAOF: Like 20 lines terse?02:05
RAOFduflu: Indeed, like 20 lines terse.02:05
RAOFYou only get interesting output on CI because we pass ARGS=-V to make test.02:05
dufluMeh, it was never a useful level of zoom anyway02:05
* RAOF would prefer to have parallel tests *always* run, because that means parallel failures will largely be caught in CI, but that's apparently difficult.02:06
RAOFduflu: Anyway, would MirReference rather than MirSurfaceId satisfy your nomenclature concerns?02:07
dufluRAOF: Sure, but don't ask mako to. It might asplode02:07
RAOFLibtypo??02:07
dufluRAOF: "MirReference" was a worse name. "Signature" or "Fingerprint" would be OK. I prefer "Signature"02:08
dufluRAOF: libtypo was called "gltext" during its development. Then at the last minute I found such a thing already existed and would be quite confusing so renamed02:08
RAOFAnd characters are a precious resource, so “typography” was rejected? :P02:09
dufluRAOF: Yes, we are programmers, humans and Australians. All three prefer shorter names02:09
RAOFI dislike both Signature and Fingerprint. Neither of those tell me that I can use it to refer to a specific object.02:10
RAOFBoth Signature and Fingerprint sound like verification mechanisms rather than reference mechanisms.02:10
dufluRAOF: "Reference" is too overloaded in programming circles. Best to not re-overload that word02:10
RAOFI... disagree.02:11
RAOFI think that the common use of Reference exactly describes what a MirReference is.02:11
dufluRAOF: In the English sense yes. But in the programming sense existing meanings of "Reference" take precedence02:12
dufluAnd there are already too many02:12
RAOFI think that this *is* the programming meaning of Reference.02:12
RAOF<shrug>02:13
dufluRAOF: Well I don't want this to become yet another case of "please rename" resulting in a worse outcome than where we started so stay on MirSurfaceId till a better word is conceived I guess02:13
dufluTo this list of nouns02:14
=== chihchun_afk is now known as chihchun
dufluHmm it's becoming a little too easy to crash the drm kernel module in vivid10:01
dufluBut since it's 6pm that tells me to give up for now10:02
anpokoh yes10:03
anpok4.1 is not much better10:03
duflualf_: Fun fact: I just noticed buffers_sent_to_compositor can contain a buffer multiple times even in a single compositor environment. So if the client misses a frame deadline, that amplifies and makes it even less likely we'll return to the client in time10:03
dufluThis might be an entirely new bug10:04
anpokjust had an interesting i915 kernel message and after that just one core left .. or 1/8 of the processing power10:07
alf_anpok: Are you using a custom kernel with vivid (4.x)?10:27
alf_anpok: I see vivid has 3.19.x by default10:27
anpokyes10:28
anpokhm cannot remember what made me switch to 4.010:28
anpokbut with 4.0 i915 crashes as soon as we do the vt switch10:29
anpok4.1 fixes that10:29
anpokmaybe i have to go backwards to solve those troubles10:31
anpokalf_: i am using the kernel from the mainline kernel ppa10:31
alf_anpok: ok10:32
alf_anpok: After calling input_manager->start() and input_dispatcher->start() is there a guarantee that the input subsystem is 100% up and running?12:47
alf_anpok: or are there asynchronous operations taking place12:48
anpokalf_: nope13:28
anpokstart does not wait unti the thread is started13:28
anpokso the first thing that happens after start() completes is a device scan..13:29
alf_anpok: is it feasible to change the code to provide that guarantee?13:30
anpokhm yes you basically could have a promise.set_value right after the legacy_dispatchable->dispatch..13:31
anpokwithin ::starT()13:31
anpokwhich is the first device scan13:31
anpokalf_: but I am not sure how long that take.. is there a problem?13:32
alf_anpok: The problem is that there is no way to tell when the server has *really* started. It's mostly a problem for tests (e.g. the end-to-end input tests I am looking into) at the moment, but even for production it would be nice to guarantee that when the socket appears the server is 100% up and running.13:36
anpokhm but instead of blocking we could do something different..13:38
anpoksend some .. trigger back to main_loop..13:38
anpokso that the compositors and input may start in parallel..13:39
alf_anpok: At the moment, the compositor starts first and blocks until its threads are up and running. We could return an std::future<> from both compositor->start() and input*->start() and allow them to start up in parallel if needed.14:00
anpokright14:01
anpokalf_: hmm will you make an mp for that?14:39
anpoki just realized that I will run into that in the next fixture I wanted to update14:40
alf_anpok: I was planning to start working on these tasks... do you have any concerns?14:41
anpokno I am kind of cleanin up the test fixtures .. cleaning out fake_event_hub..14:41
anpokalf_: no concerns, just wasnt sure if you would do it.. or expect someone to do it :)14:44
alf_kdub: "the document" refers to a proposal about the power-management architecture (powerd etc)15:11
kdubah, yes thanks15:11
=== mhall119 is now known as mhall119|afk
=== Guest50796 is now known as mibofra
=== mhall119|afk is now known as mhall119

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!