[00:02] thumper: hey just started doing the sru branch for nux. When you say bare minimum should I only init the variable that caused the bug or any that are not inited? (I am guessing all that are not) [00:08] bschaefer: I suggest all that are not [00:08] bschaefer: at least this way we avoid coming back to it [00:08] bschaefer: I also had an idea [00:08] bschaefer: to the general problem [00:08] thumper: yeah, that's what I was thinking [00:08] bschaefer: run unity under valgrind, and just look at the uninitialized reads [00:08] bschaefer: and filter on those in nux [00:09] bschaefer: should provide some interesting reading [00:09] bschaefer: actually, I have some valgrind logs around [00:09] bschaefer: and a script to filter them... [00:09] * thumper makes a note [00:09] thumper: I was actually going to ask you about that (since I remember you talking about that) [00:09] thumper: and I havent found the dash problem yet, but I am just getting over a cold...so I should be able to focus haha [00:10] * thumper nods [00:10] thumper: thought it was in TextEntry and an un inited var called _blocks_text [00:10] thumper: but I have eliminated a lot of areas [00:11] thumper: I almost feel like I should just make a branch and try to fix all the uninited vars [00:11] bschaefer: I wouldn't have one branch for all [00:11] bschaefer: it may be too bug :) [00:11] s/bug/big [00:11] thumper: yeah haha [00:12] thumper: i have found a lot but then they don't fix the bug and I forget about them [00:12] thumper: i feel if I am going through all these I should be fixing it along the way [00:12] yes... [00:12] we should [00:13] I can start making branchs for each file [00:13] when I finish this sru branch [00:23] bschaefer: coolio [00:42] lamalex, hi, tim penhey pinged me for some merged code [00:42] is there any problem here? [00:50] API: that's me [00:51] it was more me looking at the log and seeing that the code review didn't have any approved [00:51] I didn't notice that it was alex that did the merging [00:51] since he was one of the reviewers, it is ok as far as you are concerned [00:51] just not all the boxes ticked that I was expecting [00:52] bschaefer: are you comfortable looking through valgrind logs? [00:52] bschaefer: I have a dump of some uninitialized variables used in jumps [00:52] bschaefer: where nux is mentioned [00:52] thumper: I should be [00:53] bschaefer: they should all be missing initialization in unity or nux [00:53] bschaefer: I'll fire it over to you [00:53] thumper: I have used it a couple time before, but not for uninitalized vars [00:53] bschaefer: do you prefer your .edu email or gmail? [00:53] thumper: gmail, as my edu will be gone in a year [00:53] kk [00:54] thumper: sweet thanks [00:54] sent [00:55] thumper: cool, I might write a simple script to parse out noise [00:56] thumper: until you put up your script [00:56] * thumper sighs [00:57] thumper, ok, thanks [00:57] thumper: it looks like you already ran the script on it though...as it is all uninited vars [00:57] bschaefer: yes... and here you go lp:~thumper/+junk/valgrind-py [00:58] bschaefer: run it with 'valgrind.py ' [00:58] thumper: thanks, should have looked over it first... [00:58] bschaefer: you get dropped into a python interactive prompt [00:58] thumper: alright [01:35] thumper: https://code.launchpad.net/~brandontschaefer/nux/sru-fix-819721/+merge/82236 [01:38] * thumper waits for the diff [06:41] howdy [10:57] didrocks, Hi! you aware of bug 875557 ? [10:57] Launchpad bug 875557 in compiz-plugins-main (Ubuntu) "Compiz grid overlay appears after workspace switcher use" [Critical,Confirmed] https://launchpad.net/bugs/875557 [10:58] * om26er thinks would be better to undo the SRU update as thats a major regression [10:59] om26er: looking [10:59] ooh, I have seen that happen too, thought it was me [10:59] also bug 878516 caused by the same SRU [10:59] Launchpad bug 878516 in compiz-plugins-main (Ubuntu) "Regression: snap to screen edges to view two windows side by side doesn't restore window size correctly" [High,Confirmed] https://launchpad.net/bugs/878516 [11:00] om26er: it's not the current SRU in -proposed, isn't it? [11:01] om26er: there is a new version in -proposed which should ix some of those behaviors [11:01] om26er: or do I misread? [11:01] its a regression in compiz-plugins-main [11:01] and there is no -proposed of now [11:01] its in -updates now [11:02] didrocks, ^ [11:02] 1:0.9.6-0ubuntu4, right? [11:02] didrocks, yep [11:03] i downgraded and the problem is not there [11:03] downgraded to 1:0.9.6-0ubuntu2 [11:03] did you try 1:0.9.6-0ubuntu3 ? [11:03] ah no [11:03] hum, reverting, there is a lot of fixes there [11:03] smspillaz: ^ [11:04] right now, the current glitch seems way less important than what 1:0.9.6-0ubuntu3 is fixing [11:04] I'll have a look when I get back [11:04] i think i did test 1:0.9.6-0ubuntu3 and the same [11:05] om26er: and, and I'm quite not confortable reverting this one [11:05] smspillaz: basically, just to sum up, latest SRU regressed bug #875557 and bug #878516 [11:05] Launchpad bug 875557 in compiz-plugins-main (Ubuntu) "Compiz grid overlay appears after workspace switcher use" [Critical,Confirmed] https://launchpad.net/bugs/875557 [11:05] Launchpad bug 878516 in compiz-plugins-main (Ubuntu) "Regression: snap to screen edges to view two windows side by side doesn't restore window size correctly" [High,Confirmed] https://launchpad.net/bugs/878516 [11:05] great [11:05] didrocks, i have seen like 3-4 big bugs with the update [11:06] I can't seem to get anything right these days *shrug* [11:06] om26er: would have been nice that people detected them while it was in proposed :) [11:06] we already pushed -0ubuntu4 because of the regression in ubuntu3 [11:08] didrocks, yeah wonder what happened with the SRU testers there :-O [11:08] c-p-m is such a nightmare to maintain [11:08] * om26er did SRU tested in the past :p [11:08] *testing [11:10] Does nux/unity support GtkIMContext, for instance in the search text entries? [11:11] smspillaz: ? [11:12] murrayc: not a question I can answer, sorry [11:12] (don't know) [11:13] pretty sure that njpatel did some IM related stuff in unity though [11:24] murrayc, i think the O version does [11:25] mhr3: What is the "0 version"? [11:25] oneric [11:25] oneiric* [11:25] By the way, am I right that nux dropped the glibmm dependency? If so, I think that was wise. [11:26] mhr3: Thanks. We, here at Openismus, will test it out sometime over the next few days. [11:32] murrayc: don't you maintain glibmm ;-) ? [11:36] smspillaz: Yes. I mentioned at the time that the IOChannel code has some problems. There are bug reports, I think. [11:44] kamstrup: hi, i've got a tentative fix for bug 785101 [11:44] Launchpad bug 785101 in unity (Ubuntu) "unable to remove the "Apps Available for Download" section from Applications Lens" [Undecided,Opinion] https://launchpad.net/bugs/785101 [11:44] though i have to say i'm on natty so i could only check that it compiles but not test it... [11:45] kamstrup: it's in the unity-lens-applications and unity branches linked from that bug report [11:47] kamstrup: do you feel like giving it a try? i'm asking because of your comment #8 there [11:49] ockham_: it was against natty? [11:49] * kamstrup is not sure he has a natty box around... [11:49] nope, against trunk (via pbuilder) [11:50] ah, nice :-) [11:50] ockham_: seems you'remissing the settings schema? [11:50] it's in the unity branch [11:51] ockham_: also; did you bind() the settings to react on changes? [11:51] kamstrup: oops. i'm afraid no. [11:51] kamstrup: was a bit of an experiment, i admit [11:52] ah, you're just looking up the value on each query. That works as well [11:52] kamstrup: yeah, i hoped so [11:52] although also slower [11:52] so should i bind() it instead? [11:53] ockham_: if you make display_most_used_apps and display_available_apps real properties on the class then you can use gp_settings.bind() [11:54] ockham_: I think so. When we're running this on a tablet one day, we want every ounce of performance [11:54] okay, i'll do that now [11:54] cool [11:55] ockham_: when you've done that and added the schema you can merge propose it. I can probably do the needed autofoo magic to install the schemas if you want [11:56] kamstrup: about the schema, isn't it okay the way i put the options into unity's schema? [11:56] ockham_: ah, I didn't see. [11:56] ockham_: although that sorta creates a runtime dep on unity that we don't have currently I think... [11:57] the thing is, there's already an unity-lens-applications related option in unity's schema -- for u-l-a's runner [11:58] ockham_: ah, you're right [11:58] ockham_: although - that sucks :-) [12:00] ockham_: this is all slowly coming back to me - I remember complaining about this when we added the runner back in the hay day :-) [12:01] so this stuff should really be moved to a schema that ships with u-l-a? [12:02] ockham_: I think so... let me check with didrocks... [12:03] didrocks: the gschema for the runner... should we not move that into u-l-a? [12:03] to remove the runtime hard dep on unity... [12:03] kamstrup: it's depending on unity-common, isn't it? [12:03] as the schema is there IIRC [12:03] * didrocks checks [12:03] didrocks: still, for developers - it's a dep on lp:unity [12:04] makes it harder to maintain [12:04] kamstrup: well, we already have that dep for some icons IIRC [12:05] but either way, I have no strong opinion, move it if you prefer [12:05] didrocks: ok - i probably will. it makes it easier to accept patches [12:06] (and easier to test) [12:06] kamstrup: sure! :) [12:08] ockham_: I'll move the schema from unity into u-l-a and ping you when I am done [12:08] kamstrup: great! can you include the options from my unity branch? [12:09] kamstrup: and, um, can you help me some more about the bind() thing? [12:10] kamstrup: i'm declaring display_most_used_apps and display_available_apps as private members of Unity.ApplicationsLens [12:11] ockham_: if you declare them like this they'll work with bind(): public bool display_most_used_apps { get; set } [12:12] and then just add the line gp_settings.bind() [12:12] and display_available_apps = this.gp_settings.get_boolean (DISPLAY_AVAILABLE_APPS_KEY); [12:12] to the constructor? [12:12] (and the same for most_used, that is) [12:14] kamstrup: ping^ === MacSlow is now known as MacSlow|lunch [12:39] ockham_: sounds right [12:39] kamstrup: i haven't found any examples for bind() [12:40] kamstrup: but the reference suggests something like this.gp_settings(DISPLAY_MOST_USED_APPS_KEY, this, display_most_used_apps); [12:43] ockham_: i'm not sure exactly what paramsgo where :-) but it's something like that :-) [12:43] ockham_: i filed https://bugs.launchpad.net/unity-lens-applications/+bug/890660 with merge requests [12:43] Ubuntu bug 890660 in unity-lens-applications "Apps lens should bundle its own gsettings schema" [Medium,In progress] [12:43] maybe we can punk mhr3 to review ^^ ? :-) [12:45] kamstrup: do you know of any good examples for this bind() stuff? haven't found anything in unity... [12:48] ockham_: I think it must be something like this: [12:50] gb_settings.bind (DISPLAY_MOST_USED_APPS_KEY, this, "display-most-used-apps", GLib.SettingsBindFlags.DEFAULT); [12:50] (warning: untested) :-) [12:50] kamstrup: sounds good -- and seems i was close [12:54] kamstrup: another question, what are the "get" and "set" for in the declaration [12:54] public bool display_most_used_apps { get; set; } [12:54] ? [12:54] ockham_: that is a vala-ism. it means that the variable becomes a "property" [12:55] ockham_: properties are like reach public variables, that you can have change notifications on [12:55] kamstrup: oh, cool. do we need both get and set? u-l-a only reads those properties. [12:55] ockham_: I think we need the set; as well in order to allow gsettings to write to it [12:55] ok [12:59] kamstrup: ok, i compiled it successfully. i'm going to commit it now. before i push it, how can i merge your lp:~kamstrup/unity-lens-applications/include-gsettings-schema branch? (bzr newbie here) [13:06] ockham_: you can just 'bzr merge lp:~kamstrup/unity-lens-applications/include-gsettings-schema' when you're standing in your own branch. Not much to it :-) [13:06] ockham_: and then bzr commit [13:06] kamstrup: strange, i get "ssh_exchange_identification: Connection closed by remote host" [13:06] "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist." [13:06] ockham_: oI got that just a while ago... [13:06] dunno what it was [13:07] i logged out and back in, and then it worked [13:07] I think they must have reset some services [13:07] kamstrup: hm, at 3rd attempt it seems to work now [13:07] wow, odd [13:07] yup [13:08] kamstrup: is there a way to automatically re-use your commit msg or something boilerplate like "merged from lp:~kamstrup/unity-lens-applications/include-gsettings-schema?" === MacSlow|lunch is now known as MacSlow [13:17] ockham_: that msg is ok. [13:19] kamstrup: okay i think i got one final question: do i need to explicitly add my gsettings options to data/com.canonical.Unity.AppsLens.gschema.xml.in.in now? [13:20] what's puzzling me is that com.canonical.Unity.ApplicationsLens.gschema.xml also contains a shows-on-edge key in com.canonical.Unity.ApplicationsLens [13:20] where does that come from? [13:29] ockham_: where do you see that shows-on-edge key? [13:30] ockham_: but yes; you need to put your schema in there [13:30] in the generated com.canonical.Unity.ApplicationsLens.gschema.xml [13:32] kamstrup: ^ === zyga is now known as zyga-afk [13:37] ockham_: ah, no, only edit the .in.in version [13:37] kamstrup: sure; i was just curious where that stuff came in from [13:39] kamstrup: btw, what gsettings path should i use? just desktop/unity, or something like desktop/unity/lenses/applications [13:39] ockham_: it's standard automake foo... the .in files are used to extract translation templates and such [13:39] ockham_: desktop/unity/lenses/applications makes sense I think [13:40] kamstrup: alright [13:41] Having xchat highlighting "lens" was a stupid idea :-) [13:41] davidcalle: sry, will be finished soon :-) [13:42] ockham_, just kidding ;-) [13:43] kamstrup, still necessary? [13:43] mhr3: yes [13:43] ok, going to look [13:43] kamstrup: ok, i pushed it. can you give it a try? [13:44] ockham_, so i suppose the unity branch is obsolete now? [13:44] mhr3: mine is obsolete, kamstrup's not [13:45] ah, it's removing stuff, i though it's adding... [13:46] mhr3: yep, his unity branch removes stuff that's added by his unity-lens-applications branch [13:46] mhr3: i've delete my unity branch now [13:47] ockham_, and you will make another mp on top of that, correct? [13:47] mhr3: mp? [13:47] merge proposal [13:47] ah, yeah. [13:47] as soon as someone tested it successfully, that is [13:48] mhr3: (being on natty where i can't test it myself) [13:48] right [13:48] mhr3: feel like testing it? :-) [13:48] sure [13:49] mhr3: great! [13:49] ockham_, a bit odd that you're fixing bug that doesn't affect you though :) [13:50] mhr3: well it does affect me, but i think natty's unity doesn't use gsettings yet, and i'm sure going to update some time soon anyway... [13:52] so preparing for update, cool :) [13:52] mhr3: btw if it works, do you think it could be backported to oneiric? [13:54] ockham_, dunno, i dont package stuff === zyga-afk is now known as zyga [14:10] kamstrup, mhr3: soo... did you guys check out my finished branch yet (and if it works for you?) [14:14] ockham_, where is it? [14:15] mhr3: lp:~ockham-razor/unity-lens-applications/lp785101 [14:17] ockham_, could you register a merge proposal, it's hard look it over this way [14:19] mhr3: and set you as the reviewer? [14:20] doesn't matter [14:21] mhr3: ok, mp filed [14:22] https://code.launchpad.net/~ockham-razor/unity-lens-applications/lp785101/+merge/82280 [14:30] kamstrup, hello, I was told that you may know to answer my question :P Well, I have made it on how to make dynamic quicklists, connect them to actions, disable, hide them etc, but is it possible to hide the static quicklists while the dynamic ones take place while the application is running? [14:31] hakermania: not that I know of... although that would make sense... [14:31] hakermania: can you file a bug? [14:32] kamstrup, I do, but I didn't mention any kind of problem. I just asked if it is possible to hide the static ones while the program is running and the static ones are available through the unity.h. Not a bug if possible, just a missing feature [14:33] Ido - I can [14:36] kamstrup, sorry, not a native english, now I made sense, I will file a bug :) [14:37] hakermania: not worries, I read yo loud and clear :-) [14:38] s/not worries/no worries/ - not doing too well myself either ;-) [14:43] ockham_: ok, my two branches with the schema twiddling has been merged to trunk(s) [14:46] kamstrup: great! i've filed a merge proposal and asked mhr3 to test. [14:46] cool, thanks! [14:48] kamstrup, eek, i just noticed the crawling of all binary files in user's path... do we really want that? === yofel_ is now known as yofel === m_conley_away is now known as m_conley [15:47] yey, gsettings crashes if the schema doesn't exist [15:47] that's nice [15:55] hi [15:55] is it normal that unity/2d panel^Wlauncher stops hiding after some time? [16:07] diwic, ping [16:10] guys, anyone know if the improved multi-monitor support is testable/installable on Oneiric? I had to switch over the KDE for now because unity wouldn't support my three monitor setup...I'd like to switch back sooner rather than later... [16:30] hey tedg [16:30] mhr3: thx for your review. those issues should be fixed now. can you check? [16:34] i'm afraid i have to leave now, but i might be back later on [17:02] jbwiv_, it works much better [17:03] I still dispute whether unity itself is a great tool for multi-monitor use, but... [17:09] cwillu_at_work, I could understand that [17:09] is there a way to test the new functionality on 11.10? (an easy way, that is?) [17:41] ockham_, sorry, there was some other stuff i had to do, it'll have to wait till tomorrow [17:43] mhr3: alright - thx anyway [17:48] can anyone suggest where i can find some tutorials on interacting with the Unity launcher? I was looking through the documentation here: https://wiki.ubuntu.com/Unity/LauncherAPI but all the sample code is broken [17:49] mhr3: i don't need to resubmit the mp after having pushed the fixes, do i? [17:49] ockham_, nope, it'll be fine [17:49] mhr3: ok, thx === bregma_ is now known as bregma [18:49] jbwiv_, a livecd? [19:13] thumper, finally :) i'm adding the google test for the device launcher icon private impl [19:13] but when i run ./tests/test-gtest [19:14] or make check [19:14] i get [19:14] FATAL: Unable to connect to test service [19:14] not only using my branch [20:53] anyone here? [21:05] thumper, around? [21:06] andyrock: I am, but on a call [21:06] thumper, can you ping me when you're available? [21:06] sure [21:24] jaytaoko, ping [21:49] Can anyoune help me whit bug 773841? I'm new in ubuntu and I want to solve a bitesize bug! [21:49] Launchpad bug 773841 in unity-place-files (Ubuntu) "\\192.168.1.x opens http:\\192.168.1.x in firefox as opposed to smb://192.168.1.x in nautilus" [Low,Confirmed] https://launchpad.net/bugs/773841 [22:35] andyrock: pong [22:36] jaytaoko, yesterday you told me brb [22:36] then i went to bed [22:37] andyrock: sorry [22:38] don't worry :) are you available right now? [22:38] andyrock: yes [22:41] so i'm wondering if in nux there is a "tool" or something to help in creating test [22:42] i mean something to create fake events [22:42] andyrock: well I want to make a first one [22:42] andyrock: I am adding Xtest support for fake events [22:42] jaytaoko, great... :) [22:43] andyrock: I hope to have a first iteration working at the end of this week [22:43] so for the scroll - click branch... [22:43] andyrock: then I will use that to make a test framework that we can all re-use [22:43] i can wait for test right? [22:44] this makes sense [22:44] andyrock: yes, we want to enforce the need for tests [22:44] andyrock: it will make the code more robust [22:45] andyrock: so yes, your branch is fine. but I need to finish with the testing framework before we can push it [22:45] I know it... [22:45] so we should test that when the mouse state changes [22:45] the right event is emitted [22:45] not only [22:45] the scroll and mouse released event [22:45] IMO [22:46] andyrock: yes [22:46] andyrock: in short, the event on the button 1, 2, 3 should be unaffected [22:47] andyrock: the higher mouse button (including for horizontal scroll) will not have a mouse down/up event [22:47] andyrock: we have to make sure of that with XTest [22:47] yeah... another solution is supporting horizontal scroll [22:48] andyrock: you mean adding a NUX_HORIZONTAL_SCROLL event? [22:48] something like that [22:48] create another event is easier [22:48] but we can use the same envet for both vertical and horizontal scroll [22:49] andyrock: I will be adding uTouch support to nux, so I think uTouch should cover that [22:49] but the release state should not be setted any way ;) [22:50] jaytaoko: hey, I'm a unity2d guy, we're exploring testing architectures. You are building this test stuff into nux, no? [22:50] andyrock: right [22:50] greyback: hello [22:50] jaytaoko: hello :) sorry, I'm rude [22:50] greyback: we should talk about this some time [22:50] greyback: testing that is [22:50] thumper: hey. Yes I think so too [22:51] thumper, gtest doesn't work in unity [22:52] greyback: Xtest will be a separate framework, Nux itself won't need to be modified for it [22:52] andyrock: :( it did before? [22:52] I'll take a look [22:52] greyback: I want to have some test that respond to fake X events generated by XTest [22:53] greyback: XTest will specifically target the Nux window [22:53] thumper, i don't it too much in unity... but at leat two month ago yes :) [22:53] jaytaoko: I see. That makes it useful for 2d also [22:53] greyback: and Nux should process the events as usual [22:54] * thumper sighs [22:54] greyback: I think the Xtest component won't be too complex... [22:54] greyback: so we could share it [22:56] jaytaoko: magic! 2d should receive the same events anyway. [22:56] greyback: right [22:57] thumper, sorry... i don't use it... [22:57] andyrock: you don't use what? [22:57] btw it uses com.canonical.Unity.Test [22:57] thumper, i don't use unity-gtest [22:58] but two month ago i patched it [22:58] jaytaoko: could you give me a link to xtest so I check it out please? [22:58] andyrock: it should be the responsibility of the person merging the code to run make check [22:58] if i'm not wrong i ported a test from glib test to google test [22:58] if it doesn't pass, you don't merge [22:58] greyback: sure... [22:58] andyrock: I run it before every merge I do [22:59] andyrock: and soon, we'll have a landing robot, and normal people won't have commit rights to trunk [22:59] thumper, yeah but the test doesn't fail because tests fail [23:00] unity gtest tries to use com.canonical.Unity.Test [23:00] that doesn't exist on my pc [23:00] jaytaoko: or is it the usual x11 xtest extension you're using? [23:00] greyback: So XTest is an X11 extension. Check on the web to find the spec [23:00] greyback: yes, I plan on using the X11 extension [23:01] jaytaoko: ahh, sorry, for some reason I thought you were rolling your own. Sorry! [23:01] greyback: you will need libxtst-dev on your system [23:01] greyback: no, I think x11 Xtest should do [23:02] greyback: here is a short sample on how to use it: http://bharathi.posterous.com/x11-fake-key-event-generation-using-xtest-ext [23:02] jaytaoko: ok thanks [23:02] greyback: no problem! [23:10] thumper, i think that Trevinho has the same problem [23:10] with unity gtest [23:10] * thumper is checking locally [23:11] lp:unity r1735 has make check working [23:11] at least for me here [23:13] * Trevinho confirms andyrock's words [23:13] thumper, let me try [23:13] * thumper is rebuilding r1736 from scratch [23:13] Trevinho, thank you for the support ;) [23:14] I had the same issue with old versions too === m_conley is now known as m_conley_away [23:19] Trevinho: can you run r1735 locally? [23:19] Trevinho: you may be missing a library or something [23:19] * andyrock is building r1735 too... [23:20] r1736 passed make check for me [23:21] I'm hoping it is just you guys missing a package [23:21] thumper, can you run: [23:21] qdbus com.canonical.Unity.Test [23:21] and give us the output [23:22] I've already blown away my revisions, and rebuilding [23:22] thumper, i've google-mock package [23:25] brb [23:26] thumper: I've the same issue with that rev too [23:26] marco@pangolin:~/unity-trunk/build/tests$ make test [23:26] Running tests... [23:26] Test project /home/marco/unity-trunk/build/tests [23:26] Start 1: UnityGTests [23:26] 1/1 Test #1: UnityGTests ......................***Failed 10.87 sec [23:26] make check seems to be different though [23:27] yes... it is [23:28] if you go back to the build dir [23:28] and go make check, what do you get? [23:28] it runs but I get some errors like [23:28] task-1: WARN 2011-11-16 00:28:33 unity.glib.dbusproxy GLibDBusProxy.cpp:255 Cannot call method InfoRequest proxy /com/canonical/unity/testlens does not exist [23:29] yeah, I get those too [23:29] so... maybe our make check needs to be fixed [23:29] ok, then I get the result with [23:29] task-1: [==========] 71 tests from 11 test cases ran. (16570 ms total) [23:29]