[00:03] <hatch> huwshimi: have you had a chance to look at the comments on your branch from yesterday?
[00:04] <huwshimi> hatch: Was just reviewing Gary's changes
[00:05] <rick_h> hatch: did you peek if the images on the zoom was correct in trunk? /me is wondering if this is a case of broken build step?
[00:05] <hatch> rick_h: sorry I haven't I just noticed it in passing and created a ticket
[00:05] <rick_h> hatch: k
[00:05] <hatch> I also rage quit at EOD today sooooo probably won't go back at it until tomorrow
[00:05] <rick_h> hatch: k, np. I'll check it out later when I'm properly pc bound
[00:08] <hatch> rick_h: so I think that changing the path or hash of a file is better than etags because etags still require a get request
[00:08] <hatch> thoughts?
[00:09] <rick_h> hatch: so the thing is that caching layers in the middle work properly with etags nicely. It's based on the content of a file and doesn't pollute the url. 
[00:09] <rick_h> so you want to create a hash of a file, that's what an etag is
[00:09] <rick_h> it's just in the header vs the url
[00:09] <rick_h> so you don't have to see it
[00:10] <rick_h> browsers and web servers have spent a lot of brain power making these work really well
[00:10] <hatch> right but that still requires a request whereas the other approach <filehash>-main.js for example can be infinitely cached so will never request a new file
[00:12] <hatch> it's almost like an etag is for a sysadmin to implement caching whereas the hash approach is for the developer to do it :)
[00:12] <rick_h> hatch: hmmm, I guess that works. Man it seems fugly. It's true it's a request, but it's only going to make the request if the cache time has expired, and then it'll only be a HEAD request. 
[00:12] <rick_h> hatch: yea, but the thing is that because it's in the sysadmin side, it's fully supported by things like squid/varnish, CDNs, etc
[00:13] <hatch> I wonder if it's a big hit on mobile because each http request can be a huge delay
[00:13] <rick_h> I guess in our case where we've only got a few files it's not as bad, we still need etags for the images and other things we load
[00:13] <hatch> i've seen http requests over 10s long...so does it block loading of the page until that req comes back?
[00:13] <hatch> (I have no idea)
[00:14] <rick_h> hatch: well, I'd say look at our server logs and see if we've got 10s requests
[00:14] <hatch> it's not the server, it's the network
[00:14] <hatch> so for example
[00:14] <rick_h> this thing is deployed by admins into a environment on a cloud service. I doubt they're 10s from it. 
[00:14] <rick_h> not to mention the lack of mobile right now
[00:15] <hatch> client makes request -> it gets lost in internet land for 10s (what is the browser doing now?)
[00:15] <rick_h> hatch: yea, I gotcha
[00:15] <hatch> is it waiting? or is it displaying the out of date code
[00:15] <hatch> 'potentially' out of date code
[00:15] <rick_h> hatch: but we can tell stuff like that by looking at the request times for a user across the files fetched on load
[00:15] <rick_h> we 'have' the data
[00:16] <hatch> I'm not talking about us specificially
[00:16] <hatch> just about the technology
[00:16] <hatch> if the http request gets stuck somewhere....what is the browser doing
[00:17] <rick_h> well, the technology works, it tested, and works for all files. images, static js, dynamic content, etc. 
[00:17] <hatch> I think you're missing what I'm saying
[00:17] <rick_h> if the http gets stuck somewhere a user is going to reload the browser. they're an impatient lot
[00:17] <rick_h> if someone pulls the internet plug mid-request it's pulled. 
[00:17] <rick_h> so what?
[00:18] <hatch> well using the hash approach the browser (after getting the index.html) can start to render the content (assuming everything is the same) using the etag approach it has to make those extra http requests and wait for them to return to start rendering
[00:18] <hatch> (at least I would assume that's what it does)
[00:19] <hatch> so on a connection with slow http round trips it would be a large performance gain to use the hash approach
[00:19] <rick_h> well, first time it fetches the files regardless. Then the next time you request it, the browser checks the TTL and if that's passed up it makes a HEAD request saying "I'm looking for this content, with this etag"
[00:19] <rick_h> and the server says to either re-submit a GET request or carry on, your copy is fine
[00:19] <hatch> right....at which point it's waiting
[00:20] <rick_h> hatch: right, if the latency is 1s round trip it would suck. Now show me 1s round trip times from people using our tool :P
[00:20] <rick_h> hatch: and the hash solution works for files that you hash. What about the rest of them?
[00:20] <rick_h> so it works with our 3 js files, 2 css files?
[00:20] <hatch> I wasn't talking about our tool - just the technology in general
[00:20] <rick_h> we've got 50+ requests on a page load?
[00:21] <hatch> right - you probably wouldn't want to generate hash filenames for images
[00:21] <hatch> at least unless your on huge scale
[00:21] <rick_h> at that point you CDN so that no one has 1s round trips. 
[00:21] <rick_h> the files are close to them at all times
[00:21] <rick_h> unless you're in the artic on a science study
[00:21] <rick_h> then suck it 
[00:22] <hatch> oh man I wish, my http requests from my phone are constantly 1s+
[00:22] <hatch> more if it's unprimed
[00:22] <rick_h> that's total request
[00:22] <rick_h> with transfer
[00:22] <hatch> nope just round trip
[00:22] <rick_h> run speedtest on it and tell me what the ping time is
[00:23] <rick_h> sorry, but having a hard time buying that using your phone you've broken down ping times and page load time due to transfer
[00:24] <hatch> ok loading speedtest
[00:24] <hatch> http://blog.hipchat.com/2012/10/26/performance-tuning-ios-making-mobile-fast/ see point 1 on this page though
[00:25] <rick_h> hatch: yes, but a HEAD request isn't 1.5s, or 3s
[00:25] <rick_h> that was the time for his api request. Which was latency + time to build response + time to transfer the actual payload + latency again
[00:27] <hatch> 755ms ping time
[00:27] <hatch> 62ms ping time
[00:27] <hatch> i'll try once more
[00:27] <hatch> 140ms ping time
[00:27] <rick_h> yea, that's a *little* variance
[00:28] <rick_h> so 62ms ping time means a check for an updated file if the etag is expired (only after the TTL is already passed anyway) is 130ms round trip
[00:28] <rick_h> 140, it's 1/4 of a second round trip
[00:28] <rick_h> now, if it's 755, then right...you just wasted a second and a half
[00:28] <hatch> 655ms
[00:28] <hatch> they are all over the map
[00:29] <hatch> so the 'perfect' world would have every file with a hash type name, next step would be hashed js/css and then etagged images, next would be etagged everything, next (far behind) no cache headers
[00:29] <hatch> :D
[00:31] <hatch> ncie fix btw :D
[00:31] <rick_h> heh, somehow I screwed up removing the pressed version and got rid of the original version :/
[00:31] <rick_h> and a make devel didn't rebuild the sprite so didn't notice :(
[00:32] <rick_h> thanks for the catch now 
[00:33] <hatch> well it was pretty hard to miss when I pulled in trunk and was qa'ing my latest branch haha
[00:33] <hatch> I was like 'how did I break that??'
[00:34] <rick_h> ugh, was that kind of day I guess. Finished with a bang
[00:34] <hatch> check this out http://www.docker.io/
[00:34] <rick_h> yea, been there done that. api wrapper over lxc containers yay
[00:34] <hatch> that's what I was thinking it was
[00:34] <rick_h> I'd rather fix lxc container api and use juju on it
[00:35] <rick_h> but it's getting a lot of attention even from people inside canonical
[00:35] <rick_h> but all the mac-heads that <3 it hate it can't run on their machines since they don't have lxc
[00:35] <hatch> haha
[00:36] <hatch> so once the lxc api is fixed in juju then this won't be necessary any longer?
[00:36] <hatch> if I'm understanding it correctly
[00:36] <rick_h> no, the lxc api is part 1
[00:36] <rick_h> automating installs and bit is part 2 and that's juju
[00:37] <hatch> hehe ""Mac, Windows and some Linux distributions cannot natively run Docker at this time so we help you setup a Ubuntu virtual machine and run Docker inside of that.""
[10:45] <antdillon> I have added a new branch does anyone have a min to review? lp:~ya-bo-ng/juju-gui/inspector-icons
[13:04] <abentley> rick_h: So, it looks like the charm store still hasn't updated cs:~pavel-pachkovskij/precise/rack to revision 5.  Have you been in touch with anyone about it?
[13:12] <rick_h> abentley: hazmat ping'd me back in irc saying it's "out of devs hands" so I need to figure out who in IS runs it I guess and go from there? I think basically it's hung up on the uncommit or what not and not updating at this point. 
[13:14] <abentley> rick_h: Yes, that sounds right.  I bet the logs will show that the update is failing because the store branch's tip isn't an ancestor of launchpad's branch's tip.
[13:15] <bac> abentley: i see you have a card in review but can't find the MP.  is it there?
[13:16] <abentley> bac: It's this, but why do you ask? https://code.launchpad.net/~abentley/charmworld/separate-qa/+merge/178841
[13:16] <bac> abentley: b/c i assumed you needed a review
[13:16] <hazmat> rick_h, mthaddon had it last i asked about an upgrade
[13:16] <adeuring> abentley: could you take another look at https://code.launchpad.net/~adeuring/charmworld/etag-for-charm-api-view/+merge/178792 ?
[13:17] <hazmat> rick_h, but its probably in a pool rotation
[13:17] <bac> abentley: i see you don't.  move your card?
[13:17] <hazmat> rick_h, rt basically.. the charm you mentioned was published last i looked
[13:17] <rick_h> hazmat: ah ok cool. Strange one. 
[13:17] <abentley> bac: Sure.
[13:18] <abentley> adeuring: sure.
[13:18] <rick_h> hazmat: https://store.juju.ubuntu.com/charm-info?charms=cs:~pavel-pachkovskij/precise/rack should be r5 
[13:19] <rick_h> hazmat: so guessing it's not getting processed by the store code because of the strange bzr path. The user hasn't come back on irc so I've not verified he did uncommit and why. 
[13:23] <abentley> rick_h, hazmat: I'm comfortable asserting that whatever he did looks like an uncommit, and we need to ensure we handle them correctly.
[13:24] <abentley> adeuring: r=me
[13:24] <hazmat> i'm poking at the branch to understand it better
[13:24] <adeuring> abentley: thanks
[13:25] <hazmat> the store won't look at a charm again till its changed, its doing a fresh checkout when branchtips spells the change for it, there are errors it tracks but their not exposed unfortunately
[13:25] <hazmat> though they are stored in mongo
[13:28] <abentley> hazmat: If you do "bzr log -r revid:pavel.pachkovskij@altoros.com-20130301074156-vkto1nnhg3pujiyq lp:~pavel-pachkovskij/charms/precise/rack/trunk" you'll see that the revision is recorded in the branch.  But if you do "bzr log lp:~pavel-pachkovskij/charms/precise/rack/trunk" you'll see that revision isn't part of the branch's current revision history.
[13:28] <hazmat> abentley, right, but the charm store doesn't care about valid past revid.. still investigating, but in middle of meeting, eta 10m
[13:28] <abentley> hazmat: In fact, it looks like he started from scratch.
[13:29] <frankban> hazmat: hey, I need to implement an API version of env.deploy() to be used in the guiserver.  Is there a reason for the GoEnvironemnt.deploy() in the deployer not using the API?  If so, perhaps I will use a subclass. If not, it seems quite easy to me to implement the method.
[13:29] <hazmat> frankban, yeah.. no local charm support, which is a major use case for deployer
[13:29] <abentley> hazmat: I don't know if the charm store is doing update or pull, but my guess is it's not doing --overwrite, to ensure it always gets the branch tip even in this sitation.
[13:29] <hazmat> abentley, its doing a fresh checkout every time
[13:29] <frankban> hazmat: ack, so I'll just use a subclass for the guiserver
[13:30] <abentley> hazmat: Then I guess the cause is something to do with the store itself.
[13:34] <abentley> hazmat: re: "the store won't look a charm again until its changed", new revisions were added today, yesterday, the day before yesterday.
[13:35] <hazmat> abentley, yeah.. looks its a store issue what exactly i don't know
[13:35] <hazmat> abentley, incidentally charmworld should be passing in a since last date to getBranchTips
[13:35] <hazmat> abentley, just verified getBranchTips has the correct/latest output
[13:36] <abentley> hazmat: How would passing since into getBranchTips help us?
[13:48] <hazmat> abentley, less processing of redundant data, less load on lp
[13:49] <hazmat> ie instead of fetching 1k every time, it fetches what's actually changed, so typically 10 a or less day at our current rate.
[13:50] <abentley> hazmat: I don't think the load on lp to query all branches vs recently-modified branches is significant, and we want to use other means to determine what's redundant.
[13:50] <hazmat> abentley, yes, we've evolved redundant code, that doesn't make it good, or make fetching only what's changed bad.
[13:54] <abentley> hazmat: If we made the change naively, it would be bad because it would cause us to falsely mark branches as deleted that were not.  If it were done carefully, it would be more work, and without equivalent benefits, that's bad too.
[13:54] <abentley> I wasn't talking about redundant code.
[13:55] <hazmat> abentley, so how does deletion work, its based on presence in the getBranchTips output?
[13:56] <abentley> hazmat: Yes, we compare the mongodb content with the getBranchTips output, and anything in mongo not in the getBranchTips output is considered deleted.
[14:00] <hazmat> ic, except its never actually deleted from the store
[14:01] <adeuring> abentley: can you remember the reason why you removed the parameter http_cache from the .ini file? Adding them again would be a cheap way to add caching again for most of charmworld
[14:01] <adeuring> (it's r123)
[14:03] <abentley> adeuring: I believe the problem is that you get over-caching, because it doesn't vary on user.  If you add Vary: cookie, then the Google Analytics cookies break the caching.
[14:03] <adeuring> abentley: ok. so, adding etags to affected views still makes sense.
[14:05] <hatch> gary_poster: good afternoon :)
[14:05] <gary_poster> hey hatch :-)
[14:06] <gary_poster> hey frankban.  I had a good conversation with noodles about deployer integration.  you probably have thoughts as well.  Maybe we can squeeze in a quick call to coordinate later this afternoon?  maybe half hour or hour from now?
[14:06] <antdillon> gary_poster, Hi, I have some small tweaks in a branch, want me to do a mp?
[14:07] <gary_poster> antdillon, would be great.  hatch or Makyo you around to help?
[14:08] <gary_poster> or anyone in jujugui to help antdillon land the branch?  :-)
[14:08] <frankban> gary_poster: sounds good. I have a plan now indeed.
[14:08] <gary_poster> cool thanks frankban 
[14:10] <hatch> yeah I can land the branch antdillon
[14:10] <rick_h> gary_poster: I can in a bit. I'm trying to keep my head down today. antdillon can you push it up like yesterday and I'll try to pull/submit it and get it reviewed later on today?
[14:10] <rick_h> or hatch can have at it 
[14:10] <abentley> hazmat: right, the branches are marked deleted, the charms are not.
[14:10] <gary_poster> thank you rick_h or hatch.
[14:10] <hatch> don't want rick_h to forget any icons or anything this time :P
[14:11] <rick_h> hatch: :P you better handle it then 
[14:11] <hatch> lol
[14:11] <hatch> gary_poster: are you going to continue on with huws branch or would you like me to?
[14:12] <antdillon> rick_h, Its up, been up a for hours
[14:12] <antdillon> lp:~ya-bo-ng/juju-gui/inspector-icons
[14:12] <antdillon> hatch, rick_h Thank you
[14:13] <hatch> pulling
[14:13] <hatch> what's this one supposed to be doing?
[14:14] <antdillon> hatch, Added landscape icons to landscape errors in the inspector and set the width of textareas in the inspector so there is no y-scroll bar
[14:14] <antdillon> hatch, Small CSS changes
[14:14] <hatch> cool, did you check in IE?
[14:15] <antdillon> hatch, Thought you were supporting Chrome and FF?
[14:16] <hatch> http://cdn.memegenerator.net/instances/400x/19013337.jpg
[14:16] <antdillon> hatch, Lol IE6
[14:16] <hatch> haha no
[14:17] <hatch> antdillon: the icons are missing from beside the unit names in the landscape section
[14:19] <antdillon>  hatch Is there an easy was to invoke landscape errors?
[14:20] <hatch> add 100 units and wait a second the simulator will generate them pretty quick
[14:20] <hatch> or 1000 units
[14:20] <hatch> it can handle it :)
[14:22] <antdillon> hatch, Weird, there were there in the local version, might have missed an add. Hang on
[14:22] <hatch> I'm like jshint for qa - i'll hurt your feelings
[14:22] <hatch> (if you don't know what jshint/lint is that joke won't make any sense)
[14:29] <antdillon> hatch, I get it, you sue the icons are'nt there?
[14:29] <hatch> reloading, clearing cache...all that jaz
[14:29] <antdillon> hatch, Well icon (inspector-charm-landscape.png) as they both use the same
[14:30] <hatch> nope, I don't even see a style to apply them
[14:30] <hatch> style/element
[14:31] <hatch> forget to save the less file?
[14:31] <antdillon> hatch, Mmm did you get rev 930?
[14:32] <antdillon> http://bazaar.launchpad.net/~ya-bo-ng/juju-gui/inspector-icons/revision/930
[14:32] <hatch> yup 930, the background style isn't being applied....
[14:32] <hatch> second
[14:32] <hatch> oh that's right
[14:32] <hatch> this doesn't have the style set
[14:33] <hatch> antdillon: look for .status-unit-content
[14:33] <hatch> it's missing the landscape ones
[14:36] <antdillon> hatch, Odd there in the diff
[14:36] <hatch> no it's not
[14:36] <hatch> unless we are looking at two totally separate branches haha
[14:36] <hatch> you added two classes both of which are under .status-unit-header
[14:37] <antdillon> hatch, Here is the changes, is this the branch you are pulling? http://bazaar.launchpad.net/~ya-bo-ng/juju-gui/inspector-icons/revision/930
[14:38] <hatch> lol does your diff really show new classes under .status-unit-content or are you just messing with me? :)
[14:40] <antdillon> hatch, Totally does, do you not see them on launchpad?
[14:40] <hatch> thats so weird
[14:40] <hatch> they are definitely not there
[14:41] <hatch> there is only a 10line diff
[14:42] <hatch> antdillon: https://www.evernote.com/shard/s219/sh/45e433c8-7a8b-426a-afe0-aadbf0ba5f57/78a8e174510f9b91138e1753ece8871b/res/be3c1c1a-2abe-4ab8-9eff-0e0b8232c007/skitch.png
[14:42] <antdillon> hatch, I'll push a white space change and push again
[14:43] <antdillon> hatch, They are there, .status-unit-header.landscape-needs-reboot and .status-unit-header.landscape-security-upgrades
[14:44] <hatch> hatch: antdillon: look for .status-unit-content
[14:44] <hatch> :)
[14:44] <hatch> http://bazaar.launchpad.net/~ya-bo-ng/juju-gui/inspector-icons/view/head:/lib/views/juju-inspector.less#L748
[14:44] <antdillon> hatch, Ah ...
[14:44] <antdillon> hatch, My bad, sorry doing 3 things at once
[14:44] <hatch> now u owe me a beer
[14:44] <hatch> lol
[14:47] <antdillon> hatch, Yes I do! fix it there
[14:47] <antdillon> hatch, Sorry about that
[14:47] <bcsaller> still need one more review on, https://codereview.appspot.com/12323043/ rick_h you looked at this before, maybe you have time to check again?
[14:47] <hatch> antdillon: haha np
[14:48] <hatch> make devel
[14:48] <hatch> ahh crap
[14:48] <rick_h> bcsaller: sure thing
[14:48] <bcsaller> thanks
[14:48] <gary_poster> hatch, devel is made
[14:48] <hatch> thanks bot gary
[14:48] <hatch> :)
[14:48] <gary_poster> :-)
[14:48] <gary_poster> frankban, you available for guichat for a sec?
[14:49] <frankban> gary_poster: sure, joining
[14:51] <teknico> guihelp: today I'm seeing these selenium errors when running functional tests in charm trunk, yesterday they were ok, did anything related change in the gui code recently? http://pastebin.ubuntu.com/5959156/
[14:52] <antdillon> hatch, Sorry man, 932 is my last touch
[14:53] <hatch> antdillon:  :) qaing now
[14:53] <hatch> antdillon: do you have IE10?
[14:54] <antdillon> hatch, Not on this machine, I'll sign up for browserstack again
[14:54] <hatch> antdillon: it's ok I'll spin up a vm
[15:00] <rick_h> bcsaller: did this update then handle the type=checkbox?
[15:01] <bcsaller> rick_h: no, but afaik that still isn't fixed
[15:01] <rick_h> bcsaller: ok, so this will have to be revisited and updated once the bug is corrected? And test cases added to help make sure we don't break checkbox suport then?
[15:03] <bcsaller> yes, but I'm not sure what the UX should even be for checkboxes, "True/False", "Yes/No"?  Maybe the conflict icon alone implies that the other state is selected
[15:03] <hatch> wasn't it my branch that broke the checkbox support?
[15:03] <hatch> which was then fixed?
[15:03] <bcsaller> hatch: was it? I'll check again
[15:04] <hatch> gary_poster: DD in IE is working today....I'd like to take credit but.....
[15:04] <rick_h>  bcsaller ok, I'm LGTM'ing but it feels like it's incomplete with known issues hanging around. 
[15:04] <rick_h> bcsaller: I don't want to keep holding things up.
[15:04] <hatch> antdillon: looks good thanks
[15:05] <rick_h> bcsaller: if we need UX guidence maybe we can send an email for now to the -peeps list and get some feedback when the UX folks get back from IoM
[15:05] <bcsaller> rick_h: yeah
[15:06] <bcsaller> hatch: I still see an input for debug on mediawiki, with trunk merged
[15:06] <bcsaller> hatch: still works in ghost though
[15:06] <hatch> bcsaller: ohh ok, so my branch had it broken in the ghost
[15:06] <antdillon> hatch, Sorry for messing with ya, testing your link brain. Thanks
[15:06] <hatch> thanks
[15:06] <hatch> antdillon: haha np
[15:06] <antdillon> lint*
[15:07] <hatch> antdillon: what do you dev on?
[15:08] <hatch> bcsaller: rick_h we should create a ticket/card to followup about that checkbox issue because that will hold up releasing
[15:08] <antdillon> hatch, As in OS?
[15:08] <rick_h> hatch: I thoght there was already a bug and in my review I asked that it get updated to note this code tie-in. 
[15:09] <hatch> antdillon: yeah
[15:09] <rick_h> hatch: bcsaller #1207870
[15:09] <_mup_> Bug #1207870: Boolean values aren't checkboxes on deployed services <juju-gui:Triaged> <https://launchpad.net/bugs/1207870>
[15:09] <antdillon> hatch, Ubuntu ... of course
[15:09] <bcsaller> thanks
[15:10] <gary_poster> hatch, lol, ok, I'll share.  thx
[15:10] <hatch> antdillon: http://www.modern.ie/en-us/virtualization-tools#downloads this might help ya
[15:11] <antdillon> hatch, Awesome thanks
[15:12] <hatch> jujugui looking for a single very quick review for ants branch https://codereview.appspot.com/12602044/patch/1/1002
[15:13] <benji> hatch: I'll take a look
[15:14] <benji> hatch: LGTM
[15:16] <hatch> thanks ben-jai
[15:17] <hatch> I decided how I want to pronounce abel too with a long a like apple
[15:17] <hatch> not sure if that's right though :D
[15:18] <hatch> gary_poster: I'd still lke to leave the DD card and ticket for now, just because it's odd that it works all of a sudden
[15:20] <hatch> jujugui looking for one more review and QA of https://codereview.appspot.com/12567043/
[15:20] <Makyo> jujugui call in 10, kanban now
[15:20]  * hatch thinks Makyo has a macro for that now
[15:20] <Makyo> Seriously considering it.  Mostly it's just the alerts on my phone :)
[15:22] <teknico> guihelp: can someone please run the functional tests in charm trunk? "make ftest" they're broken for me: http://pastebin.ubuntu.com/5959156/
[15:23] <teknico> gary_poster: ^^
[15:26] <gary_poster> hatch +1
[15:27] <bac> teknico: running them
[15:27] <teknico> bac: thank you
[15:27] <gary_poster> teknico, ack
[15:28] <Makyo> jujugui call in 2
[15:29] <hatch> I see the mutany is live and well
[15:41] <bac> teknico: i got 1 error
[15:41] <teknico> bac: pastebin?
[15:42] <hatch> bcsaller: you broke CI ....mohohahahaha
[15:42] <bcsaller> me?
[15:43] <hatch> yeah looks like a failure in IE
[15:44] <hatch> does anyone here use zsh in their terminal?
[15:44] <rick_h> hatch: yes!!!
[15:44] <hatch> I figured you would be against it
[15:44] <hatch> lol
[15:44] <rick_h> against it? I preach it!
[15:45] <hatch> WELL THEN!
[15:45] <rick_h> https://github.com/mitechie/zshrc for my lightning talk material and 'starter' config I hand out :)
[15:45] <hatch> http://remysharp.com/2013/07/25/my-terminal-setup
[15:46] <rick_h> not a 2-line prompt fan myself, but ok
[15:46] <bac> teknico: i'll run again and capture the output.  my problems looked more environmental, the tests didn't start, installation problems.
[15:46] <hatch> rick_h: I haven't been either but I have found instances where it would be nice
[15:46] <rick_h> 15pt font?! I only run 10 or less on anything
[15:46] <hatch> I coudln't read that on my monitor lol
[15:46] <hatch> my laptop uses 10pt though
[15:46] <rick_h> I was bummed when I moved from 8pt to 10pt :/
[15:47] <hatch> I think my desktop is 14ish
[15:47] <hatch> lemme see
[15:47] <rick_h> desktop is 10, laptop is 8
[15:47] <hatch> oh I lied
[15:47] <hatch> it's 12pt
[15:47] <hatch> laptop 10, desktop 12
[15:47] <rick_h> anyway, zsh ftw. Pipe aliases, better vim mode, and rm **/*.pyc ftw
[15:48] <hatch> when I work in git it shows me the branch and status in my PS1
[15:48] <rick_h> yea, does that in bzr, git, hg
[15:48] <hatch> but it gets pretty long
[15:48] <hatch> so that's why I was entertaining the idea of a 2 liner
[15:48] <rick_h> I go short. I just use branch name
[15:49] <rick_h> I don't need to know how many changes/etc
[15:49] <hatch> do you display the full path name in it?
[15:49] <rick_h> no, only the last directory
[15:49] <hatch> ohh ok I show the full path
[15:50] <rick_h> [fix-zoom-sprite:929//juju-gui I ] for instance from last night. [branch:revno//dirname insert_mode ]
[15:50] <hatch> ahh that's nice
[15:50] <hatch> some people claim zsh is slow
[15:50] <hatch> I didn't buy it
[15:50] <rick_h> so the only perf issue is across nfs shares for some reason
[15:51] <rick_h> and if you run custom functions that are slow. 
[15:51] <hatch> bcsaller: lemme know when you wana have that chat
[15:51] <rick_h> but it's dead simple to write your own completion functions which is nice
[15:51] <hatch> ahh yeah
[15:51] <hatch> nfs shares are slow period, I just ssh into now haha
[15:51] <hatch> and use rsync
[15:51] <rick_h> zsh tab complete wins all
[15:52] <bcsaller> hatch: after the next call I can look into it with you
[15:52] <hatch> I've been trying to go more and more terminal based but on the IDE front Webstorm is looking pretty good
[15:52] <hatch> gary_poster: do we have the call in 8mins?
[15:52] <gary_poster> hatch yes
[15:52] <gary_poster> sinzui, the jujucharm redirects appear to all be gone :-(
[15:54]  * Makyo looks over rick_h's zsh stuff.  The extension aliases are cool; currently has 'alias jfdi="xdg-open"' for some of that.
[16:00] <rick_h> Makyo: yea I mainly <3 the pipe aliases. cat file.txt G word
[16:00] <rick_h> or cat file.txt L
[16:01] <rick_h> autopushd, better history sync
[16:01]  * sinzui asks webops
[16:02] <Makyo> Yeah!
[16:03] <abentley> benji: So, the apache2 charm's JSON is 15K or 3K gzipped.
[16:04] <benji> abentley: interesting
[16:05] <sinzui> gary_poster, recheck and confirm?
[16:05] <sinzui> Before I could complete my request It appears that have started working for me
[16:05] <gary_poster> sinzui, https://jujucharms.com/charms/precise/wordpress-HEAD/ not working for me
[16:05] <sinzui> it was definitely broken a few minutes for me
[16:06] <sinzui> the short works, the long does not
[16:06] <sinzui> I wonder if the redirect rules were reverted with the charm release
[16:06] <Makyo> jcsackett, is there a rv link for your branch?
[16:06] <sinzui> gary_poster, does https://jujucharms.com/charms/precise/wordpress
[16:06] <sinzui> work
[16:06] <Makyo> May have lost it in scrollback.
[16:07] <gary_poster> sinzui, yes.  
[16:08] <sinzui> https://jujucharms.com/charms/precise/juju-gui just worked for me too
[16:08] <sinzui> Nice looking page too
[16:27] <bcsaller> hatch: you want to do that call now/soon?
[16:27] <hatch> yeah now is good
[16:27] <hatch> back in guichat
[16:45] <frankban> bcsaller: I am not sure I will be able to submit the last MinUnits branch today. Anyway, here is the new API call signature: http://pastebin.ubuntu.com/5959504/ . I expect that to land tomorrow.
[16:45] <bcsaller> frankban: thank you 
[16:48] <frankban> bcsaller: mp, here is a python script I used to test the functionality: http://pastebin.ubuntu.com/5959514/
[16:53] <sinzui> gary_poster, the rule to redirect was for the long URL to the short URL. eg, /charms/ is dropped the from the url if it exists and the charm does not have a version. The example URL you have contains old-style  roots and the version hack to satisfy the GUI. That URL only exists if someone URL hacks
[17:01] <rick_h> yay, my sprint t-shirts arrived! just in time for me to wear them over this Google Chrome dust-up!
[17:02] <rick_h> thanks jcsackett :)
[17:03] <abentley> benji: I'm up for more chat if you are.
[17:04] <benji> abentley: I'm about half way through lunch so I'll ping you in 30
[17:04] <abentley> benji: Cool.
[17:06] <jcsackett> Makyo: sorry, no, i never posted. and was out to lunch. :-P https://codereview.appspot.com/12608043/
[17:34] <hatch> bcsaller: in these tests 'this.ws' in python.js should be conn (new utils.socketstub) right?
[17:35] <hatch> looks that way
[17:35] <bcsaller> hatch: I believe so, I always have to check that as well 
[17:36] <hatch> it's like one of those roads which changes names as you drive down it
[17:36] <hatch> :)
[17:37] <hatch> I forgot env.connect()
[17:39] <benji> abentley: guichat is open
[17:59] <benji> abentley: this illustrates how I was suggesting using itertools.groupby: http://paste.ubuntu.com/5959750/
[18:06] <abentley> benji: The other place "featured" is used is the page where you can set it for a charm.  I forgot to mention that.
[18:07] <benji> ok, that should be easy to deal with
[18:17]  * Makyo zooms to coffee shop to give dogs alonetime.
[19:17] <hatch> sooo hows everyones afternoon
[19:26] <hatch> jujugui looking for two quick reviews on https://codereview.appspot.com/12623043/ plz and thx
[19:27] <jcsackett> hatch: sure.
[19:28] <hatch> thanks
[19:28] <hatch> added to board
[19:28] <hatch> anyone else......onee more for the points?
[19:29] <hatch> jcsackett: did you need another review on your branch? I see only Makyo on the tag
[19:29] <jcsackett> hatch: rick got it as well; i've just not been able to lbox it away yet. :-)
[19:29] <hatch> ok added him to the board
[19:30] <hatch> sauce labs videos are broken?
[19:32] <hatch> boo urns
[19:39] <hatch> bcsaller: the CI is failing because the two Inspector Conflict UX tests are timing out
[19:39] <hatch> would you like me to investigate or do you want it?
[19:43] <hatch> ahh it doesn't appear valueChange is firing
[19:46] <hatch> I seem to remember writing about that somewhere
[19:47] <hatch> bcsaller: probably related https://github.com/yui/yui3/issues/489 and my workaround http://jsbin.com/azohuq/2/edit I'll see if this solves the issue here as well
[19:49] <bcsaller> fun stuff :(
[19:50] <hatch> although we are running an old version of YUI
[19:50] <hatch> where this might be resolved...
[19:50] <hatch> I'll try upgrading that
[19:53] <hatch> ok who wants to bet this will 'just work'
[19:54] <hatch> any takers? ;)
[19:54] <bcsaller> it should work
[19:56] <hatch> holy smokes
[19:56] <hatch> no errors
[19:56] <hatch> with the exception of the 'expose bug' that was already there
[19:59] <hatch> one test failure
[20:01] <hatch> hmm except the test action works fine in the real world
[20:10] <abentley> benji: I've had more thoughts about versioning and elasticsearch.  Do you have a minute to chat?
[20:10] <benji> abentley: sure, guichat is open
[20:14] <Makyo> jujugui can I get a quick gut-check on the direction I'm heading with deltas in go-sandbox?  Just want to make sure I'm not totally nuts.  WIP, not a real review.  https://codereview.appspot.com/12596044/diff/1/app/store/env/sandbox.js
[20:15] <bcsaller> Makyo: looking
[20:16] <Makyo> bcsaller, thanks
[20:19] <bcsaller> Makyo: how did we end up with 'currentNextRequestId', funny name :)
[20:20] <Makyo> bcsaller, haha, yeah.  It's the current RequestId for the Next RPC call.
[20:21] <bcsaller> Makyo: yeah, it could be nextRequestId though, or currentRequestId, or something, its the both that got me
[20:21] <Makyo> bcsaller, Yeah, that's fine
[20:22] <bcsaller> Makyo: the code for sendDelta and all that looks about the same, shouldn't that be moved to a common prototype rather than duplicated or am I reading the diff wrong?
[20:24] <bcsaller> the delta interval handling, etc, looks like they have more in common than not. I expect up to the perform_xxx methods they are more alike than different
[20:24] <Makyo> bcsaller, The delta object is different, but much of it can be moved out, I think, so long as the correct _getDeltaAttrs  object is called and it builds the correct data.
[20:25] <Makyo> so much of that can be abstracted.
[20:25] <bcsaller> that sounds good
[20:25] <Makyo> sendDelta should be just building a list of deltas, the internals of which are determined from getDeltaAttrs.
[20:27] <bcsaller> looks like getDeltaAttrs is even the same, just driven off a different table
[20:28] <hatch> bcsaller: when you're done with Makyo I'd like to pick your brain a sec about these keybindings
[20:29] <bcsaller> but to answer your main question, with more code reuse, yes, this looks good. I expect the structural differences are minimal, only the wire data (and the fact that GoJu needs an additional stream) seem to change. I like that
[20:32] <Makyo> bcsaller, cool, thanks. 
[20:32] <bcsaller> hatch: yeah, did you want to chat?
[20:32] <hatch> yeah real quick hangout....umm lemme fire one up
[20:33] <bcsaller> yeah, saw it was full
[20:33] <hatch> ring ring
[20:45] <hatch> bcsaller: what the..... https://github.com/yui/yui3/blob/v3.9.1/src/transition/js/transition-native.js
[20:45] <hatch> it's identical
[20:47] <hatch> so I have no idea how this worked in the first place....
[20:54] <hatch> bcsaller: unfortunately the simulate bug is not fixed in YUI 3.11 :(
[20:55] <hatch> I'ma propose this update anyways
[20:56] <bcsaller> better to have than not
[21:05] <hatch> jujugui update to yui 3.11 https://codereview.appspot.com/12627043 looking for two thorough QA's plz
[21:06] <hatch> also looking for one more review here https://codereview.appspot.com/12623043/
[21:38] <hatch> good evening gary_poster
[21:59] <hatch> jcsackett: you around?
[21:59] <jcsackett> for various definitions of around.
[21:59] <hatch> Unable to obtain lock  held by jcsackett@bazaar.launchpad.net on taotie (process #13696), acquired 13 seconds ago.
[21:59] <_mup_> Bug #13696: White border appears around kwifimanager system tray icon <kdenetwork (Ubuntu):Fix Released by kubuntu-members> <https://launchpad.net/bugs/13696>
[21:59] <hatch> when I tried to merge
[21:59] <hatch> er submit
[21:59] <jcsackett> hatch: huh.
[21:59] <hatch> yeah right?
[22:00] <jcsackett> my submit finished; there shouldn't be a lock.
[22:00] <hatch> I'll try again
[22:00] <jcsackett> hatch: you can also bzr break-lock
[22:00] <hatch> is it safe to do that? heh
[22:01] <jcsackett> it should be; i can't think of any reason i would have a lock.
[22:01] <jcsackett> hatch: i have no pending bzr operations running.
[22:01] <jcsackett> 13 seconds feels suspect...
[22:02] <hatch> well I'll see what happens
[22:02] <hatch> this time
[22:02] <hatch> but as long as you aren't running anything then I'll break the lock if it happens again
[22:05] <jcsackett> ok..
[22:05] <jcsackett> i'll postpone my EoD a bit out of curiosity.
[22:06] <hatch> sorry my lboxing is slow
[22:06] <hatch> :)
[22:08] <hatch> jcsackett: all good now
[22:08] <jcsackett> hatch: good stuff.
[22:08] <hatch> enjoy your eod
[22:08] <hatch> :)
[22:13] <jcsackett> later. :-)
[22:26] <hatch> bcsaller: will you approve     if (Y.UA.ie [22:26] <hatch> else simulate will need to be properly patched....which looks like a lot of work for the valuechange event
[22:28] <hatch> I also need to do it to get the ghost test that relies on the valuechange event to work
[22:42] <gary_poster> hey hatch, could you help Huw out with a re-review of https://codereview.appspot.com/12506044/ ?
[22:43] <hatch> on it
[22:43] <gary_poster> jujugui (Makyo, bcsaller?) could one of you review Francesco's charm branch please?  https://codereview.appspot.com/12612043/
[22:43] <gary_poster> Nicola can provide the other one tomorrow morning
[22:43] <gary_poster> Thanks, hatch!
[22:43] <hatch> gary_poster: if you're looking for some late night testing fun you could QA this branch :) https://codereview.appspot.com/12627043/
[22:44] <gary_poster> hatch, I saw that, awesome!  I would like to, but about to have a call with fam now before bed.  Just worked through 300-some-odd emails :-P
[22:45] <hatch> haha, it's ok it requires a pretty deep QA :)
[22:45] <gary_poster> I figured :-)
[22:45] <hatch> I also have a really huge hack to get CI back up and running if (Y.UA.ie [22:46] <hatch> https://github.com/yui/yui3/issues/489
[22:46] <hatch> unfortunately the workaround doesn't work for the 'special' valuechange event :/
[22:48] <gary_poster> hatch, ugh.  So...ugh. You'd just disable the one test?
[22:48] <hatch> 3 tests
[22:48] <gary_poster> :-/
[22:48] <hatch> I looked at the yui simulate code and it looks like it'll be a large amount of work
[22:49] <gary_poster> ack hatch.  did you at least file it additionally?  issue 489 doesn't mention valuechange
[22:49] <gary_poster> hatch, fwiw under circumstances I am OK with it
[22:49] <hatch> I haven't - I'll file another once I have some free time to make a repro
[22:50] <hatch> 5mo old and still no fix though....that's not very nice
[22:50] <gary_poster> :-/
[22:59] <hatch> gary_poster: reviewed and qa'd huws branch found one qa issue that can probably be pushed
[23:00]  * Makyo runs home, will look at charm branch there.
[23:00] <hatch> cya Makyo
[23:02] <huwshimi> Morning
[23:04] <hatch> morning huwshimi
[23:09] <gary_poster> hey huwshimi.  I'm about to go to bed.  Look forward to talking to you later today.  Does my comment about the side panel make sense?
[23:09] <huwshimi> gary_poster: Hey, was just replying :)
[23:09] <huwshimi> gary_poster: "Inspector charm details must be the same size as the inspector panel. (think drawer)"
[23:09] <huwshimi> gary_poster: I thought that comment meant they should always be the same height?
[23:10] <huwshimi> (A drawer is never bigger than the chest it is in)
[23:10] <gary_poster> huwshimi, it sounds like my brain wrote down what I secretly thought and not what Luca and Jaime actually told me ;-) sorry!!  is it a quick fix?
[23:11] <huwshimi> gary_poster: I can just revert my change. You want the side panel to be a fixed height (full height of the page)?
[23:13] <huwshimi> page/screen
[23:15] <hatch> huwshimi: haven't you ever seen that movie where the kids go into the closet and go into a new world?
[23:15] <hatch> he meant that kinda drawer :D
[23:15] <huwshimi> :)
[23:17] <hatch> narnia
[23:17] <hatch> that's the one
[23:56] <hatch> jujugui could I get a quick review to get CI back up and running https://codereview.appspot.com/12620044
[23:57] <bcsaller> checking
[23:57] <hatch> thanks