[12:18] <rick_h_> benji: I'm trying to see via kanban if someone picked up hatch's review. How is that indicated?
[12:18] <benji> rick_h_: we add a "tag" with our name on the "Advanced Settings" page
[12:19] <benji> (double-click on the card)
[12:19] <rick_h_> ah, gotcha
[12:19] <rick_h_> thanks
[12:50] <gary_poster> benji, rick_h_ fwiw you can also just hover over the tag icon for a quick look
[12:50] <rick_h_> gary_poster: yea, I didn't think to look at the tag
[12:50] <benji> cool
[12:50] <rick_h_> I was expecting to see people put their faces on the card but none had them
[12:50] <rick_h_> so was trying to think maybe notes, but nadda there and then decided to just ask 
[12:51] <rick_h_> since benji's email just came by and I knew he was around :P
[12:51] <rick_h_> luca_: can you make sure to run through the bugs marked 'incomplete' for the stand up today? I'd like to make sure we go through any questions and such.
[12:52] <gary_poster> jujugui, today is my daughter's birthday so I'm using some of my accumulated extra hours today to spend some time with her.  Going with her to gymnastics in 10 or 15 and back in an hour or so.  probably long early lunch.  which is a long way of saying...anything I can do for people right now, quickly?
[12:52] <rick_h_> luca_: https://bugs.launchpad.net/juju-gui/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=charmbrowser+&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_m
[12:52] <luca_> rick_h_: will do
[12:52] <rick_h_> oh, that was bigger than it looked
[12:52] <rick_h_> sorry
[12:52] <gary_poster> heh
[12:52] <rick_h_> gary_poster: have fun!
[12:52] <luca_> rick_h_: also, is there a known issue of the GUI being down?
[12:52] <gary_poster> thanks :-)
[12:53] <rick_h_> luca_: ah, was going to ask about that this morning. Figured it was to do with everything going down last night
[12:53] <rick_h_> jujugui anyone know if we need to reset the charm/etc? The gui hangs on connecting to env
[12:53] <bac> gary_poster: get pictures of her on the parallel bars
[12:53] <gary_poster> rick_h_, will investigate.  bac, heh ok  will do 
[12:59] <gary_poster> hey hazmat, the readonly stuff has broken improv. looks trivial.  could you make a quick fix?  not really here.  http://pastebin.ubuntu.com/5619066/
[12:59] <gary_poster> I mean, I'm not really here. :-) daughter's bday, taking a few hours away in morning
[13:06] <gary_poster> rick_h_, luca_ temporarily up.
[13:07] <gary_poster> hazmat, we just need improv to have line 21 of http://pastebin.ubuntu.com/5619098/
[13:07] <gary_poster> hazmat maybe we should put rapi-rollup in a shared place
[13:07] <gary_poster> rather than ~hazmat :-)
[13:08] <gary_poster> also, could you ping bac and me when this is fixed so we can make sure uistage is OK?\
[13:08]  * gary_poster runs
[13:08] <gary_poster> ttyl
[13:10] <luca_> rick_h_: thanks :)
[13:10] <rick_h_> luca_: heh, thanks gary_poster 
[13:13] <luca_> rick_h_: did you want to screen share to see this bug while its up? https://bugs.launchpad.net/juju-gui/+bug/1174392
[13:14] <hazmat> gary_poster, noted, fix in progress. will need to coordinate  a charm fix as well
[13:14] <hazmat> for the branch move
[13:15]  * hazmat notes improv should have a unit test
[13:16] <bac> so in my raring VM, if i resize a terminal window it jumps back to its original size when i give focus to another window.  anyone seeing that on raring on metal?
[13:17] <rick_h_> luca_: sinzui had that and was looking at it. Check with him at the stand up if he's found it and fixed it. Maybe just not released yet.
[13:17] <luca_> rick_h_: kk, will do
[13:27] <hazmat> rick_h_, fixed btw 
[13:28] <rick_h_> hazmat: awesome thanks
[13:28] <rick_h_> hazmat: do we need to get the charm updated them as well or is the uistage setup all set 100% ?
[13:31] <hazmat> rick_h_, uistage auto refreshes, its sans charm
[13:32] <hazmat> it does pulls from both branches on a reset
[13:43] <hatch> we had a slush blizzard last night :/ I was driving home down the freeway and it was so icy that the wind was pushing the car into the other lane lol
[13:45] <hatch> and this morning they look like a curling rink
[13:45] <hatch> good thing my commute isn't that far
[14:03] <rick_h_> hazmat: hmm, seems it updated and is down again. 
[14:04] <hazmat> rick_h_, conflict error.. fixing
[14:05] <rick_h_> thanks hazmat 
[14:07] <hazmat> wtf.. bzr diff -> http://pastebin.ubuntu.com/5619274/
[14:08] <hatch> time to switch to git? ;)
[14:08] <rick_h_> hazmat: sssh, you'll get my hopes up
[14:08] <rick_h_> oops, meant hatch 
[14:08] <rick_h_> damn autocomplete with people matching first two cahrs
[14:09] <hazmat> oh. somebody else logged in to hotfix the code hence the conflict
[14:10] <rick_h_> hazmat: ah, sorry right. Gary did a cowboy before he ran. 
[14:11] <hatch> rick_h_: lol - I'm sure the functionality is pretty close, but it's almost impossible to find out how to do things in bzr compared to the 1000s of git 'how do I do X' posts
[14:12] <hazmat> rick_h_, working now
[14:12] <rick_h_> hazmat: thanks
[14:13] <rick_h_> luca_: alejandraobregon http://uistage.jujucharms.com:8080/bws/sidebar is back up and should be ok. 
[14:13] <luca_> rick_h_: cheers
[14:14] <hatch> rick_h_: has your phone updated to the new google play?
[14:15] <rick_h_> hatch: yea, noticed it today. Well my N10 did. Haven't chceked my phone
[14:15] <hatch> ahh - my n7 didn't but my phone did, it's almost unusable on my phone
[14:16] <rick_h_> works well on the tablet, but that green on the app store side is fugly
[14:16] <hatch> yeah - and the icon/title at the top when viewing an app takes up the top 1/3 of my phone screen
[14:17] <hatch> google seems to have a thing for taking up usable space with chrome for no reason
[14:17] <hatch> ' see google docs on a small screen' heh
[14:17] <hatch> the old store had these fancy banner images and whatnot...this one is just a ton of ungodly slow loading icons
[14:19] <hatch> I have a 3.75" screen though so maybe they didn't test it on anything smaller than a 4.5" screen haha
[14:21] <hatch> rick_h_: FYI - that comment is confusing to me also....oops :)
[14:30] <bac> morning hatch.  when you're free i'd like to pair with you for a bit to get this plugin properly moved into the tree
[14:30] <hatch> alright couple minutes and I should be gtg
[14:34] <hatch> bac: ok - lets do it
[14:38] <bac> hatch: cool.  let me get arranged.  guichat?
[14:39] <hatch> sure
[14:49] <teknico> grunt, can't make charm deploy tests work, jitsu watch always failing to connect :-/
[15:36] <hatch> do we know if gary will be back for the call?
[15:39] <rick_h_> hatch: not sure. Sounded like it but maybe not
[15:50] <Makyo> jujugui - call in 10, update kanban.  We'll run with it if gary_poster isn't back for the call.
[15:51] <hatch> Makyo: what's been up with you rinternet lately? someone cut a fiber line during construction or something?
[15:51] <Makyo> hatch, New router.  Will be switching back to the old before the call, if I have time.
[15:52] <hatch> ahh - yeah that happened to me before - funny how such a 'simple' thing can cause so many issues
[15:53] <hatch> benji: how did you end up with a 10G memory leak? lol my computer would have long since crashed by then :D
[15:54] <benji> heh
[15:54] <benji> I wasn't the original reporter, but I assume swap had something to do with it
[15:54] <gary_poster> thank you Makyo! :-) I'm here, though I was thinking I asked for volunteers to run the meeting.  You up for it today Makyo ?
[15:54] <Makyo> gary_poster, Sure.
[15:54] <gary_poster> Thanks Makyo :-)
[15:54] <Makyo> Swapping router real quick.  Fingers crossed...
[15:55] <gary_poster> heh
[15:56] <Makyo> \o/
[15:57] <hatch> what was the old one so I know never to buy one :)
[15:59] <Makyo> jujugui call in 2
[16:00] <Makyo> hatch, Old one was a WRT54g, which works great, unless I put my phone on my desk, in which case it drops.  Also, it was time to switch to N.  New one was a Cisco E3200 which seems to have some problems running dd-wrt. 
[16:00] <hatch> haha wow wrt54g that's a classic
[16:01] <gary_poster> http://tinyurl.com/jujucharms
[16:03] <bac> gary_poster: remind me the pw
[16:03] <gary_poster> bac password is "password"
[16:03] <gary_poster> bac that will go away
[16:03] <bac> thx
[16:07] <bac> benji you just need the hat.  http://assets.rollingstone.com/assets/images/artists/304x304/zz-top.jpg
[16:07] <gary_poster> http://pastebin.ubuntu.com/5619568/
[16:07] <gary_poster> LOL
[16:08]  * gary_poster wants to get benji a beard extension
[16:09] <hatch> hahahahaha
[16:20] <Makyo> gary_poster, lost you :/
[16:40]  * benji gets back to the hangout too late.
[16:40] <benji> darn firefox crashed my computer
[16:40] <rick_h_> doh
[16:55] <rick_h_> gary_poster: will we have apache-like log tracking for metrics on the juju-gui to help us determine what *real* use patterns end up being?
[17:00] <gary_poster> rick_h_, great question.  apache is our front end in the prodstack configuration, I know.  I'll ask news
[17:00] <gary_poster> mew
[17:01] <rick_h_> gary_poster: cool thanks. 
[17:01] <rick_h_> jcsackett: hatch Makyo review request if anyone has time please. https://codereview.appspot.com/9052043
[17:02] <Makyo> rick_h_, I'll take a look
[17:03] <rick_h_> thanks Makyo 
[17:04] <gary_poster> rick_h_, confirmed that we can get access to apache logs
[17:18] <rick_h_> gary_poster: cool. Maybe an interesting oakland discussion might be analytics/metrics on things. Given xx charms in the intereste/featured which charms end up used more/less and such. What path people tend to use, etc. 
[17:18]  * rick_h_ wonders if there's overlap in things done like in the software center
[17:18] <ahasenack> gary_poster: hi, I just tried to install juju-gui using juju-core, basically just juju bootstrap + juju deploy juju-gui, and got this backtrace in the install hook, wondering if you saw that, before I start debugging: 
[17:19] <ahasenack> gary_poster: http://pastebin.ubuntu.com/5619768/
[17:19] <gary_poster> rick_h_, cool.  those analytics are going to come from the manage.jujucharms.com and charmstore logs, yeah?
[17:19] <rick_h_> gary_poster: some, I imagined some would be the urls hit on the gui as well. Kind of correlated together. 
[17:20] <gary_poster> benji, looking at ahasenack's report.  might be tied to your branch, or Kapil's.  ahasenack looking and will report back
[17:21]  * benji looks
[17:21] <ahasenack> gary_poster: ok
[17:21] <benji> gary_poster: that's me
[17:21] <gary_poster> benji, you on it?
[17:21] <benji> Let me look at fixing it.
[17:21] <benji> yep
[17:21] <ahasenack> what is the branch, I tried lp:~charmers/charms/precise/juju-gui/trunk but it doesn't even have that file
[17:21] <gary_poster> thanks benji.  if it is slow in the slightest please revert.
[17:21] <benji> k
[17:23] <gary_poster> ahasenack, lp:~juju-gui/charms/precise/juju-gui/trunk is true trunk.  We are the first experiment towards giving autonomy to blessed charm authors.  We need to not break the charm to have the experiment work out. :-/
[17:23] <ahasenack> ah, right
[17:23] <ahasenack> the default from the config
[17:23] <ahasenack> no, wait
[17:23] <ahasenack> that's the charm branch
[17:23] <ahasenack> gary_poster: so for some charms it's taken from somewhere else? I thought all charms were in ~charmers/charms/
[17:26] <benji> gary_poster: I'm testing the fix now by deploying the charm to EC2
[17:26] <gary_poster> ahasenack, right, that's the way it has been, and that's the way jujucharms.com reports it, but it's not true for the charm store, and this not true for juju itself.  Like I said, this is an experiment to give trusted charm owners who (appear to? :-/) have a good quality landing process the ability to be masters of the official charm.
[17:26] <gary_poster> thanks benji
[17:26] <ahasenack> ok
[17:28]  * gary_poster wants tarmac
[17:31]  * benji too.
[17:40]  * bac <3 tarmac
[17:45] <benji> gary_poster: working charm verified, trunk has fix
[17:45] <ahasenack> gary_poster: got something else now after i switched to juju-gui from ~charmers:
[17:45] <benji> ahasenack: feel free to give it another tr
[17:46] <ahasenack> gary_poster: http://pastebin.ubuntu.com/5619848/
[17:46] <gary_poster> thanks benji.  ahasenack. should work now.  thank you for the report.  don't use the charmers one.
[17:46] <ahasenack> gary_poster: bzr is not installed, is it normally installed when using pyjuju?
[17:46] <gary_poster> ahasenack, we will be pushing the ~juju-gui charm to charmers while we are in this transition period. In fact I'll ask m+3 to do so now.
[17:47] <ahasenack> gary_poster: is that a juju-core incompatibility? Just curious, will try the one from the charm store now
[17:48] <gary_poster> hey m_3.  When you get a chance, could you push the ~juju-gui juju-gui charm to the ~charmers?  I'll make an MP if you need it.  My concern is that people are going to be confused until jujucharms.com points to the right charm, which may not be for awhile.
[17:49] <gary_poster> ahasenack, I don't know why bzr is not around in that traceback, but what it is trying to do will absolutely not work in juju-core.  The ~charmers branch doesn't support juju-core (until we push the ~juju-gui one over)
[17:49] <ahasenack> ok
[17:49] <ahasenack> bzr is not installed in the instance, fwiw
[17:50] <ahasenack> at least not in PATH, I didn't actually check dpkg, and I took it down now
[17:50] <gary_poster> ahasenack, understood.  Thank you, and sorry you ran into this.  We'll improve our process some more.
[17:50] <ahasenack> np
[17:57] <gary_poster> rick_h_, gave you a quick LGTM fwiw
[17:57] <rick_h_> gary_poster: thanks
[18:10] <ahasenack> gary_poster: deploying juju-gui with juju-core worked now
[18:10] <gary_poster> yay, ahasenack!  It should, we worked hard enough for that to happen. :-)
[18:10] <ahasenack> :)
[18:15] <ahasenack> gary_poster: the gui user is now called user-admin? Or was that just a ui hint?
[18:16] <gary_poster> ahasenack, it's a juju core change.  I think we will probably want to hide the user- prefix in the future.
[18:17] <gary_poster> it will matter when juju grows authentication
[18:17] <gary_poster> real authentication :-)
[18:41] <gary_poster> benji, out of curiosity, have you been able to dupe memory leak?
[18:41] <gary_poster> AIUI the chrome tools are the best
[18:42] <benji> not yet, I've hacked up an improv script that continuously sends huge deltas but no leaks yet
[18:42] <gary_poster> huh
[18:42] <benji> the chrome tools do seem to be the best
[18:42] <gary_poster> benji how many services/units?
[18:42] <benji> I'm starting to think that the kind of delta might be the issue
[18:42] <benji> 5
[18:42] <gary_poster> hm
[18:42] <benji> the deltas are annotations
[18:43] <gary_poster> benji 5 services, 1 unit each?
[18:43] <benji> yep
[18:43] <bac> hey gary_poster, in my testing i need to show that the textarea heights are being computed correctly.
[18:43] <bac> gary_poster: but i'm getting different values when running test-server vs test-debug
[18:43] <benji> for testing my current hypothesis, the number of services doesn't matter
[18:43] <bac> i assume this has been dealt with before...  any pointers?
[18:44] <gary_poster> benji, dunno, but he had N services/2000 units
[18:44] <benji> right
[18:44] <gary_poster> bac, um.  the closest tests I know of are the hairy ones for the help text
[18:44] <bac> pointers that is for writing a robust test that deals with varying sizes across test environments
[18:45] <gary_poster> bac, and sadly they are not the most robust.  they are not horrible, but they are one of the offenders
[18:45] <bac> i can easily show that the textarea grows or shrinks as expected but fuzzily
[18:45] <gary_poster> bac, that doesn't sound too bad...?  :-D
[18:46] <bac> if its good enough for my rice cooker...
[18:49] <ahasenack> gary_poster: I have a feeling I reported this already, but I don't remember. Can easily file a bug if needed: http://pastebin.ubuntu.com/5620058/
[18:49] <ahasenack> happened when taking down the unit
[18:49] <ahasenack> gary_poster: pyjuju doesn't run the stop hook iirc
[18:50] <gary_poster> ahasenack, ah!  thank you, sure, bug would be great.  was not aware of that myself
[18:50] <ahasenack> ok
[18:51] <ahasenack> gary_poster: ah, found the original report: https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1171490
[18:51] <_mup_> Bug #1171490: "stop" hook fails <juju-gui (Juju Charms Collection):New> <https://launchpad.net/bugs/1171490>
[18:52] <gary_poster> ahasenack, thanks!
[18:52] <ahasenack> gary_poster: can I mark this one as fixed? The branch is merged, but bug is open: #1152631
[18:52] <_mup_> Bug #1152631: Juju-gui installation fails from lp:juju-gui <juju-gui (Juju Charms Collection):Confirmed for gz> <https://launchpad.net/bugs/1152631>
[18:52] <ahasenack> s/fixed/committed/
[18:52] <ahasenack> I don't know how you guys handle "Released"
[18:53] <gary_poster> ahasenack, it's released thank you.  I haven't been bug gardening lately
[18:53] <gary_poster> will get to it soon
[18:53] <ahasenack> np, I saw it by accident, I'm not stalking you :)
[18:54] <gary_poster> ahasenack, lol, np
[18:54] <benji> heh
[18:57] <hatch> hav there been no proposals or anything all day?
[18:57] <hatch> I haven't had any emails in a while...
[19:11] <hatch> there they all come....
[19:11] <rick_h_> bwuhahahaha
[19:11] <rick_h_> email overload
[19:13] <hatch> haha oh well
[19:13]  * hatch pushes them off till later
[19:13] <hatch> does anyone have any tips as to how to respond to env.get_service calls from within the application?
[19:14] <fwereade> gary_poster, bac: would you consider it a good thing or a bad thing if I were to change Options on ServiceSet (hm, why not Config?) and Config on ServiceDeploy to map[string]interface{} (from map[string]string)?
[19:14] <fwereade> brb
[19:15] <bac> gary_poster: i've got a branch that adds the resizing plugin.  i'm going to get it reviewed and landed and then wire it up with our config ui
[19:16] <bac> gary_poster: why do you need the change to the sig?  i guess going from specific to general is ok if there is a reason
[19:16] <gary_poster> fwereade, I'm guessing this is to be able to get bools, ints and floats?  if we clearly know what to send you for each type, I think we can adjust.  we probably need a period of backward compatibility.
[19:16] <gary_poster> bac I think you meant fwereade for the second one yeah?
[19:16] <bac> oh
[19:16] <gary_poster> bac for resizing sounds great
[19:17] <hatch> oh I should pass the fakebackend stuff into my environment
[19:18] <bac> fwereade: yeah, what gary_poster said.  we can adjust if the change is needed for internal purposes
[19:19] <m_3> gary_poster: sure... sorry for the imcomplete changeover
[19:20] <gary_poster> m_3, thanks, np
[19:24] <fwereade> bac, gary_poster: well, the issue is just that untyped service config data is kinda... wrong -- it's not how we store it and it's not how we return it -- but the actual wrongness is in fact relatively low-impact: I *can* just fix state and leave the API untouched, and I should probably just do that
[19:25] <fwereade> gary_poster, bac: I was only really asking in the hope that you'd say "oh god it's such a mess at the moment yes please" ;p
[19:25] <fwereade> gary_poster, bac: and in the absence of that, I think it's best to keep compatible
[19:32] <gary_poster> fwereade, heh.  The only related thing we'd say  "oh god it's such a mess at the moment yes please" is to divide up text lines and text multi-lines in the schema.  The fact that "string" can be either has consumed a sad number of days of development to produce an attractive UX that can look like a text line but expand to a text area.  It's just about done, but clarifying that would still be fabulous.  The other thin
[19:32] <gary_poster> g you describe would be nice theoretically but is not causing us practical problems.
[19:35] <m_3> gary_poster: they match now... I'll automate that until jujucharms.com is updated (requires sitdown in oakland evidently)
[19:35] <gary_poster> cool, thanks m_3!
[19:35] <fwereade> gary_poster, heh, I can imagine the hassle, but I can't see an obvious way to resolve it
[19:36] <gary_poster> fwereade, cool, then at least we already have almost solved it. ;-)
[19:36] <rick_h_> bac: might want to check out http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/javascript/formwidgets/resizing_textarea.js for any corner cases 
[19:36] <rick_h_> bac: didn't look close but worth a run through. 
[19:38] <bac> rick_h_: well, isn't that interesting!
[19:38] <rick_h_> bac: sorry, thought it was tied to the editor stuff in LP and then you guys were going RTE and such so thought you were doing html -> plain text. 
[19:39] <rick_h_> but seeing your Y.Plug looked famaliar :)
[19:39] <gary_poster> boo hoo
[19:39] <gary_poster> rick_h_, does that one have tests?
[19:39] <bac> rick_h_: it should've been packaged as a YUI utility and open sourced.  then we would've found it
[19:39] <rick_h_> gary_poster: definitely. 
[19:40] <rick_h_> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/javascript/formwidgets/tests/test_resizing_textarea.js
[19:40] <gary_poster> rick_h_, bac, boo hoo.  talk it out among y'selves and figure out what to do?  I'll join if desired, and leave it to you to decide otherwise.
[19:40] <rick_h_> gary_poster: sorry, just maybe run through mine and see if I covered any corner cases you didn't consider. Maybe check tests for ideas of tests missing
[19:41] <gary_poster> rick_h_, well, yours is battle tested, yeah?  My default thought would be
[19:41] <rick_h_> gary_poster: well been on LP for 6mo? so not aware of any bugs filed against it. 
[19:42] <gary_poster> "Does the LP one behave the way we need it to?  Can we import it directly?  If so, let's use it."
[19:42] <gary_poster> but bac, I'm leaving that decision to you, with me to help out or make a decision if you want me to.
[19:42] <rick_h_> quoted from?
[19:42] <gary_poster> sorry rick_h_ , I meant, that would be my default thought
[19:43] <rick_h_> ah, gotcha. Thought I missed an email/convo I should have seen
[19:43] <gary_poster> I was quoting my imaginary self ;-)
[19:43] <bac> gary_poster, rick_h_: sure, i'd prefer to just use the one in production.
[19:44] <rick_h_> bac :( so sorry I didn't come forward sooner. 
[19:44] <gary_poster> bac, assuming it meets all our needs
[19:44] <rick_h_> bac: really did think you guys were doing more html stuff
[19:44] <bac> rick_h_: well, we didn't put out a group-wide call for ideas
[19:44] <gary_poster> rick_h_, if you weren't here then we wouldn't even know now
[19:44] <bac> gary_poster: yes, after verifying it works for us
[19:45] <bac> gary_poster: if we use it, do we need to port the tests over or just treat it as 3rd party code?
[19:46] <gary_poster> ok bac.  I'll hold off on reviewing the rest of your branch then.  FWIW, the only comment I had so far was that AFAIK we put files like this javascripts/assets and don't need a plugins dir
[19:46] <gary_poster> bac, port tests: I would prefer so, yes.  LP is being maintained admirably, but...
[19:46] <rick_h_> so bac, first glance I don't copy over all the font attrs, but I don't see you watching for window resize events that might effect the text input. 
[19:46] <gary_poster> bac, alternatively you can release it separately :-P
[19:46] <bac> gary_poster: we discussed that and thought assets was for 3rd party stuff.  since the plugin was home grown i treated it as such
[19:47] <bac> gary_poster: if we use LP's then i'd put it in assets
[19:47] <rick_h_> bac: I'd probably have done it in widgets even though it's not technically a Y.Widget 
[19:47] <bac> yeah, well...
[19:47] <bac> directories are cheap
[19:47] <rick_h_> bac: true
[19:48] <gary_poster> bac, ack. FBOW, ns-routing-extension, reconnecting-web-socket, d3-components, and app-subapp-extension are all precedent for our general-purpose code going in assets/javascripts
[19:48] <rick_h_> ok, well let me know if I can be of any help bac. The tests and such are in that dir. To check it's use file a bug and on the bug entry it auto resizes. 
[19:49] <bac> rick_h_: thanks!
[19:49] <gary_poster> rick_h_, does it start at essentially a single line, or is it easy to make it do that?  bac, does yours work that way?
[19:49] <rick_h_> gary_poster: it takes a min-height setting
[19:49] <gary_poster> ok
[19:49] <bac> ditto
[19:49] <rick_h_> gary_poster: so filing bugs it starts out at some 50 lines ish
[19:49] <gary_poster> cool
[19:49] <gary_poster> cool thanks
[19:49] <bac> wth FBOW?
[19:49] <gary_poster> for better or worse :-P
[19:49] <rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1157138 and click edit icon on the bug description box
[19:49] <_mup_> Bug #1157138: deploying a new service does not update service name in environment view <juju-gui:Fix Committed by gary> <https://launchpad.net/bugs/1157138>
[19:49] <bac> ohs
[19:49] <rick_h_> bac: FBOW?
[19:50]  * gary_poster used it
[19:50] <gary_poster> above
[19:50] <gary_poster> my fault
[19:50]  * rick_h_ is slow EOD :P
[19:50] <gary_poster> I was overcome with a lack of desire to type "for better or worse"
[19:51] <gary_poster> in punishment, I have now typed it twice :-P
[19:51] <gary_poster> rick_h_, I'm going to try updating the demo site...
[19:51] <rick_h_> gary_poster: k
[19:56] <bac> rick_h_: yeah, that seems to be what we want, at least from playing with the bug entry box
[19:56] <rick_h_> bac: :/ cool. 
[19:56] <bac> rick_h_: i may bug you later.  let me pull it in and see what happens
[19:56] <rick_h_> bac: definitely. anything I can do to help
[19:56] <benji> ok, I have reproduced one delta-related leak: service annotations cause memory usage growth over time
[19:59] <hatch> u go girl!
[20:01] <hatch> gota love debugging those memory leaks
[20:01] <hatch> usually when you find the cause you're like 'oh duh...no wonder this is causing a leak' heh
[20:06] <gary_poster> rick_h_, OPTIONS from manage.jujucharms.com...interesting is not working from the GUI, at least over https
[20:06] <gary_poster> rick_h_, see tinyurl.com/jujugui
[20:06] <rick_h_> gary_poster: 'not working'? as in no response?
[20:06] <rick_h_> looking
[20:07] <gary_poster> rick_h_, I meant tinyurl.com/jujucharms sorry
[20:07] <rick_h_> gary_poster: yea, fighting the app cache or something atm
[20:08] <gary_poster> rick_h_, it loaded for me on one machine now
[20:08] <gary_poster> trying first one again.  rick_h_ the https aspect appears to be a big issue
[20:08] <gary_poster> because a lot faster over http
[20:08] <rick_h_> gary_poster: k, the bug fix for the OPTIONS loading is on staging. but not manage. yet
[20:09] <gary_poster> rick_h_, ah ok.  you want me to switch the jujucharms thing to staging?  Maybe just for a second, to see the difference?
[20:09] <rick_h_> gary_poster: sure, but it'll be non-https so won't show the https overhead as well I guess
[20:10] <gary_poster> rick_h_, oh right then it won't work
[20:10] <rick_h_> gary_poster: mthaddon is past EOD but can see if mew can set it?
[20:10] <gary_poster> nm
[20:10] <rick_h_> bah, why won't the app cache load? but going straight to it laods
[20:10] <gary_poster> rick_h_, you mean change it on manage.jujucharms.com?
[20:10] <rick_h_> gary_poster: can see if mew can upgrade the rev on manage.jujucharms.com
[20:10] <gary_poster> rick_h_, that would be cool
[20:10] <rick_h_> we didn't update because the apache side isn't ready and mthaddon is EOD
[20:11] <gary_poster> ah, gotcha
[20:12] <rick_h_> coming empty for mew in #is 
[20:12] <rick_h_> coming up empty that is
[20:12] <gary_poster> k
[20:12] <rick_h_> gary_poster: so yea, OPTIONS tooks 12s for me 11.5 of that receiving the 1.1MB payload
[20:12] <gary_poster> rick_h_, ack
[20:13] <rick_h_> gary_poster: that's fixed, so the first one will turn into a 200ms request
[20:13] <rick_h_> the second one will still suck. I did some research today and it's the svg in the charms killing it. So have a card to re-thjink that. a single charm json dump goes frmo 3k to 48k with the icon
[20:14] <rick_h_> since interesting is all the charms we've picked to have pretty svg icons it's all the charms that are giant and just makes it all worse
[20:14] <gary_poster> rick_h_, ack, svg makes sense.
[20:15] <rick_h_> gary_poster: ok, will hopefully have apache update tomorrow, will get a manage. deploy, and should help make a noticeable differnce with the long term plan to redo how svg/icons work.
[20:16] <gary_poster> rick_h_, cool.  if we can svgs separately--and maybe only get the ones we see?--then that sounds good to me to keep the rest as is, at least for now
[20:17] <rick_h_> gary_poster: yea, I'm thinking if we ship the visible ones, say 5 by default on sidebar, but do links servied from manage.jujucharms.com for the rest, they'll only load in small batches but be immediate for the first load
[20:17] <rick_h_> gary_poster: but that's off the top of my head, will see about a real fix/get more opinions. 
[20:17] <gary_poster> rick_h_, +1, though why don't we go for simplicity first and just load svgs as individual assets and see how that fares?
[20:18] <gary_poster> less code, better than what we have now, might be good enough
[20:18] <rick_h_> gary_poster: true, go all the way the other direction and see if we need to meet in the middle at all
[20:19] <gary_poster> yeah, at least with the images
[20:19] <rick_h_> gary_poster: right, agree
[20:19] <gary_poster> cool
[20:20] <gary_poster> trunk now hides the help text but I'm doing something wrong with a manual charm update...
[20:22] <hatch> LFR https://codereview.appspot.com/9035045/ plz :D
[20:22] <rick_h_> gary_poster: ok, abentley_ and I will work together to get a test of using links for svgs tomorrow and maybe we can revisit the staging site with some changes EOD tomorrow and re-evaluate
[20:23] <gary_poster> cool thanks rick_h_ .  any word on how stability of manage is going?
[20:24] <rick_h_> gary_poster: so we've got one *known* blocker where updates to the fulltext schema will break it. We have a card to get it into the data migration process to prevent it
[20:24] <rick_h_> gary_poster: so should be stable except when we do the ont thing we know that breaks it :)
[20:24] <gary_poster> heh
[20:24] <gary_poster> ok
[20:24] <gary_poster> have there been thoughts on how to make it more robust in general--isolation of some sort?
[20:24] <rick_h_> gary_poster: but we also need a migration story for when upstream changes how they present test data which has bit us before. They're going to file a bug from now on, but we don't have a good way to sync the changes
[20:25] <rick_h_> gary_poster: honestly, not a ton. Fire-fighting atm. 
[20:25] <gary_poster> gotcha.  I wonder if that kind of change is what we really need before we say we are ready. :-/
[20:26] <rick_h_> gary_poster: yea, but also we pull so much data from other places, bzr, juju gui stats, jenkins testing, we don't really know how fluid/etc those are yet because it's not been used. 
[20:26] <rick_h_> gary_poster: we're learning, and catching up. 
[20:27] <rick_h_> plus new tech to us like elasticsearch/mongo makes for fun learning and learning how to make it robust as well
[20:29] <gary_poster> rick_h_, ack.  the last one (new tech) is just hard, no question.  I was thinking more of the first kind of thing, but granted that you want to trust data sources because it is a lot harder not to.
[20:31] <rick_h_> ok, time to run away. have a good night all
[20:32] <gary_poster> you too, night
[20:34] <hatch> ok now I can finally get onto what I was working on last week wrt this service/charm stuff haha
[20:34] <hatch> talk about a refactor
[20:41] <benji> I hate consuming fundimentally non-visual technical information via video.  Write things down people.
[20:41] <hatch> ^ that!
[20:57] <jcsackett> rick_h_, hatch: can you think of any reason why calling .empty() would work in debugger, but not in regular execution? is "empty" timing sensitive?
[20:57] <hatch> jcsackett: no it's syncronous
[20:58] <hatch> the only thing I can think of is that the element is being re-rendered into the hole
[20:59] <jcsackett> hatch: well, something should be rendered into the whole right after i call .empty. but with debugger right after .empty() everything renders as i expect afterwards. without, not so much.
[20:59] <jcsackett> s/whole/hole/
[21:02] <hatch> hmm without any more context I can't really say
[21:02] <hatch> empty as far as I can tell will either error or work because all it's doing is calling remove and destroy on each child element
[21:03] <jcsackett> hatch: so, what i need is to completely reset a node; like it's overflow etc, because just calling setHTML doesn't then have the node scrolled at the top.
[21:03] <jcsackett> e.g. we render something that has overflow, we get scrollbars, but at render we're a few steps down.
[21:04] <hatch> node.set('scrollTo', 0);
[21:04] <gary_poster> hatch LGTM with small comments for test branch.  nice.
[21:04] <hatch> thanks
[21:05] <jcsackett> hatch: nope; it already shows scrollTo at 0, and setting it doesn't change it.
[21:05] <jcsackett> like i said, this worked in tests, but the actual ui not so much.
[21:05] <hatch> gary_poster: the reason why those clobberings aren't done in the beforeEach is because in the tests that don't clobber - if the code screws up it will cause the test to fail - which is what we want.
[21:05] <jcsackett> unless i pause with debugger.
[21:05] <gary_poster> hatch ok cool.  then go with my second suggestion :-()
[21:05] <gary_poster> :-) I mean
[21:06] <gary_poster> not blubber lips
[21:06] <hatch> haha - can do!
[21:08]  * Makyo dogwalks
[21:09] <hatch> benji: are there any docs/email about how to use the npm caching stuff you did?
[21:09] <hatch> jcsackett: does the content get deleted with empty?
[21:09] <hatch> it just doesn't scroll to the top?
[21:09] <benji> hatch: yep, docs/process.rst describes how to use it
[21:10] <jcsackett> hatch: if i pause via debugger, i see it get deleted. then on resume the new stuff renders as we would like.
[21:10] <jcsackett> if i don't pause, i don't see any evidence that empty was ever called, and the render problem is there.
[21:10] <hatch> benji: thanks - the docs are kind of all over the place haha so I wasn't sure where to look
[21:10] <hatch> the render problem being the lack of scrolling to the top?
[21:10] <jcsackett> hatch: correct.
[21:11] <hatch> hmm
[21:11]  * hatch puts thinking cap on
[21:11] <jcsackett> hatch: if it's not a simple thing, don't worry about it. i have just been reminded i have a dinner thing to get to today. i was just thinking there might be something simple about empty i didn't know.
[21:12] <jcsackett> but if it's just a synchronous destroy as i thought, then alas, there is no such luck. :-P
[21:12] <hatch> nope that sounds like some odd edge case thing to me
[21:12] <hatch> does it do the same cross browser?
[21:12] <jcsackett> hatch: yeah.
[21:12] <jcsackett> confirmed on FF and Chrome.
[21:13] <jcsackett> i'll pick it back up tomorrow, probably bug you more then. thanks for validating my fear, at least. :-)
[21:13] <hatch> haha np have a good night
[21:13] <jcsackett> you too.
[21:14] <gary_poster> night all
[21:14] <hatch> have a good night
[21:29] <hatch> anyone around for a quick review? https://codereview.appspot.com/9035045/
[21:37] <bac> rick_h_: your code went into our tree nicely and the tests seem easy to adapt
[21:37] <hatch> he had already written the same thing?
[21:39] <bac> thanks for the review Makyo.  that branch is being abandoned, though, for a better solution.
[21:39] <bac> hatch: yeah.  very nice too.
[21:39] <bac> hatch: part of an obscure skunkwerks project called "launchpad" :)  http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/javascript/formwidgets/resizing_textarea.js
[21:40] <hatch> lol looking
[21:40] <bac> about a zillion times better than the crap i was writing
[21:40]  * bac walks dog to avoid face removal
[21:42] <hatch> lol
[21:42] <hatch> this looks good
[21:42] <hatch> gona take a while to convert it all to camelCase
[21:42] <hatch> ......KIDDING
[21:42] <hatch> :P
[22:01] <rick_h_> hatch: stay away! :P
[22:01] <hatch> lol
[22:01] <rick_h_> bac: cool, glad it works for what we need then. 
[22:58] <huwshimi> rick_h_: I wouldn't start work on that icon sizes bug as it might be that Luca is mistaking the sizes with the featured icons which are larger (in both sidebar and fullscreen mode), unless of course things have changed. I was going to fix that up today anyway, but I might just reply to the bug with this note and see what he says...
[23:09] <rick_h_> huwshimi: not following
[23:09] <rick_h_> huwshimi: I know they said today they'll give us 3 dimensions to use for the badge later 
[23:09] <rick_h_> huwshimi: since the badge is always 40x40 and is too big on the sidebar and not big enough on the charm details
[23:10] <rick_h_> huwshimi: but my understanding is that if the url is /bws/fullscreen the charm-token icon should be 96x96 vs 64x64
[23:11] <huwshimi> rick_h_: Right, that's what the bug says, but that's not what the visuals have, I just wanted clarification...
[23:11] <rick_h_> yea, that's what I was telling them. They verified that's what they want
[23:12] <rick_h_> huwshimi: so I think this one falls into the outdated visuals category :/
[23:13] <huwshimi> rick_h_: I'm not convinced it's not an oversight... :)
[23:17] <huwshimi> rick_h_: We need to clarify that they no longer want the sidebar "Featured charms" section at 96px now anyway, so I'll add a note to the bug
[23:19] <rick_h_> huwshimi: ok, I'm missing something. WHen was featured 96x96
[23:19] <huwshimi> rick_h_: Oh, actually the new WIP visual we got in that email thread the other day has 96px for everything. So you're right, it looks like it will change
[23:20] <rick_h_> except sidebar, which is 64 right?
[23:23] <huwshimi> rick_h_: There's no sidebar in that mockup, but I assume it'll be 64. No idea about the Featured Charms section though.
[23:23] <rick_h_> k