| duflu | RAOF: '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 |
| RAOF | The fans want make ptest, anyway. | 02:04 |
| duflu | RAOF: Like 20 lines terse? | 02:05 |
| RAOF | duflu: Indeed, like 20 lines terse. | 02:05 |
| RAOF | You only get interesting output on CI because we pass ARGS=-V to make test. | 02:05 |
| duflu | Meh, it was never a useful level of zoom anyway | 02: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 | |
| RAOF | duflu: Anyway, would MirReference rather than MirSurfaceId satisfy your nomenclature concerns? | 02:07 |
| duflu | RAOF: Sure, but don't ask mako to. It might asplode | 02:07 |
| RAOF | Libtypo?? | 02:07 |
| duflu | RAOF: "MirReference" was a worse name. "Signature" or "Fingerprint" would be OK. I prefer "Signature" | 02:08 |
| duflu | RAOF: 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 renamed | 02:08 |
| RAOF | And characters are a precious resource, so “typography” was rejected? :P | 02:09 |
| duflu | RAOF: Yes, we are programmers, humans and Australians. All three prefer shorter names | 02:09 |
| RAOF | I dislike both Signature and Fingerprint. Neither of those tell me that I can use it to refer to a specific object. | 02:10 |
| RAOF | Both Signature and Fingerprint sound like verification mechanisms rather than reference mechanisms. | 02:10 |
| duflu | RAOF: "Reference" is too overloaded in programming circles. Best to not re-overload that word | 02:10 |
| RAOF | I... disagree. | 02:11 |
| RAOF | I think that the common use of Reference exactly describes what a MirReference is. | 02:11 |
| duflu | RAOF: In the English sense yes. But in the programming sense existing meanings of "Reference" take precedence | 02:12 |
| duflu | And there are already too many | 02:12 |
| RAOF | I think that this *is* the programming meaning of Reference. | 02:12 |
| RAOF | <shrug> | 02:13 |
| duflu | RAOF: 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 guess | 02:13 |
| duflu | To this list of nouns | 02:14 |
| === chihchun_afk is now known as chihchun | ||
| duflu | Hmm it's becoming a little too easy to crash the drm kernel module in vivid | 10:01 |
| duflu | But since it's 6pm that tells me to give up for now | 10:02 |
| anpok | oh yes | 10:03 |
| anpok | 4.1 is not much better | 10:03 |
| duflu | alf_: 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 time | 10:03 |
| duflu | This might be an entirely new bug | 10:04 |
| anpok | just had an interesting i915 kernel message and after that just one core left .. or 1/8 of the processing power | 10: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 default | 10:27 |
| anpok | yes | 10:28 |
| anpok | hm cannot remember what made me switch to 4.0 | 10:28 |
| anpok | but with 4.0 i915 crashes as soon as we do the vt switch | 10:29 |
| anpok | 4.1 fixes that | 10:29 |
| anpok | maybe i have to go backwards to solve those troubles | 10:31 |
| anpok | alf_: i am using the kernel from the mainline kernel ppa | 10:31 |
| alf_ | anpok: ok | 10: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 place | 12:48 |
| anpok | alf_: nope | 13:28 |
| anpok | start does not wait unti the thread is started | 13:28 |
| anpok | so 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 |
| anpok | hm yes you basically could have a promise.set_value right after the legacy_dispatchable->dispatch.. | 13:31 |
| anpok | within ::starT() | 13:31 |
| anpok | which is the first device scan | 13:31 |
| anpok | alf_: 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 |
| anpok | hm but instead of blocking we could do something different.. | 13:38 |
| anpok | send some .. trigger back to main_loop.. | 13:38 |
| anpok | so 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 |
| anpok | right | 14:01 |
| anpok | alf_: hmm will you make an mp for that? | 14:39 |
| anpok | i just realized that I will run into that in the next fixture I wanted to update | 14:40 |
| alf_ | anpok: I was planning to start working on these tasks... do you have any concerns? | 14:41 |
| anpok | no I am kind of cleanin up the test fixtures .. cleaning out fake_event_hub.. | 14:41 |
| anpok | alf_: 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 |
| kdub | ah, yes thanks | 15: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!