[07:01] hey Mirv, how was your week-end? [07:39] didrocks: hello, very relaxing thank you [07:40] nice! I hope the weather is better than what's I'm seeing here :) [07:40] hey sil2100! nice week-end as well? [07:41] pretty good today, spring if finally arriving [07:41] lucky you :-) [07:41] Mirv: did you get some progressed on autopilot vs sdk package? [07:45] didrocks: yes, I managed to fix all the tests eventually, in addition to adding the separate autopilot package. waiting for my merge proposal to be accepted, after which I'll contact Francis to start running the tests. [07:46] Mirv: oh, you don't need to contact him, we can add them to our generic autopilot job for daily release :) [07:46] Mirv: awesome news! good job :) [07:47] didrocks: ah, ok. thanks. [07:47] Mirv: do you mind updating this spreadsheet please: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVVX1BOYm1qdUtyX2xUNmdwWlhTS0E#gid=0 [07:47] Mirv: with the command to run and so on :) [07:47] I think you already did it :) [07:47] (just double checking) [07:47] didrocks: yes, I did :) [07:48] excellent ;) [07:50] Mirv: do you have time to check with in the daily-build-next ppa, we have a lot of unity stack failures? (not the touch stack, only the unity one) [07:51] didrocks: not right away, but I can take a look in the afternoon [07:51] thanks :) [07:53] Saviq: ping [07:53] dednick, pong [07:53] Saviq: do you know if there's something wrong with the qmluitest jenkins build? keeps failing. http://s-jenkins:8080/job/unity-phablet-qmluitests/493/console [07:54] all i can see is that it can't connect to dbus, but dont know if that is the root of problem [07:54] dednick, nah, the problem is "QXcbConnection: XCB error: 148 (Unknown), sequence: 148, resource id: 0, major code: 140 (Unknown), minor code: 20" [07:55] dednick, unfortunately we don't have a solution for that yet [07:55] dednick, we just restart the job and hope for the best... [07:55] Saviq: i c. ok [07:55] mzanetti, anything to add ^? [07:56] didrocks: hi! A very busy weekend sadly, but oh well! How about you? [07:56] sil2100: was uninteresting, stayed at home most of the time due to the bad weather [07:57] Bad weather? Oh my, here in Poland we had sunny sunshine almost all the time [07:57] 'almost' [07:57] ;) [07:57] waow, lucky, here since Friday, the weather isn't really nice… [07:57] Saviq: can i restart jobs? all i see in the "build again" page is "publish again". is that the same? [07:58] dednick, you need to log in to s-jenkins [07:58] Saviq: nevermind. yeah, i realised i wasn't logged in [07:58] sil2100: how busy are you today? we are going to switch the new HUD after the finale touch quantal image is in (today normally) [07:58] sil2100: I wonder if meanwhile you can look at the touch-related build failures in the ppa [07:59] Cimi: ping [07:59] didrocks: ok, will look - in the daily-next PPA, yes? [07:59] sil2100: right! thanks :) [07:59] tsdgeos, do you know of a way for automoc to play nice with headers kept separately from source files? [08:00] Saviq: have never found myself in need of that [08:00] so nope [08:15] Saviq: what's the rationale for such a split? [08:17] tsdgeos, better structure, really, but I'm not convinced, either [08:17] to me it seems worse structure [08:17] won't be able to find a header by just doing s/.cpp/.h [08:18] that's always confused the hell out of me [08:25] dednick, commit message missing https://code.launchpad.net/~nick-dedekind/unity/phablet-greeter-indicators/+merge/157330 [08:25] tsdgeos, yeah I actually agree, I'd just put actual includes in /include [08:25] Saviq: thanks. done [08:26] dednick, using ff or chrome? [08:26] mhr3: chrome [08:26] dednick, http://userscripts.org/scripts/show/139081 ;) [08:26] mhr3: normally. [08:26] > Also adds a warning if there's no commit message specified for the merge proposal. [08:27] ;) [08:27] tsdgeos, where only files that others might want to include, live [08:27] mhr3: cool. thanks :) [08:28] Saviq: you mean for public vs private includes? [08:28] tsdgeos, yeah [08:28] personally i like the .h/_p.h that Qt uses [08:28] but don't have any strong opinion either [08:48] mzanetti: easy one https://code.launchpad.net/~aacid/unity/filtergrid_test_findChild/+merge/160034 [08:49] mzanetti: sadly we still need one of the __testing properties [08:49] since behaviours are not part of children of a item [08:49] so there's some stuff we can't get to even if we give an objectName :/ [08:49] maybe in the C++ side we can? [08:55] tsdgeos: same with Timers btw [08:55] tsdgeos: would be awesome to have something where we could get them... but so far I couldn't come up with anything (didn't invest too much time tho) [08:56] tried using C++ QObject::children() ? [08:56] tsdgeos: nope [09:24] dednick, hi nick [09:32] mzanetti: might work [09:34] back in a sec, my X froze and now it's doing weird stuff [09:39] MacSlow, you might need to resubmit your renderer MP, LP seems to have gotten confused and has not included the latest changes (still shows conflicts) [09:40] Saviq, argl... hm... ok [09:40] MacSlow, also, I'd like to get rid of the print()s [09:41] MacSlow, I'd convert them into a signal clicked(string) [09:41] MacSlow, so that you can then test that they got clicked (or not) in the tests [09:41] MacSlow, you'll need a signal clicked(string) on both Notification and Notifications [09:42] MacSlow, and in Notifications' delegate you'll forward that signal up [09:43] MacSlow, and then in the tests use SignalSpy component to check if you can actually click on the actions [09:43] mzanetti, can you please have a quick look through https://code.launchpad.net/~macslow/unity/phablet-notification-renderer/+merge/155512 [09:43] Saviq: ack [09:43] mzanetti, and see if you come up with anything else that makes sense testing [09:43] mzanetti, read up, too [09:43] ack [09:43] mzanetti, thanks [09:44] Saviq, ok [09:48] didrocks: ok, so: [09:49] didrocks: https://code.launchpad.net/~sil2100/indicator-messages/fix_ftbfs_deprecated_func/+merge/160038 <- for the indicator-messages FTBFS [09:49] didrocks: I also have a branch for the gallery-app FTBFS but still waiting for a PPA test build [09:50] sil2100: excellent! thanks :) [09:52] Saviq: how does https://code.launchpad.net/~aacid/unity/filtergrid_remove_itemY/+merge/160050 look for the itemY function removal? [09:52] tsdgeos, we don't want to pass delegates around [09:53] Saviq: why not? [09:53] tsdgeos, they get destroyed when you're not looking ;) [09:53] sure, the only thing you have to do is not store them :D [09:53] mzanetti, ^ ;) [09:54] fight! [09:54] Saviq: well, i can pass up the "y" that's the only thing i need from the delegate [09:55] but note the carousel is already passing the delegate up [09:55] maybe not in the listview version, let me check [09:55] nope, still there [09:56] tsdgeos: in my experience using delegates inevitably leads to bad code... I do know that there are cases where its not harmful. But so far in my experience once you do that you start introducing work arounds in future revisions. [09:56] tsdgeos, my thinking was to pass up a Qt.rect() [09:56] best example: notes-app [09:56] tsdgeos, that should get parented to the Qt global object anyway [09:56] tsdgeos, but then we need to make sure to delete it afterwards [09:57] was a listView and they were using the currentItem outside of the listview. next MP changed it to be a Column + Repeater because it was crashing sometimes with the listview... [09:57] tsdgeos, and would give us all we need (i.e. in People on phone the split is _after_ the clicked item, not before it) [09:57] mzanetti: but that's like forbidding pointers because using them wrongly will make you crash :D [09:58] Saviq: sure the rect is enough, but as said also the Y is enough [09:58] tsdgeos: hmm.. I think its different... you don't realize its a pointer in QML while you do in C++. [09:58] tsdgeos, sure, here y is enough [09:58] mzanetti: you don't realize because you have no clue of QML (not you as you but you as general you) [09:58] tsdgeos: yes... that might be true [09:58] tsdgeos, in people y and height are needed [09:59] Saviq: well, it's using peopleGrid.cellHeight so "not really" [09:59] tsdgeos, right [09:59] anyways, if possible to avoid using delegates I'd vote for that. I won't cut off your head if you do so tho... [10:03] ok, i'll pass up the Y then, no need to care about creating new objects and doesn't invalidate the delegates are evil "rule" [10:09] does anyone know why when i try load Shell.qml with qmlscene, it segfaults in the Unity plugin export? http://pastebin.ubuntu.com/5592114/ [10:11] I expanded out the QT_MOC_EXPORT_PLUGIN def and it seems to be popping creating object on stack. [10:11] aaaaaaaaa [10:11] * tsdgeos shouts at bazar again [10:12] sorry :D [10:12] didrocks: is there someone already looking at the unity amd64 failure? [10:12] dednick: no idea here [10:12] sil2100: I asked Mirv to have a look if he has time, if you have any, that would be appreciated. Did you finish with the powerpc failures? is it transient? [10:23] mzanetti: autolanding 228 and 229 are of the same branch+rev? [10:24] * mzanetti checks [10:25] mzanetti, btw, any idea why the drop in line coverage http://s-jenkins:8080/job/unity-phablet-autolanding/ ? [10:26] tsdgeos: indeed. no idea how that happened [10:27] oki [10:29] Saviq: seems we added lots of new lines of code. biggest part caused by: obj-x86_64-linux-gnu.tests.mocks.Ubuntu.Application [10:30] mzanetti, yeah, that's what I thought [10:30] mzanetti, but then should we not ignore tests for coverage? [10:30] Saviq: yes. this is collected by the c++ coverage run. [10:30] mzanetti: can you reapprove https://code.launchpad.net/~aacid/unity/filtergrid_test_findChild/+merge/160034 i needed to merge with trunk for it to pass [10:30] Saviq: would need to find out how to exclude the mock dirs [10:31] mzanetti, k [10:31] oh too late, autolanding already :D [10:31] it'll fail now [10:32] sil2100: feel free to start looking at that build failure. this afternoon looks to be becoming busier all the time [10:33] didrocks: it seems to have been caused by the same little issue we had some time ago - a rebuild should help theoretically, but LP still didn't start rebuilding when I asked him to ;p [10:33] Mirv: ok ;) [10:33] Saviq, "Unity.Test" needs a UnityTestQml... were is that meant to be coming from? [10:33] What is this? It's still [10:33] I mean, it's still "Start in 1 minute" since 30 minutes [10:34] sil2100: I've seen that often [10:34] sil2100: yeah, in fact, it's "start in 1 minute after the next build finish" [10:34] next/current* [10:35] Ok, so that's confusing [10:35] MacSlow, Unity.Test is in tests/qmltests/utils/ [10:35] MacSlow, along with the qml file [10:35] Saviq: indeed :) [10:35] sil2100: ^ [10:36] But some of the timers are anyway broken - on some other LP package build I started I have 'Starts in 1 hour' for an hour already [10:36] mzanetti: well, that UT thing is what Saviq used, i just copied it :D [10:36] Useless..! [10:36] still don't like it :P [10:36] mzanetti: may as well change them all in one go [10:36] sure [10:36] i'm was jsut being consistent [10:37] :) [10:37] tsdgeos, mzanetti, if we want more explicit named import, we can, but I'm not sure I want "UnityTest.UnityTestCase" [10:37] Saviq: whats wrong with Unity.Test? [10:38] mzanetti, it's polluting the global namespace if you don't do named imports [10:38] mzanetti, and it's less obvious where it comes from [10:38] mzanetti, actually we should probably s/UnityTestCase/TestCase/ [10:38] mzanetti, and use UT.TestCase or whatever [10:39] Saviq: well in that case we would need the named import, yes [10:39] mzanetti, we want named imports to be used more, btw [10:39] do we... [10:39] I do [10:39] :P [10:39] well then... [10:39] it's namespaces [10:39] they're useful [10:40] more so than "MyCustomNameToAvoidConflictsTestCase" [10:40] I know... they're useful - but annoying when overused [10:40] for example writing QML in Plasma is disgusting [10:49] mzanetti, I'm good with changing the import name, but I'd rather keep the named import in [11:00] tsdgeos, you sure there's a conflict here? https://code.launchpad.net/~unity-team/unity/phablet.test_LensView_new/+merge/159643 [11:00] tsdgeos, just merged trunk and seems fine [11:02] Cimi: it's what all the CI stuff complained about === MacSlow is now known as MacSlow|lunch [11:19] Cimi: is that test testing anything from listview? [11:20] no [11:21] so what's the point? :D [11:23] tsdgeos, it's lensview [11:23] tsdgeos, not listview [11:23] er [11:23] sorry [11:23] Cimi: is that test testing anything from lensview? [11:23] tsdgeos, yes, searchquery [11:23] tsdgeos, I don't think there is else to test [11:24] Saviq, could you take a look at this branch for me? https://code.launchpad.net/~nicolas-doffay/unity/infographics [11:24] Cimi: it searchquery is in lens [11:24] and the lens you're using there is the fakeone [11:24] onTriggered: lens.searchQuery = "" [11:24] In particular the Sequential Animation. The property action for the visibility doesn't work, I'm clueless as to why. http://bazaar.launchpad.net/~nicolas-doffay/unity/infographics/revision/563#Greeter/Dot.qml [11:24] may be worth testing [11:24] you you're not testing that either [11:28] tsdgeos, I'm testing that [11:28] tsdgeos, the timer gets triggered when lens changes [11:28] look at the test [11:28] i know [11:28] but the timer takes 2 secs [11:28] and the tests does [11:28] change + compare [11:28] how does that work? [11:29] it doesn't [11:29] mmm so I should to tryCompare [11:29] no [11:29] the thing is [11:29] it's working because of something else [11:29] tsdgeos, on triggered changes [11:29] it's istant [11:29] Cimi: i put a console.log("EEEE", lens.searchQuery) on that timer triggered [11:29] got nothing [11:30] why would it be instant if the timer is 2 seconds? [11:31] timer.restart doesn't trigger the timer? [11:32] it starts the timer [11:32] it will take 2 seconds to trigger [11:32] ok [11:33] tsdgeos, I see [11:33] what you want is something like this actually [11:33] http://paste.kde.org/~tsdgeos/729968/ [11:33] tsdgeos, searchQuery is per lens [11:33] but this fails [11:33] tsdgeos, so if you change lens [11:33] tsdgeos, the new lens has empty searchQuery [11:33] then adding the tryCompare to the second one will exercise the timer probbly [11:33] because I previously set searchQuery for another lens [11:34] right [11:34] I should ideally go back to the initial lens where I set searchQuery and wait for the timer [11:34] yep [11:34] that's what my paste does [11:34] just saw your paste :) [11:38] tsdgeos, that? http://paste.ubuntu.com/5592300/ [11:38] might remove the first compare actually [11:42] yeah, first compare may not make sense [11:43] ok pushed [11:46] nic-doffay, yeah, looking [11:47] Cimi: do we need the "Component.onCompleted: lens = lenses.get(0)" ? [11:47] tsdgeos, not really if we have the init() [11:47] Cimi: kill it then :-) [11:47] tsdgeos, was just to set up the lensview [11:48] as it is used elsewhere [11:48] dandrader, now there's a conflict in your close from dash branch [11:49] Cimi: but doesn't init do that already? [11:49] nic-doffay, you need to merge trunk in your branch [11:51] Will do now Saviq [11:54] Ah ha\ [11:58] Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-unload-far-away-images/+merge/160083 [11:58] mzanetti, nice === MacSlow|lunch is now known as MacSlow === dednick is now known as dednick|lunch === ritz__ is now known as ritz [12:34] Saviq: greyback is currently working on fixing LVWPH, right? (when he's not on vacation) [12:34] mzanetti, yes [12:35] Saviq: will it be changed so that only visible content is loaded? [12:35] mzanetti, yes, that's the idea [12:35] ok. thanks. I've commented on my own MP with some thoughts on this [12:35] Saviq: ^ [12:36] mzanetti, once we get rid of cacheBuffer there, we will unload the whole categories [12:36] mzanetti, but then there's People :/ [12:37] mzanetti, where we have an unlimited list of entries [12:37] in a ListView that really behaves like a Column + Repeater [12:37] because it doesn't know if it's offscreen or not [12:38] Saviq: yeah... that's exactly what I would call the LVWPH issue === seb128_ is now known as seb128 [12:39] mzanetti, tsdgeos, dandrader I'd like you to have a look at https://code.launchpad.net/~saviq/+junk/interface-tests and say what's understood, what is not, do you see anything added there etc. [12:39] Saviq, ok [12:39] mzanetti, tsdgeos, dandrader, it's something of a mine field for the interface tests [12:52] Saviq: for things like test_type() I'd use _data() methods. If one fails we get better reports which type failed etc [12:52] Saviq: test_creation() could also test for !creation of uncreatableTypes? [12:53] mzanetti, I don't think we want that, if they're creatable, nothing breaks [12:53] Saviq: ok [12:53] mzanetti, same for writable [12:53] I initially tested for !writable [12:53] but then thought it doesn't make sense [12:54] Saviq, I didn't get tst_TestInterface.qml:17. Where that TestCase comes from? [12:55] Saviq: verifyProperty(): there could be properties that are CONSTANT and for thus don't have a NOTIFY signal. If this is intended to be a generic template for such tests it should reagard that [12:56] dandrader: that's not a testcase but a helper function for other cases [12:57] mzanetti, right [12:57] dandrader, that TestCase comes from the Util module [12:58] dandrader, (that's gonna be moved to the Unity.Test module when we deem it complete) [12:58] dandrader, but for now this is just an example set [12:59] Saviq, because I didn't see it being defined in the Util module itself [12:59] dandrader, qmldir [12:59] dandrader, it's a qml file [13:00] ah [13:00] oh... I seem to have another diff with different line numbers... sorry for the noise dandrader [13:00] I see it now [13:04] Saviq: there could be a signalspy attached to verifyProperty() in case its writable [13:04] mzanetti, yeah, I thought of that (and forgot) [13:04] Saviq: I think the rest looks good. can't think of anything else right now [13:04] mzanetti, but then the actual signal might be delayed [13:04] mzanetti, depending on the implementation [13:05] Saviq: hmm... it shouldn't [13:05] right, it shouldn't indeed [13:05] Saviq: hmm. that could be the case indeed... [13:06] Saviq: but you could use a signalSpy.wait(). more than 5 secs delay is definitely not ok [13:06] mzanetti, yeah probably [13:06] Saviq: I'm thinking of remote control apps, where a setVolume might need the RTT until it reflects that change [13:07] tsdgeos, gotta run to the tax office, might not make it back for the standup, you're in charge [13:07] mzanetti, it's tests, they won't be ran against an actual service [13:07] Saviq, about naming: Int QtTest "verify" is used for checking that a boolean expression is true, whereas "compare" is used to compare that an actual value matches the expected one. I think we should keep that convention [13:08] Saviq: right... in that case... I'd add a spy [13:08] so verify() is like an assert() [13:10] yes [13:12] Saviq: actaully i am in a meeting, not sure it'll make it either [13:15] hehe... MacSlow can't make it either... it'll be a quick one today :) [13:15] anyways, I'll take care of it [13:15] Saviq, for the sake of readability I would consider splitting verifyProperty into two separate functions (it has too many arguments). One for checking the existence of the property and its type and another for trying to write to it. [13:16] Saviq, or maybe having a read-only and read-and-write versions of it [13:18] dednick|lunch, planning on add anything here? https://code.launchpad.net/~unity-team/unity/phablet.fake-unity-plugin_categories/+merge/159629 === dednick|lunch is now known as dednick [13:23] Cimi: nope. it's done. Can you check your lensview branch against it? [13:23] will do [13:23] dednick, because it segfaults without [13:24] Cimi: eh? what segfaults? [13:24] lensview tests... [13:24] ah [13:25] http://s-jenkins:8080/job/unity-phablet-qmluitests/513/console [13:25] doesn't segfault on the pc [13:25] but does on CI [13:31] mzanetti: Cimi: guys won't make it to the standup, can you guys drive it? [13:31] tsdgeos, ok [13:32] dednick, nic-doffay you guys joining the standup today? [13:32] Yeah one sec. [13:45] dednick, as for the fake ApplicationManager issue when running with qmlscene. you could replace it with a very simple qml/js implementation [13:45] dednick, This is done, if I'm not mistaken, in the Stage test [13:47] dandrader: since all the files reference ApplicationManager directly, it might be quite hard to do [13:47] dandrader: i dont actually know where the ApplicationManager is created tbh. [13:48] dednick, or you could improve the fake ApplicationManager to make it work with qmlscene [13:48] dednick, tests/mocks/Ubuntu/Application/ApplicationManager.cpp [13:49] dednick: yup. thats the idea :) [13:49] lol. talking to myseld [13:49] dednick, the code is making some assumptions that seem to not hold when run from qmlscene [13:49] dandrader: thats the idea :) got it working, but dont know if it's a good solution or not [13:50] dednick, it should be easy to spot those places [13:50] dandrader: thanks. [13:50] in the code [13:50] mhr3: Hi [13:50] dednick, I actually added comments abou tit [13:50] about it [13:50] dandrader: yup, i've seen them :) [13:54] mzanetti, it's in lp:~dandrader/unity/phablet_close_apps_from_dash_WIP [13:54] mzanetti, UnityTestCase::onCalendarLongPressed() is not getting called on the second "press and hold" [13:55] mzanetti, thanks [13:55] dandrader, re verify vs. compare, which function did you have in mind? [13:56] Saviq, all of them, [13:57] dandrader, I'm not sure, it's not just about comparing two values [13:57] Saviq, I mean oll of the verifyFoo(..., actual, expected) [13:57] s/oll/all [13:58] Saviq, hmm, right === dandrader is now known as dandrader|brb [14:02] mzanetti: Cimi: standup still running? === mmrazik is now known as mmrazik|otp [14:03] tsdgeos: no [14:03] oka [14:08] sil2100: seems the build relaunch worked \o/ [14:08] sil2100: camera-app still have the python dep missing, isn't it? [14:09] didrocks: the thing is, it has the python dep in it :| [14:09] sil2100: do you reproduce in a pbuilder? [14:10] didrocks: and python2.7 along with stdlib is installed correctly - and I was unable to reproduce it locally here [14:10] Also, the ap CMakeLists.txt code is the same as in gallery-app and phone-app, and it works fine there [14:10] Cimi: why did you make https://code.launchpad.net/~unity-team/unity/phablet.test_LensView_new/+merge/160108 depend on the categories one? [14:10] Doing some testing on PPA's but it's hm taking a while [14:11] sil2100: you didn't enable a pbuilder on your machine, do you need help for that? [14:11] didrocks: I use pbuild [14:12] I think that's almost the same, just with some wrappers around it [14:12] sil2100: ok ;) you did notice some other errors in term of source package name in the media stack as well? [14:13] tsdgeos, because I thought the segfault was due to the missing categories [14:13] tsdgeos, in reality is on the opengl [14:14] tsdgeos, but the categories is still ready for review so I suppose we can review that first so it doesn't have the warning too [14:14] sure [14:15] didrocks: those, ah! Will push a merge now ;) === dandrader|brb is now known as dandrader [14:15] Cimi: you reviewing https://code.launchpad.net/~unity-team/unity/phablet.fake-unity-plugin_categories/+merge/159629 or want me to take a shot at it? [14:15] thanks sil2100 ;) === mmrazik|otp is now known as mmrazik [14:18] dandrader, re: simplyfing verifyType [14:19] Cimi: oh wait you proposed it, so you can't review it :D i'll have a look [14:19] dandrader, I'm thinking of creating a custom class that you would create and pass the object and its readable name to [14:19] s/verifyType/verifyProperty/g [14:20] dandrader, and then call verifyProperty() with the reduced set of args [14:23] Saviq, sounds promising [14:24] xD [14:25] nic-doffay, you might want to have a look at lp:~saviq/+junk/interface-tests [14:25] nic-doffay, it's not complete and I will have some changes to it, but should be a good start [14:26] Thanks Saviq [14:29] nic-doffay: so...back from the QA meeting. hit me [14:29] when genericLensView is used? [14:29] apparently it's a property in DashContent [14:30] a string [14:31] oh used as delegate nevermind [14:31] not used currently [14:31] mzanetti, check this out quickly http://bazaar.launchpad.net/~nicolas-doffay/unity/infographics_transitions/revision/617#Greeter/Dot.qml [14:31] PropertyAction on line 38. [14:31] It's supposed to do something very simple. [14:32] Here's the branch link if you'd like. https://code.launchpad.net/~nicolas-doffay/unity/infographics_transitions [14:33] nic-doffay: just to be clear... line 38 does not have a PropertyAction. but I suppose you mean line 39, right? [14:34] nic-doffay, Pause, Action 1, Action 2 << that means Action 1 simply won't have any effect, 'cause it's overwritten by Action 2 straight away [14:35]