[00:00] <rick_h_> hatch: oh hmm, strange. :/ 
[00:00] <hatch> I haven't figured out the exact change that caused it to expose that - but I'm working towards it
[00:00] <hatch> the reason it got so far was because sometimes it passes without issue lol
[00:01] <rick_h_> ok, let me know if you need any help. We've been trying hard to not have our involvement cause you grief
[00:01] <hatch> we just happened to always get a passing one rofl
[00:02] <hatch> well I would like someone to duplicate my findings - do you have a win 8 vm?
[00:02] <rick_h_> hatch: win7, but has IE10 on it
[00:02] <rick_h_> sec, just committing/linting my current branch
[00:03] <hatch> sure - I'm oh poo
[00:03] <rick_h_> oh son of a...
[00:03] <hatch> lol
[00:03] <hatch> my fix did not fix
[00:03] <rick_h_> Vbox is failing on start about a missing < tag :/
[00:03] <hatch> back to the drawing board
[00:05] <rick_h_> oh hell, the .vbox xml file is corrupt
[00:05] <rick_h_> and of course I don't backups my vms...they're vms... :/
[00:05] <hatch> how the heck...
[00:06] <rick_h_> yea, there's a -prev file that's missing half of it
[00:06] <rick_h_> and the .vbox file is empty
[00:06] <rick_h_> guess last time I shut it down it must have crashed out or something
[00:06] <rick_h_> bah, have to redo the windows install and setup. Grrrr
[00:06] <hatch> alright well no problem - it looks like the 'fix' wasn't actually a fix
[00:06] <hatch> I'll have to look for the root cause
[00:07] <rick_h_> sorry, no IE10 handy now :(
[00:07] <hatch> I am leaning towards there being some cleanup issues
[00:07] <rick_h_> always seems to be
[00:07] <rick_h_> wonder if there's some way we can monkey patch Y.Base and Y.Base/destroy to console.log creation/destruction and sort the results out
[00:08] <hatch> well turning on debug logs will - but this is only happening on prod builds
[00:09] <rick_h_> I just meant to do a tset run and list out all the crap that's not getting cleaned out in one swoop
[00:10] <hatch> ohh, well I'm not sure if that will include all the information
[00:10] <hatch> maybe we need better procedures
[00:10] <hatch> I don't know what those would be haha
[00:10] <hatch> as this is looking like some obscure race condition issue
[00:14] <rick_h_> heh, ended up creating a handlebars helper for that obj->array stuff
[00:16] <hatch> :)
[00:16] <hatch> ok I gota run for a while but I'll tell you what I have found
[00:16] <rick_h_> hatch: rgr, have fun
[00:17] <hatch> if you check out 486 and run in IE10 you will get a TON of failures
[00:17] <rick_h_> :(
[00:18] <hatch> but if you comment out test_charm_container.js then they all go away
[00:19] <rick_h_> really wish we had good ole single yui per file suite put together. oh well
[00:19] <hatch> OR if you comment out the tests in that suite they go away
[00:19] <rick_h_> k, I'm going to finish this branch up and I'll try to reset up my VM tomorrow morning and can help out 
[00:19] <hatch> if you uncomment even a single test - then boom, 100s of failures
[00:20] <rick_h_> ok...that makes no sense. /me loads up tests in that file.
[00:20] <hatch> yeah I have absolutely no idea but I really gota run now :D
[00:20] <rick_h_> k
[00:20] <hatch> have a good night, talk to ya in the AM
[05:36] <hatch> rick_h_: -status update- after a few hours of debugging I have come to the conclusion that that test suite is not causing the issue it's just seems to be triggering the issue more often. I believe I have narrowed it down to a couple strong suspects and will bring it up in the AM.
[12:09] <rick_h_> anyone around for some code reviews? https://codereview.appspot.com/8311043/ is for Huw and is mostly images :) 
[12:09] <rick_h_> https://codereview.appspot.com/8296043/ is more JS 
[13:04] <bac> hi rick_h_ -- can i get some guidance from you based on some suggestions ben made yesterday?
[13:04] <bac> rick_h_: he suggested i wrap some event handling i'm doing into a controller.  i'm a bit confused as the mechanism.
[13:05] <rick_h_> bac: sure thing. linky to what we're talking about?
[13:05] <bac> https://codereview.appspot.com/8275043/diff/2001/app/app.js#newcode364
[13:05] <rick_h_> looking
[13:08] <rick_h_> bac: sec, looking at how db/db.services work. 
[13:08] <bac> rick_h_: db.services is just a ModelList...
[13:11] <rick_h_> ok, I think I'm getting hung up on the term 'controller' being too equal to a Y.View
[13:11] <rick_h_> bac: so I think he's just meaning something like this: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/subapps/browser/views/view.js#L66
[13:11] <rick_h_> notice here I've got a helper to do all the event binding for a task
[13:12]  * bac looks
[13:12] <rick_h_> bac: and in the destructor I walk through and destroy/detach those events
[13:12] <rick_h_> bac: so I *think* he's just suggesting you move the event bindings into a descriptive helper, keeping a reference to them, and allowing them to be detached via a second method
[13:13] <rick_h_> bac: this is some of the stuff causing us issues in tests where events are created, but not auto destroyed/detached when multiple instances are created of something that binds up a bunch of events. 
[13:13] <bac> rick_h_: so there is no special infrastructure magic ... just create a new class with bind and unbind methods (or whatever i want to call them) that manages subscriptions?
[13:14] <rick_h_> no, a simpler case is a widget like: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/widgets/charm-search.js#L60 we just added a matching _unBindUI to match the widget api of bindUI
[13:15] <rick_h_> bac: I don't think you need a new class. All of this has to do with models.something so maybe there's a good class to stick this on already
[13:15] <rick_h_> bac: and you can do a db.services.bindChangeEvents()
[13:15] <rick_h_> and then db.services.unbindChangeEvents or the like
[13:15] <bac> rick_h_: and what would that call?
[13:16] <bac> what is the glue between my controller and db.services?
[13:16] <rick_h_> bac: db.services is the controller in this case. 
[13:16] <bac> no, db.services is a ModelList
[13:16] <rick_h_> so you can add bind/unbind methods to ServiceList for instance
[13:16] <rick_h_> bac: yea, that's fine. You can add methods to a ModelList
[13:18] <bac> rick_h_: nm, my bad.  i didn't realize there was a ServiceList already extending ModelList
[13:18] <rick_h_> oh hmm, so the only thing is I didn't realize that the callbacks you want to run are coming from models/endpoints. So maybe the work needs to go on that end. sorry trying to see how the parts fit
[13:19] <bac> rick_h_: yes, and model/endpoints needs to be encapsulated in a new entity
[13:19] <bac> or at least the new management methods
[13:20] <rick_h_> bac: hmm, do the callbacks belong on the serviceList themselves? Right now they're just helper methods on juju.models
[13:21] <bac> rick_h_: they could move there, i think
[13:21] <rick_h_> bac: so yea, in looking at this I'd move the callbacks into the serviceList object, have the bind/unbind events on there. And then the app.js just calls db.services.bindEvents() or the like
[13:22] <rick_h_> finally making sure to have an unbindEvents method and make sure it's called on the serviceList.destructor method
[13:22] <bac> that makes sense
[13:22] <rick_h_> cool :)
[13:22] <bac> rick_h_: one loose end, where would you suggest my endpointsMap live?  right not it too is hanging off models
[13:22] <bac> s/not/now
[13:22] <rick_h_> looking
[13:25] <rick_h_> bac: what is an 'endpoint'? a provide/requires target or something?
[13:27] <bac> rick_h_: yes.  the endpoints map is an object with lists of provides/requires for each known service
[13:29] <rick_h_> bac: hmmm, maybe endpoints shold be namespaced at least and then the bind/unbind methods created on there. It can take the serviceList instance as an argument and app.js would do models.endpoints.bindServiceList(this.db.services)
[13:30] <rick_h_> but then endpoints almost wants to be a class so you can keep instance related data (like the event handlers you're holing from bind) and remove them
[13:30] <bac> yeah, ok
[13:30] <rick_h_> bac: have a hangout, biab
[13:48] <rick_h_> bac: ok back. So what do you think? endpoints is a diff module that wants to add event callbacks to ServiceList?
[13:49] <bac> rick_h_: yeah, that's how i'm going
[13:49] <rick_h_> bac:  ok cool then. 
[13:58] <hatch> morning
[13:58] <rick_h_> morning hatch 
[13:59] <hatch> is that branch from jc one that fixes whatever was causing the failures?
[13:59] <rick_h_> hatch: once you've got your morning cup of joe have some reviews if you have a chance :)
[14:13] <hatch> sure thing
[14:13] <hatch> rick_h_: so is that branch from jc the one which fixes the test failures?
[14:17] <rick_h_> hatch: no, he's not aware of the stuff from yesterday atm. 
[14:17] <rick_h_> hatch: it's fixing some edge cases of the widget itself. I forgot to bring up swapping the teardown code around. thanks for catching
[14:17] <hatch> last night I spent a few hours trying to track down our overall test failure and I have narrowed it down to one class
[14:17] <rick_h_> which class? 
[14:17] <hatch> but in that I found a LOT of tests which fail when run on their own
[14:18] <hatch> so those will need to be fixed
[14:18] <rick_h_> hmmm, that's good though if tests fail in isolation
[14:18] <hatch> sorry, suites which fail
[14:18] <hatch> no suite should rely on a previous suite
[14:18] <rick_h_> jcsackett: ^^ so the teardown in the tests first remove the dom and then the object bound to it. Those need to get swapped
[14:19] <rick_h_> hatch: +1 for sure
[14:19] <jcsackett> rick_h_: oh, yeah, that would be good.
[14:19] <rick_h_> why I like the split files in normal YUI tests
[14:19] <hatch> rick_h_: yep
[14:19] <rick_h_> jcsackett: yea, in some cases the CI would choke because it was trying to unbind itself from a dom node long gone
[14:19] <hatch> rick_h_: the failing class has something to do with the jujuTests.utils.SocketStub class
[14:20] <hatch> if I remove the tests which use that stub they never fail
[14:20] <rick_h_> hatch: https://codereview.appspot.com/8296043/ is my branch that does the move to the handlebars helper and such
[14:20] <rick_h_> hatch: hmmm, good to know where to look then. That could suck debugging out the socket stuff like that. I've not really messed with any of that
[14:22] <hatch> yeah I'm going to bring up my findingsin our standup in 1.5h
[14:22] <rick_h_> hatch: cool
[14:22] <hatch> is there going to be a codereview url for Huw's code?
[14:23] <rick_h_> hatch: yes, I looked it over and qa'd it. It's not complete and we'll get UX to do some reviews in a bit
[14:23] <rick_h_> hatch: so if you can also peek at that I'd appreciate it
[14:23] <hatch> ahh ok
[14:24] <rick_h_> hatch: it's just showing as from me since he seems to have some issues iwth lbox/landing and I'd rather he spent time working on it vs trying to fix it
[14:24] <rick_h_> I think some of his stuff was hitting some timeouts in the api calls lbox makes to LP and such
[14:25] <hatch> ahh I gotcha
[14:25] <rick_h_> so our rule is he codes by night, I help him land by my day, and hopefully he's ready to go the next night. timezones ftw!
[14:27] <hatch> haha yeah I used to work with a team from AUS, and I was their only NA developer so at the end of the day I'd commit code and vise versa so the progress never stopped heh, it was kind of cool - also irritating sometimes if you needed some info
[14:52] <hatch> man I wish rietveld id's were sequential
[14:53] <hatch> or hashes - at least then they woudln't look sequential :D
[14:54] <hatch> the three reviews I'm working on all end in 043 :D
[15:00] <rick_h_> lol
[15:03] <rick_h_> hatch: that's crazy. Missed that when looking. 
[15:08] <hatch> rick_h_: did you notice that you can't LGTM your own code on rietveld? https://codereview.appspot.com/8311043/
[15:09] <rick_h_> hatch: yea, oh well. 
[15:09] <rick_h_> it doesn't know it's actually Huw's code
[15:13] <hatch> yeah - that's odd that it doesn't allow it
[15:13] <hatch> but you can still commit it regardless
[15:13] <hatch> haha
[15:13] <rick_h_> can't hold me back!
[15:26] <hatch> rick_h_: I'm qa'ing this design branch and the charm slider thing is just bouncing back and forth outside of the sidebar
[15:26] <hatch> charm Browser is on two lines with what looks like a search box under it
[15:26] <rick_h_> hatch: yea, the design branch only effects the fullscreen urls
[15:26] <rick_h_> the sidebar isn't handled yet
[15:27] <rick_h_> so http://uistage.jujucharms.com:8080/bws/fullscreen/precise/cassandra-2 is a sample url to qa
[15:27] <hatch> you should really position absolute this stuff so that you don't have to scroll down :)
[15:27] <rick_h_> only your local branch that is :)
[15:27] <rick_h_> hatch: :P
[15:27] <rick_h_> it really shouldn't reload the page 3 times so it doens't scroll you back to the top :P
[15:28] <hatch> rick_h_: am I supposed to be able to check/uncheck these checkboxes? or is that still WIP?
[15:28] <hatch> under quality
[15:29] <rick_h_> hatch: yea, wip. They'll get replaced with icons if checkmark and red x
[15:29] <rick_h_> they won't be editable
[15:29] <hatch> ok and one more thing - the Add button in the top right is two different colors of red
[15:30] <hatch> it's looking really good though
[15:30] <rick_h_> hatch: ok, note it please with a screenshot if you get a chance
[15:31] <rick_h_> I'd still like to be able to land it though with a bug/update report
[15:31] <rick_h_> if we get it quick I might be able to get staging updated for the UX folks to see progress before their EOD :)
[15:31] <rick_h_> hmm, I don't see the double red. Do you mean between two places or two colors on the same button?
[15:31] <hatch> sec
[15:31] <hatch> i'll screenshot
[15:31] <rick_h_> thanks
[15:32] <rick_h_> but yea, this is a first pass. There's still some more updates in a couple of tabs, the interaction between full/sidebar sizes to fix up. url tracking for tabs, etc
[15:32] <hatch> pm'd the link
[15:33] <rick_h_> thanks
[15:58] <Makyo> jujugui call in 2
[16:00] <Makyo> rick_h_, joining us today?
[16:01] <rick_h_> Makyo: yep, sec
[16:01] <Makyo> rick_h_, alright.
[16:25] <teknico> gentle reminder, quick'n'easy review opportunity, get your fix! https://codereview.appspot.com/8307043
[16:35] <hatch> teknico: on it
[16:35] <teknico> hatch, thank you :-)
[16:37] <hatch> teknico: looks good but can you do me a favour and comment out every other test file in test index.html, run the tests, then uncomment them and use describe.only() and run the tests for both prod and debug?
[16:37] <hatch> I know it's a lot of work but I'd really like to track down these test failures
[16:37] <hatch> :)
[16:37] <hatch> if not that's ok too :)
[16:38] <teknico> hatch, ok, now breath deeply and say it again *slowly* :-)
[16:38] <teknico> :-)
[16:38] <hatch> lol ok
[16:38] <hatch> I want to make sure that these tests don't rely on anything in the environment from previous tests
[16:38] <teknico> ok
[16:38] <hatch> so in order to do that we need to do a couple things
[16:39] <frankban> Makyo: do you have a minute for a call?
[16:39] <hatch> first step is to comment out every other test file in the index.html and only run this python one
[16:39] <Makyo> frankban, sure.
[16:39] <teknico> ok
[16:39] <frankban> Makyo: emily
[16:39] <hatch> next step is to uncomment all of those tests and add .only() to the describe
[16:39] <hatch> so that it will load all the other tests but only execute yours
[16:40] <hatch> if any of those fail then we have an issue with it relying (or being affected) by previous tests
[16:40] <teknico> hatch, do you mean to add .only() to just one of the tests I added, once per test?
[16:41] <hatch> nope to the describe so describe.only('your test suite', function....
[16:41] <teknico> hatch, oh, at the top, right
[16:42] <hatch> thanks sir
[16:42] <teknico> hatch, do you suspect I might get different results from what you're getting?
[16:42] <hatch> I do - but I hope you don't :D
[16:42] <teknico> hatch, ok, trying
[16:50] <teknico> hatch, when I comment out all other test files, I do get an error:
[16:50] <teknico> TypeError: 'undefined' is not a function (evaluating 'juju.newEnvironment({conn: conn})') (http://localhost:8084/test/test_env_python.js:22)
[16:50] <hatch> ugh
[16:51] <hatch> ok I'm going to propose that we create slack tasks for these fixes and tag them all the same
[16:51] <teknico> hatch, and I get the same error when using describe.only
[16:51] <hatch> yeah that's what I was afraid of
[16:52] <teknico> both when running make test-prod
[16:54] <hatch> alright can you make a bug on LP with those details and tag it with 'test-improvement'
[16:55] <hatch> please and thank you :)
[16:55] <teknico> hatch, sorry, I'm landing my branch and somewhat in a hurry to get out the door :-)
[16:55] <hatch> ok np I can create it
[16:55] <teknico> EOD and all that
[16:55] <teknico> hatch, thanks!
[17:23] <hatch> I think my sub is finally giving up the ghost after 10years
[17:26] <bac> you have your own submarine?
[17:27] <bac> or a really old sandwich?
[17:27] <bac> bcsaller: hey got a sec?
[17:27] <hatch> sub wooooooofer :P
[17:27] <bcsaller> bac: sure
[17:32] <hatch> bcsaller: any idea when you're going to drop your branch with the fakebackend stuff? I just want to make sure none of my changes are going to be clashing with yours
[17:33] <bcsaller> hatch: I can push a wip version in a few minutes and give you a link
[17:33] <hatch> cool thanks
[17:34]  * hatch races to complete to bcsaller has to deal with the conflicts
[17:34] <hatch> :P
[17:34] <hatch> s/to/so
[17:34] <bcsaller> ha
[17:35] <bcsaller> hatch: as long as we don't implement the same methods it should merge cleanly
[17:35] <hatch> yeah bzr is pretty smart that way
[17:35] <bcsaller> and that would be bad for other reasons
[17:35] <bcsaller> I did try to attach my face to the cards I'm covering 
[17:50] <hatch> ugh this testing is driving me up the wall
[17:54] <hatch> I'm almost 100% convinced all of our errors are comign from the instances created and never cleaned up in the test utils file
[18:01] <hatch> looking for two quick reviews https://codereview.appspot.com/8331043/
[19:09] <bac_> hey bcsaller, i'm trying to push the endpoints controller into the views as you suggested.  some tests are failing because, e.g, topo.get('endpointsController') is undefined.  is there another step to push it from the view into topo?
[19:38] <hatch> going to take lunch
[19:38] <bac> bcsaller: nm
[19:38] <hatch> before I go, bac did you get it?
[19:38] <hatch> oh
[19:38] <hatch> :)
[19:39] <hatch> looks like launchpad is down
[19:53] <bac> hatch: wfm.  mustf
[19:53] <bac> must've been a short glitch
[20:01] <bcsaller> bac: I'm guessing you got this but you have to pass it from the env view into the topo.
[20:02] <bac> bcsaller: yeah Makyo showed me that code
[20:02] <bcsaller> excellent
[20:19] <hatch> back
[20:20] <hatch> and good lp is back up :)
[20:53] <bac> hatch, bcsaller: the new MP is up, if you're interested in having another look...but i can also get others to do it.
[20:53]  * bac -> dog walk.  bbiab.
[20:54] <bac> oh: https://codereview.appspot.com/8338043
[20:58] <hatch> sure
[21:43] <ahasenack> guys, I'm having trouble logging in on the juju gui, it just sits there. javascript console has a lot of these: http://pastebin.ubuntu.com/5674867/
[21:43] <ahasenack> have you seen this before?
[21:44] <hatch> ahasenack: is this on uistage?
[21:45] <ahasenack> hatch: no, my own deployment, using "stable"
[21:45] <ahasenack> using chrome 26.0.1410.43 (Official Build 189671) 
[21:45] <ahasenack> (not chromium)
[21:46] <hatch> ok one moment
[21:47] <ahasenack> hatch: it opened now
[21:48] <ahasenack> hatch: after ~10min or so
[21:48] <ahasenack> hatch: it's a big juju deployment, maybe because of that
[21:48] <ahasenack> hatch: well, bigish, around 40 computers
[21:49] <hatch> hmm no that shouldn't be it
[21:49] <hatch> I'm just investigating that error
[21:49] <hatch> sorry I'm doing like 10 things at once :D
[21:50] <hatch> ahasenack: ok that error shouldn't happen
[21:51] <ahasenack> hatch: ok
[21:51] <hatch> it's saying its an unknown event of type msg
[21:51] <hatch> but msg is a known and valid event
[21:51] <hatch> is it reproducable?
[21:52] <hatch> reproducible*
[21:52] <ahasenack> hatch: I think it's still showing
[21:52] <ahasenack> hatch: let me clear the console
[21:53] <ahasenack> hatch: I don't see it anymore, let me logout and login
[21:54] <ahasenack> logout got me this
[21:54] <ahasenack> Uncaught TypeError: Cannot read property 'parentNode' of null 
[21:54] <ahasenack> http://pastebin.ubuntu.com/5674904/
[21:54] <ahasenack> let me try login now
[21:55] <ahasenack> hatch: worked right away, just got one tiny backtrace
[21:55] <ahasenack> http://pastebin.ubuntu.com/5674908/
[21:55] <hatch> ok we have a ticket already for that one - actually it may be fixed in trunk already
[21:56] <ahasenack> I'm trying a new incognito window
[21:57] <ahasenack> hatch: yeah, it happened again
[21:57] <ahasenack> hatch: I think right after the login form showed fully
[21:58] <hatch> it throws the unknown event error?
[21:58] <hatch> does it hang too?
[21:58] <ahasenack> hatch: http://i.imagebanana.com/img/iijtafab/Selection_004.png
[21:59] <ahasenack> hatch: it's not frozen, I haven't typed in a password yet
[21:59] <hatch> ok let me know if it works as expected
[21:59] <ahasenack> hatch: I'm logging in, and it looks like it will take a long time again
[21:59] <hatch> hmm
[22:00] <ahasenack> page looks frozen, cursor is a normal arrow, events keep coming in in the console
[22:03] <hatch> hmm
[22:06] <hatch> I'm not even sure what version 'stable' is
[22:06] <hatch> jujugui anyone know ^
[22:07] <hatch> ahh looks like it's from 2013-02-35
[22:08] <hatch> ahasenack: I would be interested if the error still happens on trunk - are you familiar with the process to deploy trunk? Or is this a 'real' environment you're working with?
[22:09] <ahasenack> hatch: it's 0.3.1
[22:09] <ahasenack> hatch: this one I can't upgrade, but if I get the chance I will try trunk
[22:09] <hatch> hmm
[22:10] <hatch> I thought our most recent release was 0.2.1
[22:10] <Makyo> hatch, ahasenack - event is missing the 'op' attribute.  Looks like strange data coming from juju.
[22:10] <hatch> Makyo: oh you're right
[22:10] <hatch> I missed that
[22:10] <hatch> oops
[22:10]  * hatch kicks himself
[22:15] <ahasenack> hatch: oh, and it logged in now
[22:15] <ahasenack> I wasn't paying attention to that window, could have been a few minutes ago
[22:16] <Makyo> There is an err: true in there, so maybe it's a response to a bad call from the gui.
[22:21] <ahasenack> I need to go, see you guys around tomorrow
[22:21] <hatch> Makyo: that's returned by default I think...see ln123 in python.js
[22:21] <hatch> ahasenack sure thing have a good night
[22:22] <ahasenack> thanks
[22:22] <ahasenack> you too
[22:23] <hatch> bac: review done - let me know if you have any questions
[22:24] <Makyo> hatch, That would mean the gui's in read-only mode, correct? And if so, the 'eventually logging in' part of the problem seems kind of out of place.  Looking into _firePermissionDenied, though.
[22:25] <Makyo> Ah, just adds a notification.  Something to ask about later
[22:25] <hatch> Makyo: yeah that's what I was thinking too
[22:26] <hatch> I can't think of any other instance when err would be 'true'
[22:26] <Makyo> Yeah, not unless something really did come from juju with an error.
[22:26] <hatch> yeah but that would log to the juju console
[22:26] <hatch> I guess I never got him to check that
[22:26] <hatch> :)
[22:30] <hatch> yay one more test then I'm done un/expose
[22:30] <hatch> holy lots of tests
[22:40] <hatch> ok I need to assert a string which has single quotes in it so I wrapped it with double quotes....well the linter doesn't like that
[22:40] <hatch> so I escaped them....but now they won't assert
[22:40] <hatch> lol
[22:40] <hatch> any way I can tell the linter to shove-it ?
[22:49] <hatch> ahah!
[22:49] <hatch>   /*jshint quotmark:double*/
[23:01] <hatch> if anyone is still around and looking for a review to do :) https://codereview.appspot.com/8339044/
[23:09] <Makyo> Sure, give me a few.
[23:19] <hatch> thanks
[23:55] <Makyo> hatch, for later, it occurs to me that ahasenack won't be able to check notifications until the login eventually succeeds, since they aren't available until then through the UI, and may not even be stored.  Still, we can hope.