RAOFWTF Linux?01:36
RAOFIf I get interrupted in the middle of recvmsg while receiving file descriptors do you _really_ dup() all those descriptors and give them to me twice?01:37
dufluRAOF: dup would mean different fd values... ?01:44
RAOFduflu: Precisely.02:00
dufluUmm kay02:00
RAOFThis is, obviously, somewhat awkward.02:01
=== chihchun_afk is now known as chihchun
dufluRAOF: Could you take a glance at this? https://code.launchpad.net/~mir-team/mir/fix-1339700-take2/+merge/22653404:09
RAOFduflu: Sure.04:16
RAOFduflu: Why do you think that “while(count > 0) cv.wait(lock);” would be more efficient than “cv.wait(lock, [](){ count > 0 });”?04:23
dufluRAOF: Because there's no lambda required. No callback into one, no inlining, and no extra work for the compiler. So even if it could be made as efficient as the "while" syntax it would still require a lot more work by the compiler to do so04:24
dufluNot to mention it's easier to read. There's always a loop to wait on a condition, so it's nicer to get people to read it as "while (something)" instead of "do_stuff(until not cond)"04:26
RAOFI don't know; wait(for_thing) pretty easy to understand.04:34
dufluAfter optimizations it should generate the same code. But the while syntax is even easier to read, and requires no compiler optimization effort to generate optimal code04:39
RAOFRoughly the inverse code, but pretty much, yeah.04:42
RAOFHowever, I think the lambda code is easier to read.04:43
RAOFSo, personal taste :)04:43
dufluI did notice at some point in the past (Mir) developers preferred reading all logic lef-to-right in long lines. Prior to that most developers read top-to-bottom04:45
RAOFAt a guess, that'd be the influence of functional programming..04:46
RAOFThe lambda asserts state, the loop describes how to get that state..04:49
dufluRAOF: I think "while()" is a more reliable assertion in C-anything. But that's just me I guess05:30
dufluIt's also clearer that the condition is tested while locked (and must be)05:31
RAOFIt's not really an assertion, though; it's a proceedure.05:32
dufluRAOF: Knowing bare minimum about the C language it is a logical assertion :)05:32
dufluwhile (A) B; means A is no longer true after05:33
dufluAnd then, lunch05:33
=== chihchun is now known as chihchun_afk
RAOFOf *course* I can't reproduce that bug now that I've got some debugging in place. How stupid of me to presume I might be able to..06:28
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
greybackalf_: hey, nested servers GL contexts - they are not getting alpha buffers are they?12:05
greybackalf_: no they can, it just seems I'm not configuring things correctly to get a gl context with alpha12:08
greybacka nested server has the RGBA of the nested gl context decided based on the current format of the display output.12:09
greybackit seems the format QtComp is getting does not have alpha enabled12:09
greybackQt also reports that the GL context it is getting has no depth of stencil buffers either - which is odd, as I would expect rendering errors as a result, but visually it looks ok12:11
greybackdepth _or_ stencil12:12
alf_greyback: Are you referring to a context you get with mg::Display::create_gl_context() or the one that is current when you make_current()12:13
greybackalf_: an excellent question12:13
greybackalf_: yeah I'm referring to mg::Display::create_gl_context()12:16
alf_greyback: Ok, I see that's broken, it always returns zero alpha12:17
alf_greyback: (broken for nested)12:17
greybackalf_: ok, that was confusing me. Thanks!12:17
alf_greyback: what behavior do you need?12:18
greybackalf_: I just want to read the RGBA/depth/stencil buffer sizes into Qt. But I was doing that for a temporary context I created with mg::Display::create_gl_context - so Qt thought it had no alpha/depth/stencil buffer12:20
greybackbut instead I can just read that from the current context when I call make_current()12:21
alf_greyback: do you get alpha for the context you get from make_current()?12:21
greybackalf_: I need to check, but I think so yes12:21
alf_greyback: as you mentioned, by default the surface/context RGBA a nested server uses matches the format of the real output framebuffer (in the system compositor), which is probably RGB. You can override this with the_display_configuration_policy(). Not sure if unity8 already does this. For depth/stencil you need to override the_gl_config()12:27
greybackalf_: we override the_gl_config() anyway12:28
alf_greyback: that's only for depth/stencil though12:28
greybackalf_: indeed. So you recommend we override the_display_configuration_policy too? In unity8?12:28
alf_greyback: question is, why do you need alpha for unity8's surface?12:29
greybackalf_: we don't actually. Qt does complain if depth & stencil missing though12:30
alf_greyback: ok, but you set that with the_gl_config(), so I am confused about the actual problem...12:30
greybackalf_: there may not be an actual problem, aside from what is returned by mg::Display::create_gl_context not being what I expected12:32
=== olli_ is now known as olli
=== greyback is now known as greyback|lunch
=== greyback|lunch is now known as greyback
kgunnmterry: hey, are you available for some help/thots on debian control file changes?14:06
mterrykgunn, sure14:06
alf_mterry: Hi! I noticed that in USC trunk we are waiting for two frames to be posted before marking a session as ready. Is this a workaround for some unity8 issue?14:06
mterrykgunn, is this more ABI breakage stuff?  :)14:06
mterryalf_, it was a workaround for *something* -- without that we'd get black frames first.  Either Qt or Mir or some driver code was posting black frames14:07
kgunnmterry: nope, more like shuffling some libraries around to make them shared libraries14:07
alf_mterry: ok, I guess I should keep it in the refactoring then :)14:08
kgunnmterry: ...oh, and alan_g brot up this bug...so maybe it is14:09
ubot5Ubuntu bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,Triaged]14:09
kgunnbut the discussion started with the mp :)14:09
kgunnand adding packages to the control14:09
mterrykgunn, so you need to add a new libmirshared1 package?14:10
kgunnmterry: yeah, effectively....and instead of just reading14:11
kgunnand hoping to get it right, alan_g was wanting someone with some experience to possibly guide14:11
mterrykgunn, k14:13
alan_gmterry: there's more problems there than just adding a new library. We've existing libraries that ought (AFAICS) to be versioned.14:13
mterryalan_g, hello!14:13
alan_gmterry: hi14:13
mterryalan_g, like libmirplatform14:13
alan_gand mesa/libmirclientplatform.so14:14
alan_gand android/libmirplatformgraphics.so14:14
mterryalan_g, so many ABIs!14:15
alan_gI can (mostly) sort out the cmake side of things but the packaging files are "magic"14:15
mterryalan_g, well, since you'll be changing the name of the files it installs (they'll have ABI version numbers now), you at least get to avoid the pain of breaks/replaces14:16
mterryalan_g, do you have a branch that does the cmake side of things?14:16
alan_gmterry: I started with the new library. Not touched the existing ones yet. (Was trying to understand things first.)14:17
mterryalan_g, ok, let me look at existing packaging and recommend a thing14:18
kgunnmterry: yeah, thanks...i was thinking a brief review of where we are would be helpful14:18
alan_gAnd, maybe mesa|android/libmirplatformgraphics.so doesn't matter as it implements an API defined in libmirplatform.14:18
mterryalan_g, so libmirshared would be in practice an internal library, right?  no -dev?14:20
mterryalan_g, none of these libraries have .symbols files  :(14:22
alan_gmterry: I think it needs a -dev - as there are headers14:22
mterryalan_g, are they public headers though?  Like, will third-party packages build against it?  Doesn't hurt to have them be public, but just asking14:22
alan_gthere are public headers (I'm looking to see how these get published now)14:24
alan_gAh! they are installed by mircommon-dev.install14:27
mterryalan_g, ah... hm.  So you'll have to add a breaks/replace on libmirshared-dev14:28
alan_gOr rename to libmircommon ;)14:29
alan_gWhich would work14:29
mterryalan_g, fair14:29
mterryalan_g, you'd probably want to rename mircommon-dev to libmircommon-dev then14:30
alan_gSo that would need a replace anyway?14:31
mterryalan_g, yeah for its old name.  You might want to do all of Provides/Conflicts/Replaces for the old name, so the old package is removed on upgrade14:35
alan_gmterry: and I can just add "libmircommon1 (= ${binary:Version}), " to that and the libraries that use it?14:36
mterryalan_g, well not to the libraries that use it, they'll have automatic dependencies created by shlibs:Depends14:37
mterryalan_g, but for libmircommon-dev, yes14:37
alan_gOK. I'll try that for now. Is there an easy way for me to test/validate my changes?14:38
mterryalan_g, try an upgrade from a PPA and make sure it installs new packages fine and removes the old package...14:39
mterryalan_g, or you could use dpkg -i locally and make sure it complains correctly, but it won't automatically remove package, it will just error out14:39
alan_gmterry: I'm not at all familiar with packaging - how do I get it on a PPA?14:40
mterryalan_g, do you have a PPA associated with your LP user?14:41
alan_gNot if I had to do something to get one14:41
alan_gI see "Create a new PPA"14:42
mterryalan_g, yup, do that14:42
mterryalan_g, just make some random testing PPA for yourself14:42
mterryalan_g, OK, now when you're ready, you can build a source package locally with debuild -S14:44
alan_gfrom the checkout root?14:44
mterryalan_g, yeah14:45
mterryalan_g, and then do...  dput ppa:alan-griffiths/NAMEOFYOURPPA ../mir_VERSION.changes14:45
mterryah, junk-ppa I see14:45
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|lunch
alan_gmterry: Sorry to keep bugging you. "debuild -S" gets as far as debsign: gpg error occurred!  Aborting...16:54
mterryalan_g, oh right...  do you have a gpg key that LP knows about?16:55
alan_gmterry: yes16:55
mterryalan_g, OK16:56
mterryalan_g, so do "dch -i" and put some dumb comment in there, make sure to change UNRELEASED to utopic16:57
mterryalan_g, then try debuild -S again16:57
* alan_g looks guilty - he's still on trusty16:58
=== dandrader|lunch is now known as dandrader
mterryalan_g, trusty!  tsk tsk  :)17:17
mterryalan_g, you can still push to the PPA from trusty, but you won't be able to test the upgrade path on your local machine that way17:17
dandraderdednick, is a MirPromptSessionEvent event tied to a surface? ie. does it happen in relation to a specific surface?17:32
* dandrader clueless about prompt sessions17:32
dandraderalan_g, you there?17:36
=== alan_g is now known as alan_g|EOD
alan_g|EODdandrader: not really17:38
dandraderracarr__ ping17:41
dednickdandrader: not tied to the surface17:41
dednickdandrader: go directly to the client prompt session.17:41
dandraderdednick, oh....17:41
racarr__dandrader: Hi :) welcome back17:42
dandraderracarr__, hi17:43
dandraderand thanks :)17:43
dandraderracarr__, so in mir, MirEvents are always tied to a surface, right?17:44
alan_g|EODmterry: something still went wrong - but I'll deal with it tomorrow17:44
dandraderracarr__, or at least that's what it seems to be from reading the client api17:44
mterryalan_g|EOD, k, poke me when I'm online17:45
dandraderracarr__, ie, MirEvents are always and will always be directed to some MirSurface of some client. i.e., the client never gets a MirEvent directly from the MirConnection or something. always through the handler set by mir_surface_set_event_handler17:48
racarr__dandrader: That sounds right to me17:50
dandraderracarr__, ok. but then we have MirPromptSessionEvent in MirEvent...17:53
dandraderracarr__, which, as dednick said, is not tied to a surface17:53
racarr__hmm I missed that17:56
racarr__dandrader: I wonder if those are just consumed in the client library? i.e. the lambda in MirPromptSession::MirPromptSession in the client library.18:03
dandraderracarr__, which then generates a mir_prompt_session_state_change_callback call to the api user?18:05
racarr__dandrader: SEems right18:05
dandraderracarr__, I guess so, but then it seems wrong to me to have that in a MirEvent which is supposed to contain events that reach the api user through mir_event_delegate_callback18:06
dandraderracarr__, would be like it's exposing an implementation detail to the API user18:07
dandraderracarr__, right?18:08
racarr__dandrader: I would agree yes18:11
racarr__I am not a MirPromptSession expert so to speak lol18:11
dandraderracarr__,  me neither. will talk to dednick tomorrow18:11
racarr__but yeah...I think MirEvent is a strange chocie18:11
racarr__ive always felt it was strange to put18:11
racarr__anything besides18:11
racarr__Input events in "MirEvent"18:12
dandraderracarr__, even surface resizes?18:12
racarr__I kind of think its better if you just have18:12
racarr__resize events or surface events or whatever18:13
racarr__but there is no need to group them all in the "all in one event"18:13
dandraderracarr__, you do if they are going all to be sent to the same callback18:14
racarr__maybe they shouldnt be though because18:14
racarr__the callback kind of has funny semantics right, i.e. called from different threads18:14
racarr__depending on the event type.18:14
dandraderracarr__, hmm, I think it's more like a design choice: "have 1 callback  and put a type field in the event" or "have one callback per event type and remove the type field"18:16
dandraderhistorically the first option is more popular18:17
racarr__I think its kind of a misguided attempt to save typing18:18
racarr__at the expense of a small amount of coupling (e.g. in ABI breaks) between18:19
racarr__what could be unrelated structs18:19
racarr__but in this situation it probably doesnt matter much18:19
=== dandrader is now known as dandrader|afk
racarr__finished one pass through the whole QPA20:22
greybackracarr__: thanks!20:41
greybackracarr__: do you have review comments?20:47
racarr__greyback: Just mailed them21:05
racarr__greyback: The most concerning thing for me is some of the signal usage21:05
racarr__and things that look like Q_EMIT address-of-value-reference-passed-by-mir21:06
greybackracarr__: what line numbers are you using?21:06
racarr__oh sorry I think all line numbers are in21:06
racarr__the respective implementation file21:06
racarr__the class in latest rev21:07
greybackracarr__: ah those are the class name21:07
racarr__yes sorry my review strategy21:07
racarr__was I wrote down all the classes21:07
racarr__shuffled them in to a random order21:07
racarr__and then started reading21:07
racarr__oh also paste21:08
racarr__is a little alarming21:08
greybackQ_EMIT of pointers to mir objects done with care, the objects those pointers point to, qtmir has a shared_ptr to, so the pointer should always be valid21:08
greybackracarr__: I /think/ paste is what we've had in unity-mir for some time :)21:08
racarr__yes ive just never reviewed it before lol21:09
racarr__it seems like it hsould at least have the focus check21:09
greybackfocus check?21:09
racarr__You shouldn't be able to paste unless you are focused at least right21:09
racarr__otherwise why not just paste all the time and see what you get21:10
racarr__I saw  some of the Q_EMITs had comments like in SessionAuthorizer...but for example SurfaceConfigurator::attribute_set21:11
racarr__if someone connects to that with a queued signal it could crash right?21:12
greybacktrue. sadly there's no way to enforce a direct connection21:13
greybackbut I think that class will go away, since now there's the SurfaceObserver21:13
racarr__oh yeah that should go away21:14
greybackrequestAuthorizationForSession "but it seems like this non blocking behavior requires code connecting to the signal to make the right choice."  - it does indeed21:17
greybackone needs to use a direct connection to that signal to properly authorize sessions21:17

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