| === broder__ is now known as broder_ | ||
| === duflu__ is now known as duflu | ||
| === Trevinho__ is now known as Trevinho_ | ||
| === TheMuso` is now known as TheMuso | ||
| === alan_g is now known as alan_g|afk | ||
| tsdgeos | mzanetti: you really are very discouraging on your comment | 10:40 |
|---|---|---|
| mzanetti | tsdgeos: yeah... sorry.. but it really feels too dangerous... you're mixing thread contexts a lot in here | 10:41 |
| mzanetti | tsdgeos: if you want we can do a hangout and talk about it | 10:41 |
| tsdgeos | no i don't want | 10:41 |
| tsdgeos | i have better things to do thatn convincing you | 10:41 |
| tsdgeos | you can propose something that works | 10:41 |
| tsdgeos | since you think the whole approach is crap | 10:42 |
| tsdgeos | and can't be salvaged | 10:42 |
| mzanetti | tsdgeos: well, do you see my concerns at least or do you think I'm wrong? | 10:42 |
| tsdgeos | mzanetti: i do see that you don't think the code is fixable | 10:43 |
| mzanetti | tsdgeos: yeah... just adding more mutexes I think won't cut it here | 10:43 |
| tsdgeos | you're wrong | 10:43 |
| mzanetti | ok | 10:43 |
| tsdgeos | but i don't feel free to instruct you | 10:43 |
| tsdgeos | well you're actaully right | 10:44 |
| tsdgeos | i don't even need any more mutex | 10:44 |
| mzanetti | but I'd like to know where I'm wrong | 10:44 |
| tsdgeos | but wathever | 10:44 |
| tsdgeos | then you should have worded your review better | 10:44 |
| mzanetti | and asking you now to explain me where I'm wrong doesn't help any more? | 10:45 |
| tsdgeos | meh i hate being sick | 10:46 |
| tsdgeos | mzanetti: ok, let's start with the first | 10:48 |
| tsdgeos | tell me when why i need a mutex in worker->m_reply | 10:49 |
| mzanetti | tsdgeos: ok... that's probably indeed not needed. I thought the abort case is problematic there | 10:54 |
| mzanetti | no... it's not... ok | 10:54 |
| Saviq | tsdgeos, eat a snickers! | 10:55 |
| tsdgeos | Saviq: don't have one at hand, going outside the building will just increase my sickness/grumpyness :D | 10:56 |
| Saviq | :) | 10:56 |
| * Saviq looks for same-day amazon snickers delivery | 10:56 | |
| mzanetti | if you find that, don't tell me where | 10:57 |
| tsdgeos | mzanetti: ok, want me to add a comment why since you got confused by it? Do you have a suggestion on the wording of the comment? | 10:57 |
| mzanetti | tsdgeos: no :D feel free to call me anything you want | 10:57 |
| tsdgeos | oh wait you still think the code can't be fixed | 10:57 |
| mzanetti | well, the main reason was the other comment | 10:57 |
| tsdgeos | so problably no point on adding a comment | 10:57 |
| tsdgeos | ok the other comment | 10:59 |
| tsdgeos | mzanetti: you're right that that looks pretty dangerous and i guess it's only working because qtquick is doing some delayed connection of stuff somewhere, but adding a simple QMetaObject::invokeMethod with Qt::QueuedConnection fixes your issue, doesn't it? | 11:03 |
| mzanetti | let me have a look | 11:03 |
| === vrruiz_ is now known as rvr | ||
| mzanetti | tsdgeos: right... making setSourceSize invokable and onvoking that queed would probably do it | 11:08 |
| * mzanetti tries again | 11:08 | |
| mzanetti | tsdgeos: right... making setSourceSize invokable and invoking that queued would probably do it | 11:08 |
| mzanetti | ok, well then, thanks for explaining. Changing my vote to a needs fixing. Can you also please add a comment for the first question? | 11:11 |
| === Malsasa_ is now known as Malsasa | ||
| mzanetti | tsdgeos: is the ignoreAbort really needed? I mean, if the future is working already, the reply is already finished and abort won't do anything any more, no? | 11:14 |
| tsdgeos | mzanetti: it clears the data from the reply | 11:15 |
| mzanetti | oh, really... didn't know that | 11:15 |
| tsdgeos | me neither | 11:15 |
| mzanetti | ok then it is needed indeed | 11:15 |
| tsdgeos | got lots of interesting crashes/errors because of that | 11:15 |
| mzanetti | I can imagine | 11:15 |
| Saviq | tsdgeos, fun times http://pastebin.ubuntu.com/8938872/ :| | 11:16 |
| tsdgeos | damn | 11:16 |
| tsdgeos | Saviq: i guess we can't repro, no? | 11:17 |
| Saviq | tsdgeos, actually we can, but it needs to be timed | 11:17 |
| Saviq | tsdgeos, happens with mterry's branch to skip the second PIN unlock screen if emergency dialer is up | 11:17 |
| tsdgeos | i see | 11:17 |
| tsdgeos | if we can kind of repro this i don't think it'd be that hard to fix | 11:18 |
| Saviq | let's see how often I can get this | 11:19 |
| facundobatista | Hola! | 11:19 |
| mzanetti | o/ | 11:19 |
| tsdgeos | mzanetti: any suggestion for the comment? | 11:23 |
| tsdgeos | mzanetti: // worker->m_reply is always valid at this point | 11:24 |
| tsdgeos | seems a bit weeak | 11:24 |
| mzanetti | tsdgeos: yeah, elaborate a bit more please. something like: m_reply has finished at this point and won't be touched any more | 11:35 |
| mzanetti | Saviq: can we do such changes in control files now or will that still break with ~rtm? https://code.launchpad.net/~seb128/unity8/set-inline-reply-hint/+merge/240766 | 11:39 |
| Saviq | mzanetti, it'd have to be "translated" to rtm, the upstream version should have been bumped instead | 11:40 |
| seb128 | mzanetti, I should append a ~ to the version | 11:40 |
| Saviq | seb128, well, we need to be able to depend on that change in u-s-c | 11:40 |
| seb128 | oh, in fact there is no revision there | 11:40 |
| seb128 | so it should be fine | 11:40 |
| Saviq | seb128, but > 20141105 in rtm might not include that change | 11:40 |
| seb128 | Saviq, mzanetti, we don't want those changes in rtm anyway | 11:41 |
| Saviq | seb128, not now, but we'll have the same problem for ota | 11:41 |
| seb128 | we have a workaround for rtm | 11:41 |
| seb128 | Saviq, k, feel free to change it to suit your workflow better | 11:41 |
| mzanetti | ok... works for me then... I just wanted to make sure as we broke the train with such things a couple of times already | 11:41 |
| Saviq | seb128, https://code.launchpad.net/~seb128/ubuntu-settings-components/define-text-hint-property/+merge/240706/comments/593655 | 11:42 |
| seb128 | Saviq, k | 11:48 |
| tsdgeos | mzanetti: actually i'm not sure i can do the invokemethod thing, in my mind invokemethod with a delayed connection should be smart enough to not crash if the receiving object goes away, but i am reading the code and seems it is not :/ | 12:18 |
| tsdgeos | reading more | 12:18 |
| tsdgeos | not a trivial amount of code | 12:19 |
| mzanetti | tsdgeos: it is not | 12:19 |
| mzanetti | tsdgeos: QPointer helps with that though | 12:19 |
| * mzanetti digs out some code | 12:19 | |
| tsdgeos | sure, but i can't qpointerize Qt code ;) | 12:19 |
| tsdgeos | yeah i can add yet another intermediate object | 12:20 |
| tsdgeos | meh | 12:20 |
| mzanetti | tsdgeos: https://gitorious.org/xbmcremote/xbmcremote/source/44687da6c75326be456d5778d728afcbf1a2386e:libxbmcremote/imagecache.cpp#L167 | 12:20 |
| mzanetti | tsdgeos: you'd just need to hold the target in a QPointer yourself. the data will be smart enough to go to 0 which in turn makes the invoke smart enough | 12:21 |
| mzanetti | invoke just fails if you have a valid address for an invalid object | 12:21 |
| tsdgeos | qt should add the qpointer in QPostEvent | 12:21 |
| mzanetti | yeah, I guess it should | 12:21 |
| mzanetti | not sure about other ramifications with that though | 12:21 |
| tsdgeos | but i guess it would be slower | 12:21 |
| tsdgeos | hmmm | 12:23 |
| tsdgeos | i don't see how that works at all | 12:23 |
| mzanetti | the code I linked? | 12:23 |
| tsdgeos | yeah, i mean .data() returns a qobject no? | 12:23 |
| mzanetti | or 0 if it went away | 12:24 |
| tsdgeos | sure | 12:24 |
| mzanetti | yeah, invokeMethod(0) doesn't do anything | 12:24 |
| tsdgeos | but the problem is if it goes away *after* i call invokeMetho | 12:24 |
| tsdgeos | not before | 12:24 |
| mzanetti | uh oh | 12:24 |
| tsdgeos | before i know it's there | 12:24 |
| * mzanetti thinks about it | 12:24 | |
| tsdgeos | i have a mutex for that :D | 12:24 |
| mzanetti | A programmer had a problem. He thought to himself, "I know, I'll solve it with threads!". has Now problems. two he | 12:26 |
| greyback | I've always worked under the assumption that invoke doesn't watch the lifetime of the object you pass it | 12:26 |
| mzanetti | greyback: it doesn't | 12:28 |
| greyback | well I've been right all this time so :) | 12:29 |
| mzanetti | greyback: the problem we're facing now is that even though we watch it ourselves, there might be the possibility of it going away in between we call invoke() and it actually happening | 12:29 |
| mzanetti | tsdgeos: well, signal/slot connection otherwise, that should be clever enough to disconnect it/ check it when it actually happens | 12:30 |
| greyback | mzanetti: yep. signal/slot ideal then | 12:31 |
| tsdgeos | mzanetti: on the other hand http://paste.ubuntu.com/8940082/ works just fine | 12:35 |
| tsdgeos | and valgrind does not complain at all | 12:35 |
| tsdgeos | so it seems indeed somewhere is seeing that has to remove the post | 12:35 |
| mzanetti | does invokeMethod use postEvent in the end? | 12:36 |
| tsdgeos | yep | 12:36 |
| tsdgeos | if it's a queued one | 12:36 |
| mzanetti | hmm. ok. then I guess we're good. also I didn't have any troubles with that xbmcremote code I posted above. and it's been in use for quite a while now | 12:37 |
| tsdgeos | QCoreApplication::postEvent(object, new QMetaCallEvent(idx_offset, idx_relative, callFunction, | 12:37 |
| tsdgeos | 0, -1, nargs, types, args)); | 12:37 |
| mzanetti | tsdgeos: you still need the QPointer before the invokation though as it will break passing an invalid address | 12:37 |
| tsdgeos | now i want to read the code again to see where it's removing it from the even list | 12:37 |
| tsdgeos | mzanetti: no i don't | 12:37 |
| mzanetti | or well, some other means of making sure it's there | 12:38 |
| tsdgeos | it's guaranteed the pointer is valid at that point | 12:38 |
| mzanetti | ok | 12:38 |
| tsdgeos | ah right qobject destructor does | 12:40 |
| tsdgeos | if (postedEvents) | 12:40 |
| tsdgeos | QCoreApplication::removePostedEvents(q_ptr, 0); | 12:40 |
| tsdgeos | so yeah we're good | 12:40 |
| mzanetti | aha! cool | 12:41 |
| tsdgeos | so basically you need to guarantee the object is valid until the end of the invokeMethod Queued call | 12:43 |
| tsdgeos | after that you're fine filling it | 12:43 |
| tsdgeos | killing it | 12:43 |
| mzanetti | yep | 12:44 |
| === MacSlow is now known as MacSlow|lunch | ||
| Saviq | cwayne, hey, can you assign bug #1389192 somewhere? | 13:16 |
| ubot5 | bug 1389192 in unity8 (Ubuntu) ""Fitbit" text in Dashboard has poor grammar, capitalization, punctuation, and call to action" [Undecided,New] https://launchpad.net/bugs/1389192 | 13:16 |
| Saviq | and bug #1389195 | 13:16 |
| ubot5 | bug 1389195 in unity8 (Ubuntu) ""Fitbit" section in Dashboard goes to a near-empty screen when tapped" [Undecided,New] https://launchpad.net/bugs/1389195 | 13:16 |
| mzanetti | dednick: hey, is this still needed? https://code.launchpad.net/~nick-dedekind/unity8/axis.calculator.first.position/+merge/174262 | 13:22 |
| === alan_g|afk is now known as alan_g|lunch | ||
| cwayne | Saviq: ugh, i marked invalid, will do so again and move to hanloon | 13:30 |
| ragnarock | Hi guys ,I am facing some screen issues in my asus x550l 14.10.can I contact to someone for support and fixing this thing | 13:31 |
| Saviq | cwayne, yeah, I know you did, but Matthew just re-confirmed it again, don't we have a public project that we could assign to? | 13:32 |
| cwayne | Saviq: no because it's a private scope | 13:33 |
| Saviq | :/ | 13:33 |
| cwayne | Saviq: i just logged the same bug in hanloon and marked this one invalid | 13:33 |
| Saviq | cwayne, sounds like it's gonna ping-pong back to you | 13:33 |
| Saviq | or well, me | 13:33 |
| cwayne | Saviq: i commented with the new bug url | 13:34 |
| Saviq | ok thanks | 13:34 |
| cwayne | sorry, just get mad that i talked to him on irc and told him this was a private scope that shouldn't have public bugs, bit frustrating when people don't listen | 13:34 |
| Saviq | mzanetti, I noticed recently that BFB does not reset the dash to apps properly any more if you have a temp scope open (e.g. store) | 14:06 |
| Saviq | works if you're in/over Manage Scopes, but not otherwise | 14:07 |
| Saviq | mzanetti, I also had a feature proposal for Tagger - would be nice to have a history of recognized codes, otherwise I had to take photos and then try and recognize them after (which didn't always work depending on how the photo came out) | 14:09 |
| * Saviq goes back to filing bugs | 14:15 | |
| === alan_g|lunch is now known as alan_g | ||
| dednick | mzanetti: hm. nope, that's kinda old | 14:22 |
| mzanetti | Saviq: ok, yeah, please file some bugs, will implement it when I touch tagger the next time | 14:26 |
| mzanetti | Saviq: can we drop this? https://code.launchpad.net/~saviq/unity8/fox-clock-formatting/+merge/198843 | 14:35 |
| mzanetti | its from 2013 too | 14:35 |
| === MacSlow|lunch is now known as MacSlow | ||
| Saviq | mzanetti, done | 14:36 |
| Saviq | mzanetti, I got stuck on lockscreen, no crash, did you get anywhere with investigating that? | 14:37 |
| mzanetti | let me find the bug | 14:37 |
| * Saviq is installing dbg symbols right now, but there's a suspect "recvmsg" in the top thread | 14:37 | |
| mzanetti | hmm, interesting | 14:38 |
| mzanetti | Saviq: so I personally only ever saw this when being away from a computer | 14:39 |
| tsdgeos | damn, it's a pain that vivid and rtm are not compatible | 14:59 |
| * tsdgeos flashes mako with vivid | 14:59 | |
| tsdgeos | devel-proposed is now vivid, right | 15:06 |
| tsdgeos | ? | 15:06 |
| Saviq | tsdgeos, yes | 15:07 |
| === cwayne is now known as cwayne-afk | ||
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === om26er_ is now known as om26er | ||
| mhall119 | Trevinho_: ping | 18:08 |
| === dandrader is now known as dandrader|afk | ||
| mhall119 | Trevinho_: bregma: we still don't have any session on Unity 7 for UOS | 19:35 |
| mhall119 | I think, given the more user/consumer focus of UOS, that we really should have a session on how to use (and get the most out of) the current default desktop | 19:35 |
| mhall119 | kgunn: we also have no session on Mir, which I think we really need both to talk about what currently works (screenshots now in Unity 8, which is awesome) as well as what's planned for the future (especially concerning desktop feature support) | 19:40 |
| kgunn | mhall119: i lost connection for a bit....so what's the also | 19:45 |
| mhall119 | kgunn: we also have no session on Mir, which I think we really need both to talk about what currently works (screenshots now in Unity 8, which is awesome) as well as what's planned for the future (especially concerning desktop feature support) | 19:45 |
| mhall119 | kgunn: before the "also" was be asking Trevinho_ and bregma for Unity 7 sessions | 19:46 |
| mhall119 | kgunn: there's a lot of confusion and open questions about what desktop features Mir will support, UOS is a great opportunity to clear tha tup | 19:48 |
| kgunn | mhall119: i proposed this | 20:24 |
| kgunn | http://summit.ubuntu.com/uos-1411/kgunn72/meetings | 20:24 |
| kgunn | if i could thurs late morning that'd be great | 20:24 |
| mhall119 | kgunn: thanks, I've added it to the Ubuntu Development track | 20:34 |
| mhall119 | will ping those track leads to review it | 20:34 |
| kgunn | mhall119: i figure i'll show up with a semi-scrubbed roadmap and just talk thru with some time for Q&A | 20:35 |
| === dandrader|afk is now known as dandrader | ||
| mhall119 | kgunn: sounds like a plan, thanks | 20:38 |
| === qengho is now known as CardinalFang | ||
| === CardinalFang is now known as qengho | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!