[08:19] <rogpeppe> mornin' all
[08:25] <frankban> hi rogpeppe 
[08:28] <rogpeppe> frankban: hiya
[09:01] <frankban> rogpeppe, fwereade: isolation suite stuff proposed in https://github.com/juju/testing/pull/5
[09:02] <rogpeppe> frankban: looking
[09:02] <frankban> thanks
[09:03] <rogpeppe> frankban: if you're going to have a new package (not a bad thing), perhaps isolation.Suite might be a better name
[09:03] <rogpeppe> frankban: although testing.IsolationSuite would probably work fine too
[09:04] <frankban> rogpeppe: testing.IsolationSuite introduces an import loop
[09:04] <rogpeppe> frankban: what's the loop?
[09:05] <frankban> rogpeppe: logging requires testing, isolation (testing) requires logging
[09:05] <rogpeppe> frankban: logging requires testing? how come?
[09:06] <frankban> rogpeppe: the old LoggingSuite (that we need to preserve for backward compatibility) embeds testing.CleanupSuite
[09:07] <rogpeppe> frankban: that seems spurious to me
[09:07] <rogpeppe> frankban: can't we change all the places that use LoggingSuite to use IsolationSuite instead?
[09:11] <frankban> rogpeppe: we can, but that would require fixing all the  LoggingSuite tests using env vars. I guess we want to eventually do it anyway, but the idea is to have an incremental step in the direction of our current goal: separate utils/*, charm etc from juju-core/testing
[09:12] <rogpeppe> frankban: alternatively, just pull LoggingSuite into testing. it's easy to break out later.
[09:13] <rogpeppe> frankban: and it's all pretty trivial stuff
[09:14] <frankban> rogpeppe: I like this more, then we have everything into testing: testing.CleanupSuite, testing.Logging(Only)Suite and testing.IsolationSuite
[09:14] <rogpeppe> frankban: that sounds good to me
[09:16] <frankban> rogpeppe: +1, I'll do that. Please let me know when your review is done, and I'll start moving thos eparts
[09:28] <fwereade> frankban, rogpeppe: yeah, that sounds reasonable, it doesn't feel like such an awfully large package -- but I note that it's this sort of thing that causes packages to gradually grow (not wanting to create lots of tiny ones) and makes them hard to split up (because the loops often mean you can't split off *one* package, you have to split off two or three)
[09:28] <fwereade> frankban, rogpeppe: but I reiterate that in this case I think it's ok
[09:29] <rogpeppe> fwereade: i'd like to move towards loggingsuite not embedding cleanupsuite, and then we can factor out things.
[09:30] <rogpeppe> fwereade: i agree that it's not great that testing is likely to accumulate a big bag of deps
[09:30] <fwereade> rogpeppe, yeah, that is the plan
[09:31] <fwereade> rogpeppe, but starting by preserving LoggingSuite is the chosen first step on that path
[09:39] <frankban> fwereade, rogpeppe: MP updated, and it also seem juju-core must be changed in only one place to use the new logging suite path
[10:13] <rogpeppe> frankban: i'm not that familiar with github comments - i'm *thinking* that each comment is published the moment I click "Comment on this line", but please let me know if you haven't seen any review comments.
[10:15] <frankban> rogpeppe: yeah github comments are "real time" (and I don't like that since I usually iterate a lot when reviewing)
[10:15] <rogpeppe> frankban: yeah, i agree - i very often go back and change mments
[10:16] <rogpeppe> earlier comments
[10:16] <frankban> rogpeppe: except for juju-core, are we aware of other projects using the LoggingSuite?
[10:16] <rogpeppe> frankban: no, i'm pretty sure that juju-core is the only one (well, some of my stuff might do, but ignore that)
[10:18] <frankban> rogpeppe: just another question about your comments: I know the fixture methods are just methods, I used embedding because it seemed sane to me to rely on the gocheck runner, without simulating its behavior (which I agree is not likely to change, but who knows...)
[10:20] <rogpeppe> frankban: i don't think that calling the method is "simulating behaviour" to any meaningful degree. if gocheck doesn't call the methods, we're stuffed, so unit testing by calling the methods seems fine to me.
[10:21] <frankban> rogpeppe: ok I am convinced, this way I can also separate the two tests there
[10:45] <rick_h_> morning all
[10:49] <frankban> rogpeppe: re-proposed with the changes
[10:49] <frankban> rick_h_: morning
[10:50] <rogpeppe> frankban: looking
[10:50] <rogpeppe> rick_h_: hiya
[10:50] <frankban> thanks
[10:52] <rogpeppe> frankban: do you know if it's possible to see just the new changes, with the comments shown too?
[10:53] <rogpeppe> frankban: (like codereview allows)
[10:53] <frankban> rogpeppe: I don't think it's possible, there is no history when rebasing. I agree reitveld is much better
[10:54] <rick_h_> the comments are still there and you can click on them to see the old code that was commented on
[10:54] <rogpeppe> frankban: i mean, it doesn't matter much here, but in more complex changes, it's really useful to be able to see the comments and the changes that were made in response.
[10:54] <rick_h_> but you don't get just the diff in the new changes
[10:54] <rick_h_> it's an argument for saving rebase until landing I suppose. 
[10:54] <rogpeppe> rick_h_: so it's not actually possible to see what changes have been made since a comment (without downloading the patch directly, i guess)
[10:54] <rogpeppe> ?
[10:55] <rick_h_> rogpeppe: yea, so if we didn't rebase down until after you got the :+1: then you could view commit by commit
[10:55] <rogpeppe> FWIW, that was something that i would do on almost every review
[10:55] <frankban> rogpeppe: that's unfortunate in github
[10:55] <rick_h_> it's something we can talk about. 
[10:56] <rick_h_> rogpeppe: yea, I've been trying to find time to investigate running reviewboard in our CI environment to help but time hasn't been overflowing lately. 
[10:56] <frankban> rick_h_: that's an idea, assuming the final rebasing does not require reviewers eyes
[10:56] <rick_h_> frankban: yea, in theory it shouldn't
[10:56] <rogpeppe> rick_h_: could you view that on github itself? or would you need to pull down the (unrebased) patch?
[10:56] <rick_h_> rogpeppe: reitveld left a lot of sour tastes in people's mouth though much of that blame lies more in LP->reitveld
[10:57] <rick_h_> rogpeppe: so a partial step would be a policy not to rebase your branch down until just before you submit it for merging
[10:57] <rogpeppe> rick_h_: yeah, the lp->rietveld bridge was a bit awkward
[10:57] <rick_h_> rogpeppe: that would be in GH itself and would get you much closer to what you want
[10:57] <rick_h_> frankban: I'll add a friday card and you guys can discuss?
[10:58] <frankban> rick_h_: sure, +1 thanks
[10:58] <rogpeppe> rick_h_: i'd find that useful, i think - for complex changes it can be very hard to see what changes have been made in response to a comment, and whether the correspond with what's wanted
[10:58] <rogpeppe> s/the correspond/they correspond/
[10:59] <rick_h_> rogpeppe: understood, it's something we fight with LoC limits and multiple reviews required to land on larger branches
[10:59] <rick_h_> rogpeppe: so we don't always feel that pain ime
[10:59] <rogpeppe> rick_h_: what are the LoC limits, BTW?
[11:00] <rick_h_> in the GUI 400 LoC and less you need one review and one QA
[11:00] <rick_h_> over 400 LoC you need two reviews and one QA minimum...possibly 2
[11:00] <rick_h_> over 800 ish LoC you need to break it down or bribe reviewers and beg for forgiveness
[11:01] <rick_h_> rogpeppe: that is more diff LoC than actual LoC 
[11:01] <rick_h_> LoD (lines of diff)
[11:01] <rogpeppe> rick_h_: that's including context, right?
[11:02] <rick_h_> rogpeppe: yea
[11:02] <rogpeppe> rick_h_: so a one line change would be ~10 LoD
[11:02] <rick_h_> it's usually closer to 5ish but yea
[11:03] <rick_h_> hmm, GH doesn't report the real diff size does it. Looking at https://github.com/juju/juju-gui/pull/348 it just has the +69/-14
[11:03] <rogpeppe> rick_h_: i get 9 lines, not including the file header
[11:03] <rick_h_> oh yea, hover it I see
[11:03] <rick_h_> so https://github.com/juju/juju-gui/pull/348 is an 83 LoC diff technically
[11:04] <rick_h_> rogpeppe: ok, sounds good then. Not normally checking the size of a one line change. It's under any limits :) Then you just need to figure out if self-review is possible. 
[11:04] <rogpeppe> rick_h_: the 83 lines looks like 69+14, not the diff output line count
[11:04] <rogpeppe> rick_h_: i suspect git diff | wc will be considerably larger
[11:04] <rick_h_> rogpeppe: ah right bah
[11:05] <rick_h_> rogpeppe: I guess it's just habit these day. We're used to breaking down small enough. You're right that we don't currently have a good number in GH like we did in LP
[11:06]  * rick_h_ makes a mental note to figure out how to port the old rules to GH 
[11:06] <rogpeppe> rick_h_: tbh, i prefer lines without context - it doesn't penalise changes which change quite a few individual lines in a simple way
[11:07] <frankban> FWIW my branch in review has +204  −67 and "git diff master | wc -l" returns 425
[11:09] <frankban> rogpeppe: the magic calldepth value was pre-existing, I don't have that answer, if you do I'd be happy to add a comment there
[11:10]  * rogpeppe hates the "publish immediately" thing
[11:10] <frankban> rogpeppe: heh, ok I'll add a todo
[11:11] <frankban> rogpeppe: also, when a review is completed, we usually add a final comment (not inline) so that the author knows when to start looking for comments
[11:11] <rick_h_> frankban: yea, we used to have different limits based on language back in launchpad. JS could have more than python in that case. 
[11:12] <rick_h_> +1 for the overall comment after all the in-lines are done
[11:12] <rogpeppe> frankban: where do you add that final comment?
[11:13] <frankban> rick_h_: yes, also go diffs can be longer than python ones (gofmt stuff etc)
[11:13] <rogpeppe> frankban: oh, i see, on a different pae
[11:13] <rogpeppe> page
[11:13] <frankban> rogpeppe: yeah, in the conversation tab
[11:13] <rogpeppe> i think there should be an exception for low complexity diffs, particularly mechanically generated changes
[11:13] <rick_h_> definitely
[11:14] <rogpeppe> for instance, in Go, you may well change an import path which might affect 1000s of lines, but it can still be a trivial change
[11:14] <rogpeppe> it's got to be a judgement call in the end, i think
[11:14] <frankban> yeah
[11:16] <frankban> rogpeppe: how do you merge stuff in github? just use the big green button?
[11:16] <rogpeppe> frankban: i've no idea :-)
[11:16] <rogpeppe> frankban: i am an utter git newbie
[11:16] <frankban> :-) I'll ask on #juju-dev
[11:17] <rick_h_> yea, just hit the green button
[11:17] <rick_h_> until we get the libraries in CI and using the :shipit: lander
[11:22] <frankban> rick_h_: cool, merged
[11:31] <frankban> rogpeppe: ok, golxc uses logging.LoggingSuite, I'll update that and then juju-core
[11:33]  * rick_h_ heads to take the boy to day care
[11:33] <rick_h_> rogpeppe: if you get a sec can you add a card to the board please for your current work?
[11:34] <rogpeppe> rick_h_: ah yes, will do
[11:51] <frankban> rogpeppe: could you please take a quick look at https://code.launchpad.net/~frankban/golxc/fix-logging-suite/+merge/221210 ?
[11:51] <rogpeppe> frankban: not on codereview?
[11:52] <frankban> rogpeppe: no lbox files in golxc
[11:52] <rogpeppe> frankban: you can still use lbox
[11:53] <frankban> rogpeppe: you are right, let me create that
[11:53] <rogpeppe> lbox propose -for lp:golxc/trunk
[11:54] <frankban> rogpeppe: https://codereview.appspot.com/92660046
[11:55] <rogpeppe> frankban: i'm not sure about hardcoding /usr/bin there
[11:56] <rogpeppe> frankban: who's to say whether that's the location that the user is using for their lxc binaries?
[11:57] <rogpeppe> frankban: i think that probably commandArgs.SetUpSuite should save the value of $PATH, then TestCreateArgs etc can restore it
[11:58] <frankban> the errors are like this: http://pastebin.ubuntu.com/7536121/
[12:01] <frankban> rogpeppe: +1 on saving the PATH
[12:07] <frankban> rogpeppe: updated
[12:16] <hazmat> frankban, afaics bug 1324097 is still an issue (just filed that)
[12:16] <_mup_> Bug #1324097: charm get api doesn't work with store charms <juju-core:New> <https://launchpad.net/bugs/1324097>
[12:17] <rick_h_> hazmat: cool will add that to our maintenance backlog to look at
[12:17] <rick_h_> hazmat: or is that related to the recent refactor work?
[12:18] <hazmat> rick_h_, its been a bug in that implementation since it was done
[12:18] <rick_h_> hazmat: ok cool, added to our on deck maint. 
[12:26] <frankban> hazmat: we are now working on breaking the store into a separate project. rick_h_: is the goal to have the store itself expose an API for getting charm files?
[12:27] <rick_h_> frankban: yes, it'll be part of the api v4
[12:27] <hazmat> frankban, not related
[12:28] <rick_h_> frankban: speaking of going to share a doc with you to keep an eye on
[12:28] <hazmat> frankban, unless your going to remove the broken api method
[12:28] <rick_h_> frankban: but as hazmat says, this is more a store bug issue and with us working on the store it's something we should keep an eye on and be willing to update as we bring up ownership. 
[12:29] <rick_h_> frankban: and things like this will be great for bringing up new go/store devs
[12:29] <frankban> hazmat: that's what I was asking, we'll take a look at that, thanks
[12:29] <frankban> rick_h_: +1
[12:34] <hazmat> its not really a store api atm, the bug is against the state server api.. 
[12:34] <hazmat> rick_h_, apiv4 of charmworld? what's the delta on that? i was looking at implementing v3 api against the env to be able to support demos
[12:34] <rick_h_> hazmat: TBD
[12:35] <hazmat> ic
[12:35] <rick_h_> hazmat: once we pull the store out we'll be working on defining api v4 to fix issues with v3, add current store functions required, and adding new ones for bundles/etc so that they're loaded like charms
[12:48] <hazmat> rick_h_, what version of osx were you on?
[12:48] <hazmat> re bug 1323803
[12:48] <_mup_> Bug #1323803: ssl handshake fails on osx  <juju-deployer:New> <python-jujuclient:New> <https://launchpad.net/bugs/1323803>
[12:49] <rick_h_> hazmat: hmm, latest? /me checks
[12:49] <rick_h_> 10.9.3
[12:49] <rick_h_> hazmat: and the openssl version matched the linked url discussion
[12:52] <hazmat> rick_h_, so this is an osx and python issue.
[12:52] <rick_h_> hazmat: yes
[12:52] <rick_h_> hazmat: and webcocket library issue perhaps
[12:53] <rick_h_> hazmat: I chased it down enough to get close but filed a bug from there. Was trying to help that stein guy get notes on doing his demo stuff from osx and it's more work than I've got time for before I leave tomorrow
[12:53] <hazmat> rick_h_, no.. its deeper than that
[12:53] <rick_h_> hazmat: I've added it to our board to look into as we'll hit this with our current work to make juju-quickstart work on osx
[12:53] <rick_h_> hazmat: right, but it sounds like there might be config/ways to enforce ssl3 at handshake?
[12:53] <rick_h_> and skip ssl2
[12:53] <hazmat> rick_h_, its an libssl issue.. the best fix we can do without modifying python or osx version of ssl
[12:54] <hazmat> is to change the server to only do ssl3 or tlsv1
[12:55] <rick_h_> hazmat: cool, yea I'm not sure if there's a decent work around for the client or it requires server changes. I figure we can't be the first to hit this stuff (and a google search proves we're not)
[12:55] <hazmat> rick_h_, there is no workaround for the client
[12:55] <hazmat> without changing python versions, patching py2.7, bundling a new libssl
[13:13]  * hazmat upgrades his osx machine to 10.9
[13:29] <kadams54> guihelp: I haven't seen this kind of failure in a CI build before and I'm not really sure what went wrong: http://ci.jujugui.org:8080/job/juju-gui/1108/console
[13:29] <rick_h_> kadams54: looking
[13:30] <rick_h_> kadams54: so your failure was in IE https://saucelabs.com/jobs/fc4e2430d0da47ae8d17960df1bd795d to go look at the sauce data
[13:30] <rick_h_> kadams54: and the failure was in the notifier widget, which has a giant "FIX ME" because it causes spurious failures so this means just retry. 
[13:30] <kadams54> Damn you notifier!
[13:30] <rick_h_> :)
[13:30] <rick_h_> kadams54: so get that link you have to find the top of that suite run where the link is output
[13:31] <kadams54> Yeah, this is one of the tests that consistently fails inconcistently in local dev
[13:31] <kadams54> Ah yes, I see the URL now. Thanks.
[13:31] <kadams54> How do I trigger a retry? Delete the "Test FAILed" comment?
[13:32] <rick_h_> yep, notifier is the one place we still have some timeout based stuff that doesn't clean up well and hits race conditions. To fix it means to really refactor the code heavily so it's a maint. card of work to do
[13:32] <rick_h_> kadams54: no, you have to actually login to jenkins and "build with parameters" and put the sha in 
[13:32]  * rick_h_ checks of kadams54 has a jenkins account
[13:32] <rick_h_> heh, guess not
[13:40] <rick_h_> kadams54: can you please help look at the review backlog and grab one or two please?
[13:41] <kadams54> rick_h_: I would if this wasn't my swap day :-)
[13:41] <rick_h_> kadams54: oh right, wtf get out of here
[13:41] <kadams54> I'm just here to try and get my branch landed…
[13:41]  * rick_h_ boots kadams
[13:41] <kadams54> LOL
[13:41] <kadams54> Will do.
[13:41] <rick_h_> yea, don't worry about it. run away. I'll make sure it gets landed today
[13:44] <rick_h_> jcsackett: class based views
[13:45]  * jcsackett blinks
[13:45] <jcsackett> did i miss some chatter?
[13:45] <rick_h_> :P
[13:45] <rick_h_> jcsackett: no, but it just popped in my head
[13:56] <rick_h_> Makyo: hatch halt the line, we need to clear out reviews please before working on anything else. 
[13:57] <rick_h_> Makyo: hatch kadams is out today so really need your help to clear the backlog. I'll help out after my call at the top of the hour
[14:02] <hatch> rick_h_ sure
[14:16] <frankban> rogpeppe: any idea about why the new suite produces tons of errors? https://code.launchpad.net/~gz/juju-core/logging_dep_fixes/+merge/221228
[14:18] <rogpeppe> frankban: almost certainly because it's calling an external command that relies on some environment variables
[14:18] <rogpeppe> frankban: for example, $HOME will not be set
[14:18] <frankban> rogpeppe: we are using LoggingCleanupSuite, not IsolationSuite
[14:18] <rogpeppe> frankban: ah. hmm.
[14:18] <rogpeppe> frankban: can you reproduce the errors yourself?
[14:19] <frankban> rogpeppe: yes
[14:20] <rogpeppe> frankban: hmm, seems a little odd to me - i'd try rolling back selectively to see where the problem started
[14:21] <frankban> rogpeppe: oh maybe I've found something
[14:22]  * rick_h_ changes location back to the house. back in a sec
[14:22] <rick_h_> ccccccdilrkrtfngcdcubbvfldjujftufgbrdufvirfj
[14:22] <rick_h_> ccccccdilrkrgknbcenkijtgtjflrffcrdlivielkfrr
[14:23] <rick_h_> bah, yubikey by the headphone jack fail
[14:23]  * rogpeppe authenticates as rick_h
[14:36] <rick_h_> bah, was my password so obvious?
[14:41] <hatch> lol
[14:59] <rick_h_> jujugui call in 2
[15:01] <rick_h_> bac: around today?
[15:15] <bac> y'all sounded amazing on my new noise cancelling earbuds!  so lifelike, except for the lack of ambient noise.
[15:15] <hatch> next time I'll whisper at you so it's like i'm IN your head
[15:15] <rick_h_> bac: <3 those. I got those before my last trip and use them a ton now
[15:16] <bac> hatch: hah.
[15:16] <bac> rick_h_: got them mainly for flights.  they have to do all instructions in english and spanish and it goes on forever.
[15:17] <rick_h_> bac: yep, why I got them
[15:17] <hatch> luca how did you make that Las Vegas story on G+?
[15:18] <luca> hatch: it’s made automatically from the pictures I took on my phone.
[15:18] <hatch> so you just upload them into the same album and it 'just works' ?
[15:19] <hatch> because that's really cool!
[15:19] <luca> hatch: I’m not sure, I take the pic, it uploads on wifi, I then usually add it to a public album (this one: https://plus.google.com/u/0/photos/113969209489447903536/albums/6006958803479294513) and then it makes it
[15:19] <luca> hatch: I think it’s triggered off of a series of photos
[15:19] <hatch> cool, must be a new type of auto-awesome
[15:20] <luca> hatch: so if you take a lot of a certain period of time it knows your somewhere special
[15:20] <luca> yeah
[15:20] <hatch> maybe it also requires the GPS to be on 
[15:20] <hatch> so the photos are geo tagged
[15:20] <luca> it did one for my holiday in Italy too which is better https://plus.google.com/113969209489447903536/posts/Vr6GLXYdkT6
[15:20] <luca> yeah, I think it needs GPS
[15:20] <luca> My italy holiday story is all based around location
[15:22] <hatch> cool - so were you biking in that race?
[15:22] <luca> hatch: No, thats the Giro, the second biggest professional race.
[15:23] <luca> hatch: I followed it for 5 days
[15:23] <luca> it’s like the tour de france
[15:23] <hatch> ohhh cool, I didn't know people did that :)
[15:23] <hatch> you're like a bike groupie :P
[15:23] <luca> just the Italian version of it which has more climbs and worse weather
[15:23] <luca> haha yeah
[15:24] <hatch> Looks like it was a great time
[15:24] <hatch> and this story is really awesome :)
[15:24] <luca> it was great, a lot of fun, a lot of riding and driving
[15:24] <luca> I was really tired after it hehe
[15:24] <luca> the story came out really good
[15:25] <hatch> So how does one follow a bike race? You fly there then bike behind them? 
[15:25] <luca> it’s difficult
[15:25] <luca> and complex
[15:25] <luca> I took my bike over
[15:25] <luca> and a rucksake of cycling clothes and a few casual stuff
[15:26] <luca> you can’t cycle the routes because they move too fast
[15:26] <luca> and the roads get cloased off about an hour before they come through
[15:26] <luca> usually you get up early in the morning, find a good spot of the course to watch them and spend the time waiting by cycling a part of the course
[15:27] <luca> every night is a different hotel
[15:27] <hatch> then after they pass drive ahead?
[15:27] <rick_h_> hatch: luca yea it goes back through all your photos and builds a story using time/location info
[15:27] <luca> yeah, you shoot round to a different part of the course
[15:27] <luca> every morning you check out of a hotel
[15:28] <luca> so in 5 days we covered 1000’s of km’s, rode about 250km, slept in 4 different hotels and got up every morning at 6:30
[15:28] <hatch> heh sounds like an awesome trip :)
[15:28] <hatch> and makes for a great story :)
[15:28] <luca> hehe
[15:28] <luca> thanks
[15:40] <Makyo> jujugui quick review/qa https://github.com/juju/juju-gui/pull/347
[15:40] <hatch> I can do it
[15:40] <hatch> #3 for today :P
[15:40] <hatch> I feel a little like a gatekeeper
[15:40] <rick_h_> today is review day in the UIEng house
[15:41] <hatch> Makyo I THINK your CI failures are the spurious ones
[15:41] <Makyo> Oh, it hadn't loaded the comment.  Let me check.
[15:41] <Makyo> I still had the "This can be automatically  merged"
[15:42] <Makyo> I'll rerun.
[15:48] <rogpeppe> frankban: what commands have you been using to propose a change to github.com/juju/testing ?
[15:48] <rogpeppe> frankban: are you using the command line or the web UI?
[15:48] <frankban> rogpeppe: web UI
[15:48] <rogpeppe> frankban: ok :-\
[15:52] <rogpeppe> anyone know how to create a pull request from the command line?
[15:53] <hatch> onnne moreeeee
[15:53] <rogpeppe> frankban: also, what command do you use to do the rebase? i always try to read the help for rebase and get totally flummoxed by the maze of flags and possibilities
[15:54] <hatch> code reviews all caught up and shipping the ones that can be shipped
[15:55] <frankban> rogpeppe: rick_h_ can help you more with rebasing, I hate that. I created a script which helps me collapsing changes into a single commit without rebasing, but I am sure it can be considered exotic.
[15:56] <frankban> rogpeppe: anyway, here it is, I called that git-prepare (so that you can run it with "git prepare"): http://pastebin.ubuntu.com/7537428/
[15:57] <rogpeppe> frankban: thanks
[15:57] <rogpeppe> frankban: wow
[15:58] <frankban> rogpeppe: oh, it uses git sync: http://pastebin.ubuntu.com/7537446/
[15:59] <frankban> rogpeppe: it assumes origin is your own remote (e.g. github.com/rogpeppe/testing) and juju is the central remote (github.com/juju/testing)
[15:59] <rogpeppe> frankban: BTW your first sed command could be a little simpler: sed -n 's/^\* //p'
[16:00] <rogpeppe> frankban: ah, i've only got one remote - i've been pushing to github.com/juju
[16:00] <rogpeppe> frankban: is that considered bad form?
[16:00] <frankban> rogpeppe: yeah, it is really just a quick hack to make me at least understand the process, because I really don't get rebasing
[16:00] <frankban> I have to spend some time learning it I guess
[16:02] <frankban> rogpeppe: it seems a more usual workflow is 1) fork the project on github 2) work on a branch of your fork and 3) propose your branch for merging into the original one (usually develop, but in the juju case I saw master is used)
[16:03] <frankban> rogpeppe: to do that, I basically removed github/juju/testing in my $GOPATH, cloned from my remote, then added the juju remote
[16:03] <rogpeppe> frankban: i *think* you should just be able to do git remote add
[16:03] <frankban> rogpeppe: and you can use my "git sync" to sync the two remotes if you like it
[16:03] <rick_h_> sorry was afk
[16:04] <rogpeppe> rick_h_: just being my usual git-confused self :-)
[16:04] <frankban> rogpeppe: yeah, but I wanted origin to be my fork, not juju, and I haven't looked at how to rename remotes
[16:04] <rick_h_> rogpeppe: heh, it takes some learning for sure
[16:04] <hatch> git makes a lot of sense once you understand wtf is going on under the hood :D
[16:05] <rick_h_> rogpeppe: we've got a workflow in the gui hacking doc to help. It has some helpful aliases, process, etc
[16:05] <rick_h_> https://github.com/juju/juju-gui/blob/develop/HACKING.rst#typical-github-workflow
[16:05] <hatch> of which, I use none because I'm a masochist 
[16:05] <frankban> hatch: other versioning systems make a lot of sense even before understanding C
[16:05] <rick_h_> rogpeppe: it tries to work through setting up the two remotes, sync'ing between them, and keeping your branch up to date
[16:06] <hatch> frankban haha, well git is special :P
[16:06] <hatch> Makyo not sure if you noticed - I assigned a card for you under Project 1
[16:06] <rogpeppe> i just wc'd the combined output of all the git help commands. 21480 lines.
[16:06] <hatch> today is the day I break non-il flag
[16:07] <rogpeppe> that's quite something for something that's just a glorified fs
[16:07] <hatch> rogpeppe lol!!
[16:07] <hatch> rogpeppe actually it's a glorified db
[16:07] <hatch> :)
[16:07] <frankban> rogpeppe: this can help: http://git-man-page-generator.lokaltog.net/
[16:07] <hatch> ^ hahaha 
[16:07] <rick_h_> :P
[16:08] <rogpeppe> frankban: ha ha. is that markov chained from the git man pages?
[16:08] <rick_h_> jcastro: sent a nice github link out
[16:09] <hatch> rogpeppe https://www.youtube.com/watch?v=ZDR433b0HJY This video is a great intro to git and actually uses git without any of the git commands to show you how it works
[16:10] <rogpeppe> hatch: i think part of the problem is that everyone these days seems to learn by example, whereas i think i learn best by understanding the primitives
[16:10] <frankban> rogpeppe: sadly that's absolutely realistic, the real git help is stackoverflow IMHO
[16:11] <hatch> rogpeppe then that video is your Yellow Sun
[16:11] <hatch> holy crap I'm a nerd
[16:11] <rogpeppe> hatch: i do actually understand how the *underlying* primitives work (well, mostly) - but the primitives we have to work with are the actual git commands
[16:12] <rogpeppe> hatch: http://en.wikipedia.org/wiki/Yellow_Sun ?
[16:12] <hatch> rogpeppe http://en.wikipedia.org/wiki/Superman
[16:12] <hatch> :D
[16:13] <hatch> superman gets his powers from the yellow sun
[16:13] <rogpeppe> hatch: ah, ok. i'm not big on comic book fiction
[16:14]  * rogpeppe watches the video
[16:14] <hatch> lemme know what you think
[16:14] <hatch> :)
[16:14] <Makyo> hatch, okay, thanks.
[16:18] <hatch> luca Paolo sounds like someone who uses Reddit :P
[16:18] <luca> hatch: rofl
[16:18] <hatch> haha
[16:25] <hatch> looks good luca 
[16:25] <rogpeppe> hatch: does the video cover rebasing, BTW?
[16:25] <luca> hatch: thanks :)
[16:26] <hatch> rogpeppe it has been a long time since I've seen it so I can't remember. 
[16:26] <rogpeppe> hatch: ok
[16:26] <hatch> was there a certain question you had about rebasing though that I might be able to answer?
[16:30]  * rick_h_ goes for food
[16:35] <hatch> Makyo just FYI you'll need the il flag for your branch
[16:35] <hatch> it doesn't happen with the inspector on the right
[16:35] <Makyo> Alright
[16:36] <rogpeppe> hatch: specifically, if i want to rebase my commits before upstream merging, what would be the usual options and arguments that i'd need?
[16:38] <hatch> ok assuming you haven't merged anything into this branch since you branched it from develop(or master or whatever your source is) you will run `git rebase -i HEAD~3` where 3 is the number of commits you want to rebase
[16:39] <hatch> say some new code landed in the source branch that you wanted in yours, ----do not merge that branch in---- run `git rebase develop` where develop is the source branch, this will re play your commits on top of the newly updated branch
[16:40] <rogpeppe> hatch: what if i *did* merge that branch in? or is that a "you're fucked now, boyo" kind of thing?
[16:41] <hatch> well....not totally....but it's considerably more work :) 
[16:41] <hatch> think of git commits always wanting to lay layers on top, if you smush some in the middle it's going to break your sandwich 
[16:41] <hatch> (at least the way we do it)
[16:42] <rogpeppe> hatch: ok, so in general i should *never* merge trunk when developing a branch?
[16:42] <rogpeppe> hatch: (unlike standard bzr usage, for example)
[16:43] <hatch> correct - if you really need code thats landed use `git rebase trunk` and, assuming this branch was branched from trunk, it will update your branch to the latest code in trunk and re apply your commits on top
[16:43] <hatch> btw not everyone agrees with using rebase - the git world is really of two camps, the rebasers, and the not :)
[16:43] <rogpeppe> hatch: IME, you almost always want code that's landed, because you need to check that your changes work in the context of all the changes that have landed since you started work on the branch
[16:44] <rogpeppe> hatch: i think given the lack of nested commits, rebase is the only reasonable way
[16:44] <hatch> yep, so running `git rebase trunk` will get you that
[16:44] <hatch> assuming your branch was branched from trunk
[16:44] <hatch> git rebase <source branch>
[16:44] <rogpeppe> hatch: so the source branch argument must be a direct ancestor of the current head?
[16:45] <rogpeppe> hatch: ah, no, i see
[16:45] <hatch> no, but to keep a clean commit history it should be
[16:46] <hatch> cool
[16:46] <rogpeppe> hatch: where's the HEAD~3 syntax documented?
[16:46] <hatch> hmm, not sure, lemme look
[16:47] <rogpeppe> hatch: and why do you want to make it interactive (the -i arg) ?
[16:47] <hatch> say you had 5 commits, and you wanted to keep 2 outside ones but smush the other 3, this will let you pick and choose ( you can even re order the commits )
[16:48] <rogpeppe> and otherwise it smushes them all down to one, right?
[16:49] <rogpeppe> hatch: one other thing: does rebase actually commit anything, or do you have to rebase, then commit?
[16:50] <hatch> I think you need to use --autosquash to have them automatically smushed
[16:51] <hatch> rogpeppe it rewrites history so it will be committed but not pushed - if you have pushed those old commits to a remote repo you'll now have to do `git push -f` as the histories won't line up
[16:51] <rogpeppe> hatch: ah, so when people say "rebase before proposing", that's what they're implying?
[16:52] <hatch> rogpeppe well some people code with checkpoint commits and you should only commit logical commits into the main repo - so they want you to get rid of the checkpoint commits and turn them into 'topic commits'
[16:52] <rogpeppe> hatch: (--autosquash, that is)
[16:52] <hatch> and when I say rebase rewrites history...it only rewrites the high level history so if you screw up you CAN get stuff back http://stackoverflow.com/questions/134882/undoing-a-git-rebase
[16:53] <hatch> that's why you never want to commit passwords/keys etc into GIT because it's VERY hard to truly delete something
[16:54] <rogpeppe> hatch: ah, i didn't know about the reflog
[16:57] <hatch> if you think of git as an api on top of a database you realize that you can do pretty much anything once you figure out how the commands work :)
[16:58] <hatch> rogpeppe sorry I can't find where the HEAD~3 syntax is documented. But it means from HEAD move two commits back 
[16:58] <hatch> HEAD~1 points to head
[16:59] <hatch> weird I know...
[16:59] <rick_h_> it's like array negative syntax
[16:59] <rick_h_> [-1]
[16:59] <rick_h_> is the last char
[16:59] <rick_h_> [:-3] is the last three chars or commits in this case
[16:59] <rick_h_> inclusive of HEAD
[17:00] <rogpeppe> hatch: so if i want to do the equivalent of "bzr push", squashing all the commits i've made into one commit message, i look in the log to find out how many commits i've made, count them (call it $n), do "git rebase HEAD~$n", then do "git rebase origin" ?
[17:01] <rogpeppe> hatch: hmm, but i don't see a place to specify the commit message there
[17:01] <hatch> close but not quite
[17:01] <hatch> :)
[17:01] <rogpeppe> hatch: and "git rebase HEAD~$n" isn't going to do anything, is it?
[17:01] <rogpeppe> hatch: hence the -i flag
[17:02] <hatch> `git checkout <souurce branch>` `git pull <remote> <source branch>`
[17:02] <rogpeppe> hatch: but i hate interactive commands (i almost never use them) so i'd like to know how to do this non-interactively
[17:02] <hatch> `git checkout <branch>`
[17:02] <hatch> `git rebase --autosquash <source branch>`
[17:02] <hatch> I think it'll take the last commit message
[17:03] <rogpeppe> hatch: the help for --autosquash says that "This option is only valid when the --interactive option is used."
[17:03] <hatch> oh wait
[17:03] <hatch> yeah autosquash looks for a special commit message
[17:03] <hatch> sorry I use interactive :) one sec lemme look into this
[17:04] <hatch> kadams54 hey I had one quick comment on your branch then it's gtg mind checking that out :)
[17:06] <kadams54> hatch: Yeah, I actually hopped on to ask you about that. I posted a reply in the PR.
[17:06] <hatch> cool looking
[17:07] <hatch> doh I missed that
[17:07] <hatch> ok you can shippit
[17:07] <hatch> thanks
[17:07] <kadams54> Great
[17:07] <hatch> rogpeppe doesn't look like it's possible without some extra scripting :/ sorry
[17:08] <rogpeppe> hatch: ok.
[17:09] <hatch> rogpeppe I've found that I typically don't want to merge them all into a single commit, but instead to a few 'topic commits' so I've become accustomed to using -i
[17:10] <rogpeppe> hatch: ok, interesting
[17:10] <rogpeppe> hatch: can you group all the changes in a particular directory into one commit, for example?
[17:11] <hatch> rogpeppe there IS a way to commit only blocks of code but I can't remember how to do that. 
[17:11] <hatch> git has a VERY awesome feature called bisect
[17:11] <rogpeppe> hatch: ok. so in general you'll be squashing contiguous sequences of commits
[17:12] <rogpeppe> hatch: bzr has that too
[17:12] <hatch> oh? oh cool
[17:12] <rogpeppe> hatch: (well, it may be quite different i guess)
[17:12] <hatch> git bisect allows you to bounce between commits automatically to test where something broke
[17:12] <rogpeppe> hatch: for finding the commit that introduced a particular thing
[17:12] <hatch> so you want commits which help speed this process up
[17:12] <hatch> if you end up with one 2000 line commit, that's not going to be very helpful
[17:13] <hatch> or if you end up having to bisect through 100 broken wip commits
[17:13] <rogpeppe> hatch: the other side of the coin is that it's useful having a commit that corresponds to a given code review
[17:13] <hatch> for that we have PR's and a merge commit
[17:13] <hatch> see https://github.com/juju/juju-gui/commits/develop
[17:14] <rogpeppe> hatch: i found it incredibly great to be able to look at a given commit in the log and jump to the review to see what was going on in people's minds when they made that commit
[17:14] <hatch> yep you can do that with the merge commits
[17:15] <rogpeppe> hatch: so the log we're seeing on that page isn't the set of commits we'll see in the git log?
[17:16] <hatch> rogpeppe that's identical to what's in the git log, but github 'enhances' it to provide links directly to the pr's in question 
[17:17] <rogpeppe> hatch: so, some of the entries there are of the form "Merge pull request #xxx from..." and some are like "This thing happened". Why the difference, and how can I make my commits look like the latter rather than the former?
[17:18] <hatch> here is the git log and the github output https://www.evernote.com/shard/s219/sh/3878c3c3-b935-41ac-8a88-50f6d5f6a9fc/fe800bfa9baa93a8a89fa6f8886a3c65
[17:18] <hatch> although I just noticed it's using the wrong email for my git commits :/
[17:19] <hatch> anywho - when our CI merges the commits it intentionally creates these merge commits so that you can see what commits line up to the PR's
[17:22] <rogpeppe> hatch: i don't understand. the merge commits are created by jujugui (which presumably is the CI bot, right?), but how do they match up with the other commits, which seem arbitrarily sequenced in between those commits?
[17:22] <hatch> they are ordered by time
[17:23] <hatch> that's why they don't match
[17:23] <rogpeppe> hatch: oh, that's a bit weird.
[17:24] <hatch> yeah - it makes sense the first time you have to bisect something though :D
[17:24] <hatch> easy to find the commit which caused the problem and then the PR associated with it
[17:24] <rogpeppe> hatch: so the history there doesn't actually correspond to the commit log history, but to when people actually made those changes?
[17:25] <hatch> well no this is identical to the git log history 
[17:25] <rogpeppe> hatch: and that's ordered by time?
[17:25] <hatch> yeah, but remember that people can rebase things, that's why the timestamps are out of wak
[17:28] <hatch> also - if you rebase incorrectly you can screw up the order too :)
[17:28] <rogpeppe> hatch: but... this feels really odd to me. so you're saying that the log is essentially arbitrarily order?
[17:28] <rogpeppe> ordered
[17:28] <hatch> there is no 'order' to a git log, it's essentially a flattened tree
[17:28] <hatch> it's not like bzr with revno's
[17:28] <rogpeppe> hatch: flattened by time-of-commit, right?
[17:29] <hatch> it's a little more complicated than that....like flattened by tree position
[17:29] <Makyo> Here's a helpful alias for logs, if it helps: lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
[17:30] <hatch> rogpeppe to run that copy and paste this : git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
[17:30] <hatch> Makyo good call, that does make it easier to reason about
[17:31] <rogpeppe> Makyo: ah, that --graph is useful, thanks
[17:32] <rogpeppe> ha, less(1) doesn't seem to display colours
[17:32] <hatch> rogpeppe you may also find this interesting http://nvie.com/posts/a-successful-git-branching-model/
[17:33] <rogpeppe> hatch: so if it's flattened by tree position, then i still don't see how successive commits to the tree can get spread out
[17:34] <hatch> yeah I don't truly understand it either
[17:35] <rogpeppe> hatch: hmm, yeah, it's definitely not strictly time-ordered
[17:35] <hatch> no, if you rebase commits they can get assigned old dates for new commits
[17:35] <hatch> it's kind of funky
[17:35] <hatch> it's like, it's position in the graph 
[17:36] <rogpeppe> hatch: i was just looking at the dates of the commits in the log
[17:36] <hatch> I'm sure if you followed the merge step by step through the graph it would make sense
[17:38] <hatch> yeah - if you rebase new commits into old commits, they get assigned the old timestamp not the new one
[17:39] <hatch> which puts the timestamp and graph position 'out of sync' I suppose
[17:39] <rogpeppe> i have to say it's not entirely clear which commit corresponds to which pull request (for example, I *presume* that 002d86d094977ff33880a126a46b9876a11534ea corresponds to 90a1f669d8885c5fd0f6c7d9c0c591a749ab6c0a but it's just a guess
[17:39] <rogpeppe> )
[17:39] <Makyo> Huh, didn't notice it until I went back inside to work on a brighter monitor, but the spinner stays overlaid on the inspector in the instance where the sticky headers used to overlay.  I'll see if I can driveby it.
[17:40] <hatch> Makyo really? Darn that didn't happen to me, should be a quick fix :) definitely drivebyable
[17:40] <Makyo> hatch, yep, I'll take a look.  I've got the slow connection.
[17:40] <rogpeppe> perhaps the algorithm is "for a given entry in the log, go forward in the log until you find a jujugui commit with the same author"
[17:40] <hatch> rogpeppe that does seem like a reasonable technique :)
[17:41] <rogpeppe> hatch: but is it actually fail-safe?
[17:41] <hatch> Makyo heh :) who knew there was an advantage to slow internet
[17:41] <hatch> rogpeppe hopefully you don't need to bisect that often
[17:41] <hatch> :)
[17:41] <Makyo> hatch, yeah :)  Can only see it on the nice screen, it's so close to the background color.
[17:41] <rogpeppe> hatch: it's not necessarily about bisecting, just finding relevant discussion on changes
[17:42] <hatch> ohh - yeah we typically don't have that many commits between merges so it's pretty easy to find
[17:42] <hatch> YMMV I suppose
[17:43] <rogpeppe> hatch: BTW, is there an equivalent of "bzr qannotate" (i.e. git blame but with a nice place to view the commits corresponding to different lines of code)?
[17:43] <hatch> rogpeppe there IS but I don't know how to get to it, you'll have to hit the googles
[17:54]  * rogpeppe is done for the day, having failed to propose his PR. oh well.
[18:02] <Makyo> hatch, Going through the DOM, there are two whole inspectors and the charm browser all rendered in the left hand side, and it's just the z-index on the expose button making it show through.
[18:02] <rick_h_> the new state stuff isn't cleaning up old views on state change
[18:02] <rick_h_> ?
[18:03] <hatch> Makyo ok thats...od
[18:03] <hatch> d
[18:03] <hatch> yeah sounds like the inspector isn't being destroyed properly
[18:03] <Makyo> rick_h_, perhaps.  Still digging to find out what's happening.  z-index seems to be the problem with the spinner overlay, too.
[18:03] <hatch> maybe check _emptySectionA method in browser.js
[18:04] <hatch> moving this search is a headache - it breaks darn near everything heh
[18:11] <hatch> I wish the watchers worked in vagrant
[18:13] <hatch> CSSSSSSSSSSSS
[18:14] <jcastro> hey rick_h_
[18:15] <jcastro> since frankban isn't here:
[18:15] <rick_h_> jcastro: howdy otp but what's up? 
[18:15] <hatch> uh oh
[18:15] <jcastro> juju git-deploy charms/mysql
[18:15] <jcastro> :D
[18:18] <hatch> yuss the search widget is placed inside the charmbrowser view now
[18:18] <hatch> now to make it work
[18:21] <hatch> poo premature celebration 
[18:28] <hatch> Makyo I need to edit the spinner rendering code in the charmbrowser, mind if I do that driveby?
[18:28] <hatch> to avoid conflicts
[18:32] <hatch> Makyo https://github.com/hatched/juju-gui/commit/9c03ac923b9e92fa97be1ba1ebe873f6f3fe828e
[18:32] <Makyo> hatch, go ahead, I'm still digging, haven't gotten that far yet.
[18:32] <Makyo> +1 on the change
[18:36] <hatch> :) If you have any q's about how that stuff works lemme know, I might have an idea :P
[19:00] <hatch> rick_h_ i'm in the hangout whenever
[19:53]  * rick_h_ steps away for a few 
[21:07] <hatch> back
[21:12] <hatch> Makyo hey, any luck on the dual render front? I'm curious :)
[21:23] <Makyo> hatch, not yet, I was thinking it was due to reloadInspector adding an event after destroy
[21:23] <Makyo> But that doesn't appear to be it.
[21:24] <hatch> Makyo maybe if you put a debugger in the initializer and turned on async tracebacks you'll be able to see when they get called
[21:24] <Makyo> Alright, will try that out.
[21:25] <Makyo> I just can't tell if it's getting reinitialized or if it's being left in place by destroy
[21:26] <hatch> ahh - well as I understand it, you cannot re-initialize a Y.Base derrived object
[21:26] <hatch> but that doesn't mean that it's not being destroyed properly or that it's not being double-rendered or something
[21:26] <hatch> or double initialized for that metter
[21:33] <Makyo> hatch, it just looks like a destroy thing, but I can't quite pick it apart, there's a lot of hidden stuff going on.  https://gist.github.com/makyo/ab415ea871490c001b59 seems to fix it, but I'm not sure if it's right or not.
[21:34] <hatch> looking
[21:34] <hatch> ahhh
[21:34] <hatch> ok lemme dig into this for a sec
[21:35] <hatch> Makyo here is the problem https://github.com/juju/juju-gui/blob/develop/app/views/inspectors/service-inspector.js#L96
[21:36] <hatch> I think
[21:36] <Makyo> That's what I was thinking, but debuggers never hit in there.
[21:36] <hatch> really?
[21:36] <hatch> hmm wth
[21:36] <Makyo> Yeah, I have no idea.  It's like that's never called under the il flag.
[21:37] <hatch> so removing the inspectors container and detaching it's events solve the issue...
[21:39] <Makyo> Yeah, which has me wondering if destroy is doing all its supposed to.
[21:39] <hatch> well destroy always leaves the container in the DOM in Y.View's which I think is crazy but it's never been an issue for us before because we always pass one in
[21:40] <Makyo> Yeah.
[21:40] <hatch> does this 'hidden' inspector work? 
[21:40] <Makyo> I guess I was thinking something else.
[21:40] <Makyo> Let me check.
[21:40] <hatch> or are the events detached
[21:42] <Makyo> They're still attached.
[21:42] <hatch> ok so that tells me that the destructor isn't being called at all
[21:43] <hatch> http://yuilibrary.com/yui/docs/api/files/app_js_view.js.html#l146
[21:43] <Makyo> Yep.  That's why I was thinking it had been intercepted by something.
[21:45] <hatch> if you create a destructor method in the service-inspector.js file and put a debugger in there does it get called?
[21:47] <Makyo> Yeah
[21:48] <Makyo> Wait, hmm.
[21:48] <Makyo> It's destroyed properly when you click close, just not when you open a second inspector. 
[21:48] <Makyo> I noticed that before, but forgot about the state thing,  Let me see if it's destroyed there.
[21:48] <hatch> ahah!
[21:52] <Makyo> hatch, if I changestate to null (thus emptySectionA), then changestate to the new inspector, everything's golden.
[21:53] <Makyo> So I need to see about destroying previous inspectors if the inspector changes state.
[21:53] <Makyo> The only downside is that there's a brief flash of the charm browser
[21:53] <hatch> ahh that would make sense
[21:53] <hatch> yeah
[21:53] <hatch> we can probably write a nicer way to render the new one then destroy the old one later on maybe
[21:54] <Makyo> Yeah.  For now, let me focus on that.
[21:54] <Makyo> Thanks for being a sounding board
[21:54] <hatch> :-) no problemo
[22:12] <Makyo> Three line fix.
[22:12] <hatch> :D and 100 line tests
[22:12] <hatch> lol
[22:12] <Makyo> Half frustrating, half relieved.
[22:12] <Makyo> Right? :{
[22:12] <Makyo> :P
[22:13] <hatch> yeah I feel your pain
[22:13] <hatch> https://www.humblebundle.com/books I just bought this....hope they don't -all- suck :D
[22:41] <Makyo> hatch, https://github.com/juju/juju-gui/pull/349 if you're still around
[22:42] <hatch> I am
[22:42] <hatch> heh nice 
[22:46] <Makyo> I'll take a quick look at getting rid of the flash before EoD
[22:46] <Makyo> Thanks
[22:48] <Makyo> ...that was easy.
[22:48] <Makyo> Well, quick follow up, then.
[22:51] <hatch> haha that was an easy fix after tracking it down :)
[22:52] <Makyo> Yeah, exactly.  Destroy wasn't being called because destroy wasn't being called :)
[22:53] <hatch> lol
[22:59] <hatch> dangit where is Huw I have a CSS organization question
[22:59]  * hatch hopes his ears are burning so he comes online
[23:00] <huwshimi> Morning
[23:00] <hatch> A HAH there he is
[23:01] <hatch> see I told u Makyo  ^ 
[23:01] <huwshimi> Uh oh
[23:01] <hatch> :P
[23:01] <hatch> lol
[23:01] <Makyo> Haha
[23:01] <hatch> dangit where is Huw I have a CSS organization question
[23:01] <hatch> [16:59:20]
[23:01] <hatch> hatch
[23:01] <hatch> hopes his ears are burning so he comes online
[23:01] <huwshimi> :)
[23:02] <hatch> huwshimi see line 10 https://gist.github.com/hatched/0584d2ae4d9726a148e8
[23:02] <hatch> why doesn't this work? 
[23:02] <hatch> shouldn't it?
[23:03] <hatch> I CAN move it out....it just seems like this should be the right way to do it
[23:04] <hatch> or does that syntax only work in SASS and not LESS
[23:04] <huwshimi> hatch: & equals the parent, so you you're trying to find an element that is '.charm-list .with-home [parent] {...}'. I guess that translates to '.charm-list .with-home .charm-list {...}'
[23:05] <hatch> ohhh
[23:05] <hatch> I se
[23:05] <hatch> e
[23:05] <hatch> dug
[23:05] <hatch> duh
[23:05] <hatch> thanks for making me look stupid
[23:05] <hatch> :P
[23:05] <huwshimi> hatch: If you're trying to select a .charm-list that has the class .with home you need to do &.with-home
[23:06] <hatch> https://gist.github.com/1c327a656d3c9af423bb is what I'm trying to do
[23:06] <hatch> I was just hoping I could keep it more contained
[23:06] <hatch> because it effects the charm-list element
[23:06] <huwshimi> hatch: Oh yeah, I hate having do do that sometimes.
[23:07] <huwshimi> hatch: No solution that I'm aware of.
[23:07] <hatch> drat, alrighty
[23:08] <hatch> huwshimi lemme know if my comments on your PR's don't make sense
[23:08] <hatch> I'll be working a bit past EOD today to make up for some lost time
[23:09] <huwshimi> hatch: Sure, just taking a look.
[23:12] <huwshimi> hatch: Makes sense.
[23:12] <hatch> sounds good - I have no idea why your other branch wouldn't land....
[23:13] <huwshimi> hatch: Yeah, strange...
[23:37] <huwshimi> hatch: How do I bind the moveToken event? Something like this? this.addEvent(this.get('unitTokens').on('moveToken', this._placeServiceUnit, this));
[23:37] <huwshimi> hatch: Will that bind to new unitTokens?
[23:38] <hatch> moveToken is fired from the token?
[23:38] <Makyo> hatch, quick driveby on that flash: https://github.com/juju/juju-gui/pull/350
[23:39] <hatch> huwshimi: the tokens set the machine view panel to be a bubblle target so in the machine view panel you would go `this.on('*:moveToken', this._placeServiceUnit, this)`
[23:39] <hatch> Makyo nice, I can't QA now because I'm in a middle of some search switchover stuff but I'll try later on
[23:40] <Makyo> Cool, lemme know.  I'll be around
[23:41] <huwshimi> hatch: Great, that works. Did you want to review this last set of changes (I know there's a +1 already)?
[23:42] <huwshimi> (haven't pushed up yet)
[23:42] <hatch> sure I'll take a peek once you push
[23:42] <hatch> I'm sure it's good :)
[23:44] <huwshimi> hatch: One sec, I've broken a test.
[23:47] <hatch> np
[23:48] <huwshimi> hatch: I'll let you know once phantomjs stopps crashing
[23:48] <huwshimi> stops
[23:49] <hatch> oh...good luck, I have to run my tests in the browser because it crashes 100% of the time for me
[23:53] <hatch> Makyo I've queued you up another card - this one's going to take some architecture planning :)
[23:53] <Makyo> Eeeexcellent.
[23:53] <hatch> we should have a pre-imp whenever you want to get started on it
[23:54] <huwshimi> hatch: Changes are up.
[23:54] <hatch> cool I'll take a look
[23:54] <Makyo> Tomorrow, hatch. Dinner time
[23:54] <hatch> yeah definitely :)
[23:55] <hatch> huwshimi looks good 
[23:55] <hatch> huwshimi happy with where the branch ended up?
[23:56] <huwshimi> hatch: Yeah, it was a bigger branch than I thought it would be, but it seems OK
[23:57] <hatch> yeah almost 1000 line diff haha
[23:58] <huwshimi> hatch: There's a lot of tests in there...
[23:59] <hatch> haha yes, yes there are