[00:01] <huwshimi> rick_h: NP, hard work all round. Nice to finally have it released!
[00:29] <hatch> morning
[00:30] <hatch> I haven't had anyone rage tweet me yet about a bug so it must be working well ;)
[00:31] <huwshimi> hatch: I broke something, but I can't reproduce it
[00:31] <hatch> well then that's someone elses problem isn't it? :P
[00:31] <huwshimi> hatch: And someone said they went to "view all notifications" and there's no way out
[00:31] <huwshimi> out/back
[00:32] <hatch> hmm there is DEFINITELY a bug there....but the backbutton and hitting the juju link both work to get out
[00:36] <huwshimi> Ah right
[00:47] <Makyo> I saw a 'It takes too long to load' tweet, but that's bout it.
[00:48] <hatch> yeah - that was probably part of the 250http requests it was making lol
[00:49] <Makyo> It's a request per image in any photo site, we just delay all that :)
[00:51] <hatch> no the js wasn't being rolled up
[00:51] <hatch> :)
[00:52] <hatch> latest blog post http://fromanegg.com/post/56193994218/juju-gui-v0-8-and-jujucharms-com-released
[00:52] <Makyo> Ohhh
[00:52] <Makyo> Rock on.
[00:52] <Makyo> I did tweets, and I redid the screencast today with my mic.
[00:53] <hatch> oh awesome!
[00:53] <hatch> where is the link to the vid I'll add it to the post
[00:53] <Makyo> I lost everything in a few catastrophic crashes, so the end result is still rougher than I'd like, but hey, marketing materials.
[00:54] <hatch> aww boo!
[00:54] <Makyo> It will be at https://www.youtube.com/watch?v=W3RDt3YpikM Still processing.
[00:54] <Makyo> Just a few verbal stumbles, no sound problems.
[00:54] <hatch> ahh well those happen
[00:55] <hatch> thanks I'll be sure to embed as soon as it's up
[00:55] <hatch> does it give you an eta? I've never uploaded a video before
[00:55] <Makyo> Only on uploads, not on processing.
[00:56] <Makyo> Can preview here, I guess: http://ubuntuone.com/5EjNP5D50mRe2PxXa9yhl6 But that's the full HD video.
[00:56] <hazmat> couple of oddities on jujucharms.com
[00:56] <hatch> no thanks
[00:56] <hatch> :)
[00:56] <hatch> hey hazmat, what did you run into?
[00:57] <hazmat> hatch, jujucharms.com, search for log, click logstash-agent, click interface get a redirect, looks like some oddity around the icon fetching
[00:58] <hazmat> hatch, doing a full reload on the logstash-agent page and the interface 'tab' loads fine
[00:58] <hatch> yeah then the browser appears to think it's in the logstash charm
[00:59] <hatch> hazmat: ok I see what the issue is....I think
[00:59] <hatch> trying to repro
[01:01] <hatch> yeah it looks like there is a error which is causing the click handler to not 'prevent default'
[01:01] <hazmat> i can get some other ones where the main content well grays out
[01:01] <hazmat> but navigation works
[01:01] <hatch> yeah this is an odd one
[01:02] <hatch> at least it's repro-able so we should be able to track it down
[01:02] <hatch> can I impose on you to file a bug? :)
[01:03] <hazmat> sure
[01:03] <hatch> thanks :)
[01:18] <rick_h> hazmat in chrome?
[01:18] <rick_h> there's a known routing bug that changes the url and causes a redispatch in chrome
[01:25] <hazmat> rick_h, in chrome
[01:26] <hazmat> er. chromium
[02:00] <Makyo> hatch, gave you the wrong URL: http://www.youtube.com/watch?v=V2H3fat0K5w
[02:07] <rick_h> hatch: yea, wild day today :)
[02:23] <rick_h> Makyo: much better sounding
[02:24] <rick_h> Makyo: remind me next sprint. I've got a 2 port USB audio box and a trio of condenser mics and pop filters for when we did interviews at OLF and PyCon
[02:24] <Makyo> rick_h, Yeah, the difference between the mic under the keyboard and anything external is impressive :P
[02:25] <Makyo> rick_h, Oh?  Rock on :D My mic's a bit big to bring traveling, but I do have a portable Tascam.  The mics might be better, since it's not a separate device, don't have to fool around with kdenlive to sync things.
[02:25] <rick_h> actually have an 8-port M-Audio but only works under windows/mac so it's only ran once :(
[02:25] <rick_h> Makyo: yea, I got a series of stuff for doing traveling interviews. Table top mic stands, etc
[02:25] <Makyo> Awesome :D
[02:26] <rick_h> heh, I could watch this all day :)
[02:27] <rick_h> check out how fast that search is :P
[02:29] <rick_h> lol, nice closing Makyo 
[02:29] <rick_h> 'adds a bit of charm on the top"
[02:30] <Makyo> Hah, yeah, figured something cute to close it out :)
[03:36] <hatch> Makyo: yes...yes you did
[03:36] <hatch> :)
[03:36] <Makyo> ?
[03:36] <hatch> re url
[03:36] <Makyo> YT created two links, one is still dead :/  At least we still have the other!
[03:38] <hatch> post updated with video
[03:38] <hatch> you're gona be famous
[03:38] <Makyo> eFamous.
[03:38] <Makyo> iFamous
[03:39] <hatch> infamous
[03:40] <hatch> crazy Ubuntu Edge is over $3m
[12:17] <rick_h> jujugui reviews please for a hot item of getting the charm details left breakout panel working to show off (though lots of bugs in it still) https://codereview.appspot.com/11714043
[12:17] <bac> rick_h: o/
[12:17] <gary_pos`> rick_h, cool! on it
[12:17] <bac> is gary_pos` your rap name?
[12:17] <gary_pos`> lol
[12:17] <rick_h> hah!
[12:18] <benji> rick_h: I'll do the second review
[12:19] <bac> benji: i'm already doing it
[12:19] <gary_poster> I was going to do second review buit now I'll just do extra qa :-)
[12:19] <bac> didn't you see me raise my hand?
[12:19] <benji> bac: oh, I missed that; next time wave harder
[12:19] <gary_poster> benji and bac are doing the reviews! /me said happily
[12:19] <bac> i like that plan
[12:19] <bac> o//////
[12:19] <benji> heh
[12:19] <gary_poster> lol
[12:19] <rick_h> thanks guys, appreciate it. Just realize that things like the events and such in the working charm details are borked a bit. The tabs updates the url, and some links want to work a bit strangely. but it displays and loads content in a readable way
[12:20] <benji> rick_h: so hold off on reviewing?
[12:20] <bac> stand down
[12:20] <rick_h> benji: no, this is a step 
[12:20] <rick_h> please review
[12:20] <benji> k
[12:20] <gary_poster> stand up!
[12:20] <rick_h> will follow up with more clean up and such. But this reorg of the html/css needs to go forward
[12:21] <rick_h> I'm just trying to prevent a bunch of bugs getting filed after this :)
[12:21] <rick_h> and with that...time to make some coffee
[12:35] <bac> so sil wrote an indicator widget to track ubuntu edge and gustavo (i assume) put this graph together http://ubuntu-edge.info .
[12:36] <rick_h> yea, with data ...let there be visualizations
[13:12] <rick_h> benji: replying and updated branch coming. I didn't update all the CSS because honestly I indented it one left under .juju-inspector and would rather not refactor it in this branch atm.
[13:12] <rick_h> benji: and I didn't get the reference... I fail :(
[13:12] <rick_h> benji: QA go ok? or bac were you going to come back for QA?
[13:13] <benji> rick_h: that's completely understandable (the non-changes to CSS and the reference non-getting)
[13:13] <benji> rick_h: oh, I didn't QA; but I can.  Shall I?
[13:13] <rick_h> benji: appreciated. I'm going to try to run it through some more browsers to be sure but QA is appreciated
[13:14] <benji> I'll QA now.
[13:14] <bac> rick_h: actually i didn't qa as i thought gary_poster was going to.  i will now.
[13:16] <rick_h> hmm, so yea I see in FF the inspector doesn't remove on close but it does on chrome...wtf
[13:17] <rick_h> and wow FF is slow to start up
[13:24] <gary_poster> rick_h, bac, sorry, did basic qa on cherome and looked good.  didn't get farther because of calls
[13:24] <gary_poster> chrome
[13:25] <gary_poster> rick_h, nice (maybe?) quick fix would be fixing height the way we do for the inspector itself.  I think we do it wrong for ghost though
[13:25] <rick_h> FF is being very inconsistent with me. Maybe I should load a non-nightly version. 
[13:26] <bac> rick_h: so that breakout panel has no scrolling.  i assume that is known.
[13:27] <rick_h> bac: yea, just looking at that with gary here. I think I need to change that from the viewlet container to the overall container perhaps. Testing now
[13:27] <bac> cool. i'd never seen it before.  will be nice.
[13:27] <bac> rick_h: thanks, btw, for the nice QA instructions.  i think we should strive to make that part of all MPs
[13:28] <rick_h> bac: hmm, though it would require the tab changes to re-run the calculate height on the viewlet manager somehow. 
[13:29] <bac> IANAUXD but the white panel with no border looks naked to me
[13:32] <benji> rick_h: QA-wise I can't see any problems
[13:33] <rick_h> thanks, looking to see if I can get scrolling before landing. 
[14:01] <hatch> morning
[14:03] <abentley> sinzui: I note that charmworld/6, apache2/3 and mongodb/0 all have agents down.  Reboot them?
[14:04] <abentley> Shall I reboot them?
[14:04] <sinzui> abentley, yes please :(
[14:04] <sinzui> abentley, I rebooted charmworld and mongodb yesterday or the day before to
[14:04] <sinzui> too
[14:05] <sinzui> abentley, oh, and I rebooted the basenode last week
[14:05] <sinzui> somethings is very sad in canonistack
[14:10] <abentley> sinzui: Everything is back up.
[14:11] <sinzui> :)
[14:17] <hatch> gary_poster: is there something particular you would like me on right now?
[14:18] <rick_h> gary_poster: landing the charm details branch right now. I got the scrolling working in it. So it should be 'good enough' for 'oooh pretty' demo purposes if you want to work with the guys out at OSCON on that. 
[14:18] <gary_poster> hatch, gimme one sec
[14:18] <hatch> sure np
[14:18] <gary_poster> rick_h, awesome, thanks!
[14:18] <rick_h> gary_poster: the next plan is to finish up the CSS and get autocomplete landed and then will head back to bugs/making the charm details less 'there be dragons'
[14:19] <Makyo> Will be in a little late, have to take the dogs to dog camp today, had forgotten.  Back in a little bit.
[14:19] <rick_h> Makyo: so yay that sprint work closes up a bit. 
[14:19] <rick_h> Makyo: we call it 'puppy school' :)
[14:20] <gary_poster> rick_h, sound perfect! thanks
[14:20] <Makyo> Woo!  Will push to get local charms figured out today, then.
[14:21] <rick_h> Makyo: yea, let me know if we need to chat on how we can work that out. 
[14:21] <rick_h> it's one of the big 'dragons' but figure they won't hit that in a demo
[14:25] <gary_poster> ok hatch, one silly task but great for oscon would be to make unit collections ordered, and initially closed
[14:25] <hatch> gary_poster: can do!
[14:26] <hatch> decending order by the machine number?
[14:26] <hatch> the headings are already ordered
[14:26] <gary_poster> hatch thanks.  no, I mean headings.  oh, yeah, lemme see
[14:28] <gary_poster> hatch headings don't seem to be ordered to me
[14:28] <gary_poster> hatch I go to http://comingsoon.jujucharms.com/:flags:/serviceInspector/
[14:28] <gary_poster> deploy 100 of mysql
[14:28] <hatch> checking
[14:28] <gary_poster> type cntrl-s to turn o nsimulator
[14:28] <sinzui> abentley, I am very tempted to create a view that return a charmworld heartbeat right now. If I land that, I can remove the "latest" routes you want me to move
[14:28] <gary_poster> and I see running before errors, for instance
[14:28] <sinzui> too many things to do right now
[14:29] <abentley> sinzui: That would be great.
[14:29] <hatch> gary_poster: hmm that's a regression
[14:29] <hatch> I'll look into it
[14:30] <gary_poster> thanks hatch.  next task maybe: we are getting reports of people (including our CEO) going to jujucharms.com and getting "connecting to juju environment" forever
[14:30] <gary_poster> hatch I can't dupe
[14:30] <hatch> that happens when there is a console error
[14:30] <gary_poster> hatch, possible approaches would be
[14:31] <hatch> I wonder if we can trap those somehow...
[14:31] <gary_poster> hatch that's what I thought
[14:31] <gary_poster> hatch, we could trap and then ask user to report?
[14:31] <gary_poster> via email or something lame?
[14:32] <gary_poster> capturing info for us?  Or we could send to google analyticsw?
[14:32] <hatch> yeah until we have something 'proper' set up
[14:32] <gary_poster> we have the events now
[14:32] <gary_poster> in GA
[14:32] <hatch> I'm not sure we can send that much data into analytics
[14:32] <gary_poster> so we could send arbitrary things
[14:32] <hatch> I could be wrong though
[14:32] <gary_poster> bac, was there a limit as to how much we could stasgh in the GA events?
[14:33] <gary_poster> sinzui, in a similar "respond to events before they are emergencies" approach, it would be nice to do some kind of stress testing of m.j.c sometime very soon to see if we can stomp out the 504s.
[14:34] <bac> gary_poster: i don't recall
[14:34] <gary_poster> bac, cool np
[14:34] <gary_poster> hatch, anyway, offer to email and maybe offer to reload?  very open to suggestions :-)
[14:35] <hatch> yeah I'm just not sure how to capture the error
[14:35] <hatch> well...in a way that makes sense
[14:35] <hatch> can't wrap the whole app in a try/catch :P
[14:35] <hatch> and it's a bit of work to write our own exception handler
[14:35] <gary_poster> hatch why not?  can't we do a try catch on index.html?
[14:35] <gary_poster> around Y.use?
[14:36] <hatch> I 'think' YUI captures some of these errors automatically
[14:36] <gary_poster> hatch, another approach would be to have a setTimeout loop that keeps track of progress
[14:37] <gary_poster> if we've been waiting too long then we start ofering help
[14:37] <rick_h> gary_poster: the 504s were brought up in the config change where a timeout was moved from 1s to 3s before responding with a 504. 
[14:38] <abentley> hazmat: I've replied to your comments on https://code.launchpad.net/~abentley/juju-deployer/get-flattened-deployment/+merge/175689 do any of my proposals suit you?  Or what would you like done?
[14:38] <hatch> gary_poster: that could work as a first step - but of course we would like something somehwat automated so we can get the real errors
[14:38] <gary_poster> rick_h, ack.  but does that tell us anything about root cause or remediation?  IIUC that's a band-aid not a solution
[14:39] <hazmat> abentley, i guess i'm trying to understand better the goal, you don't have any files in this context? you just have the full data structure to do resolve parents on ?
[14:39] <hazmat> abentley, is the context charmworld ingest of a bundle?
[14:39] <abentley> hazmat: Right, and right.
[14:40] <sinzui> looks like google is indexing mange.jujucharms.com again
[14:40] <hazmat> abentley, also the underlying branch for the mp  has changed significantly
[14:40] <hatch> gary_poster: first I'd probably like to try wrapping our instantiation of app in a try/catch and see if errors bubble up
[14:40] <hatch> or if they are caught lower
[14:40] <hazmat> the mp target that is
[14:40] <abentley> hazmat: I saw.
[14:41] <sinzui> jcsackett, hangout?
[14:41] <jcsackett> sinzui: already there.
[14:48] <gary_poster> hatch +1.  I think they bubble up.  I'd be tempted to wrap all of the second "startTheApp" function body in a try...catch
[14:48] <gary_poster> in index.html
[14:49] <hatch> gary_poster: yeah might as well catch everything
[14:50] <hatch> also....locally the headers sort properly
[14:50] <hatch> and it's the same revno
[14:50] <hatch> heh
[14:50] <hatch> I don't suppose coming soon can be set to devel?
[14:50] <gary_poster> hatch, huh.  maybe "running" is the only problem?  locally did you try starting with the simulator off and then turning it on?
[14:50] <benji> abentley: does this ring any bells? http://paste.ubuntu.com/5904369/
[14:50] <hatch> I didn't...
[14:50] <hatch> I'll try that
[14:51] <hazmat> abentley, commented there.. the deployment class has a bit of logic around actually validating the deployment which would  be good for a ingest as well 
[14:51] <abentley> benji: Usually means elasticsearch isn't running on your localhost.
[14:51] <hatch> rick_h: https://twitter.com/horse_js/status/359687049655238657 rofl
[14:52] <hatch> ^ gary_poster you may also find that funny
[14:52] <abentley> hazmat: Thanks.
[14:52] <gary_poster> hatch lol
[14:52] <hatch> haha
[14:53] <benji> abentley: I thought the same thing, but the process is there, it is listening on that port, and "wget -O - localhost:9200" displays a JSON document apparently generated by the server
[14:53] <hatch> gary_poster: simulator off first causes this bug - the data is sorted correctly but the UI doesn't updated appropriately
[14:53] <hatch> will investigate
[14:53] <gary_poster> cool thanks hatch
[14:56] <abentley> benji: I don't know what would cause that, then.  You could try running the exact same command at the commandline.  You can get the exact same command by running nosetests without the logging filters.
[14:58] <hatch> oh right......d3
[14:59] <hatch> I have half a mind to write a d3 wrapper that doesn't look horrendous :)
[15:01] <hatch> ok I am able to reproduce the bug with the simulator on all the time too
[15:01] <hatch> definitely a d3 thing now
[15:04] <hatch> a-hah!
[15:11] <rick_h> gary_poster: I'm definitely +1 on logging from the JS. I have done that on other projects before where the JS would file log items in the back end on errors and the like. 
[15:11] <rick_h> gary_poster: there's been talk of doing oops-tools in charmworld and maybe a JS -> oops tools would be cool
[15:11] <rick_h> gary_poster: but for a quick hack, the free tier on something like loggly might work out. There's some exising logger helper https://github.com/loggly/loggly-castor/ and http://loggly.com/support/sending-data/logging-from/application-logs/javascript/
[15:12] <rick_h> gary_poster: it does look like oops-tools does have a charm, though not used it. 
[15:13] <bac> gary_poster: sinzui has invited me to the 1330Z orange standup, which conflicts with our one-on-one.  could teknico and i trade 1:1 times?
[15:13] <rick_h> ugh, though yea that requires rabbitmq and pgsql to come along for the ride
[15:13] <hatch> rick_h: gary_poster though because this is potentially intranet software - pinging an external server might be a big nono - along the same lines as the analytics code
[15:14] <rick_h> hatch: yea :/ why oops-tools is probably the best way to go long term I guess though it makes me sad
[15:14] <hatch> I'd like to pop up an alert saying there is an issue - here is what's being sent - do you want to send....similar to how ubuntu does it now
[15:14] <hatch> at least the interactions are expected that way
[15:15] <rick_h> hmm, I was thinking a little deeper than that so that we could alert ourselves to things before they break. 
[15:15] <rick_h> it's server side and no private data involved. I don't know why we have to ask for permission to send
[15:16] <hatch> we might be talking about two different things
[15:16] <hatch> I'm tralking about js errors in the browser
[15:16] <hatch> talking*
[15:16] <rick_h> hatch: yea, why are we asking "can i send this error to a server" on a js error in the browser?
[15:16] <rick_h> It's asked in ubuntu because the data sent might contain content from your private file, etc. 
[15:17] <rick_h> we don't have any of that
[15:17] <hatch> because it'll need to contain the dataset that triggered the error
[15:17] <rick_h> if there's an error jfdi
[15:17] <hatch> simply saying 'error on line x' is pretty useless :)
[15:17] <rick_h> hatch: on all public data...
[15:17]  * gary_poster back and reading...
[15:18] <rick_h> hatch: right, but you can get a traceback and send it
[15:18] <rick_h> there's no need to stop and ask imo
[15:18] <hatch> to send any potential data in the stack you do
[15:18] <rick_h> what potential data are we afraid to send w/o permission?
[15:19] <hatch> well prettymuch anything
[15:19] <rick_h> hatch: specific please. You're using the gui on jujucharms.com and an error occurs. What data in e.stack are we afraid to send?
[15:20] <hatch> deployed charms
[15:20] <hatch> number of units
[15:20] <hatch> config.js
[15:20] <rick_h> on jujucharms.com?
[15:20] <gary_poster> rick_h, hatch, it's all potentially personal data, *but*
[15:20] <gary_poster> we can take the GA approach
[15:20] <gary_poster> that we have now
[15:20] <gary_poster> specifically
[15:20] <rick_h> how is config.js private on jujucharms.com?
[15:20] <hatch> it's not
[15:20] <hatch> but why would you build a tool simply for one usecase
[15:20] <gary_poster> we send the info
[15:21] <gary_poster> and if people don't like it, on jujucharms.com, they don't use it
[15:21] <rick_h> because we have users hitting issues we can't replicate right now on jujucharms.com and that's the case I'm trying to address asap 
[15:21] <gary_poster> as a tool, we give an option to turn it off
[15:21] <rick_h> gary_poster: +1
[15:22] <gary_poster> hatch, I think that's entirely in line with our privacy policy, and we already have the warnings/links about this
[15:23] <hatch> I suppose this is all assuming the console error hasn't bricked the app :)
[15:24] <hatch> and allows us to fire data to GA
[15:24] <rick_h> hatch: right, but if we implement something all logging should go to it. And we wrap it with console.log in debug and 'send log to remote location' in production
[15:24] <rick_h> hatch: thus something like loggly or oops-tools
[15:24] <hatch> I wrote a console.log wrapper a long time ago that did that
[15:24] <rick_h> hatch: yep, I think we all have :)
[15:24] <hatch> haha
[15:25] <hatch> mine is locked in a svn repo export.....(plz don't make me install svn just for that) :P
[15:25] <rick_h> hatch: heh, I've been trying to find mine in my NAS backup from a few years ago and then figured it was for jQuery and I probably don't want to find it. 
[15:26] <rick_h> I'd be afraid to find my 3-6yr old JS code
[15:26] <hatch> gary_poster: I get a different popup menu on comingsoon than I do on trunk for build-relation and the like....same revno...
[15:26] <hatch> rick_h: did you see my link from horse_js above?
[15:27] <rick_h> hatch: yea, long history there. I find it more sad than funny
[15:27] <hatch> awww :(
[15:27] <rick_h> creator of pylons, turbogears, Paste and half the wsgi world of tools, all went to mozilla and went JS
[15:28] <gary_poster> hatch, popup: yeah I think our makefile has css issues.  i will try to kick it
[15:28] <hatch> rick_h: clear indication that JS is a better language :P
[15:28] <rick_h> ....
[15:28] <rick_h> indication that JS needs more smart devs to make it suck less? imported from the best...
[15:29] <hatch> oooOooOoooo
[15:30] <rick_h> well, I should say js 'tools' since they stole a bunch of framework and tool authors from Python to hack on JS tools/libraries. 
[15:30] <hatch> rumor has it that Google has moved V8 devs to Dart
[15:30] <rick_h> poor devs
[15:31] <hatch> lol
[15:31] <hatch> the two guys that were doing the IO talk on the Dart compiler were from V8
[15:31] <hatch> I want to say they....wrote V8?
[15:31] <hatch> I can't remember exactly now
[15:35] <hatch> do we have any way to debug the d3 script?
[15:35] <hatch> some way to switch to an uncompressed version?
[15:36] <gary_poster> hatch, yes...devel should use it
[15:36] <gary_poster> hatch if it doesn't we have a bug
[15:36] <hatch> yeah that's giving me the compressed version
[15:36] <gary_poster> we have the uncompressed version around tehre somewhere, pretty sure
[15:36] <gary_poster> Makyo, any clues ^^^ ?
[15:37] <Makyo> Just a sec, let me look into it real quick.
[15:39] <hatch> the d3 source is 7000lines of undocumented code....oy vey
[15:40] <Makyo> gary_poster, hatch, we have the uncompressed version from npm, would need to make it available in assets, change the fullpath in modules-debug, and use the compressed version in modules-prod.
[15:41] <hatch> ahh
[15:41] <hatch> we should probably fix that at some point hey?
[15:41] <gary_poster> hatch, Makyo +1
[15:42] <Makyo> hatch, sure. Just means breaking from our current pattern with modules-prod
[15:42] <hatch> Makyo: if I change this insert() to append() it works but with insert I get a DOM Exception 12 https://gist.github.com/hatched/de5e686fa7028a200396
[15:42] <Makyo> Which is fine, of course, just a new thing for me, is all.
[15:43] <hatch> Makyo: ok well we can leave it for now but maybe we should revisit how we do module loading entirely
[15:43] <Makyo> hatch, a wishlist item.  It might be good to at least figure out a path forward.
[15:43] <hatch> yeah
[15:45] <Makyo> Hm, I might actually be crazy.  Maybe it's easier than that.
[15:45] <Makyo> Coffee required, though.
[15:45] <hatch> I just changed the file in modules_debug for noe
[15:47] <Makyo> Alright
[15:47] <hatch> and found the issue
[15:48] <hatch> well so I thought
[15:48] <hatch> hehe
[15:48] <hatch> I think the d3 api is wrong
[15:48] <Makyo> :P
[15:48] <Makyo> Check for issues, then, if that's the case.
[15:49] <hatch> oh...
[15:49] <hatch> our version isn't even close to the most recent
[15:49] <hatch> lol
[15:49] <hatch> that could be why the api and the code don't match
[15:49] <hatch> haha
[15:50] <Makyo> I mean, the gist code will cause errors because the before argument should return a node, and now it's just logging stuff.  Should use .call for that.
[15:50] <hatch> right I added that in....it now returns a string
[15:51] <hatch> but the whole fn is being passed to the querySelect()
[15:53] <hatch> Makyo: I see our package.json says <3 for d3.....is there a bug in d3 v3?
[15:56] <gary_poster> hatch, rick_h Makyo https://pastebin.canonical.com/94869/
[15:56] <Makyo> hatch, We had a version-freeze earlier this year.
[15:56] <abentley> hazmat: How do you run the tests in the new deployer?  The README still says "python deployer/tests/test_deployment.py"
[15:56] <Makyo> Before v3 came out.
[15:56] <hatch> right - but I mean was there a reason for this freeze specifically
[15:56] <rick_h> gary_poster: uh..so that's ungood
[15:57] <gary_poster> jujugui call in 3
[15:57] <gary_poster> kanban now :-D
[15:57] <hatch> gary_poster: ugh...I know 'why' thats happening but I don't have a proper fix
[15:57] <Makyo> hatch, We froze all versions to keep landing branches sane, that was the thing.  If you want to do a full QA run and get us up to v3, I've got no problem with that.
[15:57] <abentley> hazmat: But that fails with ImportError: No module named deployer.config
[15:57] <rick_h> gary_poster: what was the url at this point? 
[15:58] <hatch> our module code isn't pulling in all the required dependencies
[15:58] <hatch> so yui goes and fetches the rest
[15:58] <hatch> there IS a https yui combo service though....
[15:58] <gary_poster> rick_h, checking
[15:58] <rick_h> hmm, spinner image is also pulled from non-https
[15:59] <rick_h> wtf, why is the spin.min.js not in the rollup?
[15:59] <rick_h> ugh
[15:59] <rick_h> ah, because it's spinning while things load I guess 
[15:59] <gary_poster> yes
[15:59] <hatch> they see me spinnin....they hatin
[15:59] <gary_poster> lol
[16:00] <hatch> :)
[16:00] <hatch> Makyo: ok I'm going to have to attempt an upgrade because the version we are on does not accept a fn as the second argument to insert
[16:00] <gary_poster> hatch, rick_h fwiw: plain old jujucharms.com 
[16:00] <gary_poster> no url
[16:00] <gary_poster> chromium
[16:01] <gary_poster> jujugui call now
[16:01] <rick_h> gary_poster: ok, looking and trying to reproduce. Only one I can repo is the close-orange.png atm
[16:03] <gary_poster> rick_h, hatch could be from loading devel version yesterday? clear cache?
[16:03] <rick_h> gary_poster: maybe
[16:03] <hazmat> abentley, python -m unittest discover
[16:03] <rick_h> gary_poster: but we shouldn't be doing that in devel either. 
[16:03] <hazmat> abentley, from within top level of the source tree.. there are other options as well. 
[16:03] <adeuring> abentley, sinzui could one of you review thes mp: https://code.launchpad.net/~adeuring/charmworld/1202665-nofile-errors/+merge/176418
[16:04]  * sinzui looks
[16:08] <arosales> gary_poster, when I export an environment  via 'shift-d'  any strings such as "on/off/yes/no" are parsed as keywords and not strings.  Is this a gui thing or a deployer thing?
[16:08] <gary_poster> arosales, on call will reply soon
[16:08] <arosales> gary_poster, example is just export a mysql/wordpress env, and then try to redploy with the deployer and errors come up as the values aren't strings
[16:08] <arosales> gary_poster, ack
[16:17] <rick_h> robbiew: do you have a few min to do a hangout with a screenshare for this jujucharms.com issue? 
[16:18] <robbiew> rick_h: when I'm out of this call, sure
[16:18] <rick_h> robbiew: ty
[16:19] <sinzui> adeuring, r=me with an additional comment.
[16:20] <adeuring> sinzui: thanks
[16:25] <rick_h> robbiew: calling back, was logged into wrong account. 
[16:30] <gary_poster> rick_h, ben was able to dupe once in incognito mode, and then could not.  Makyo hatch and I cannot repro at all in incognito or otherwise
[16:30] <rick_h> gary_poster: talking with robbiew now, looking and trying to make sense
[16:30] <gary_poster> thanks rick_h 
[16:32]  * benji jumps into the escape pod.
[16:38] <rick_h> gary_poster: ok, I don't understand how we're starting the app. We're not using the domready event, there's some sort of setTimeout() in there. I think we're just hitting race conditions with the order for3 files getting loaded 
[16:38] <rick_h> the stuff we're doing in app/index.html seems like it'd be fragile 
[16:38] <hatch> rick_h: so it's reproducable?
[16:38] <rick_h> hatch: so he had it over and over while he was using a cached file. On a freshly cleared cache it went away
[16:40] <rick_h> gary_poster's gotten it once in incognito mode, but only once. I can't help but think it's some sort of race. In his network graph on a failing case the files were coming in on the network tab way out of order of listing in the index.html, which shouldn't matter unless startTheApp isn't waiting for files to load first...and it seems like that's the way it works now
[16:40] <gary_poster> rick_h, join https://plus.google.com/hangouts/_/7fb7c30f3a232db57dd8549738fb98e723d90d4a ?
[16:45] <hatch> hangouts crashed
[16:52] <gary_poster> 1) enable etag support
[17:04] <gary_poster> hey frankban 
[17:04] <gary_poster> something we will want to add to our static file serving:
[17:04] <gary_poster> etag support
[17:04] <frankban> gary_poster: sounds good
[17:04] <gary_poster> I assume we could do that really easily
[17:04] <gary_poster> cool thanks
[17:05] <frankban> gary_poster: IIRC we will also need to add "/test" when serve-tests is true in the charm, or something like that
[17:05] <gary_poster> frankban, yes, good point
[17:06] <frankban> gary_poster: ok, I'll create two cards
[17:06] <gary_poster> thanks frankban 
[17:07] <bcsaller> crazy lag was crazy
[17:07] <hatch> gary_poster: bcsaller is going to attempt to create a somewhat simple prototype of this approach because I think that we agree it's the right way to do it, but I'm having a hard time seeing where it'll be injected while keeping it 'simple'
[17:30] <hatch> bcsaller: the odd thing was that the video was on time but the audio was way behind haha
[17:33] <rick_h> hatch: can you ok https://codereview.appspot.com/11571044 if you get a sec?
[17:33] <rick_h> After doing a bunch of reading I'm less sure of this fix, but it seems a worthwhile change regardless. :/
[17:35] <hatch> rick_h: hmm
[17:35] <rick_h> gary_poster: fyi, from what I can read you're right. they should be run in order 
[17:35] <hatch> it appears that we might 'need' to do the flag approach
[17:36] <rick_h> hatch: well, I'm not sold there isn't something else here. A bad network issue? a truncated file? freaking hard to see since I can't dupe
[17:36] <hatch> yeah exactly
[17:36] <gary_poster> rick_h, ack.  was going to comment that if we do this, we should include a comment about why.  also afaict (http://www.w3.org/TR/html5/scripting-1.html#attr-script-defer) we should not have defer or async on non-src script tasg
[17:36] <rick_h> http://www.html5rocks.com/en/tutorials/speed/script-loading/ is the latest/best info I can find atm 
[17:37] <rick_h> gary_poster: bah, then never mind on this because the only way this 'makes sense' in the limited way it does is if we're also saying the manual script block only executes in order
[17:37] <gary_poster> rick_h, ah. :-/
[17:37] <gary_poster> hatch, rick_h, nasty global flagsies then?
[17:38] <rick_h> I was trying to test it out here to see if it worked as expected with the defer in the non-src block. http://stevesouders.com/cuzillion/?c0=hj1hfft1_0_f&c1=hj1hfft3_1_f&c2=hj1hfft2_1_f&c3=hb0hfft0_1_f&t=1374600345467
[17:39] <gary_poster> huh
[17:39] <gary_poster> interesting
[17:39] <gary_poster> well, if we go that way, maybe include that page in comment? :-/
[17:39] <rick_h> gary_poster: yea, I can add comments to both links and just say "this is a trial..." and see if reports stop coming in. 
[17:39] <rick_h> but as I said to start, I'm less sure of myself now than I was on the call :/
[17:41] <gary_poster> heh, I hear you
[17:43] <rick_h> gary_poster: ok, well I'll add docs to the code, links to the two files, and land this for now. It won't make things worse and we can see what happens. 
[17:43] <arosales> gary_poster, not urgent but in reference to my export question hazmat pointed to bug 1200625, which is the issue I am seeing.
[17:43] <_mup_> Bug #1200625: gui export is exporting invalid config options / not respecting type when serializng <juju-gui:New> <https://launchpad.net/bugs/1200625>
[17:43] <rick_h> gary_poster: and if we can get any way to reliably dupe it I promise to tear it apart
[17:43] <gary_poster> rick_h, +1
[17:43] <arosales> I added my comment to that bug.  Posting here as an fyi
[17:43] <gary_poster> arosales, ah thanks I'm afraid that had completely slipped my mind.  looking
[17:44] <arosales> gary_poster, no worries, not urgent just wanted to follow up and post here when you had an opportunity.
[17:44] <gary_poster> cool thank you much arosales 
[17:45] <hatch> rick_h: cool page - 5.5s load time?
[17:45] <bcsaller> rick_h: isn't 'defer' the opposite of what we want, sync loading is the default, we need to ensure execution doesn't happen till the parse is finished though.
[17:46] <rick_h> bcsaller: defer says the fiel can be dowloaded async, but must be executed int he order it appears in the dom
[17:46] <rick_h> async says that you can download this file async, and execute it as soon as you're ready regardless of order
[17:46] <bcsaller> and after the doc has been parsed, hmm
[17:46] <rick_h> hatch: yea, there's timers installed in each external file to demonstrate order
[17:47] <hatch> ahh
[17:47] <rick_h> bcsaller: right, but our JS is right before the footer already
[17:47] <rick_h> bcsaller: so the body parsing shouldn't cause us any issues from what I can see. 
[17:47] <arosales> gary_poster, sure np. hazmat helped point to the bug.
[17:47] <bcsaller> yeah... hmm
[17:47] <gary_poster> bcsaller, https://bugs.launchpad.net/juju-gui/+bug/1200625 has more details now fwiw.  it does seem like a yaml lib problem.  I'd vote on the proper fix being a switch to letting the deployer handle our exports, except that won't work for some of other plans (being able to import deployer file, allow modifications, and then send back to deployer).  therfore maybe we need to fix the yaml lib
[17:47] <rick_h> bcsaller: testing with/without locally is darn near identical. 300ms diff in times
[17:47] <_mup_> Bug #1200625: gui export is exporting invalid config options / not respecting type when serializng <juju-gui:New> <https://launchpad.net/bugs/1200625>
[17:48] <gary_poster> bcsaller, not a burning issue.  just letting you know
[17:48] <hatch> rick_h: I'm worried this is simply a bandaid
[17:48] <rick_h> hatch: I'm worried it won't work at all. 
[17:48] <hatch> lol
[17:49] <rick_h> hatch: from what I can tell the issue we think we have should not happen as the code stands today
[17:49] <gary_poster> +1
[17:49] <hatch> I agree
[17:49] <gary_poster> I think this is a browser bug :-/
[17:49] <rick_h> see - http://www.html5rocks.com/en/tutorials/speed/script-loading/#toc-quick-reference 
[17:49] <rick_h> gary_poster: and that's possible. it was only in chromium and FF was working for him
[17:49] <rick_h> gary_poster: and I know chrome-ium is the most aggressive with this stuff
[17:49] <gary_poster> y
[17:50] <rick_h> so *maybe* by saying "Hey smarty pants...I want these defer'd and respect my authority" it helps
[17:50] <rick_h> but ugh and ugh and ugh 
[17:50] <hatch> rick_h: so reading through that page it looks like the only way we can be sure is using the ugly flags
[17:50] <hatch> because each browser does it differently
[17:51] <rick_h> hatch: but even flags can cause issues if it's outside of this. A bad file tranfwer or the like
[17:51] <rick_h> then the flags never run and you just get a spinner over and over and no error because you never run :)
[17:51] <hatch> do you think the server is truncating it?
[17:51] <hatch> is that what the source lookd like on robbies machine?
[17:51] <rick_h> hatch: so the cache'd all-yui.js that we copied from the browser into vim had no TabView module defined in it :/
[17:52] <rick_h> once we cleared the cache it worked
[17:52] <hatch> :/
[17:52] <rick_h> with a ctrl-shift-delete empty cache
[17:52] <hatch> ohh
[17:52] <hatch> TabView specifically?
[17:52] <rick_h> hatch: so maybe it's all just related to the yesterday single serve files since we still service all-yui.js 
[17:52] <hatch> it's a caching issue then
[17:52] <rick_h> hatch: well that was my canary in the coal mine
[17:53] <rick_h> hatch: right, but gary_poster reproduced it one time in in-cognito mode
[17:53] <hatch> bin/merge-files:82
[17:53] <rick_h> which I'll assume is not cache related
[17:53] <hatch> I had to add that in becuase tabview wasn't loaded by default
[17:53] <rick_h> hatch: yea, we manually add it due to build issues, but it should be there
[17:53] <rick_h> hatch: so robbiew had a bad file, I'm not sure on gary_poster's run. I'd love to have peeked at his all-yui.js file when he dupe'd the error
[17:53] <hatch> right - so the only time it won't be is if it was loading an old file?
[17:54] <hatch> s/?/.
[17:54] <rick_h> bah, and sorry for the pings guys /me replaces real people names with jojo and bubu :)
[17:54] <hatch> lol
[17:54] <rick_h> hatch: I *think* but hard to say for 100% without seeing it 
[17:55] <rick_h> anyway, if anyone gets an error stop, don't breath, and screenshare with me pls kthx :)
[17:55] <hatch> haha
[17:55] <hatch> rick_h: I'm not confident that we should land this defer
[17:55] <hatch> because I'm pretty sure it'll do exactly what it's doing now
[17:56] <hatch> reading the docs
[17:56] <rick_h> hatch: I know, but it can't hurt any. The worst case is that we wait for until right be domready to execute and it'll cost us a few ms, best case it helps load these files async and buys us a couple of ms and helps
[17:56] <hatch> haha, I'll lgtm it
[18:02] <rick_h> and <3 that we hit the t-shirt goal for the sprint. I'm only sad I can't bring it to PyOhio this weekend. thanks jcsackett 
[18:24] <hatch> somehow updating d3 causes the makefile to try and simlink yui twice.....?
[18:24] <rick_h> lol
[18:24] <rick_h> our Makfile hates you for making fun of it
[18:25] <hatch> clearly
[18:25] <hatch> it's also garbled it's code to make it unreadable
[18:25] <hatch> oh wait....no that's just normal
[18:25] <hatch> :P
[18:26] <gary_poster> rick_h, hatch, I just got an instance of the failure.  http://ubuntuone.com/7K2T0TNIV9koJYv5p35mGE
[18:26] <hatch> ok so that means that the config file hasn't loaded yet
[18:26] <rick_h> w...t...f... window is not defined?
[18:27] <rick_h> oh, juju-config is undefined
[18:27] <gary_poster> right
[18:27] <rick_h> nvm, yea config hasn't been run
[18:27] <hatch> so we need to do the hacky 'flag' technique I mentioned I guess
[18:27] <gary_poster> so race condition
[18:27] <gary_poster> yeah it seems so
[18:27] <hatch> because clearly they aren't being executed in order
[18:27] <hatch> that sucks, it feels so hacky
[18:27] <rick_h> yea, and every doc says it should so browser bug
[18:27] <gary_poster> y
[18:28] <hatch> gary_poster: thanks for getting the bug :D
[18:28] <gary_poster> hatch, np ;-)
[18:28] <hatch> how did you repro it?
[18:28] <hatch> have you been sitting there hitting refresh for the past hour?
[18:28] <hatch> lol
[18:28] <gary_poster> hatch, random.  was trying to go look at comingsoon
[18:29] <rick_h> hatch: so 1) how are you giong ot hacky it?
[18:29] <hatch> gary_poster: can you check to see if the config file was fully downloaded?
[18:29] <hatch> or did you close it already?
[18:29] <rick_h> 2) can't we defined startTheApp above config.js and have config.js run it at the end?
[18:29] <hatch> thinking maybe the server is truncating it?
[18:30] <gary_poster> hatch reloaded already
[18:30] <gary_poster> sorry
[18:30] <hatch> no problem
[18:30] <rick_h> hatch: so if we defined the startTheApp as a function call above the 3 included files and defer them in order and call startTheApp from config.js worky?
[18:31] <hatch> rick_h: at points we would consider a file 'done' executing it assigns a flag to some global, the settimeout fn then checks that all the required flags are set - if they are, then it starts the app
[18:31] <rick_h> hatch: or did you have some other hacky in mind
[18:31] <rick_h> hatch: so it'll look on some setTimeout interval until run then?
[18:31] <gary_poster> yeah the startTheApp dance we have now assumes that the file loading approach works
[18:31] <rick_h> /look/loop
[18:31] <hatch> which is should haha
[18:31] <hatch> rick_h: yeah it can be part of the current loop
[18:31] <gary_poster> right
[18:31] <rick_h> yuck loops
[18:31] <gary_poster> but if we are no longer using that method
[18:32] <gary_poster> we can simplify.
[18:32] <gary_poster> ugly :-(
[18:32] <gary_poster> feels dangerous/fragile
[18:32] <rick_h> yea
[18:32] <gary_poster> we should be able to rely on browser for this stuff
[18:33] <hatch> we could put this starttheapp in a separate file
[18:33] <hatch> maybe it only guarantees the order of externally loaded scripts
[18:33] <hatch> tbh i've never seen this error before
[18:33] <rick_h> hatch: yea, defer (by the docs) is ignored on non-src script tags except in IE according to that page linked previously
[18:35] <gary_poster> we could move config load first (before all-yui)
[18:35] <gary_poster> and then put startTheApp in modules.js
[18:35] <rick_h> https://code.google.com/p/chromium/issues/detail?id=247909
[18:35] <gary_poster> hacky hack hack hack :-/
[18:35] <hatch> gary_poster: yeah that could work
[18:35] <hatch> rick_h: of course there is a bug lol!
[18:35] <rick_h> hatch: well, it's a bug that's closed because they can't dupe reliably
[18:36] <hatch> haha yup
[18:36] <rick_h> so at least we're not alone
[18:36] <gary_poster> heh
[18:37] <hatch> I suppose there is some comfort in numbers while walking into a pit of fire
[18:37] <rick_h> well if no one else sees any issue I'd want to keep looking at what we're doing wrong
[18:38] <hatch> I like gary_poster's approach
[18:38] <hatch> that should solve the issues
[18:38] <gary_poster> maybe tricky though
[18:38] <gary_poster> simpler to do what you proposed
[18:38] <gary_poster> because modules.js differs in dev and prod
[18:38]  * rick_h wonders what it would take to get rid of all js out of index.html and just load files that run. 
[18:39] <hatch> bah! take your common sense garbage elsewhere
[18:39] <gary_poster> that's an idea.  looking
[18:39] <gary_poster> lol
[18:39] <rick_h> oh, you know what...damn
[18:39] <rick_h> so we load modules, modules loads .use(['juju-gui'])
[18:40] <rick_h> YUI block looks if it should block or go, it says go
[18:40] <rick_h> we need to define a module for config.js, .use([juju-gui, gui-config]) 
[18:40] <rick_h> annd the YUI block will wait on it's own won't it hatch ?
[18:40] <gary_poster> that's making some sense
[18:40] <hatch> yep
[18:41]  * rick_h tries to remember everything about the YUI loader he can recall
[18:41] <hatch> I thought there was a reason why we weren't doing that though?
[18:41] <hatch> ohh right
[18:41] <rick_h> I wonder if just swapping config/modules would work?
[18:41] <hatch> we need the config to pass into the yui()
[18:41] <rick_h> in the list
[18:41] <rick_h> hatch: yea...right
[18:41] <rick_h> hmmmm
[18:41] <hatch> trying to overwrite the yui linked dir twice.... https://gist.github.com/hatched/05b4c61ec923f46c8a9b
[18:41] <rick_h> but that YUI.use() block doesn't have anything that says to wait for ie
[18:42] <rick_h> hatch: running what make command?
[18:42] <hatch> make devel
[18:42] <gary_poster> hatch make clean for now
[18:42] <hatch> gary_poster: this is after upgrading d3 version
[18:42] <hatch> trunk works fine
[18:42] <hatch> make clean and make clean-all both have no effect
[18:43] <hatch> it's actually trying to make the link twice
[18:43] <rick_h> hatch: give me a sec to look
[18:43] <hatch> the odd thing is the actual make error message
[18:44] <hatch> it references d3.v2.min.js ?
[18:44] <rick_h> hatch: yea, look around line 249 
[18:44] <rick_h> $(JAVASCRIPT_LIBRARIES): | node_modules/yui node_modules/d3
[18:44] <hatch> ahh ok i'll strip all of these v2's
[18:47] <hatch> wow lots of v2's everywhere
[18:51] <hatch> *sigh* of course we can't just upgrade
[18:51] <hatch> how silly of me to assume
[18:51] <hatch> :D
[18:54] <hatch> who knows about the file unscaled-pack-layout.js ?
[18:55] <gary_poster> Makyo, bcsaller, ^^^
[18:55] <Makyo> Me.  Why?
[18:55] <hatch> after deploying a charm
[18:55] <hatch> I get an error on line 98
[18:56] <hatch> Cannot read property '_modelName' of undefined
[18:56] <rick_h> gary_poster: I can'
[18:56] <rick_h> t help but wonder if https://codereview.appspot.com/11577044 would be enough
[18:56] <rick_h> or if we'll just get a new error because modules.js wasn't fully loaded since it'll be the last script in line...
[18:57] <hatch> Makyo: here is what 'd' is https://gist.github.com/hatched/201696944f12cf95e6ab
[18:57] <hatch> so no 'data'
[18:58] <gary_poster> rick_h, +1.  I was looking at this and thinking too.  This is fragile, but only because the browser isn't doing the right thing.  As far as modules, I bet it will be fine:  that's using the YUI loader
[18:58] <Makyo> What's changed in your code that would lead to the wrong value being passed to the pack layout?  I'm not seeing the error locally, and that file's been around for a while.
[18:58] <gary_poster> and we Y.use('juju-gui')
[18:58] <hatch> Makyo: I upgraded to d3 v3
[18:58] <hatch> have a few minutes to pair?
[18:59] <Makyo> Sure.
[18:59] <hatch> guichat?
[19:00] <Makyo> Sure, why not.
[19:00] <hatch> ok there
[19:00] <rick_h> gary_poster: k
[19:01] <rick_h> gary_poster: yea, I'm trying to look at how modules/the startTheApp yui block interact atm. 
[19:02] <rick_h> hatch: got the error. config.js is loaded and not truncated in the dev tools. 
[19:02] <rick_h> gary_poster: interestingly, it has an etag header on it 
[19:03] <rick_h> at least in comingsoon it does
[19:03] <rick_h> yea, looks like production has etags as well
[19:04] <gary_poster> ah yeah
[19:05] <benji> Aaaaaand we're back!
[19:07] <rick_h> welcome back benji 
[19:08] <benji> I can now type "initrd (hd0,3)/boot/grub/i386-pc/initrd.img-3.8.0-28-generic" correctly in only one try.
[19:09] <rick_h> ooh, so you had a 'special' time recently 
[19:09] <benji> heh
[19:17] <hatch> gary_poster: got a second to hop into guichat?
[19:17] <gary_poster> hatch sure
[19:17] <hatch> about this ordering thing
[19:21] <hatch> Makyo: any idea on an eta to do the swap over?
[19:21] <Makyo> hatch, half day, I'd say.
[19:21] <Makyo> then reviews.
[19:21] <hatch> cool thanks
[19:39] <hatch> bcsaller: are you around?
[19:44] <hatch> Makyo: join us in guichat?
[19:52] <hatch> thanks Makyo
[20:08] <bcsaller> hatch: yes, here, sorry
[20:09] <hatch> bcsaller: it's ok, we got-r-figured
[20:43]  * Makyo retrieves dogs from camp.  Back in a bit.
[21:19] <hatch> hmm I Just got a "cannot deploy service" error....but it deployed the service anyways
[21:21] <gary_poster> heh, that's not good
[21:23] <hatch> yeah it turns out it was the result of a bad object call in the d3 code....
[21:23] <hatch> hmm
[21:23]  * hatch adds to his notes to investigate
[21:24] <hatch> good news is the technique that we are using is working....
[21:24] <gary_poster> yay :-)
[21:25] <hatch> some odd interactions though
[21:25] <hatch> when I click 'Confirm' there is a good 1-2s delay before the ghost inspector dissapears
[21:26] <gary_poster> I noticed something like that.  Of course, that probably is indicative of real world behavior--the real world behavior might be worse, in fact
[21:26] <hatch> ahh, happens the same on comingsoon w/o the flag but we aren't indicating the timeout on the new inspector
[21:26] <hatch> we'll need some type of a spinner or something
[21:26] <gary_poster> we ought to have indicators of "I know what you want; gimme a sec"
[21:26] <gary_poster> yeah
[21:26] <hatch> lol
[21:26] <gary_poster> luca had a site with some of that
[21:26] <hatch> "YO, I'm workin here!"
[21:26] <gary_poster> heh
[21:27] <hatch> in my best Jersey Shore accent of course
[21:27] <gary_poster> of course :-)
[21:40] <gary_poster> bac, hey.  Is this resolved-ish? https://bugs.launchpad.net/juju-gui/+bug/1189502
[21:40] <_mup_> Bug #1189502: Google analytics use should be configurable via the charm <juju-gui:Triaged> <https://launchpad.net/bugs/1189502>
[21:41] <hatch> lunching
[21:41] <gary_poster> bac, sorry never mind
[21:41] <gary_poster> it is not
[21:43] <gary_poster> hatch, when you get back: will https://bugs.launchpad.net/juju-gui/+bug/1170031 be completely fixed by inspector, or just improved?
[21:43] <_mup_> Bug #1170031: show_enviornment called multiple times even on other views <juju-gui:Triaged by hatch> <https://launchpad.net/bugs/1170031>
[21:44] <gary_poster> um, sorry, bac, yes it is :-)
[22:08] <bac> gary_poster: well, that bug is half solved.  on/off is provided but the google id is not configurable
[22:47] <hatch> gary_poster: that bug is partially fixed now but once we switch to the inspectors it'll be 100% fixed
[23:28] <rick_h> gary_poster: got a phone call from jcastro. The phrasing was something like "Man, people love this stuff!"
[23:28] <hatch> :D
[23:28] <rick_h> gary_poster: didn't have your info to call, will fill in 100% when he writes up the report, but wanted to me to pass notes to the whole team that we killed it. People are eating up the Gui 
[23:29] <hatch> it feels great to know people love the product you make :D
[23:29] <rick_h> gary_poster: said in his talk he went through how to do stuff and then said "And if this is too hard, pull up the gui and just drag it to deploy it" 
[23:29] <hatch> lol
[23:29] <gary_poster> rick_h, :-) awesome
[23:29] <rick_h> so not a ton of info since he called from the floor while I was out to dinner, but wanted to pass along as requested
[23:30] <gary_poster> thanks rick_h :-)
[23:32] <gary_poster> huwshimi, hi.  hope you saw that too ^^^ that's with a big thanks to a lot of your hard work, and we've had lots more praise
[23:32] <huwshimi> gary_poster: Awesome!
[23:37] <hatch> $3.6M on the Edge