[13:39] <gary_poster> bcsaller, hey.  when you get in ping me please and let's have a quick call and/or pair a bit
[13:40] <bcsaller> gary_poster: sounds good, want to aim for around 9am EST?
[13:40] <gary_poster> +1 bcsaller 
[14:07] <bac> hi benji, question about object literal formatting
[14:07] <benji> sure
[14:08] <bac> the 'closing brace not on a line by itself' rule means all outstaning closing braces bunch up on the last real line?
[14:08] <bac> looks funny
[14:10] <benji> bac: I'm not super happy with that either, but it seems to be the prevailing way in JS land, and it keeps down the vertical explostion that happens when even a few literals are nested
[14:11] <bac> yeah, but any visual attempt to match closing is completely lost
[14:12] <benji> agreed; braces suck <shrug>
[14:12] <benji> I guess it's a "pick your poison" kind of thing
[14:12] <bac> benji: so is this correct?  http://paste.ubuntu.com/1407811/
[14:12] <benji> bac: nope, let me paste that reformatted real quick
[14:14] <benji> bac: here you go http://paste.ubuntu.com/1407818/
[14:15] <benji> that snippet of code is a very good test case, by the way
[14:15] <benji> we should use it to vet/demonstrate whatever style we use
[14:16] <bac> benji: hope i'm not being annoying but "object literals have their opening brace on a new line"
[14:16] <bac> so line 2 should begin with a brace,no?
[14:16] <benji> bac: that is the current/old one; my branch that includes the new style hasn't landed yet; I figured that we would discuss it at the standup this morning before I landed it
[14:17] <bac> ok, well i can't very well follow unpublished rules.  :)
[14:17] <benji> ...since apparently my mail to the list went unnoticed
[14:17] <benji> what, next you'll want to be able to read the secret laws enforced by the goverment
[14:18] <bac> yeah, that "no standing unless you can prove we did what we won't tell you did" is great orwellian logic
[14:19] <benji> bac: Wikileaks to the reascue: http://paste.ubuntu.com/1407828/
[14:23] <bac> benji: i'd change line 62 to say 'equal sign or colon' to address code like line 94
[14:23]  * benji looks
[14:24] <benji> ah, yeah that would be good; doing so
[14:35] <bac> benji-the-style-guru, what do you think about this: http://paste.ubuntu.com/1407868/
[14:43] <benji> bac: looks good; the spaces before/after the braces aren't to my particular liking, but I don't know if they are common or not
[14:44] <bac> the SG used to say " there is a space after the opening brace of an object literal"
[14:44] <bac> benji: but, under the new regime, shouldn't the brace be on the previous line, which would look funny
[14:45] <benji> nope, they are one-liner object literals; I guess I should clarify that the style guide is talking about multi-line.  If it will fit on one line, there is no reason not to do so
[14:46] <bac> a-ok
[15:07] <bac> frankban: "2) By default, clicking on ``Charms``, I only see one deployed service. I
[15:07] <bac> expected to see five of them (the five ones I see in the env view)."  -- I think this is a problem with the sample.json file showing deployed services that do not actually appear in the charm store.
[15:07] <bac> frankban: we should get a fix made to the sample.json if that is the case so it isn't confusing
[15:09] <frankban> bac: yes, I agree
[15:09] <bac> frankban: as to what constitues 'deployed', i show those that have a matching package name, not the exact same charm.  i'll clarify with jovan
[15:14] <frankban> bac: is it possible to check for the same charm? If so, what do you think about creating a card to implement that? I deploy a service using a charm, and when I filter for "deployed" charms, I'd expect to see only the charm used to deploy that service. But yes, maybe that's a UX question.
[15:14] <gary_poster> Makyo, hey.  I'm working on my branch, assuming you didn't get around to it last Friday.  Safe assumption?
[15:15] <bac> frankban: yes, in fact it is easier to just match the exact charm.  my interpretation is different.  so, the UX dudes need to decide.
[15:15] <Makyo> gary_poster, Yep, been buried in tests.
[15:15] <gary_poster> cool Makyo
[15:15] <bac> frankban: fwiw, my original implementation did what you suggest but i found it unhelpful
[15:16] <frankban> bac: because you already can see the deployed charms in the env scene? 
[15:18] <bac> frankban: b/c i thought the user might want more choice.  i'm not strongly defending that stance, though, so i'm glad you raised the point.
[15:28] <hazmat> 2m standup bac, bcsaller, benji, frankban, gary_poster, Makyo, teknico 
[15:28] <gary_poster> thanks
[15:39] <bac> benji: i'm going to land my branch using the new style
[15:40] <gary_poster> :-)
[15:40] <benji> k
[15:40] <teknico> hazmat, http://pastebin.ubuntu.com/1408004/
[15:42] <bac> goodspud: please ask jovan to join
[15:44] <goodspud> bac, emailed him... he left the room
[15:44] <bac> goodspud: ok thanks
[15:48] <Makyo> Actually, going to bring my laptop with me to the vet to finish current task. Won't have IRC, but will have email.
[15:49] <mattuk1972> makyo - thats dedication :-)
[15:50] <Makyo> mattuk1972, the waiting room is crazy boring, anyhow :P
[15:50] <Makyo> Anyway, available on email if needed.
[16:01] <gary_poster> hazmat, I think I am on call...do you think you are on call?
[16:01] <gary_poster> noone here
[16:02] <hazmat> gary_poster, i'm around
[16:03] <gary_poster> hazmat yeah wrote that just before you joined
[17:20] <bac> hi jovan2, thanks for your reply.  it does make sense
[17:20] <gary_pos`> hazmat, are co-located services supposed to be able to have a special relationship with one-another, or are they only sharing the same machine as an optimization, or something else?
[17:20] <jovan2> bac: great, thanks.
[17:20] <bac> jovan2: if a deployed charm is no longer in the charm store then it just won't match
[17:20] <gary_pos`> s/one-another/one another/
[17:20] <hazmat> gary_pos`, density only. no relation
[17:20] <gary_pos`> cool thanks hazmat
[17:22] <jovan2> bac: can we capture that fact and then display alternatives for that charm that are actually in the charm store now?
[17:22] <jovan2> bac: so if mysql3 is deployed but no longer in the charm store we can instead display mysql 4 or 5 or whatever?
[17:24] <bac> jovan2: that is getting complicated to implement.  perhaps we can talk about that as an enhancement but it will not be straightforward.
[17:25] <bac> jovan2: something like if a charm is in the charm store results and matches exactly with one deployed, show it.  if there is no match but the package for the charm matches a deployed charm then show all charms of that package?
[17:27] <jovan2> bac: I'm not sure what you mean by that last statement, about no match but a package match…
[17:28] <bac> jovan2: that is the case where the deployed charm is no longer in the charm store
[17:28] <bac> mysql3 in your previous example
[17:29] <bac> so if there is a mysql3 deployed and the charm store search results have some other mysql charms, then show all of them because the packages are the same
[17:29] <jovan2> bac: how is matching done, I assume it's on more than the charm name?
[17:29] <bac> personally i think that's going to be pretty confusing
[17:30] <bac> jovan2: currently i'm making a list of packages that are represented by deployed charms and use that to filter the results.  but that's incorrect per your email.  so i would create a list of exact charms deployed and use that to filter the result set.  but we can mix and match.
[17:31] <bac> jovan2: i think this extended behavior needs to be given some more thought.  for the first pass i'd like to land using the exact charm filtering
[17:32] <jovan2> bac: ok, but for an extreme example, what happens if *none* of the charms match?
[17:32] <bac> not extreme at all.  in that case the 'deployed' selector will not show anything
[17:33] <bac> that case will happen anytime you search for something that has not yet been deployed
[17:33] <bac> jovan2 is that what you mean?
[17:33] <bac> jovan2 should we do a G+ hangout?
[17:34] <jovan2> bac: yes we should
[17:34] <bac> jovan2: i'm in the juju-gui hangout
[17:44] <bac> thanks jovan2
[17:44] <bac> frankban: still around?
[17:44] <frankban> bac: yes
[17:45] <bac> frankban: the behaviour you saw with the app not filling the browser is present in trunk but not seen on staging
[17:45] <jovan2> bac: I'll document what we agreed in our Q&A spreadsheet: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AghxhFfxY6uqdEFrNTdRbFdLTDRpRjJhOE5QWXR6ckE#gid=0
[17:45] <bac> frankban: on trunk if i resize my window, then it'll grow to fill
[17:46] <bac> frankban: so something weird is happening but i don't think i introduced it
[17:46] <bac> frankban: is that what you were seeing?
[17:50] <frankban> bac, I was seeing the charm panel partially going over the status bar (at the bottom of the page)
[17:51] <gary_poster> fwiw, uistage redraw-on-resize seems to be working well for me, including with charm browser open
[17:52] <frankban> bac: http://ubuntuone.com/1b9iMmsKd8EklKIdQKVtmK
[17:57] <bac> gary_poster: yes, me too
[17:58] <gary_poster> cool
[17:58] <bac> gary_poster: just not trunk running locally
[17:58] <gary_poster> oh
[17:58] <gary_poster> weird
[17:58] <bac> frankban: yes, i see what you're describing.  i did not take into account the new height of the filter widget.  good catch.
[18:01] <gary_poster> hazmat, have you already determined from Dean or therve when they are scheduling the Landscape work that we depend on?
[18:14] <hazmat> gary_poster, just got back from lunch.. i'll schedule a meeting
[18:40] <hazmat> gary_poster, meeting scheduled and email sent.. i'm hoping if we can nail down the annotations format, we should be able to work in parallel without much issue.
[18:41] <gary_poster> ok cool thanks
[19:42] <gary_poster> ok bcsaller starting hangout unless you have one already...
[20:02] <bac> hi hazmat, with the new charm store search filter it becomes very obvious that the data improv is serving up is cooked.  by that i mean, the charms it claims to use are not ones that are now available in the charm store which makes the 'deployed' filter not have any matches.
[20:03] <bac> hazmat: could you update the sample data to have the URLs match those in the charm store?
[20:03] <bac> i realize this is not a scaleable request...
[20:04] <hazmat> bac in meetings for the next two hrs.. 
[20:04] <hazmat> bac... your saying the string values aren't the same?
[20:04] <bac> hazmat: yes, the charm store URLs
[20:04] <hazmat> bac those are real charm versions in the sample.json
[20:04] <hazmat> bac, they might not be current anymore though.. but they are valid
[20:05] <hazmat> bac so this speaks to needing historical data in the charm browser/api endpoint
[20:05] <bac> hazmat: yes, since they are not current they no longer match.  jovan has requested actual matching of the version
[20:05] <bac> hazmat: we can discuss it later when you are out of your calls
[20:05] <hazmat> bac thanks
[20:06] <hazmat> bac .. search should return current, but we should have info for older revs i agree.. the versions url refs are supported though they just return current atm.. let's talk more latter
[20:35] <benji> gary_poster: I'm ready to take over bug 1083618 if now is a good time for a hand-foff
[20:35] <_mup_> Bug #1083618: Automatically generate releases <juju-gui:In Progress by gary> < https://launchpad.net/bugs/1083618 >
[20:35] <benji> s/-f/-/
[20:35] <gary_poster> cool benji
[20:36] <benji> I want an IRC client that accepts sed replacement directives, like above, and applies them so you just see the fixed line
[20:37] <gary_poster> benji, clojure channel does that or similar IIRC
[20:37] <benji> heh
[20:38] <gary_poster> benji bzr+ssh://bazaar.launchpad.net/~gary/juju-gui/bug1083618/ is branch
[20:38] <benji> k
[20:38] <gary_poster> just committed my broken current state
[20:38] <gary_poster> if you uncommit and shelve that then it should work as it was when we talked last
[20:39] <gary_poster> tasks: 
[20:41] <gary_poster> benji http://pastebin.ubuntu.com/1408759/
[20:41]  * benji looks
[20:42] <benji> ok, all that makes sense
[20:42] <gary_poster> benji, also Kapil requested that main Makefile targets be grouped so it is easier to see what the API is when you look at the file, but that could be separate branch as you wish.  I would have done it separately
[20:42] <gary_poster> if you need anything else benji lemme know.
[20:42] <gary_poster> thank you benji!
[20:43] <benji> gary_poster: yeah, seperate branch seems appropriate; I suppose we would have an ASCII fence (###########) around them to draw attention to them
[20:43] <gary_poster> maybe so
[20:44] <bac> benji at your leisure would you re-review my branch?
[20:45] <benji> bac: sure; will do so right now
[20:45] <bac> it includes your changes, francesco's changes, new interpretation by jovan, and matt c's CSS tweaks
[20:47] <bac> benji i'm going to run an errand but will be back in a little while
[20:47] <benji> k
[21:46] <gary_poster> lost you bcsaller 
[21:46] <bcsaller> says I'm still connected
[21:46] <bcsaller> do you still have the vim session?
[22:03]  * Makyo briefly walks sedated dog.  Should be interesting.
[22:04] <benji> Makyo: you need to video that; sounds like YouTube gold
[22:05] <benji> right up there with the kids talking crazy stuff after having their wisdom teeth extracted
[22:09] <gary_poster> night all
[22:19] <Makyo> benji, he did run into a bush.  Wish I'd gotten it on video.  
[22:19] <Makyo> Got a picture of the aftermath, at least: http://s3.amazonaws.com/imgly_production/6307924/large.jpg
[22:26] <bac> ugh, sedated dogs are just sad.
[22:27] <Makyo> Yeah, he was whining just laying down earlier, but is much better now.
[22:27] <bac> but that doesn't stop me from using them as props to recreate famous American paintings
[22:27] <bac> http://www.flickr.com/photos/squishy/47501983/in/photostream/
[22:27] <Makyo> Turns out he broke a carpal bone in his front foot.
[22:28] <Makyo> Hahah, awesome