[00:03] <rick_h__> huwshimi: reviewed
[00:03] <rick_h__> huwshimi: thanks!
[00:03] <huwshimi> rick_h__: Thankyou
[00:03]  * huwshimi looking
[01:48] <rick_h__> urulama: go to bed!
[01:48] <rick_h__> :P
[08:24] <frankban> rogpeppe1: monring, I updated the branch with your (great) suggestions, would you like to take anothe rlook?
[08:24] <frankban> another even
[08:24] <rogpeppe1> frankban: looking
[08:24] <rogpeppe1> frankban: morning too, BTW!
[08:24] <frankban> thanks
[08:25] <urulama> oh, hey there frankban, rogpeppe1
[08:25] <frankban> morning urulama 
[08:25] <rogpeppe1> frankban, urulama: is your Go install from a PPA? I'd like to sort out the godeps problem that was mentioned on the list last night.
[08:25] <rogpeppe1> urulama: hiya!
[08:26] <frankban> looking
[08:26] <urulama> rogpeppe1: i can create new VM with go from PPA if needed
[08:26] <rogpeppe1> urulama: i'd be interested to see what happens when you do that, so yes please
[08:26] <urulama> rogpeppe1: made a note for the task, will do after lunch. if needed sooner, np
[08:27] <frankban> rogpeppe1: 2:1.2.1-2ubuntu1 from trusty
[08:27] <frankban> is there a ppa for 1.3>
[08:27] <frankban> ?
[08:27] <urulama> frankban: btw, Go on homebrew was bumped to 1.3.1 ...
[08:29] <rogpeppe1> frankban: have you run gofmt on your branch?
[08:32] <frankban> rogpeppe1: sublime usually gofmt each time I save
[08:32] <rogpeppe1> frankban: hmm, i guess that comments mean that fields don't line up. interesting.
[08:33] <frankban> rogpeppe1: comments in a struct definition? yeah 
[08:33] <urulama> frankban: gosublime package?
[08:33] <frankban> urulama: yes
[08:34] <frankban> urulama: it's pretty cool, the only downside is that I started not caring about indentation/white spaces also when writing python or javascript, feeling sad each time I realize saving does not fix everything for me
[08:35] <urulama> frankban: good to know, tnx. I use the same package.
[09:26] <rogpeppe1> frankban: re-reviewed. thanks for making the changes.
[09:54] <frankban> rogpeppe1: thanks for the re-review
[09:54] <rogpeppe1> frankban: np
[10:25] <urulama> rogpeppe1, frankban: we can make a search query on a name for a charm over Charm.Meta.Name, but there is no such equivalent with bundles like Bundle.BundleData.Name, only through BaseURL
[10:25] <urulama> rogpeppe1, frankban: the question is - did i miss something with the bundle name?
[10:25] <urulama> rogpeppe1, frankban: or we actually don't have one?
[10:27] <frankban> urulama: we don't have a bundle name as a separate concept, we have the bundle URL
[10:28] <rogpeppe1> urulama: frankly, having the charm name inside its metadata was a mistake
[10:29] <rogpeppe1> urulama: but that's what we've got, so we leave it there
[10:29] <rogpeppe1> urulama: the actual name of the charm is defined by its id, as frankban says
[10:31] <urulama> rogpeppe1: ok, so the proper way would be to not use Charm.Meta.name at all, but just IDs in both cases
[10:31] <rogpeppe1> urulama: yes
[10:31] <urulama> rogpeppe1: got my answer, tnx
[10:33] <urulama> rogpeppe1: so, if i upload a charm trusty/mywordpress, but that has a name theirWordpress, and when i search for myWordpress, the resulting charm would show the name theirWordpress in the GUI?
[10:34] <rogpeppe1> urulama: i'm not sure. it depends on the GUI logic
[10:34] <rogpeppe1> urulama: it *shouldn't* do
[10:34] <urulama> rogpeppe1: :D
[10:35] <rogpeppe1> urulama: one possibility is that we could refuse uploads of charms where the metadata name doesn't match the actual name
[10:35] <urulama> rogpeppe1: was thinking the same thing, but then, it would be better for not requiring the name at all and just add it in code
[10:36] <urulama> if we need to have Charm.Meta.Name nonempty
[10:36] <rogpeppe1> urulama: i don't think we can fill in Charm.Meta.Name ourselves, unfortunately
[10:37] <rogpeppe1> urulama: because i think it's important to have the charm metadata be an exact reflection of what you get if you fetch the metadata.yaml file from the archive
[10:37] <rogpeppe1> urulama: and we can't change that
[10:47] <rick_h__> morning wheee
[11:23]  * urulama lunches
[12:39] <frankban> jrwren_: morning, how is it going with the quickstart branches?
[12:50] <jrwren_> frankban: on the back burner.
[12:50] <frankban> jrwren_: ok
[12:53] <rick_h__> frankban: jrwren_ let's check with urulama if it's ok to make that the goal for friday though please. 
[12:53] <rick_h__> frankban: jrwren_ urulama actually feature freeze is today
[12:53] <rick_h__> frankban: jrwren_ urulama can we get those done up and a release out?
[12:54] <rick_h__> sorry, I should have looked at that earlier this week
[12:54] <jrwren_> rick_h__: quickstart?  sure.
[12:54] <rick_h__> urulama: is that ok with you if I steal jrwren_ to get that updated today and out?
[12:55]  * urulama starts singing "Aaaaall by myseeeeeelf ...."
[12:55] <jrwren_> lol
[12:55] <urulama> rick_h__, jrwren_: sure, np
[12:55] <rick_h__> urulama: ty much
[12:56] <urulama> rick_h__: frankban as well, right. So with rogpeppe1 out tomorrow, i'll go back to QA part of the story. It's all fine.
[12:57] <rick_h__> urulama: it's all good, I think getting the search docs/etc together is +1 and it sounds like there's some back/forth going on
[12:57] <rick_h__> urulama: so I'd not change up plans really on that front?
[12:57] <rick_h__> or maybe I'm misunderstanding. 
[12:58] <urulama> rick_h__: i'm always an optimist that i'll have time to code :D
[12:58] <rick_h__> hah
[12:58] <frankban> rick_h__: I was thinking about white listing: are we still ok with the plan given that 1) it does not prevent people to use the hooks/ dir as a mp3 repo and 2) in the future, we possibly have the same problem with resources?
[12:59] <rick_h__> frankban: let's punt on whitelisting until we know how the zip access holds up under pressure
[12:59] <rick_h__> frankban: I think that's the main driver we had before that we don't have now, disk space of uncompressed files laying around
[13:00] <rick_h__> frankban: we can reevaluate it as a whole closer to release time once we've used it more.
[13:01] <frankban> rick_h__: so, IIUC no white listing for now?
[13:01] <rick_h__> frankban: correct
[13:01] <frankban> rick_h__: +1 cool
[13:01] <rick_h__> you've convinved me :)
[13:01] <rick_h__> well you and urulama 
[13:02] <frankban> :-)
[13:08] <jrwren_> :( whitelist sounded so fun.
[13:08]  * rick_h__ goes to start the morning now that morning calls are through. biab
[13:18] <jrwren_> I'm not sure what to do with this: https://code.launchpad.net/~evarlast/juju-quickstart/support-lxc-clone/+merge/227250
[13:18] <jrwren_> frankban: ^
[13:19] <frankban> jrwren_: what's the problem?
[13:19] <jrwren_> nevermind. launchpad is foreign.
[13:27] <jrwren_> frankban: updated: https://code.launchpad.net/~evarlast/juju-quickstart/support-lxc-clone/+merge/227250  its marked approve already. I don't know what next step is.
[13:28] <frankban> jrwren_: looking
[13:30] <frankban> jrwren_: looking at https://juju.ubuntu.com/docs/config-LXC.html#fast-lxc-creation it seems that on certain platforms lxc-clone defaults to true
[13:32] <jrwren_> frankban: which is why I didn't specify originally.
[13:34] <frankban> jrwren_: can't we just provide that information in quickstart? "LXC clone is enabled by default for Trusty and above, and disabled for earlier Ubuntu releases."
[13:34] <jrwren_> frankban: whatever you want.
[13:34] <frankban> jrwren_: thank you
[13:35] <frankban> jrwren_: other than that, you can go ahead and land it. we use lbox for quickstart, so I'd suggest to just "lbox propose" and then "lbox submit" the branch
[13:36] <jrwren_> ok
[14:00] <bac> rick_h__: i'm in 1:1 hangout
[14:01] <rick_h__> bac: doh sorry
[14:40] <hatch> lazyPower: hey do you have a link to the talk by Jamie Windsor?
[14:46] <jcsackett> jujugui: can someone confirm a bug for me? want to make sure i haven't got something weirdly local going on.
[14:47] <hatch> sure
[14:47] <lazyPower> hatch: https://www.youtube.com/watch?v=hYt0E84kYUI
[14:47] <jcsackett> hatch: cool. on develop, with mv flag, deploy a service and immediately commit (so autodeploy).
[14:47] <rick_h__> it shouldn't do that now, kadams updated to stop it
[14:48] <rick_h__> jcsackett: we need to do the follow up to block the 'confirm' and add a UI there
[14:48] <rick_h__> jcsackett: I think that's what he's working on currently
[14:48] <jcsackett> rick_h__: ok, so we know we have an issue?
[14:48] <hatch> lazyPower:  cool thanks
[14:48] <jcsackett> b/c right now i see an uncommitted unit hang around.
[14:48] <rick_h__> jcsackett: sorry, I guess what's the issue? 
[14:49] <rick_h__> jcsackett: we know and kadams has a card in progress around completing work there
[14:49] <hatch> haha I was waiting for the actual issue description (and it never game :'( )
[14:49] <jcsackett> rick_h__: ok, didn't realize summary and UX changes included that.
[14:49] <rick_h__> jcsackett: so yes, after trying it I see that it doesn't deploy 
[14:49] <rick_h__> jcsackett: so this is expected
[14:49] <jcsackett> rick_h__: dig.
[14:49] <hatch> ohh 
[14:49] <hatch> yeah
[14:49] <rick_h__> jcsackett: it's WIP I guess
[14:49] <hatch> expected
[14:49] <hatch> :)
[14:50] <jcsackett> rick_h__: all good, just making sure. it complicated QA locally for my branch, and then i saw it on develop, and then i was like "huh"?
[14:50] <rick_h__> jcsackett: understood
[14:50] <rick_h__> sorry for the distraction :)
[14:50] <rick_h__> distraction around your QA that is
[14:50] <jcsackett> rick_h__: all good. i'm just happy i didn't a) cause a bug and b) somehow screw up my develop branch.
[14:51] <jcsackett> since, y'know, it wouldn't *remotely* be the first time i'd done that.
[14:51] <rick_h__> jujugui call in 10 please kanban
[14:53] <hatch> rick_h__:  can huws branch land?
[14:53] <rick_h__> hatch: I don't think so, the callback of the items seems broken?
[14:53] <rick_h__> hatch: I wanted to chat with you about that this morning, after the standup?:
[14:54] <bac> jujugui: regrets, i have another meeting and won't make the standup
[14:54] <rick_h__> bac: summary of your stuff, is you came, you saw, you debugged?
[14:54] <rick_h__> bac: what's the progress of the slack update?
[14:55] <hatch> rick_h__:  oh ok, it worked perfect after he made the changes from my review
[14:55] <bac> rick_h__: i have submitted it for review but gotten no bites yet.  will ping tom.
[14:55] <rick_h__> hatch: yea, I'm :/ on the way it's working but maybe I'm not following something
[14:55] <hatch> I'll pull it down and take a look
[14:55] <rick_h__> bac: rgr ty for the update
[14:59] <rick_h__> jujugui call in 1 or now, go go go
[15:00] <rick_h__> antdillon: around for call?
[15:01] <rick_h__> kadams54: there he is
[15:01] <kadams54> joining…
[15:02] <kadams54> Chrome apparently needs a restart
[15:13] <hatch> urulama: Parallels 10 is now available :)
[15:14] <urulama> hatch: already in use ;)
[15:22] <hatch> urulama:  haha nice - I'm skeptical, I'll wait a bit lol
[15:22] <hatch> although the upgrade from 8 to 9 was painless
[15:22] <urulama> jujugui: the inital search doc was shared with everyone. it's a live doc. jrwren_ and bac please take a look next week, as we might start working on search part
[15:23]  * bac looks
[15:24] <urulama> hatch: at least 14.04 works out of the box now :D
[15:24] <bac> jujugui: azure sent out email about rolling reboots tomorrow and the next day.  may affect our CI. (not sure if everyone gets those mails.)
[15:24] <urulama> hatch: and it does fill slightly faster
[15:24] <bac> let me know if it goes wonky
[15:24] <urulama> hatch: feel even
[15:25] <hatch> urulama: the only real problem I'm having with 14.04 is that the audio is really quiet - also I can't quite get my keybindings correct but that's probably just me being crazy
[15:25] <jrwren_> frankban: updated: https://code.launchpad.net/~evarlast/juju-quickstart/which-juju/+merge/227238 & https://codereview.appspot.com/132770043
[15:26] <frankban> jrwren_: looking
[15:27] <urulama> hatch: +1 on keybindings
[15:40] <urulama> jujgui: cu tomorrow
[16:07] <frankban> jrwren_: reviewed, https://codereview.appspot.com/132770043/ . please ping me if something is not clear. I am trying to proceed with the quickstart release so I did not have time to further investigate
[16:08] <jrwren_> frankban: thanks.
[16:08] <frankban> jrwren_: also note that Rietveld allows you to reply in line and/or mark requested changes as done while working on the branch. This really helps keeping track of what's done
[16:09] <frankban> jrwren_: then, when you are ready, you can just "lbox propose" again
[16:21]  * rick_h__ takes lunch time
[16:43] <hatch> kadams54:  you have the worst internet :)
[16:43] <kadams54> ?
[16:43] <hatch> might be time to upgrade to dialup
[16:44] <hatch> you ping timeout all the time
[16:44] <kadams54> Ah
[16:49] <hatch> lazyPower:  is there a juju plugin to allow `juju export` to work on lxc?
[16:50] <hatch> say I want to run juju-gui in a local deployment but allow someone external on the net to access it (assuming they can access my primary machine)
[16:50] <rick_h__> hatch: you'd have to map that IP out to the internet
[16:51] <hatch> rick_h__:  yeah I was hoping for a juju plugin to do it for me - and assume that the outside could access a specified port on my machine
[16:51] <rick_h__> hatch: it has to do your router/etc so not sure how it would do that
[16:52] <hatch> rick_h__:  well assume my router will allow acces to my machine on port 8888 
[16:52] <hatch> I need to get the gui from the lxc instance to be available on my host machines port 8888
[16:52] <hatch> that should be scritable 
[16:55] <frankban> guihelp, I just noticed we no longer support saucy, is it correct
[16:55] <frankban> ?
[16:56] <rick_h__> frankban: yes
[16:56] <hatch> heh that will cause an issue for our dev vagrant image :)
[16:56] <hatch> which I'm pretty sure is saucy 
[16:56] <rick_h__> EOL July 17, 2014
[16:56] <frankban> rick_h__: are we supposed to QA quickstrat on utopic?
[16:56] <rick_h__> https://wiki.ubuntu.com/Releases
[16:56] <frankban> quickstart even
[16:56] <rick_h__> frankban: hmm, we should as this is what we're heading to
[16:56] <rick_h__> frankban: and OSC
[16:56] <rick_h__> OSX
[16:57] <rick_h__> anyone running utopic? BradCrittenden?
[16:57] <frankban> rick_h__: yeah, osx is on the list. we should change the QA instructions and readme for quickstart: we need to remove saucy and add utopic
[16:58] <rick_h__> frankban: adding a card for it now
[17:00] <frankban> rick_h__: I prepared quickstart for release with two quick branches and packages for v1.4.2 are being built now. It's my EOD so I'd like to pass the release to someone else (in the case it's not ok for me to continue tomorrow morning).
[17:01] <rick_h__> frankban: rgr, are the release process docs there? I'll get BradCrittenden and jrwren_ to help track things up. 
[17:01] <rick_h__> frankban: thanks for getting that going and have a good night!
[17:01] <frankban> rick_h__: what we need to do is 1) wait for the packages to be published (https://code.launchpad.net/~juju-gui/+archive/ubuntu/quickstart-beta/+packages)
[17:02] <frankban> 2) QA on trusty and utopic (pre release QA is described in the HACKING file)
[17:02] <frankban> 3) copy the PPA packages to juju/stable PPA 4) "make release" -> PyPI
[17:03] <frankban> 5) make and test the homebrew release
[17:03] <frankban> 6) add a release tag to trunk and have a drink
[17:03] <frankban> rick_h__: ^^^
[17:03] <rick_h__> woot thanks frankban 
[17:03] <lazyPower> hatch: its possible but not with teh default setup
[17:03] <lazyPower> i wrote a blog post about this
[17:04] <frankban> rick_h__: thank you
[17:04] <lazyPower> hatch: http://blog.dasroot.net/making-juju-visible-on-your-lan/
[17:04] <hatch> lazyPower:  thanks 
[17:04] <hatch> kind of sucks
[17:04] <hatch> :)
[17:04] <lazyPower> yes, yes it does
[17:05] <hatch> I.....hate......networking
[17:05] <lazyPower> and that article was written against 12.04 - so it may have changed a bit. 
[17:05] <lazyPower> I haven't revisited using LXC as my primary since i setup a VMAAS cluster
[17:05] <lazyPower> but the networking was similar.  1 ETH device for my communication, 1 ETH device as a bridge adapter for the VMAAS cluster. same basic concept being applied.
[17:09]  * rogpeppe1 is done for the day.
[17:09] <rogpeppe1> happy weekends all, see y'all on tuesday!
[17:10] <hatch> jcsackett:  ok, lots of comments heh,
[17:10] <hatch> mind responding then I'll take another look 
[17:11] <hatch> lazyPower: couldn't a juju plugin just use sshuttle to forward the services ip and port to some supplied port on the host?
[17:11] <hatch> I know that's not probably how plugins are supposed to work, buuuuuut
[17:11] <lazyPower> hatch: contributions are welcome ;)
[17:11] <hatch> does that sound like it's a valid solution though?
[17:12] <lazyPower> i dont think sshuttle works like that
[17:12] <lazyPower> it might, but i'm not terriblyf amiliar with using it as a proxy binding for services like that - i'd think you'd have better luck using UFW rulesets
[17:12] <lazyPower> er, IPTables rather
[17:13] <lazyPower> but in any case, that gets hairy, and its not going to work 100% of the time, as networking is a complicated monkey to just assume a particular use case and run with.
[17:13] <hatch> hmm, I used to frequently use `ssh` to create a tunnel between an lxc instance and the host machine for testing
[17:13] <hatch> I never tried to get that out of the host machine though...
[17:14] <lazyPower> the only good way i can see to do it, is to create a bridge adapter and handle host routing that way.
[17:14] <lazyPower> and its not bullet proof
[17:15] <hatch> *sigh* networking shouldn't be this hard heh
[17:30] <BradCrittenden> rick_h__: i have a utopic vm but don't run it daily.  can spin up for testing
[17:36] <rick_h__> bac: appreciate it, qa'ing the quickstart packages on trusty now
[17:36] <rick_h__> bac: even just a quick lxc setup for utopic might work
[17:39] <bac> rick_h__: perhaps, but i've got this vm just sitting here...
[17:39] <rick_h__> bac: ok cool
[17:42] <jcsackett> hatch: was grabbing lunch. looking at your comments now.
[17:43] <kadams54> hatch: https://github.com/kadams54/juju-gui/blob/develop/app/views/viewlets/service-overview.js#L467
[17:43] <kadams54> I'm guessing this is why my changeState event isn't bubbling up to browser.js?
[17:43] <hatch> kadams54:  looking
[17:44] <hatch> kadams54:  does it look like events fired from the deployer bar would hit the browser?
[17:44] <hatch> browser.js
[17:44] <hatch> I'm not familiar with where it's instantiated 
[17:44] <kadams54> The DeployerBarView is created by app.js
[17:45] <kadams54> Which would make it a peer to browser.js?
[17:45] <hatch> no 
[17:45] <kadams54> Not really sure how subapps work
[17:46] <hatch> browser.js is a totally different app 
[17:46] <hatch> lemme take alook
[17:46] <jcsackett> do we actually need to maintain the subapps idea? are we ever going to have more, and do we gain much by having browser separated like that anymore?
[17:47] <hatch> jcsackett:  yeah - we don't have to rewrite it now :) in fact I was going to propose an idea where we have more 'subapps' but at a much higher level
[17:47] <hatch> haven't thought it through yet
[17:47] <rick_h__> jcsackett: the reasons on that were a couple fold I can tell you about in our call later
[17:47] <jcsackett> rick_h__: cool.
[17:47] <hatch> kadams54:  in _renderDeployerBarView, after we instantiate the deployer bar add `this.deployerBar.addTarget(this);` 
[17:47] <hatch> that 'might' make it work
[17:48] <hatch> at least give it a try
[17:48] <kadams54> k
[17:48] <hatch> if not I can guide you through a real fix
[17:50] <hatch> why is the machine-view-panel in /widgets? lol
[17:50] <rick_h__> because we agreed Y.Widget does not == Widget in a generic sense :P
[17:51] <hatch> if mv is a widget then......daayyyyymmmmnnnn
[17:52] <rick_h__> well, it didn't start out like this :P
[17:52] <rick_h__> you forget this stuff started 5 months ago 
[17:52] <rick_h__> it's bee a long long ride
[17:52] <rick_h__> patches welcome hah
[17:53] <hatch> lol
[17:54] <hatch> oh man bare metal tokens are so messed up
[17:56] <hatch> kadams54:  this is quite the bug you found....
[17:56] <kadams54> *sigh*
[17:56] <hatch> I might have to defer
[17:57] <hatch> it's actually an issue with how bare metal containers are rendered
[17:57] <hatch> it wasn't an issue before because we just cleared out the model
[17:57] <hatch> so it was all re-rendered
[17:57] <rick_h__> huh? I thought this was around 'auto place' in the summary?
[17:57] <rick_h__> what's it got to do with bare metal containers?
[17:57] <hatch> rick_h__:  I'm referring to the bug he found in my branch
[17:57] <rick_h__> oh
[17:59] <hatch> kadams54:  would you be ok if I punted on that bug, landed this and then fixed it as an immediate follow-up?  Because it's actually an existing condition
[17:59] <kadams54> Sure.
[17:59] <hatch> thanks I'll update the PR accordingly
[18:00] <hatch> card created
[18:02] <rick_h__> kadams54: call time
[18:04] <hatch> Makyo:  because of this issue I created two cards at the bottom of Project 1 wrt the config changed stuff, feel free to take them as I will be pre-disposed for today likely
[18:07] <hatch> kadams54:  did that fix work?
[18:10] <kadams54> hatch: Yeah, it worked, thanks.
[18:11] <hatch> great
[18:14] <hatch> jcsackett:  replies to your replies :)
[18:14] <hatch> I'm going to grab some lunch now
[18:19] <jcsackett> hatch: so, i see it modifying the model to set the deleted flat, but otherwise just creating records.
[18:21] <jcsackett> hatch: i can maybe see an argument about the `delete unit.machine` bit, but not the whole method.
[18:39]  * bac afk for a bit
[19:09] <hatch> back
[19:09] <rick_h__> go get him jcsackett!
[19:10]  * jcsackett laughs
[19:11] <jcsackett> hatch: you up for a quick chat?
[19:11] <rick_h__> guihelp anyone know how to 'copy packages' to another ppa?
[19:11] <hatch> jcsackett:  so anywhere in the application which decides it wants to delete a machine has to then duplicate the code in that method elsewhere? 
[19:11] <hatch> yeah sure, just lemme get the dogs inside
[19:11] <jcsackett> hatch: cool.
[19:12] <jcsackett> hatch: standup room, when you're ready. :)
[19:12] <hatch> omw
[19:26] <jcsackett> i will confess, when rick_h__ jumped in i was worried i was about to be huwed. :p
[19:27] <hatch> hahahahaha
[19:27] <hatch> huwed
[19:27] <rick_h__> lol
[19:27] <hatch> that's so a thing new
[19:27] <hatch> now*
[19:27]  * kadams54 feels clueless
[19:27] <kadams54> What's a "huwing"?
[19:28] <hatch> when you do your branch
[19:28] <hatch> get it reviewed and make changes
[19:28] <hatch> then rick_h__ comes in and changes the implementation 
[19:29] <hatch> so maybe "huwing" should be rewriting code
[19:29] <hatch> lol
[19:30] <rick_h__> :P
[19:30] <hatch> kadams54: is your card in review the one in coding?
[19:30] <rick_h__> I can't help it I have opinions that occassionly are useful
[19:30] <kadams54> Not any more :-)
[19:30] <hatch> haha thx
[19:31] <kadams54> guihelp: Looking for reviews on https://github.com/juju/juju-gui/pull/506
[19:31] <hatch> kadams54:  doing it
[19:31] <kadams54> Awesome
[19:40] <jcsackett> kadams54: i'll be your second review if i can put you as the second for mine (once i get done with being reviewed by hatch)
[19:40] <kadams54> jcsackett: Deal.
[19:40] <jcsackett> awesome. :)
[19:46] <hatch> kadams54:  done - one comment you can look into 
[19:48] <jcsackett> hatch: so, unhappy moment--if i remove the units in the ECS, i have no way of getting at them to add them to unplaced units in the machine view. :/
[19:49] <hatch> jcsackett:  shouldn't you be able to call the 'render unplaced units' method and it'll update the list?
[19:50] <jcsackett> ...maybe.
[19:50] <jcsackett> i'm dubious, but that might work.
[19:52] <hatch> _renderUnplacedUnits is what it's called
[19:53] <hatch> it might need to be upgraded to check if it's already rendered it though...
[19:53] <hatch> agile......
[19:53] <hatch> lol
[19:59]  * jcsackett groans
[19:59] <rick_h__> ruh roh
[19:59] <jcsackett> well, it seems to need some sort of magic to let a unittoken be back in it once it's palced.
[20:01] <jcsackett> so, the problem is that once you assign the unit, it's no longer in this.get(unitTokens), which is what the renderUnplaced thing uses.
[20:02] <hatch> http://i.dailymail.co.uk/i/pix/2012/10/27/article-0-15B4ABD0000005DC-0_634x376.jpg
[20:03] <jcsackett>  /me laughs
[20:04] <hatch> lol love that pic
[20:04] <jcsackett> yeah, when we place a unit, we remove it from unit tokens; so i'm going to need to a) figure out why delete unit.machine isn't picked up as a change to a unit for that event, and b, wire that handler up to add it back to the unitTokens.
[20:04] <jcsackett> so...this is probably not landing today.
[20:04] <hatch> jcsackett:  well....
[20:05] <hatch> so maybe what you do is leave it the way you had it, with a bug about this functionality - because that should really be rendering the unplaced units by parsing the model
[20:05] <rick_h__> jcsackett: sounds like you're on a good path there.
[20:05] <jcsackett> rick_h__: the "not landing today" path or the "fuck it, land it this way with a bug" path? :p
[20:05] <rick_h__> if you need to pause a card to fix something first there's nothing wrong with that
[20:06] <rick_h__> I sometimes think we need to do that more than the 'land with issues and I pinky swear to make it better next' thing
[20:06] <jcsackett> rick_h__: i don't know that this is really fixing something else, per se. i think its within scope for this card.
[20:06] <jcsackett> as long as we're all comfortable with this card hanging out for another day.
[20:06] <jcsackett> :p
[20:06] <rick_h__> jcsackett: right, I meant you're on the right path with the event wiring
[20:06] <jcsackett> i am, to be clear, b/c this does seem better.
[20:06] <jcsackett> yeah.
[20:06] <rick_h__> jcsackett: +1, good fix using the right model ftw
[20:06] <jcsackett> but, i need to not look at it for a bit. :p kadams54, your PR ready for a second review?
[20:07] <kadams54> jcsackett: yup, have at it. And yours?
[20:07] <rick_h__> jcsackett: it's close to EOD, put it away for the night
[20:07] <hatch> jcsackett:  ok awesome....thanks
[20:08] <rick_h__> speaking of, going to step away until calls start back up in an hour
[20:08] <rick_h__> biab
[20:08] <jcsackett> kadams54: tomorrow for mine. :p
[20:08] <hatch> ok now what was I doing before all these reviews....
[20:09] <hatch> besides jammin to Hardwell 
[20:09] <jcsackett> hatch: it's always fun to regain state after reviews, isn't it? :p
[20:09] <bac> rick_h__: i'm doing the quickstart QA on utopic now.  sorry for the delay
[20:09] <hatch> jcsackett:  haha yep
[20:09] <rick_h__> bac: ok, let me know if you find anything asap.
[20:25] <hatch> You know you live in the prairies when this tweet is a thing....... https://twitter.com/SKGov/status/502545556389236737
[20:28] <kadams54> I've been waiting for that crop report!
[20:29] <kadams54> Good to hear the farmers are busy desiccating.
[20:36] <hatch> haha
[20:36] <hatch> there is actually a 'crop report' on one of the radio stations as a show
[20:36] <hatch> I mean.....99% of the land here that's not covered by trees is farm land sooooo it stands to reason it would be an important part of the economy
[20:36] <hatch> still comical 
[20:40] <hatch> I think I'm going to become an ophthalmologist - one is in the news for billing $2.2M last year......
[20:42] <hatch> average is $1.02M/year
[20:46] <jrwren_> hatch: what kind of crops over there?
[20:46] <hatch> what's your poison? ;)
[20:46] <hatch> mostly grains
[20:47] <jrwren_> hatch: barley. Can you get me a deal?
[20:47] <hatch> lol maybe
[20:47] <hatch> barley is hardcore
[20:47] <jrwren_> I'm hoping for like $20/bushel
[20:48] <hatch> umm I think it's like $3 right now.....
[20:48] <hatch> so yeah....$20...deal!
[20:48] <jrwren_> $3/bushel?!?!
[20:49] <hatch> Oct Barley: unchanged at $2.683 USD or $2.975 CDN
[20:49] <jrwren_> zomg, I should so buy.
[20:50] <jrwren_> do you know what they charge at the brew store?
[20:50] <jrwren_> its like $50!!!
[20:50] <hatch> haha, bagging it into a fancy bag is expensive! 
[20:50] <jrwren_> so is malting
[20:51] <hatch> probably not $47 expensive mind you
[20:52] <hatch> you can buy a metric tonne for $140 lol
[20:53] <jrwren_> this is going to be me, but with barley: http://thedailywtf.com/Articles/Special-Delivery.aspx
[20:53] <hatch> hahaha
[20:55] <hatch>  instead of virtually trading 28,000 tons of coal, Brad had somehow ended up with 28,000 tons of real coal.
[20:55] <hatch> hahahahaha
[21:07] <bac> that story does look fishy
[21:08] <bac> Brad may be a doofus, but "1".lower() != "true"
[21:08] <bac> what am i missing?
[21:11] <jcsackett> bac: the story was debunked a few years ago along with a bunch of other dailywtf stories.
[21:11] <bac> jcsackett: but but but, they could've at least made it internally consistent
[21:11] <jcsackett> bac, actually, i think it is.
[21:11] <bac> how's that?
[21:12] <bac> so the confirm for physical delivery came back as a '1'
[21:12] <jcsackett> right, and that .lower() doesn't equal "true".
[21:13] <jcsackett> so if you're setting a flag to stop, you'll se false, and go "ok, no physical delivery, we're good"
[21:13] <jcsackett> right?
[21:13] <bac> right, so on the originator's side physicalDelivery is False, so ... so they think it is consistent.  gotcha
[21:14] <jcsackett> i mean, it's still a load of crap, but it's consistent crap. :p
[21:14] <bac> :)
[21:14] <bac> and, once again, brad is the butt of the joke.  it all started with "Rocky Horror"
[21:24] <urulama> rick_h__: ping?
[21:25] <rick_h__> urulama: pong
[21:25] <urulama> rick_h__: hey there
[21:30] <bac> rick_h__: i'm still working my way through the QA.  everything is fine so far.
[21:31] <rick_h__> bac: ty
[21:52] <bac> rick_h__: i declare quickstar 1.4.2 yar on utopic
[21:54] <rick_h__> bac: cool because I got it released and smoser uploaded it a while ago. Thanks for safety checking it out
[21:54] <rick_h__> I really appreciate the check
[21:54] <bac> np
[21:54]  * rick_h__ needs to start to add these release milestones to his calendar
[22:22] <huwshimi> Morning
[22:27] <rick_h__> morning huwshimi 
[22:30] <hatch> morning huwshimi
[22:33] <huwshimi> hatch: Call?
[23:44] <huwshimi> rick_h__, hatch: How do I pass the correct 'this' to a callback? http://paste.ubuntu.com/8110037/
[23:45] <hatch> huwshimi:  you want the context from the token?
[23:45] <hatch> myFunction.bind(this)
[23:45] <huwshimi> hatch: Yeah
[23:45] <hatch> function() {}.bind(this)
[23:46] <huwshimi> hatch: So this would work? this._handleMoveIconClick.bind(this)
[23:46] <hatch> that will create a bound version of that function and return it
[23:46] <hatch> yep
[23:46] <hatch> if you want to stub that method however for tests
[23:46] <hatch> you'll have to do it BEFORE that bind is called
[23:46] <hatch> because bind() actually returns another method which is bound to a specific context
[23:46] <huwshimi> hatch: Brilliant, that worked :)
[23:46] <hatch> if that makes sense....
[23:46] <hatch> :)
[23:47] <huwshimi> makes sense