[11:01] morning party people [11:01] TGIF [11:54] guihelp https://github.com/juju/juju-gui/pull/325 is ready for QA and review [11:55] kadams54: got it, will look in a sec thanks [11:56] kadams54: can you pull the WIP from the title? [11:56] Sure… though my thoughts were that someone else would take over and land that branch. [11:56] kadams54: I think we're down a few fokls today so not sure it'll move today [11:56] OK [11:57] if you're back on monday we can review/qa today but I think half the team is out [11:57] but cool, I'll take a look and if it's cool/close will try to get it landed. If not, we can catch up monday [11:57] and get outta here and enjoy the weekend man [11:58] the chilly, cold, wet, ugh weekend :/ [11:58] hah [12:01] Alright, I'm out. (Though I already spotted a typo in the comments, likely due to some errant Vim commands, that will need fixing.) [12:38] hi tvansteenburgh, you pinged me last night after i was AFK. what's up? [13:00] bac: nvm, it's already fixed :) [13:00] tvansteenburgh: my kind of problem [13:04] morning [13:04] morning redir [13:04] morning, all. [13:06] very celebrate! wow [13:06] heh, I'm falling over tired over here so you guys will have to prop me up for meetings kthx [13:06] * redir props [13:16] redir: what are you celebrating? [13:16] morning party [13:17] oh [13:17] heh [13:17] still mainlining coffee [13:17] that's not quite as festive as i'd imagined [13:17] that's what I missed this morning. Didn't make my coffee [13:17] oh moka pot, here I come! [13:18] I do have that doge meme in my head since dinner last night. [13:18] :/ [13:18] hah [13:23] jujugui ci is rebooting and such fyi [13:24] redir: how was your couscous dinner? [13:24] * rick_h_ is testing out running landscape across our CI server ans such [13:27] I can't kill vim [13:27] bac it was really good [13:27] pretty inexpensive fresh pasta [13:27] wine <10 a glass [13:27] and wow. very quality [13:28] cool. [13:28] how do I unfreeze vim [13:28] ? [13:28] you froze vim? wow [13:28] open a terminal and `sudo killall (g?)vim` [13:29] (not sure if you're running vim or gvim [13:30] looks like he did 'killall weechat' [13:30] lol, reboot when all else fails [13:31] hey, anyone have experience with SMART hard drive warnings? [13:31] If I see one I buy a new hard drive [13:31] about the end of my experience with them [13:31] yeah, but does BAD mean you have time to recover? [13:31] not sure [13:32] I don't know if it was vim or tmux [13:32] no key resopnses [13:32] in that term [13:32] dropped ssh connection? [13:32] kill vim was just responing under new pid [13:32] tried killing tmux and that killed it all [13:32] local vim [13:32] lol [13:33] slowly trying vim. using for editing configs only first [13:33] can't imaging trying to write code modally [13:33] :) it's super awesome [13:34] :) [13:34] I had a bunch of intro videos but they seemed to have been pulled :( [13:34] so edit [13:34] much powerful. wow [13:35] hmm, my blip account was removed it seems. [13:35] * redir refrains from googling blip [13:36] vague memory of blip is surfacing. Keeps taking longer to find things in my wetware [13:37] https://www.youtube.com/watch?v=XXJO_Swmdnw is the one I put on youtube. I'll have to try to find my other orig videos and upload them or someting [13:38] ooh, here we go. i did upload #3 and #4 as well https://www.youtube.com/watch?v=KVAeelM-0QI https://www.youtube.com/watch?v=SzrcMilnre8 [13:39] for some reason hearing your voice in a youtube video weirds me out. [13:39] heh, not surprising [13:40] wow, 2010? Time flies [13:57] bac I don't know that it can measure if you have time to recover [13:57] I think those smart tools just tell you that things are failing [13:58] OK importing stuff into the jcorestore to start adding search [14:06] redir: huh? [14:07] redir: not sure that's something you should bite off atm. There's a lot more there than meets the eye. [14:08] http://bit.ly/1ox5YpO [14:08] redir: if there's no smaller bugs to tackle, I'd suggest chatting about some intro task we need for the next step in our store process [14:08] redir: yea, that's a loaded bug and a half there [14:08] http://bit.ly/1ox66Wv [14:08] only two left [14:09] really [14:09] importing charms anyhow [14:09] redir: ok cool, then let's put those on ice and start to look at the upcoming tasks we plan on planning-poker'ing on monday and see if we can start something there [14:09] open to a chat if you are awake [14:09] redir: cool yea, understood [14:09] * redir looks at on deck [14:09] yea, jump in the standup room? I might have to bail as I'm expecting a call but no idea when it'll arrive [14:11] jumping [14:22] * rick_h_ goes to make coffee [14:27] hey all, what do you think of my latest blog post? http://fromanegg.com/post/85890866087/unidirectional-data-flow-architecture [14:35] hatch: your page does not load in safari [14:35] hatch: cool [14:35] bac, it's just you :) [14:35] rick_h_ thx [14:38] that is unlikely [14:39] analytics shows people from Safari and I have safari [14:39] s/from/on [14:50] jujugui: call in ten. [14:50] drats, it seems to be an orangesquad holiday [14:52] hatch: do users "visit" urls? [14:52] hah, sure, why not? :) [14:52] do you have better wording: [14:52] ? [14:53] hatch: I don't really know. I just understood gui to not be URL driven [14:54] it's VERY url driven now [14:54] :) [14:54] you mean with the new work going in? [14:55] redir yeah - many interactions update the URL so that it's sharable [14:55] it may have been before too. I just had this conception that it loaded and you did stuff and state changed but the url didn't [14:55] yeah, well the url only changes when the state is potentially sharable [14:56] so, viewing an inspector? sharable, dragging a machine around, not sharable [14:56] and it devises state from the URL [14:56] on the first pass yes [14:56] subsequent passes the url is updated from state changes [14:56] because the state is more detailed than the url needs to be [14:58] right and app state isn't really a resource [14:58] AFIU [14:58] well, it's the resource which determines what the app is doing [14:59] jujugui call in 1 [15:23] react does look cool. [15:24] yea, I generally hate the whole mixing of definitions/model stuff in the HTML, but it does the thing I like of "here's some data redraw" really really well [15:24] jcsackett: given that aaron and curtis are not here today, could i bug you about some charmworld archeology? [15:24] bac: oh dear. i suppose so. :p [15:24] jcsackett: specifically bug 1096131 and its companion branch https://code.launchpad.net/~abentley/charmworld/login-config/+merge/142974 [15:24] bac: if you want to hangout, give me about 5 min. [15:24] * jcsackett needs more coffee [15:24] <_mup_> Bug #1096131: login/logout buttons do not update correctly [15:25] oh wow, i probably will have nothing to contribute on that, but give me a moment to make coffee and look at it and then i can try and answer questions. [15:36] jcsackett: back? [15:39] bac: back. [15:40] I see what you did there [15:40] * jcsackett lauchs [15:42] jcsackett: you make a hangout? [15:44] bac: just tried to do video from the msg you sent me on g+ [15:44] shall i try again? [15:44] yes, or just paste the url [15:44] i can't figure out how to start a hangout on the phone [15:45] so both core store and cw want to use mongo.juju['charms'] for persistence [15:46] but differently [15:48] redir: yea, well the two were indepenant [15:48] independent [15:48] tried to cheat and index the charms imported by charmload [15:49] lol [15:49] got the full family fued XXX [15:49] s/fued/feud [15:49] woot! got my power cables for muy nucs [15:50] * redir imagines rick_h_ doing victory dance with power cables [15:50] damn, I ordered 3' cables on purpose! [15:51] * rick_h_ grumbled [15:51] short victory dance? [15:51] yea, not short enough I guess [15:52] oh well, not going to send them back over it [15:52] it's on a rack, I don't need 6' of cables. The plug is 12" from the box [16:05] haha [16:06] I needed a ethernet cable a while back, the only one I had was 100ft long [16:06] it needed to go 2' [16:06] :D [16:47] doesnt' look like a nything sets the version for migrations in the DB [16:48] redir: ? the migation tool chain itself marks the versions [16:49] Datastore is not currently versioned [16:50] * redir reads more code [16:51] redir: oh, you have to init it [16:51] make db_init? /me has to go look [16:51] guys - there was a problem connecting to my NAS, I need to contact my system administrator [16:52] rick_h_: that is kind of what I mean [16:52] /msg hatch [16:52] :D [16:52] I was figuring that make run would set the current version or something [16:52] redir: yea, it should have [16:52] I've not touched this in a long time so catching up [16:53] hmm, wtf. The upgrade process makes sure it's initialized [16:54] redir: check out 'ensure_initialized' [16:54] so not sure what's up. [16:55] k, will keep digging. thought I'd see if anyone knew off the top of their head [16:59] guihelp anyone seen mass failures of tests that attempt to set focus? They cause script errors in FF and chrome [16:59] rick_h_ is this in test-server? [17:00] hatch: yes [17:00] got it [17:00] the browser needs to be in focus [17:00] else they will fail [17:00] hatch: https://github.com/juju/juju-gui/pull/326 [17:00] yea, it's got focus, or thought it did [17:00] even chrome? [17:00] yeah even chrome [17:01] TypeError: 'null' is not an object (evaluating 'chosenOne.simulate') [17:01] ok, it had focus and dies in YUI in the event handling [17:01] no, not that [17:01] Uncaught TypeError: Cannot read property 'className' of null [17:02] e.mix.removeClass dom-base-min.js:8 [17:02] e.mix.toggleClass [17:02] ahh I see it [17:02] I'll have to pull it down to see [17:02] I'll check [17:03] hatch: thanks, yea love another set of eyes to see if you can dupe it or what not [17:03] * rick_h_ goes to get food stuffs annoyed [17:10] rick_h_ when I run the tests separately they pass [17:14] hatch: yea, if I run them individual they're fine [17:14] the problem is in test_browser_search_widget.js [17:14] k, I'm heading back there. [17:14] whatever error is in there is non-obvious it seems. I'll go back through what's changed in there [17:15] yeah I looked at the diff....and wow, what a diff lol [17:15] the issue may not be in the test file per-se, it might be in the code it's running too [17:15] yea [17:15] stepping away for food and will restab it with a giant knife [17:15] sure [17:20] rick_h_ the issue is with the test: 'should support setting search string' [17:20] lol, two lines [17:21] yeah - would you like me to continue on it or do you want to take it from here? [17:21] hatch: cool thanks, will start to walk wha that does [17:21] ok cool [17:21] hopefully it doesn't something really bad and cascading test failures are actually a good thing lol [17:23] hah, heh it does a focus [17:23] hatch: so it's back to the focus issue [17:27] :( [17:29] hatch: yea, comment out the line 'input.focus()' and tests pass [17:29] I'm curious as to what changed in that branch to cause it to fail [17:29] yea, you and me both [17:30] from the obscure test messages it seems like maybe input doesn't exist? [17:30] or an event issue [17:30] I'm wiring some debug/try/catch stuff aroud that line [17:30] +1 [17:33] ooooo sexy http://www.autoblog.com/2014/05/16/2015-nissan-370-z-nismo-revealed-pics/ [17:33] Sometimes I wish I had somewhere to drive to [17:38] https://github.com/rdio/jsfmt [17:38] I was wondering how long it'd take you to find that [17:39] haha [17:40] I think we do a pretty good job at our layouts but maybe this will be better for the chaining bits than gjslint :) [18:17] rick_h_ any luck? [18:17] otp [18:23] what's otp? [18:23] I keep reading one-time-password and I know that is wrong [18:28] on the phone [18:28] or "on the potty" [18:28] I read it as the second [18:28] -always- [18:28] lol [18:30] great [18:30] such porcelain [18:31] helps though [18:32] much appreciate [18:33] lol [18:35] on the phone :P [18:35] interviews are fun fun fun wheeee [18:35] hatch: no, I'm angry and closed the PR and going to try to find a way to do that work better by starting over and trying to find some incremental steps [18:36] hatch: running tests all along the way better to catch when I make the testing gods angry [18:36] well...we have always had issues with focus() [18:36] yea, but not like this [18:36] no, this is an odd one [18:36] every focus call in the suite, simulate or otherwise, is throwing a JS error down in YUI land and causess the suite to bomb out [18:37] I started commenting out every failing test, everyone one was around focus stuff [18:37] after I got to 7 I stopped and decided my branch is evil and must be exorcised [18:38] hmm [18:38] this is less than ideal [18:38] you're telling me [18:40] hatch or rick_h_, i am trying to replace a method on a view with a stub, but the stub isn't getting called when the event fires (trying to more directly test event listenting than just assuring 'on' gets called in bindEvents) [18:40] the actual method is, instead, as though no stub were created. [18:40] is replacing something bound via 'on' in initializer not possible? [18:40] are you stubbing the prototype? [18:40] jcsackett: show me the money! ... I mean code [18:40] you'll need to stub the method before the event handler gets called [18:40] er [18:41] event binder [18:41] jcsackett: you have to stub it on the live instance [18:41] hatch: and stub it on the prototype, not on the view itself? [18:41] jcsackett: do it on the instance of the view [18:42] well you should stub it on the live instance if you can [18:42] not the View class [18:42] but if you can't then you need to do it on the prototype [18:42] before the instance is created [18:42] rick_h_, hatch: i'm doing it on the live instance. i'll try prototype and create new instance. [18:42] jcsackett: code, it should completely work if you're on the instance [18:43] rick_h_ unless the event is bound before it can be stubbed [18:43] well the event should be bound to a callback [18:43] that is stubable at any time on the instance [18:43] depends on how the event is created, it may be creating a bound instance of the callback, not calling the method you think it is [18:43] then it sholdn't do that to be more testable and refactorable :P [18:44] node.on('click', cb, this) [18:44] in this case, cb is a bound function, not the original one [18:44] right, I understand, but I'd push that we update that to node.on('click', this._onClick, this) [18:45] same problem [18:45] the stubbing has to be done before that binding [18:45] hatch, rick_h_ https://pastebin.canonical.com/110371/ [18:46] jcsackett yeah that's not going to work [18:46] you're stubbing the method after it's been bound [18:47] man I swear we do this. [18:47] I thought I had a test which tests what you're doing though [18:47] just checks that the on method is called properly [18:47] you're testing if the yui event system works [18:47] (which it does.....we hope) [18:47] no, you're testing that the callback does the right thing based on event data passed into it [18:48] hatch: yea, I mean true in this case, but we've got a lot of tests that catch events stuff [18:49] https://github.com/juju/juju-gui/blob/develop/test/test_machine_view_panel.js#L186 [18:49] yeah - it's just that those tests are fraught with issues that we seem to always run into [18:49] heh [18:49] hatch: oh, but I don't use the stub code [18:50] I'm pretty sure that this test tests exactly what you're trying to do jcsackett but skips the yui event handling [18:50] I just view._showDraggingUI = function(ev) { done(); } [18:50] jcsackett: ^ [18:50] don't use the makeStub, but just change the function. It's on an instance, you don't have to reset it, and you can do whatever assertions you want in the function you create [18:55] rick_h_: i tried that too and it didn't work. [18:55] hatch: i'm doing this because just seeing if 'on' gets called doesn't seem like much either. [18:56] jcsackett I'm not sure I understand? [18:57] jcsackett: push a branch up please. [18:58] jcsackett I'm pretty sure to do what you want to do you will need to stub the method out on the prototype of a NEW view, not the one created in the beforeEach [18:58] it'll have to be done before you actually call `new` [18:58] if I'm understanding what you're doing correctly [18:58] hatch: ok, i'm game for trying that. [18:59] if THAT doesn't work, then you have other problems :-) [19:02] jcsackett if you still have problems after that we can pair on it [19:02] if you like [19:03] nope, that fixed it. [19:03] bac all your tests pass? [19:04] of course, now we return to the question, hatch, of whether this approach has any value--do you really think just asserting that 'on' was called for each event is sufficient? [19:04] i feel uncomfortable seeing that, but if others think that's enough, i don't want to add more tests to a not super fast suite. [19:04] well your test is definitely more thorough [19:04] hatch: dig. [19:04] but since so much is 'faked', the other view, the callback ect [19:05] you're testing a) the event was attached b) that the proper callback is called [19:05] removing YUI from that equasion you're left with that the proper method was called with the proper args [19:06] know what I mean? [19:06] I'm not saying you SHOULDN'T write your test....I just question what it adds over what's already there (assuming YUI works) :) [19:07] hatch: well, that's the question i'm asking. b/c truthfully, i would rather replace the test checking that 'on' was called with three tests checking each event after fire. but if that's not *actually* an improvement, it's slower test run time for nothing. [19:07] well, not so much slower test run time, but more tests for nothing. [19:08] how do I checkout bzr branch to a different revno [19:08] ie: bzr switch -b test -r510 [19:08] still checks out 511 [19:09] jcsackett well I suppose if you used the 'real' token view to emit the event via it's own mechanisms then it would be a good integration test [19:09] know what I mean? [19:12] hatch: yeah, but the last thing we need is more integration tests masquerading as unit tests. not saying integration tests would be bad. [19:12] i think, basically, my testing experience says "test the right events are fired and test the right behavior happens when an event is received"; checking 'on' is called doesn't feel like the latter to me, but perhaps it is. [19:13] but isn't that what you;re doing right now? creating an integration test? the current test calls the method in question, and makes sure that method does what it's supposed to do [19:13] which is kind of the definition of a unit test [19:14] so this test is saying "yes on() was called with the proper arguments" [19:14] sure; i suppose that's true. [19:14] whereas yours is saying "yes the callback gets called when it receives this event" [19:14] you make a very good point. [19:14] found it [19:14] * jcsackett has no love of js events and tests [19:14] :p [19:15] hah, sometimes I make sense :D [19:19] redir: you see test failures in trunk? [19:19] i'll checkout trunk in a second [19:19] but I am on a fresh branch from trunk, so should be OK [19:20] bac now working my way back on rev at a time., but still seeing fails [19:20] so I have something broken [19:48] jcsackett so what did you end up deciding on? :) [19:48] hatch: i took your point--there's better work to do then shaving that yak. [19:48] oh Kay! [19:57] bac wrong version of elasticsearch running [19:57] fixed most. I still see on though [20:07] grabbing lunch [20:07] /making [20:11] redir: sending frankban an email saying you were looking at the dep stuff. Please make sure to shoot an email when you EOD [20:11] redir: even if it's "I didn't get around to it" so that he knows the status [20:12] rick_h_: yeah trying to figure out why I have test failure now that I didn't have before [20:12] redir: all good, just don't want to leave it hanging [20:18] * rick_h_ heads out for the day. Have a good weekend all! [20:34] bac you gone/ [20:34] ? [20:34] jcsackett: ? [20:34] redir: ? [20:35] trying to understand why this test is failing but am failing to understand what it is testing even [20:35] redir: what test? [20:35] paste? [20:35] test_search.py:TestUpdate.test_simple_change_dynamic_to_static_mapping [20:36] oh, that looks like a fun one [20:38] mmm [20:38] redir: all of the test in the two test_search.py files pass for me... [20:39] * redir shakes computer [20:40] kaaaahhhhhnnnn [20:40] redir: so, in summary, it fails for you on trunk? [20:40] bac yes [20:41] wait, i was on revno 510. trying again with 511. [20:41] bac I converted to a lightweight checkout [20:41] redir: you are on 511 with no mods? [20:41] so totally fresh build today [20:42] bac yea [20:42] Ran 102 tests in 30.792s [20:42] OK [20:42] me deletes checkout and starts fresh again [20:43] if it fails again, please paste the output. [20:44] files not in mapping is the gist of the failure [20:50] what's the logic for when we should use the event tracker vs just using this.on($event)? [20:51] jcsackett: use the event tracker if your level of indirection is less than 5 [20:51] * jcsackett blinks [20:52] bac: is that an actual answer, or am i missing a reference? and if it's the former, i don't follow. :p [20:52] it was a bad joke [20:53] I laughed [20:54] jcsackett I suppose, whenever the event is being atttached to something that may not be removed when the instance is destroyed [20:54] so if the event is on the instance...well then there isn't a ton of risk because when the instance goes, so does the event. If it's on a dom node however..... [20:54] it's really a piece of mind thing though [20:55] as in "i'll give you a piece of my mind"? [20:56] lol, just like that, yes [20:57] Eddie would be proud [21:00] hatch: awesome, that makes perfect sense, thanks. [21:00] coolio, np [21:04] is there a charm to install charmworld? [21:05] we have an email list? [21:05] jujugui@ or something? [21:06] there is a charmworld charm [21:06] redir yes i'll pm it to u [21:06] bac is it useful for developing [21:06] ? [21:06] hatch: merci [21:06] not really [21:06] boo [21:08]