[11:34] <frankban> hi rogpeppe: when you have time, I need another approval for https://codereview.appspot.com/7947043/
[11:35] <rogpeppe> frankban: looking
[11:35] <frankban> rogpeppe: thanks
[11:37] <rogpeppe> frankban: there was one little thought i had last night, and it seems i lost the comment somewhere
[11:38] <rogpeppe> frankban: in annotator.insertOps, if you reverse the order of the operations, the code could become a little simpler looking
[11:40] <rogpeppe> frankban: like this: http://paste.ubuntu.com/5649143/
[11:41] <frankban> rogpeppe: I see. ok
[11:48] <frankban> rogpeppe: I'll make this change and then land the branch, sounds good?
[11:48] <rogpeppe> frankban: i've just made one other final suggestion in the review
[11:49] <rogpeppe> frankban: LGTM with both those changes made, thanks!
[11:49] <frankban> rogpeppe: cool, thanks
[12:15] <gary_poster> frankban, hi.  are you available for a quick consultation on some CI/shelltoolbox topics?
[12:16] <frankban> gary_poster: sure
[12:16] <gary_poster> thanks frankban.  no rush, guichat when you are available
[12:25] <rogpeppe> gary_poster: hiya
[12:26] <rogpeppe> gary_poster: do you know if anyone is currently working on adding more fields to the various allwatcher info types?
[12:26] <gary_poster> rogpeppe, benji if anyone
[12:26] <gary_poster> he will be the person to do it
[12:27] <benji> rogpeppe: not at the moment, but soon
[12:27] <rogpeppe> benji: ah - i've had a request from green for public address and status in unit info. if you're about to do it, i'll leave it to you though.
[12:28] <benji> rogpeppe: I can do that, if gary_poster doesn't have any immediate plans for other things for me to work on
[12:29] <gary_poster> benji, I would take advantage of rogpeppe being willing to do some of the work we need :-)
[12:29] <rogpeppe> lol
[12:29] <benji> heh
[12:30] <rogpeppe> benji: i'd be happy to do it. i could do all the other fields at the same time if you like - let me know what you need
[12:30] <benji> we need what is used in the GUI, let me see if there is an easy to extract list
[12:32] <gary_poster> benji, my guess was in app/store/env/sandbox.js in _deltaWhitelist
[12:32] <gary_poster> it is at least a reasonable start
[12:32] <benji> cool, looking
[12:35] <benji> rogpeppe: here is a pretty good list of attributes: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/store/env/sandbox.js#L213
[12:40] <rogpeppe> benji: thanks. the only immediate issue i see is machine.instance_state and machine.public_address
[12:41] <rogpeppe> benji: because we don't currently have those available.
[12:41] <rogpeppe> benji: except by talking directly to the environment
[12:41] <benji> we'll take what we can get, for the time being :)
[12:42] <gary_poster> rogpeppe, agreed with benji, but I suspect we need to figure out how to get at least one of those.  I'll do a quick search...
[12:42] <rogpeppe> gary_poster: i have two possible solutions in mind
[12:43] <gary_poster> we definitely use public_address...
[12:43] <gary_poster> looknig for other
[12:43] <gary_poster> yup, we use instance_state too
[12:43] <rogpeppe> gary_poster: could you use the public address from the units instead?
[12:44] <gary_poster> rogpeppe, if they are functionally equivalent then absolutely
[12:44] <rogpeppe> gary_poster: yes, i think the PublicAddress in a unit is just what would be provided by the machine
[12:44] <gary_poster> rogpeppe that's perfect then
[12:45] <rogpeppe> gary_poster: the instance state is a little harder, as it's something that needs to be polled from the provider
[12:45] <gary_poster> benji ^^ PublicAddress on units will require some tweaks.  Could you note somewhere, publicly (card) or privately (personal task)
[12:45] <rogpeppe> gary_poster: one solution involves putting the information in the state, and adding a jujud worker that polls for information from the provider. the other involves adding an API call to retrieve the info explicitly
[12:45] <benji> gary_poster: dure
[12:45] <gary_poster> :-)
[12:45] <benji> or "sure" even
[12:46] <rogpeppe> gary_poster: i'm inclined towards the latter currently. something like MachineInfo(id string) struct{PublicAddress string; InstanceState string}
[12:46] <gary_poster> rogpeppe, that sounds workable.  We only show that on one very deep detail page
[12:47] <gary_poster> rogpeppe, what would you expect the usual turn-around time on a response to that query to be?  or is that a fair question?
[12:47] <rogpeppe> gary_poster: that seems good then. and it's something that can be changed deliberately by an admin, so having manual control of refresh might be a good thing
[12:47] <benji> gary_poster: card added 
[12:48] <gary_poster> thank you benji
[12:48] <rogpeppe> gary_poster: 680ms
[12:48] <benji> np
[12:48] <rogpeppe> gary_poster: more or less :-)
[12:48] <gary_poster> rogpeppe, lol ok UI'll take it
[13:52] <hatch> mornin
[14:00] <teknico> rogpeppe, hi :-) I need some more help with one last reset() function in api_test.go
[14:01] <rogpeppe> teknico: i've got a call right now. will be with you in a short while.
[14:01] <teknico> rogpeppe, great, thanks
[14:01] <teknico> I'll start writing as an attempt to optimize the pipeline :-)
[14:02] <teknico> I rewrote opClientServiceDestroy to attempt destroying a non-existent service, as you mentioned yesterday: http://pastebin.ubuntu.com/5649448/
[14:03] <teknico> it works because TestOperationPerm ends up matching the error with "permission denied" (not sure how much the test is meaningful though)
[14:03] <teknico> however, I still have a problem with opClientDestroyRelation: opClientDestroyRelation
[14:03] <teknico> ehm, http://pastebin.ubuntu.com/5649442/
[14:03] <hatch> benji: doing a review on your branch right now
[14:04] <benji> cool, thanks hatch 
[14:04] <teknico> as you can see, it has the usual problem of trying to destroy the relation that still exists
[14:05] <teknico> sorry, it tries to *add the relation that has not been destroyed yet
[14:05] <teknico> I tried rewriting it in the same guise as opClientServiceDestroy, attempting to destroy a non-existent relation
[14:05] <teknico> but the result is not as good: it works for some machines but not for others in the loop
[14:07] <teknico> that's the last reset() function you asked me to add, then I'll be able to propose this branch and go back to what I was working on originally
[14:12] <hatch> gary_poster: after the morning chat can you bring me up to speed on the CI stuff?
[14:12] <gary_poster> sure thing hatch
[14:12] <gary_poster> thanks
[14:14] <hatch> benji: review done - just trivial stuff but I think you might agree :)
[14:14] <benji> cool, I'll take a look
[14:25] <rogpeppe> teknico: out of call
[14:25] <rogpeppe> teknico: looking at your paste
[14:25] <rogpeppe> teknico: how about just DestroyRelation("foo", "bar") ?
[14:26] <teknico> rogpeppe, you asked for it: :-) http://pastebin.ubuntu.com/5649498/
[14:26] <rogpeppe> lol
[14:26] <benji> hatch: thanks for the review, I've responded, most interestingly to the asynchonicity issue
[14:27] <rogpeppe> teknico: interrrresting...
[14:28] <hatch> benji: so wrt the done() - I meant to put the done() in the event callback
[14:28] <gary_poster> jujugui call in 2
[14:29] <rogpeppe> teknico: that doesn't look like it's related to the DestroyRelation. it may be a genuine, honest to goodness bug. :-)
[14:29] <hatch> right now "potentially" the conn.msg() call could fire, and before the callback is run it could run the assert
[14:29] <teknico> rogpeppe, nice
[14:29] <rogpeppe> teknico: could you paste me a branch url please?
[14:29] <hatch> this is a huge MAYBE - but one that would be damn near impossible to track down :)
[14:29] <teknico> rogpeppe, https://code.launchpad.net/~teknico/juju-core/fix-cleanup-in-api-tests
[14:29] <teknico> rogpeppe, and now it's my turn to have a call
[14:30] <benji> I'm torn between putting in a done() to be pragmatic and resisting voodoo.
[14:30] <rogpeppe> teknico: ok, that'll keep me busy for a bit...
[14:30] <teknico> rogpeppe, what if I just leave that last one out for now?
[14:31] <rogpeppe> teknico: let me try to get to the bottom of the issue first
[14:31] <teknico> rogpeppe, ok
[14:31] <rogpeppe> teknico: it *should* work, i think
[14:42] <hatch> benji: yeah - I can see it never being an issue but I would like to err on the side of caution :)
[14:45] <hatch> rick_h_ possible to get that review?
[14:45] <teknico> rogpeppe, out of call, shoot when ready
[14:45] <Makyo> Some morning humor: https://github.com/joho/7XX-rfc
[14:46] <rick_h_> hatch: ah, yea. link me again please? It doesn't show in my codereview since i didn't participate yet
[14:46] <hatch> https://codereview.appspot.com/7815047/
[14:47] <teknico> Makyo, ha! that's nicely comprehensive, except for one glaring omission: no mention of mysql
[14:47] <Makyo> teknico, Hah!
[14:47] <rogpeppe> teknico: try this: lp:~rogpeppe/juju-core/tekniko-fix-cleanup-in-api-tests
[14:48] <teknico> Makyo, otoh, it having to be on *github* is slightly unnerving, do they plan that many revisions?
[14:48] <Makyo> RFPR - Request For Pull Requests?
[14:49] <teknico> rogpepbe, I will, I mean rogpeppe ;-)
[14:54] <teknico> rogpeppe, while tests run, did that last failure actually expose a bug or not?
[14:54] <rogpeppe> teknico: no, it didn't
[14:54] <rogpeppe> teknico: i'd missed the assertion failure higher up the log
[14:54] <rogpeppe> teknico: i *think* that branch should give you most of what you need
[14:54] <teknico> rogpeppe, good
[14:55] <rogpeppe> teknico: you can look at the diffs to see what i did to solve the problem
[14:56] <teknico> rogpeppe, I did, and I may even have understood the approach :-)
[14:56] <rogpeppe> teknico: :-)
[14:57] <teknico> rogpeppe, the TestOperationPerm tests pass, great job, thanks!
[14:57] <teknico> rogpeppe, now running all apiserver tests, and then the whole thing
[14:57] <rogpeppe> teknico: cool
[15:00] <bac> hi bcsaller, free to chat?
[15:00] <bcsaller> bac: winding down call, maybe  5 minutes
[15:00] <bac> bcsaller: great
[15:15] <rick_h_> hatch: heads up, I got a conflict merging your branch into a fresh trunk copy in app/views/topology/service.js so an quick pull from trunk should make landing easier 
[15:19] <bcsaller> bac: still on call, I'll ping you soon
[15:19] <bac> ok
[15:21] <rick_h_> hatch: ping
[15:21] <hatch> hey sorry in call
[15:21] <rick_h_> hatch: ah, np. got ? for you when you get off in QA here
[15:21] <hatch> sure
[15:30] <hatch> rick_h_ guichat?
[15:30] <rick_h_> hatch: sure can, sec
[15:30] <bcsaller> bac: ok, off call
[15:31] <bac> bcsaller: ok.  so you want to hangout now or in a few minutes?
[15:31] <frankban> benji: LGTM with a few questions
[15:31] <benji> cool, thanks
[15:31] <benji> I'll be done with your review in a minute.
[15:31] <bcsaller> bac: we can do it now but I think normal chat room is taken
[15:32] <bac> bcsaller: i'll make one
[15:35] <teknico> uhm, I wonder why compiz is a bit crashy lately
[15:37] <Makyo> teknico, has been for me, too.
[15:37] <Makyo> Dash, too.
[15:37] <Makyo> Blacklisting my work directory helped, so that it wouldn't search through branches.
[15:38] <teknico> Makyo, oh, nice, if it speeds it up it's definitely worth it, how do I do that?
[15:39] <Makyo> teknico, System Settings - Privacy - Files - Don't record activity in the following folders.
[15:39] <Makyo> Makes a big difference, even with "Record activity" set to off.
[15:40] <teknico> Makyo, why do I have no Privacy icon in system settings?
[15:41] <Makyo> teknico, 12.10?
[15:41] <teknico> Makyo, yep, are you on raring?
[15:41] <Makyo> teknico, Not yet.
[15:41] <teknico> uhm
[15:42] <Makyo> Another that helped, if you have ccsm, is to go to the Unity Plugin, Experimental tab, and set Dash Blur to No Blur.
[15:44] <teknico> Makyo, found that one, thanks, but now the dash is a bit too transparent
[15:44] <teknico> Static Blur seems a nice compromise, whatever that means :-)
[15:48] <hatch> oh man my internet is so slow right now
[16:03] <teknico> rogpeppe, it's finally there: https://codereview.appspot.com/7873046
[16:03] <rogpeppe> teknico: thanks! looking...
[16:06] <hatch> rick_h_ FYI I have been using tmux for my ubuntu ssh and it's workign really well although it triggers a lot of 'changed' events causing my terminal tab to flash when nothing has changed
[16:06] <hatch> I don't know if you have run into the same thing before?
[16:06] <rick_h_droid> hatch cool. yea any activity in the Window will activate things.
[16:07] <hatch> but there is no activity - does it maybe poll which triggers activity?
[16:08] <rick_h_droid> hmm I use it for irc and it has a clock that updates and join/part messages
[16:08] <rick_h_droid> so it's always updating 
[16:08] <hatch> ahh ok no problem I was just curious really
[16:11] <hatch> rick_h_droid I pushed the new merge - it all worked properly here
[16:11] <hatch> try a fresh checkout
[16:12] <hatch> I'm just about to run the tests in IE
[16:13] <rick_h_droid> ok will do
[16:13] <hatch> but first I better let these updates finish - updating a vm and tryign to use it at the same time is....well damn near impossible lol
[16:20] <hatch> gary_poster: it's looking like travis can do bzr
[16:20] <gary_poster> hatch, really!  interesting
[16:20] <gary_poster> I thought it was github specific
[16:20] <hatch> yeah - i'm trying to load more details but my internet is VERY slow
[16:20] <hatch> will link in a sec
[16:20] <hatch> :)
[16:22] <gary_poster> hatch, I looked before and stopped reading after this sentence, actually: "As a free community service, Travis CI limits build duration to about 20 minutes"
[16:22] <gary_poster> unfortunately
[16:22] <gary_poster> that's not us
[16:22] <rogpeppe> teknico: reviewed
[16:23] <hatch> gary_poster: they have a 'pro' version in beta and it's also OSS so we could run it ourselves (if we wanted)
[16:24] <gary_poster> no reason to run YA CI system AFAIK.  :-/
[16:24] <gary_poster> the hosting part is the good part
[16:24] <gary_poster> hatch, going to go get some lunch. biab
[16:24] <teknico> rogpeppe, thanks but... oh no! latestUnit! I don't want to lose it!
[16:24] <hatch> sure - I agree
[16:24] <hatch> just letting you know :)
[16:25] <gary_poster> cool :-)
[16:25] <teknico> rogpeppe, :-) can it be useful somewhere else?
[16:25] <rogpeppe> teknico: you'll just have to treasure it in your memory (and bzr history) :-)
[16:25] <hatch> rick_h_droid the lock-zoom branch passes the tests in IE as well so as long as you can confirm you don't get those errors with this merge then I'll submit
[16:25] <rogpeppe> teknico: nothing is lost :-)
[16:25] <rick_h_> hatch: so I'm still seeing the error/issue when I go to all notifications, then click 'view details' on the first one
[16:26] <rick_h_> hatch: and the same issue on the N10 with the view details, but working on the N7
[16:26] <hatch> well what the...
[16:26] <hatch> I can't even reproduce in IE
[16:26] <hatch> haha
[16:27] <hatch> this is on a fresh checkout?
[16:27] <rick_h_> I get it in both stable chrome and the beta chrome on the N10
[16:27] <rick_h_> hatch: yes, all merged with trunk, pulled your latest updates, make clean-all, make, make devel
[16:27] <hatch> ahah!
[16:27] <rick_h_> hmm, /me goes to try the test-server on the machine
[16:27] <hatch> I was able to reproduce it
[16:28] <hatch> :D
[16:28] <rick_h_> which one?
[16:28] <hatch> Uncaught TypeError: Cannot read property 'parentNode' of null
[16:28] <rick_h_> ah cool
[16:28] <hatch> damn I'll have to write a test for this now
[16:28] <hatch> lol
[16:30] <rick_h_> wow, crazy to see how tests run in 17.8s on desktop chrome, passing 50s on the N10
[16:31] <hatch> rick_h_ that error is on trunk
[16:31] <hatch> so I'm going to merge this then create a ticket for it
[16:31] <hatch> are you ok with that?
[16:31] <hatch> that's why I couldn't reproduce it :D
[16:31] <rick_h_> hatch: sure thing. So my QA is that N7 looks ok, N10 has issues we don't know about yet
[16:32] <hatch> ok, although not ideal, I don't have a N10 to test with
[16:32] <rick_h_> though after 159s :( all tests do pass on the N10
[16:32] <rick_h_> hatch: yea, I can try to help at some point but really under the gun. 
[16:32] <hatch> yeah - when I was starting with the N7 - I could simulate the needed events but manually they woudln't work
[16:32] <hatch> so the tests would pass but it woudln't work hah
[16:59] <hatch> anyone know what ports I need for juju communication?
[16:59] <hatch> just 22?
[17:01] <hatch> so far I have 22, 80, 443
[17:05] <gary_poster> hatch juju communication from the GUI? to what?
[17:05] <hatch> I was just thinking what ports things like 'juju bootstrap' communicates through
[17:07] <gary_poster> hatch, ah.  not sure.  would have guessed 22.  bcsaller, you happen to know?
[17:07] <hatch> that's entirely possible - I'm just spinning up the instance now
[17:07] <hatch> so I haven't gotten that far
[17:07] <gary_poster> oh ok
[17:08] <hatch> sorry I googled tarmac and realized I had no idea what was going on so took the EC2 setup side
[17:08] <hatch> s/going/doing
[17:08] <hatch> :)
[17:08] <gary_poster> hatch, cool.  I may need to do ec2 also.  was about to in fact
[17:09] <gary_poster> jenkins has been waiting for an m1.small for almost an hour now
[17:09] <gary_poster> on canonistack
[17:09] <hatch> oh that's what it was doing
[17:09] <hatch> I was wondering
[17:09] <gary_poster> yup
[17:09] <gary_poster> for the bootstrap node
[17:09] <gary_poster> fun
[17:10] <hatch> oh geeze - then it will definitely fail because it won't be able to provision any more :)
[17:10] <gary_poster> unless it waits forever for that.
[17:11] <hatch> guichat to run over what I am to do with this micro instance?
[17:11] <gary_poster> y
[17:29] <teknico> rogpeppe, all tests pass, landed, fingers crossed :-)
[17:30] <rogpeppe> teknico: cool, thanks!
[17:32] <hatch> doing this CI I wish we were in an office so I could do this http://imgs.xkcd.com/comics/compiling.png
[17:32] <hatch> :D
[17:46] <hatch> gary_poster: Unexpected initial authentication state: [True, None]
[17:46] <hatch> have you seen that one? IE test_staging_services error
[17:47] <gary_poster> hatch that's a diagnostic I added for that test.  The good news is that I never actually got the diagnostic before because of a problem I apparently fixed in the previous revision :-)
[17:47] <gary_poster> lemme remind myself...
[17:48] <gary_poster> hatch, that should just be info--how did the test itself fail?
[17:48] <hatch> I'm not sure I'll have to review the video
[17:48] <hatch> oh wait
[17:48] <hatch> it didn't fail
[17:48] <gary_poster> hatch pastebin the output for me pls?
[17:48] <gary_poster> yay!
[17:48] <gary_poster> good that makes sense
[17:49] <hatch> man do these tests fly now :)
[17:49] <gary_poster> heh, good
[17:50] <hatch> chrome and firefox both say " unable to complete test run." ERROR
[17:50] <hatch> they are alsmost all done then I"ll link you the output
[17:55] <gary_poster> hatch so let's go to guichat
[18:09] <hatch> 3x-5x speed increase for Y.Base coming in the next YUI
[18:09] <hatch> OOoOOOooooo
[18:11] <rick_h_> yay
[18:12] <hatch> that's HUGE considering that base is in everything
[18:12] <hatch> haha
[18:12] <benji> gary_poster: my telepathy tells me that now is a good time for you to talk about my next task
[18:13] <gary_poster> benji :-) ok to the guichat
[18:24] <hatch> ok it takes ~16:30 to start the tests
[18:37] <hatch> gary_poster: firefox exhibits the same 'caching issue' that IE does
[18:38] <hatch> that's why the GUI tests are failing
[18:39] <gary_poster> hatch, ugh
[18:40] <gary_poster> hatch, btw on IE I have a new opinion about the Javascript Error thing and whether we should retry.  It's not cut and dry IMO.  We can have that conversation later
[18:40] <hatch> chrome finishes the unit tests then hangs
[18:40] <gary_poster> hatch, should timeout eventually
[18:41] <gary_poster> then we can see why the numbers are wrong
[19:09] <rick_h_> hatch: got a sec to sanity check this build issue? http://paste.mitechie.com/show/914/
[19:10] <rick_h_> jcsackett: maybe you know, did you deal with something like this ^^
[19:10] <rick_h_> it looks like it's trying to load the module from YUI vs the gui src
[19:14] <jcsackett> rick_h_: no, never saw that. has tabview been modified since i checked it in?
[19:15] <rick_h_> jcsackett: no, I did move it because I wondered if it was a path issue. It was originally just widgets/tabview
[19:15] <jcsackett> rick_h_: but you got this error with it as widgets/tabview too?
[19:16] <rick_h_> jcsackett: yea, hmmm, you konw it was working. I have a running make devel that was working ok. I wonder if something went batty. make clean_all time
[19:17] <rick_h_> I end up with a app.js.map laying around. /me goes through bin/merge-files
[19:18] <rick_h_> if I don't require the tabview in my view code it works
[19:19] <rick_h_> so I had a working setup, added the tabview, but didn't restart the make devel and it kept working. Once I stopped to lint/push it blows up
[19:22] <jcsackett> bizarre.
[19:22] <rick_h_> yea, grrr at this build stuff sometimes
[19:22]  * jcsackett nods
[19:41] <hatch> ok back
[19:42] <hatch> rick_h_ hae you solved the issue?
[19:43] <rick_h_> hatch: no, I'm tracing through how this merge-files gets it's list of files to merge/build but it's tedious 
[19:43] <rick_h_> hatch: some how the script thinks yui should have a node_modules/yui/browser-tabview/browser-tabview module
[19:44] <rick_h_> hatch: but we've got browser-tabview listed in our modules-debug and it's in the list and picked up as far as I can tell so far
[19:45] <hatch> that will happen if the module name is not specified
[19:45] <rick_h_> 'module name is not specified' where?
[19:46] <hatch> well if the module name isn't registered it'll try to load it from where yui.js was loaded
[19:47] <rick_h_> hatch: ok, getting closer. The if (details && details.requires) {
[19:47] <rick_h_> check is failing for the tabview module
[19:47] <rick_h_> looking into wtf dteails/details.requires is
[19:50] <rick_h_> oh hell...tabview module was a YUI().add instead of YUI.add
[19:50] <rick_h_> so it broke out of all the hacks in the build system to replace YUI.add and such I guess
[19:51] <rick_h_> thanks hatch jcsackett, all good now
[19:51] <jcsackett> rick_h_: well damn, sorry for that crap.
[19:52] <rick_h_> jcsackett: heh, all good. Simple error. Just hard to debug. Looking at the end of the files in the requires part vs the top of the file. 
[19:52] <hatch> rick_h_: haha oh I hate that - I've done that so many times
[19:52] <rick_h_> jcsackett: helped me also realize that the namespaces on the browser-tabview were reversed juju.browser.widgets vs juju.widgets.browser like elsewhere
[19:52] <rick_h_> hatch: hah! well lesson learned. Next time I see it it'll jump out at me more
[19:53] <rick_h_> and I figured out how to pdb up a node script as well 
[19:57] <hatch> pdb?
[19:57] <hatch> oooo that namespace thing should probably be fixed....no?
[19:58] <jcsackett> hatch: pdb is the python debugger; i'm guessing rick_h_ means he has figured out use of the node equivalent?
[19:58] <rick_h_> hatch: yea, I've got it correcting here
[19:58] <rick_h_> jcsackett: right, basically node debug xxxx allows you to do debugger; in a script
[19:58] <rick_h_> but it's fugly ... /me misses pdb
[19:59] <jcsackett> rick_h_: our tests are run via node when run in the command line, right? so we could potentially command line debug failures?
[19:59] <hatch> ohh ok  :) I was like "pdb? new node debugger??" h
[19:59] <hatch> aha
[20:01] <rick_h_> curses!!!!! now extend failed, verify dependencies in tests. /me pulls plug
[20:05] <jcsackett> rick_h_: did you add any extends?
[20:07] <rick_h_> jcsackett: no, didn't think so. looking over diff 
[20:12] <rick_h_> hmm, Y.TabView is undefined
[20:13] <rick_h_> but it's manually defined in merge-files
[20:14] <jcsackett> that's...bizarre.
[20:14] <jcsackett> rick_h_: you're hitting all the fun issues with this one, aren't you?
[20:15] <rick_h_> jcsackett: heh, well the dippy things works from the app. It's just getting build/test happy so I can submit some work
[20:17]  * jcsackett nods.
[20:17] <jcsackett> that *is* where the fun goes.
[20:18] <benji> hmm, that's odd: the units in an error state are grey (like running instances); I would have expected them to be red
[20:19] <jcsackett> rick_h_: do we think the charm-small widget will change size depending on where its used, or can we assume constant width? i'm thinking it should have a "width" attribute for purposes of placement in the category container. (and the slider, probs).
[20:20] <rick_h_> jcsackett: so for now I'm thinking it'll be constant and determined via css. Why a ATTR?
[20:21] <jcsackett> rick_h_: the charm container wants to be some multiple of the charm small width. and that will vary based on the "max" it shows before being expanded.
[20:21] <jcsackett> so it would be good if it could get the width from small and set its own width correspondingly, right?
[20:22] <rick_h_> jcsackett: so I'm thinking that what we'll do is to have the number to show be an ATTR on the container and let the charm-smalls just be block levels and will float/resize dynamically based on space via css
[20:22] <rick_h_> jcsackett: might attach it with the grids framework later on
[20:23] <jcsackett> rick_h_: ah, yeah, that works.
[20:23] <jcsackett> and means less work for me, so i'm down with that.
[20:23] <rick_h_> so I'd just default to say '5' in the container and we'll work the rest out from that
[20:23] <rick_h_> oh man this fixes it but damn is it evil
[20:25] <jcsackett> ?
[20:28] <rick_h_> https://code.launchpad.net/~rharding/juju-gui/fullscreen_charmview/+merge/155595 L466
[20:28] <rick_h_> jcsackett: ^
[20:29] <jcsackett> rick_h_: that's bizarre.
[20:29] <jcsackett> but if it works, it works.
[20:29] <jcsackett> (apparently bizarre is my new favorite word today)
[20:39] <rick_h_> hatch: I'm going to try to get this ready for review here in a sec. It's not complete. I'm coming up on a big diff at this point and will spend tomorrow refactoring, but it 'works' so want to close up a loop. 
[20:40] <hatch> sure
[20:40] <hatch> fyi - did you look into node-inspector?
[20:40] <rick_h_> hatch: no, didn't look at node-inspector
[20:40] <hatch> ok it's just another option for debugging node
[20:40] <rick_h_> ah bah...needed a -edit on there. One more ride...
[20:40] <rick_h_> cool, will keep that in mind
[20:50] <jcsackett> rick_h_: isn't this way late a day for you?
[20:51] <rick_h_> jcsackett: yea, well gotta get stuff done. Trying to go late from now until launch. Have a call in an hour anyway so meh
[20:51] <rick_h_> go lbox go... 
[20:55] <hatch> rick_h_ ok I'm ready
[20:55] <hatch> just needed to fire off a potential working CI
[20:55] <hatch> very potential
[20:55] <hatch> lol
[20:56] <gary_poster> hatch, another crazy idea: see what versions of chrome saucelabs offers on different platforms and try switching our chrome to other platforms/versions to see what happens
[20:56] <hatch> sure thing
[20:56] <hatch> I'm hoping it's a bug in the after
[20:56] <hatch> I had to push to my own branch - it woudln't let me push to yours
[20:57] <gary_poster> hatch, yeah, makes sense
[20:57] <gary_poster> we can only share in ~juju-gui branches
[20:57] <gary_poster> (or other teams we both are members of)
[20:57] <hatch> ohh ok
[20:58] <hatch> gary_poster: very simple change this time http://bazaar.launchpad.net/~hatch/juju-gui/ci/revision/467
[20:58] <hatch> and it still works locally
[20:58] <gary_poster> cool hatch
[20:58] <hatch> so as long as that wait_for_script() works as advertised it should work
[20:58] <gary_poster> :-)
[20:59] <hatch> hah
[20:59] <hatch> famous last words - I might as well quit now
[20:59] <hatch> lol
[21:01] <hatch> rick_h_ are we going to get a codereview url?
[21:01] <hatch> or is it just hung up in internet land
[21:11] <rick_h_> hatch: sorry, battery died at the coffee shop...lbox take 3
[21:11] <hatch> lol
[21:12] <rick_h_> yea, fail submit for this one...fighting me every step of the way
[21:13] <hatch> for some reason I am getting a ton of visits to my blog to invalid php urls
[21:15] <rick_h_> hatch: jcsackett https://codereview.appspot.com/7581045 there we go
[21:15] <hatch> awesome
[21:16] <rick_h_> so it's incomplete but it 'works' so I'd like to get it in and on staging for UX to play with while I spend tomorrow refacoring/solid'ing it up
[21:33] <hatch> review done
[21:34] <hatch> benji: your propose won't let me actually view any diffs
[21:34] <hatch> could you try proposing again?
[21:36] <hatch> everything looks ok as far as the merge goes
[21:45] <hatch> gary_poster: are you still around?
[23:16] <gary_poster> hatch, no :-)