[01:51] where is smspillaz ;) [02:06] sleeping probably [02:24] Ideas for testing welcome: https://code.launchpad.net/~thumper/unity/fix-865840/+merge/89812 [02:29] thumper, hey. So I have a question about what I should be working on next. [02:30] how's your valgrind? [02:30] thumper, need to practice using it! [02:30] bschaefer: ok... [02:31] alias valgrind-unity='G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --num-callers=50 --leak-check=full --track-origins=yes --log-file=unity-valgrind.`date +%Y%m%dT%H%M%S`.txt compiz --replace 2>&1 | tee /home/tim/unity-valgrind.`date +%Y%m%dT%H%M%S`.log' [02:31] bschaefer: there is my alias [02:31] bschaefer: you'd need to change the path [02:31] bschaefer: what I do is switch to vt1 and make sure that the appropriate bits are exported [02:31] function use-local-compiz [02:31] { [02:31] export DISPLAY=:0 [02:31] export COMPIZ_CONFIG_PROFILE=ubuntu [02:31] } [02:32] from my .bashrc [02:32] running under valgrind makes it very slow [02:32] but it is gathering nice data [02:32] try it a few times [02:32] and perhaps we could have a talk to go through some output [02:32] thumper, cool, I dont think I have ever used alias before but it makes sense [02:32] bschaefer: put that in your .bashrc file too [02:33] thumper, alright, doing that right now [02:37] thumper, ok, done with that. Now using that which will put the logs files in ~/unity-valgrind.* and looking thought those for mem leaks? [02:37] looking through those* [02:39] one of those will be the output from the console [02:39] the other will be the valgrind output [02:39] the .txt file I think is the valgrind one [02:39] with the .log being the console log output from unity [02:40] there are interesting things with uninitialised reads/writes/jumps to [02:40] they often relate to uninitialised variables [02:40] along with the potential / definite leaks [02:41] thumper, you are right about it being slower, but it's all working [02:41] and cool this should be fun to dig through [03:04] thumper, so I just found 3 in LauncherModel.cpp. Should I just make a branch and request a merge? [03:17] bschaefer: sure === dyams|away is now known as dyams [03:25] good morning [03:27] hi dyams [03:28] thumper: hi :) [03:30] thumper, alright done. https://code.launchpad.net/~brandontschaefer/unity/uninitialized-launcher-model/+merge/89819 [03:32] bschaefer: hang on [03:32] bschaefer: those variables have default constructors [03:32] bschaefer: they are std::lists [03:32] bschaefer: they don't need to be explicitly initialized [03:35] thumper, hmm well valgrind doesn't seem to complain anymore about though [03:35] bschaefer: can you pastebin me the valgrind log? [03:37] thumper, it's not showing up anymore and I removed that one...which I shouldn't have but I was testing if valgrind would complain again [03:37] thumper, Ill delete the init and then restart valgrind one sec [03:38] it was a un inited stack error though; and it pointed to LauncherModel::Populate(). [03:49] bschaefer: it and it2 :) [03:51] thumper, dang, I just saw it point to that file then saw the 3 Base vars were not inited and I couldn't find the class [03:51] then you said it was a list, then I found the typedef... [03:51] that explains that :) [03:52] thumper, It looks like just it2 needs to be removed; and it looks like it gets inited in the for loops [03:54] bschaefer: ok, so change your branch to revert your other commit (you could just uncommit it (then revert)), and change it to delete it2 [03:54] bschaefer: bonus points for changing the for loops to range based for loops [03:56] thumper, alright; and will try to change to use a range. (Looking it up!) [04:00] thumper, so I would use for_each and then make a new private function which does those 2 lines of code [04:03] thumper, opps never mind... [04:04] thumper, found out what I needed, I need to start reading the new c++ standard... === dyams is now known as dyams|away [04:41] thumper, alright pushed, getting bzr to push took a little === dyams|away is now known as dyams [09:18] hey greyback, one question about testability-verify-... [09:18] Saviq: shoot [09:19] `raise if PASSTHROUGH_EXCEPTIONS.include?...` sounds like it shouldn't raise if PASSTHROUGH_EXCEPTIONS contains that Exception class? do I get that right? [09:23] Saviq: yeah, that's correct. And I'm missing the definition of PASSTHROUGH_EXCEPTIONS in my MR! [09:23] greyback, but also, if I understand ruby correctly (and I might not), the line: [09:24] It's so that the test runner won't catch errors like NoMemoryError, SignalException, Interrupt, SystemExit [09:24] raise if PASSTHROUGH_EXCEPTIONS.include? $!.class [09:24] will _only_ raise if the condition is true? [09:24] greyback, I removed the Approved status from the MR so that tarmac doesn't merge [09:25] Sorry, let me start again [09:26] "raise if PASSTHROUGH_EXCEPTIONS.include?" *will* raise if the exception thrown is one of the PASSTHROUGH exceptions, i.e. if NoMemoryError occurs, it is caught by run(), but then raised again [09:26] ah so those aren't treated as failures [09:26] exactly [09:26] or errors [09:26] they basically stop the test [09:26] indeed [09:27] makes sense, only maybe we should call that list something else? [09:27] like CRITICAL_EXCEPTIONS or something? [09:27] Can do. I just copied what Test::Unit was using. But that's a better name IMO [09:28] cool [09:32] dyams, hey, re remove-unused-code-shell-launcher-animation - do you think we could have a test to ensure no regressions there? [09:33] greyback, that's actually a question for you, too ^ - do we yet have a plan of how to test transitions? are we targeting that at all? [09:33] Saviq: define "transitions" for me please, animations between states? [09:33] greyback, yes [09:34] greyback, the above is about animating the launcher position [09:34] maybe we could have visual verification with 3-4 steps along the way [09:34] that might not be fast enough, though [09:35] Saviq: right, I'd be concerned how reliable that would be [09:35] yup, exactly [09:35] we could test the value of x along the way, though [09:35] again - in 3, 4 steps [09:36] just to verify it reaches the in-between states and doesn't go full-on at once [09:36] saviq: one sec [09:36] That's something that needs more research, how to do timing-measurements with testabililty. How to check a quantity changes smoothly from x to y in time t. [09:37] yeah and also the issue I can think of now is that there's always a resolution, and qml uses reals for animations [09:37] saviq: it was a dead code.. hence removed [09:38] dyams, that's fine, but removing dead code calls for ensuring it was dead by a test ;) [09:38] Saviq: Checking the value a few times might do then [09:38] but you would have to use ranges [09:38] 'cause the actual value would be something like 23.2131412321 [09:39] and again, it might miss 23 completely if the animation is fast enough that with every frame it skips some values [09:40] that calls for video verification... [09:40] anyway [09:40] some time later [09:40] saviq: :) sure... [09:40] dyams, nevermind, looks like there's no way yet to test that yet [09:41] and the current tests already ensure the launcher works good enough [09:41] saviq: true [09:41] greyback: some questions about testability-target-host-split, ready for them? or busy? [09:41] tsdgeos: in meeting, 5-10 mins [09:41] mhall119; hyia, to answer your earlier question: each Lens should be for a specific data type, e.g. Music, Books, Sheet Music, News, Photos, Comics, etc... If a Lens for a content type already exists, it is hoped other developers will contribute scopes to interface new sources of data with the Lens. So if a 'Comics' Lens already exists, we would hope that a Indian comic fan would write a scope to pull content from say http://onlin [09:41] eindiancomics.blogspot.com/ into the comics Lens. We would want to discourage them from writing another Lens, because it is more useful to users to have less Lenses interfacing with more sources of content. Part of the value the Dash gives to users is content aggregation, and while a proliferation of Lenses would make life more difficult, a proliferation of scopes is very useful and desirable. Basically the rule is "If a Lens alre [09:41] ady exists for the data type, focus on writing scopes for that Lens. No not create a new Lens, if you need to modify the Lens contact the Lens author and contribute a patch" [09:44] dyams, one thing you could test close to that code is manualSliding [09:44] we don't yet have it in -shell [09:44] saviq: ok, but this branch if for shell itself [09:45] dyams, yes I know [09:45] will test and review properly soon [09:45] saviq: thank you :) [09:45] ok dyams do your stuff, Kaleo will be doing the gesture stuff anyway, he'll do the tests for that [09:46] saviq: ok === dyams is now known as dyams|lunch === dyams|lunch is now known as dyams [10:10] nerochiaro: ping [10:10] dyams: yes ? [10:11] nerochiaro: Bfb activate is using DBus to display Dash. no? [10:11] dyams: no if you merge my branch [10:11] nerochiaro: ah..ok [10:11] dyams: it was, but i'm removing this [10:11] nerochiaro: you are? [10:12] tsdgeos: yep, we had a discussion with Kaleo yesterday and there will be some restructuring in that part [10:12] tsdgeos: what are you working on ? [10:12] nerochiaro: sure. that was my concern. [10:12] nerochiaro: i did that already [10:12] that = do not use dbus [10:13] tsdgeos: what do you use instead ? [10:13] nerochiaro: https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_no_dbus_to_ourselves/+merge/89247 [10:14] tsdgeos: dyams: nevermind, the stuff i'm working on is not related [10:14] was my mistake [10:14] nerochiaro: ok :D [10:15] * nerochiaro needs another cup of tea [10:15] sorry guys [10:15] tsdgeos, you saw my comment on that? can you please go through all the changes and ensure they are tested? [10:15] Saviq: i did [10:16] ok [10:16] Saviq: there's two changes, 1 to bfb, that is tested already elsewhere, 2 to alt+f2 to open the dash, i'm trying to test that now but failing [10:16] somehow i can get testability to introspect unity-2d-places (in unity-2d) [10:17] any idea why that might be happening? [10:17] nerochiaro: ok [10:18] tsdgeos: I hope removed that DBus call in your new branch already [10:18] tsdgeos, you _can_? [10:18] Saviq: i can't :D [10:19] well, i can but there's only one child shown in tdriver_visualizer [10:19] which means it's not very useful [10:19] tsdgeos, you'll have to take that with greyback [10:20] yep [10:20] waiting for him [10:20] tsdgeos: one child of what? [10:20] was in a 5 min meeting 30 min ago [10:20] dyams: in the tdriver_visualizer tree, there's the "sut" root and then there is just one child "unity-2d-places" [10:21] but i can't see the rest of stuff inside it [10:21] tsdgeos: ask tdriver to refresh in 5 secs, in the mean time open the dash and the lense you want [10:22] ahh [10:22] that worked [10:22] cool [10:22] tsdgeos: yes [10:27] tsdgeos: ok, I'm free now. What did I miss :) [10:28] greyback: nothing important, just some comments about your merge for the split thing [10:28] tsdgeos: they're very important :) [10:28] greyback, your fail-not-error branch got merged (even though I changed its status to Needs Review...) [10:28] greyback: there's a "sleep 1" in a test that seems like it might be better to do in a separate MR? [10:29] tsdgeos: Hmm, possibly. I noticed that the delay was needed when I made that split. It caused the test to fail, so I added it. [10:29] greyback: also i was wondering about the tests you have commented with "#Disabling this failing test due to poor window Xid detection by xdotool - fix on the way" [10:30] My thinking was to keep the tests passing. [10:30] greyback: not that i care much about that sleep 1, i understand it's a "fix the test because of this feature uncovers a bug in the test", so it's ok [10:30] greyback: when is the "fix" for those arriving? [10:30] greyback: i'd say it's better if we keep them failing so we realize there's some things that don't yet work? [10:31] tsdgeos: yeah, xdotool's search gives you every XId an application has. Often an app has more than one. xdotool gives you them all, but only one is the actual visible window, and it's not obvious which [10:31] not sure if we use those features though [10:31] tsdgeos: I've a branch with a in-progress fix in my machine [10:33] If we are testing if an application is started by the dash, or want to move application window around, we need a reliable search [10:34] ok [10:34] tsdgeos: I've no objection to having tests failing in trunk right now. In which case I'll remove these comments & stuff [10:34] so i'd prefer if we keep the failing tests [10:34] as something we know has to be fixed [10:34] fair enough [10:34] greyback: also are we getting an "official" qttasserver in precise? Would be cool not to depend on your ppa [10:35] tsdgeos: Yeah, that's something I mean to do :( [10:35] it's on my todo list [10:36] ok [10:36] tsdgeos, greyback what about disabling them with xtest? [10:37] so that they don't contaminate the test results? I know that might reduce the apparent need to fix them [10:37] Saviq: I also have on my todo list a way of counting all disabled tests, so they're not forgotten about [10:40] Saviq: i'm not sure a real fail is a contamination of the test results, but i'm ok with wathever the bigger team decides i was just exposing my opinions :-) [10:41] tsdgeos, remember that once the auto- stuff is implemented a failed test means no merge [10:42] Saviq: ok, then yes, we need to hide fails [10:42] greyback: i'll approve the MR then [10:43] tsdgeos: I'll remove those little comments & bits. [10:43] greyback: read up, Saviq has a good reason to leave that commented [10:44] tsdgeos: ah yes. You had another comment about me missing something from the README [10:44] greyback: it is in the README, but not in the wiki, the stuff about adding the ppa [10:45] tsdgeos: ohhh, that had me confused [10:47] tsdgeos, re root file tests - only the last test actually fails [10:48] looks like verify_not() works kind of weird [10:49] Saviq: what you mean with "only the last test actually fails" ? [10:49] tsdgeos, the first two tests pass [10:49] the first one is ok to pass [10:49] but the second should fail, no? [10:49] all of them should pass [10:49] tsdgeos, not when I only merged the tests on stock unity-2d-shell [10:50] tsdgeos, I'm testing the tests themselves [10:50] well, you can't tests the tests on stock unity-2d-shell [10:50] I can [10:50] sure [10:50] but does not make sense [10:50] does [10:50] the feature is not there [10:50] exactly [10:50] so the tests should fail [10:51] that's exactly what tests should do [10:51] if the feature isn't there [10:51] that if the previous code was good enough [10:51] sure [10:51] i can't help that when previously you gave [10:51] -thisissomeshit [10:51] it did not fail [10:51] tsdgeos, yes, of course [10:51] tsdgeos, but the second test should fail [10:51] ok [10:52] so let's start again because i'm confused then :D [10:52] tsdgeos, "Verify app does not start without a rootqml parameter" does not fail [10:52] on stock shell [10:52] unity-2d-shell launches fine [10:52] and that should be a fail, shouldn't it? [10:53] yes [10:53] it should [10:53] exactly [10:53] it doesn't [10:53] i see [10:53] let me have a look [10:53] tsdgeos, https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_choose_root_file/+merge/89290/comments/193480 [10:54] tsdgeos, just `bzr merge lp:~aacid/unity-2d/unity-2d-shell_choose_root_file -c922` into unity-2d-shell [10:54] sure [10:55] I'm not sure the first test makes sense, though [10:55] not as part of root qml file test, at least [10:55] whether shell launches or not should probably be a separate test somewehre [10:55] i can remove it if you want [10:55] I think it's just cruft in there [10:56] ok [10:56] gone [10:58] dyams, please do not commit tests in one commit with the fix, makes it difficult to check whether the tests fail without the fix [10:59] saviq: ok [10:59] saviq: will have separate branch for tests from now on. [10:59] dyams, not necessarily separate branches [11:00] dyams, just separate commits at least [11:00] saviq: ok, sure [11:00] dyams, we'll probably have some guidelines on that soon [11:00] already discussed that with Gerry and Ugo [11:00] saviq: ok [11:04] Saviq: dyams: tsdgeos stand-up? [11:04] greyback, I've a meeting, IIRC, let me verify [11:04] Saviq: np [11:04] ah no, it got moved [11:04] coming [11:05] nerochiaro, standup? [11:05] Saviq: sure, hold on [11:05] holding [11:06] dyams, ? [11:06] dyams, standup [11:06] ? [11:09] saviq: oops [11:09] dyams, come on in, we already started [11:10] saviq: yes...coming [11:13] hey greyback [11:13] didrocks: yo [11:13] greyback: small question, I'm implementing the unity settings for https://docs.google.com/document/d/1ILTJDiDCd25Npt2AmgzF8aOnZZECxTfM0hvsbWT2BxA/edit?hl=en_US#heading=h.jztfy8l5q9v5 [11:14] so, the question is: do you have similar settings for 2d? [11:14] if not, it will be good that you point the same value :) [11:15] Indeed. So, we have our own dconf value for autohide on/off [11:15] We used to have the left-corner option, I can't remember if it was removed or not. [11:15] fix the god damn focus problem [11:15] beforei put my fist through several pcs [11:15] i cant believe that doesnt shit anybody else to tears ;) [11:16] snadge: unity or unity2d? [11:16] unity [11:16] same problem manifests as 2 symptoms in particular.. right click menu, sometimes disappears when you move the mouse over it [11:17] also the autocomplete feature when typing into firefox location bar.. doesnt work.. even though you are clearly typing text into it.. both problems happen when you switch from another workspace to the workspace in question [11:17] and its not easily reproduceable.. some kind of race condition [11:18] smspillaz knows about it at least [11:19] greyback: hum, so I'll need to listen to unity-2d and 3d keys it's a pain :/ [11:19] greyback: especially that one is in gsetting and the other in gconf [11:20] it happens on every pc i use unity on though [11:20] greyback: anyway, let's do it this way for now, I'll look at the settings, you need to have the icon size though [11:23] didrocks: we need it? Really? [11:23] greyback: well, the option will be there [11:23] hi all! is indicator-loader3 supposed to work with the appmenu right now? [11:23] when i try to start it (running metacity), i get this: http://paste.ubuntu.com/814857/ and an empty loader window. [11:23] and you will get bugs I guess about "why does it work in 3D" [11:23] didrocks: sure. [11:24] didrocks: ok, we had preliminary work done on that, will revisit [11:25] didrocks: I'll send you a email with where we save settings. [11:25] greyback: thanks :) [11:26] Kaleo, we'd like you to come in to discuss approaches to multimonitor support in unity-2d-shell [11:26] Kaleo, dyams is only here for another hour, otherwise we can do it tomorrow morning [11:26] (yes, I know you only have half an hour now) [11:27] saviq: Will have the same QML FilterCheckOption.qml for new renderer filter-check-option-compact too. [11:27] dyams, yup [11:28] saviq: Or shall we have a separate one already? Just for future purpose? [11:29] dyams, the file will have to be named FilterCheckOptionCompact.qml, 'cause that's how we're loading the filter renederers [11:29] getting rid of hyphens and word/camelCasing [11:29] dyams, it's probably best to either have an abstract one [11:29] and two inheriting from them [11:30] or just the compact one inheriting from the standard one [11:30] for such a small difference the latter is probably better [11:30] saviq: sure, lets have separate qml already [11:35] saviq: yes, very small difference indeed [11:37] Saviq: pushed a change to the tests of the rootqml thing, should behave correctly now (i.e fail without the feature and work with it) [11:37] tsdgeos, thanks [11:39] greyback, did you see that your fail-not-error branch got merged? you didn't manage to get the tweaks in [11:40] Saviq: yep:( Revert or do follow-up? [11:40] greyback, follow-up [11:40] Saviq: *nod* [11:41] greyback: you say merge error fixed in https://code.launchpad.net/~gerboland/unity-2d/testability-target-host-split/+merge/89743 but last commit is from 18 hours ago? [11:41] tsdgeos, the qml file in root-qml-arg is +x? [11:41] tsdgeos: hmm, didn't I push? [11:42] Saviq: should not be, let me check [11:42] Saviq: it's not here, do yo see it there? [11:42] tsdgeos, yeah, I wonder why [11:43] oh no [11:43] it's not now [11:43] I think it's VBox's shared folder issue [11:43] ignore [11:43] ok :D [11:44] greyback: seems not? [11:44] tsdgeos: did you do an actual pull? I did push [11:44] greyback: no, i'm just looking at https://code.launchpad.net/~gerboland/unity-2d/testability-target-host-split/+merge/89743 [11:44] * tsdgeos pulls [11:44] tsdgeos: yeah me too. But just in case LP is confused [11:45] no, nothing got here when pulling [11:45] r877 is the last one [11:45] tsdgeos: hmmm [11:45] tsdgeos: wrong fecking branch. [11:45] tsdgeos: sorry, my bad [11:47] Kaleo, added you to https://code.launchpad.net/~aacid/unity-2d/unity-2d-shell_choose_root_file/+merge/89290 - please have a quick look and comment whether that's what you had in mind [11:48] dyams, are you working in a RTL env? [11:48] dyams, if so, it would be great if you could tackle the RTL issues as it's difficult to test for us [11:49] tsdgeos: ok, should be there now. Sorry about that [11:50] greyback: approved that for you [11:50] saviq: no, but i needed to check it, hence tried once [11:50] tsdgeos: thank you [11:50] saviq: I'm LTR only :) [11:50] dyams, oh ok [11:51] that's actually what I thought, but just noticed all the RTL related things you put on the wiki [11:51] dyams, also, the [] is supposed to show who's working on the issue [11:51] saviq: yeah [11:51] are you working on the RTL issues you encountered? [11:51] or plan to [11:51] saviq: who is working... oh ok.. [11:52] ; [11:52] ;) [11:52] saviq: :) it is the name of the reporter yet [11:52] saviq: no, thats what I felt :) [11:53] dyams, please get rid of those you've assigned yourself to that you don't plan on working on [11:53] saviq: i remove my name there [11:54] saviq: yes, done [11:54] Saviq: note this branch: https://code.launchpad.net/~haggai-eran/unity-2d/rtl-rebased/+merge/82151 [11:54] Saviq: he's done a lot of work on RTL support for unity-2d [11:54] greyback, yeah, I know [11:54] Saviq: ok good [11:55] greyback: I think it should have been split into pieces. [11:55] greyback: I mean Haggai's branch [11:55] dyams: me too [11:56] do you? the diff isn't that big, really [11:56] Saviq: it wouldbe easier to test in smaller chunks [11:56] trye [11:56] *true [11:56] I don't like the "switch keys" approach [11:57] ah nvm [11:57] PL/EN? [11:57] it's just used in one place anyhow [11:57] greyback, no, left/right [11:57] Saviq: oh right [11:58] he has a function there that switches left for right and the other way around if RTL [11:59] anyway [11:59] true, I thought it was wordaround for panel-service not being rtl friendly [11:59] anyhoo [12:01] Saviq: the resizable-tiles stuff is needed for unity-2d. [12:01] greyback, hrm? [12:02] Saviq: you removed it from shell, no? [12:02] greyback, you mean resizable launcher? [12:02] Saviq: yes that's it, sorry [12:02] nerochiaro: did you discover how to invoke slots from testability? [12:03] greyback, yeah I reverted it for it needed revisiting [12:03] greyback, there was a whole bunch of 0.21321434312 * some value [12:03] Saviq: yeah, I didn't like that either [12:03] tsdgoes: call_method() might work [12:04] greyback, we should probably discuss that with design - what're the designed proportions between all the parts [12:04] whether it's a preset margin [12:04] stuff like that [12:04] greyback, so that's going to be supported in unity in 12.04 [12:04] Saviq: must talk to Kaloe about it. I assume he showed that work to the Designers [12:04] ? [12:05]