[00:00] rick_h_: sure [00:00] huwshimi: https://plus.google.com/hangouts/_/21324660ffbef8901b7665922ca8fd083514e628?authuser=0&hl=en [00:01] rick_h_: on way === rogpeppe1 is now known as rogpeppe [10:59] are you ready for some football! ... I mean landing! [11:07] luca_: morning [11:09] Hi rick_h_ how are you? [11:09] luca_: tired :) [11:10] rick_h_: hehe [11:10] luca_: sorry for the asking around for stuff that's still coming. We're basically hitting feature freeze today and trying to squeeze every last bit we can [11:10] luca_: do you guys have an asset for the reviewed charm graphic? [11:10] rick_h_: interesting! [11:10] rick_h_: you mean the star in the circle? [11:10] luca_: I asked huw about it and he didn't see one last night and didn't get a chance to look at it last night. [11:11] luca_: correct [11:11] luca_: I'd like to try to see if I can get something that 'works' in this morning asap [11:11] rick_h_: do you need it as an svg? [11:11] luca_: svg or png would be perfect I think. [11:11] actually, png would probably be best so we can sprite it with the rest [11:12] rick_h_: ok, no problem, Jovan is on the case [11:12] luca_: ty much! [11:12] rick_h_: If its feature freeze today then if I supply enhancements tomorrow is there still a possibility to get those implemented? or is today the cut-off? [11:13] luca_: so if they're bug fixes/tweaks there's a chance. but the goal will be to stop adding stuff and make what we have work smoothly [11:14] rick_h_: right, ok [11:14] luca_: so no promises. All depends on how much time we need to spend on polishing the stuff we do have. Why I wanted to get filters ready this morning so they get into the set of features to spend time polishing [11:14] same with the provider failing indicators, etc [11:15] rick_h_: I see [11:15] rick_h_: thank you :) [11:16] rick_h_: Has there been any conversation of when the next release is/could be? [11:16] luca_: the goal is to get everything running today [11:17] luca_: I've got 3 branches from the weekend that need to be reviewed and landed and we can't seem to keep charmworld (the backend) up and running atm so hopefully get all that in and by my EOD have things running [11:17] gui default, provider notification in place, and search filtering working [11:17] sorry, gui default == browser by default as some.ip.address/ [11:18] we'll polish and have another update release wed and then thursday change over jujucharms.com to point to the production setup we get going today [11:18] is my understanding at least [11:20] rick_h_: ok, that sounds good but also sounds like your gonna be super busy [11:20] luca_: nothing different ;) [11:20] come on the weekend! [11:30] rick_h_: hehe, when are you flying to SF? [11:30] luca_: sunday sometime [11:31] rick_h_: ah, cool, looking forward to my 9 hour flight! [11:31] luca_: heh, yea as much as I enjoy some of the europe visits, nice to just have a few hours in the air [11:33] rick_h_: yea, its nice to be able to fly for a short time and get somewhere different. [12:00] yay, I got my internet working again [12:01] working internet > * [12:01] heh [12:17] what was the problem benji with your internets? [12:18] I wish I knew. Ever 24 to 48 hours my router and/or laptop decide that they are no longer on speaking terms. Rebooting just one or the other doesn't help, both have to be rebooted. [12:18] all the other devices in the house stay connected just fine [12:27] jovan2: ping, can you help me with this badge? I'm trying to get things like up per the presentation but don't have exact numbers so winging it a bit. [12:28] jovan2: http://uploads.mitechie.com/lp/approved-badge.png is what I've got working but the badge looks too big. You gave me a 40x40 svg that I saved to a .png for spriting. What size is that supposed to be? [12:28] jovan2: and it looks like it's the same sized on the larger icon when viewing details? Is that correct? [12:34] rick_h_, hi. any word from Tom on schedule? [12:34] gary_poster: no, I started to talk with him this morning but he ran to a meeting [12:34] not heard back yet [12:35] ok rick_h_ , please let me know how that turns out. Maybe include me if you like. I want two pieces of info: the answer to your request and the answer to arosales Friday request (the Monday/Wed/(Thurs)/Fri schedule [12:35] ) [12:35] If I get that info without being involved, big +1 ;-) [12:35] gary_poster: k [12:36] but happy to be involved as well [12:36] understood [12:36] honestly, we've got our stand up in an hour and hoped to put sinzui on it since they've been working on this up to this point [12:37] ok rick_h_. makes sense (as long as it works out :-P ) [12:43] rick_h_, do you have any time to talk about a strategy for today--specifcally about a branch I am trying to land that you reviewed, and about spinners, and about how you want to work reviewing/landing the other branches you have pending? [12:43] gary_poster: sure thing [12:43] thanks rick_h_ guichat [12:44] loading [12:52] rick_h_: is there an ETA when the api will be up again? [12:52] luca_: working on it [12:53] rick_h_: ok [12:54] luca ping, can you help me with this badge? I'm trying to get things like up per the presentation but don't have exact numbers so winging it a bit [12:54] luca_: http://uploads.mitechie.com/lp/approved-badge.png is what I've got working but the badge looks too big. You gave me a 40x40 svg that I saved to a .png for spriting. What size is that supposed to be? [12:57] rick_h_: 40px should be correct [12:58] rick_h_: as far as I can tell from looking at the PSD's it is 40x40px [12:59] luca_: ok, looks big from the use [13:00] rick_h_: if you get it up today then we can take a look and tweak if need be [13:00] luca_: yea, see the screenshot [13:01] rick_h_: that screenshot seems to be zoomed in [13:14] luca_, my understanding from Friday [13:14] 's call was that we agreed that search filters are a very nice to have for this deployment, not a requirement [13:14] was that your understanding, or did I mishear? [13:14] luca_: it's not :) [13:15] luca_: it's on a window that's only 960px wide, but it's not zoomed in [13:16] luca_: putting it up for review and will try to have it for you guys to look at. That's an easy tweak we can do any time so if it's big now it's not killer [13:16] gary_poster: filters were a requirement, categories were a nice to have. [13:16] rick_h_, fwiw the whole image looks zoomed in to me too, just comparing service box sizes--you on a RMBP maybe? [13:16] luca_, ah :-( [13:16] gary_poster: no, just normal HD 21" display. Ok, I'll get it up and we'll go from there. [13:18] luca_, still don't agree that it is a blocker, but hopefully we don't have to have that discussion further. :-) I am going to suggest/request that we prioritize fixes/polish to other parts of the UX first, and be able to hide the search filters if necessary. Happy to have a call about this with you/ale/jovan to clear up my misunderstanding if desired [13:23] gary_poster: the reason its classed as a blocker is that information has been streamlined in certain views which are prohibitive to use, and show less information than what jujucharms.com currently shows, the filters are used a validators for decisions and therefore are prioritised as a blocker. Categories are not seen in the same light. For example the Ubuntu series is not shown on the charm token and was instead highlighted by the [13:23] filters. It doesn't stop the use of the product and therefore can be classed as a NTH but the UX is degraded. [13:24] rick_h_, I'm toying with idea of spinning up an EC2 GUI instance that we (1) turn sandbox on, (2) point to your ec2 charm thing, (3) use your "left hand default" branch with merges & conflict resolution from trunk [13:24] managed in a shared separate branch, perhaps [13:26] luca_, full ack that it is a very degraded experience without the filters. full ack that we want them, and if we can have them by rollout, we should.. Moreover, because rick_h_ worked all weekend, we might. However, I have two basic opinions about it in regards to schedule: [13:26] (1) it is better to have this deployed this week without filters than to not have it deployed. [13:26] (therefore it is not a blocker, technically) [13:27] (2) As a corollary, polish on other elements should come first, and we should make sure we have an escape hatch if we decide that the search filters can't make the cut [13:28] luca_, FWIW, if we agreed on the above, I would still say the chances are better than 60% that the filters will make it in this week. [13:29] hey hatch, you start in half hour, right? [13:32] luca_: staging is back up http://uistage.jujucharms.com:8080/bws/sidebar /cc gary_poster [13:33] gary_poster: I agree, there are higher priorities than filters but it has a huge knock on to the layout esp to the full screen charm browser. It's ok if you prioritise them below other stuff, we need to know as soon as possible if they don't make it in to figure out how to fix the layout in that case. [13:33] rick_h_: thank rick :) [13:35] luca_, understood and will do. thank you. [13:37] rick_h_, one more quick strategy call when you have a chance. [13:37] I will be happy to put a timer on it for < 2 minutes :-) [13:38] gary_poster: on standup[ [13:38] figured [13:38] rick_h_, link? [13:38] standup link [13:38] https://plus.google.com/hangouts/_/cf491220dfb7736cee2876baf29110eeb52f5997?authuser=1 [13:38] wuld like to join [13:41] rick_h_: API down again [13:41] :-( [13:47] gary_poster: yup I'm just finishing up breakfast and going through emails [13:48] cool hatch. let's talk/plan in 13 min or so ("so" being up to 30 minutes as you wish :-) ) [13:48] sounds good - might take me a bit to go through 50 emails :) [13:48] apparently someone was working over the weekend :P [13:48] :-) [13:49] oh they ported a yaml parser from c to go and took a 37% hit in speed....ouch heh [13:55] it only takes 0.3 seconds to build gojuju? wow [13:59] the past two days were +16-20C and lastnight it snowed.... [14:02] gary_poster: ok guichat? [14:05] hatch, on it. [14:06] https://bugs.launchpad.net/charmworld/+bug/1170099 [14:06] <_mup_> Bug #1170099: Promulgated branches not owned by charmers are not considered "reviewed". [14:07] thanks gary_poster [14:07] welcome rick_h_ (actually from sinzui on other channel :-) ) [14:21] rick_h_, I am going to work on getting the staging instance up rather than the filter review. Is that ok? [14:21] gary_poster: rgr [14:21] or should I do filter review first? [14:21] really up to you [14:21] gary_poster: no, let's get it up. I'll try to create a new root branch from the first one that makse the browser default [14:22] gary_poster: and pull the other two bugs, provider failures, reviewed icons on top of that [14:22] if we can get 3/4 branches up and in front of UX that's a win imo [14:22] ok cool rick_h_ . Lemme know when you have that. Maybe put that in a lp:~juju-gui branch so we can all manage if needed? [14:22] gary_poster: I will say thuogh the bug found in current staging is something that will blow up a staging instance fo r us [14:23] gary_poster: the test results threw out a new un-expected value and that caused some code to go boom [14:23] abentley: is lokoing at it right now [14:23] gary_poster: sure thing, I'll make sure to push them up there as a series of branches keyed off the browser default [14:24] rick_h_, should I change gui ec2 config to point to manage ec2 config? [14:24] I mean, point to your manage ec2 instance? [14:24] We can switch it out easily enough [14:24] later [14:24] gary_poster: cool, sure we can http://ec2-54-224-248-114.compute-1.amazonaws.com/ is my instance running now [14:25] cool rick_h_ will do [14:26] hey hatch [14:34] bac hey. quick call? [14:34] gary_poster: sure [14:34] bac cool guichat [14:40] fyi http://jsfiddle.net/ericf/FGu9G/ <- yahooapis.com on https ----- it's a secret ;) [14:43] cool :-) [14:43] benji, quick call? [14:43] gary_poster: sure [14:43] thx guichat [14:55] hatch do you have experience debugging JS memory leaks? [14:55] yep [14:55] hatch cool [14:55] * hatch goes to newegg.com and buys more ram [14:55] there fixed [14:55] ;) [14:55] gary_poster: I lost you [14:56] hatch, heh ok thx [14:56] gary_poster: but seriously, I have done it quite a few times so I can take a look if you need [14:57] hatch cool. may ask benji to talk with you [14:57] chrome heap snapshots ftw [14:58] yeah it kind of sucks with YUI because it hides a lot of the sources [14:59] but such is life [15:02] gary_poster: ok, lp:~juju-gui/juju-gui/default-all-the-things is the merge of all three branches. Merged fine and qa'ing some. [15:02] 826 tests....wow I am sure we had less than half that when I started [15:02] heh [15:03] hatch: yea, and still need a bunch more [15:03] thx hatch [15:03] oh I didn't write them all [15:03] I was just using it as a time reference point [15:03] :D [15:07] gary_poster: I'm not sure that it's ever ok to use `verisimilitude` .....just saying ;) [15:18] gary_poster: heads up that staging is up and enables QA of the branch you reviewed https://codereview.appspot.com/8651046/ [http://127.0.0.1:8888/bws/fullscreen/precise/varnish-2] [15:20] hatch :-P [15:20] rick_h_, great. on call will look asap [15:20] gary_poster: np, cool [15:26] hatch: Makyo bcsaller any of you able to do a second review on https://codereview.appspot.com/8797047/ please? [15:29] rick_h_, sure [15:29] Makyo: ty much === hatch is now known as eric_f === eric_f is now known as hatch [15:37] rick_h_, hmm, quick question. The icon looks fine but doesn't hold too much meaning on its own. Are there plans for adding title texts to some of these down the road? [15:37] Makyo: ah, probably should put a title on it. I missed it [15:38] just means "Reviewed charms" [15:38] rick_h_, yeah. Easy enough to tell from the source, but that won't be handy. [15:38] Makyo: well on hover it'll come up [15:39] rick_h_, Sorry, I meant at the moment. I'm fine with hover. [15:44] cool there is a Not LGTM as well as LGTM with the reviews [15:50] jujugui call in 10; please update kanban [15:51] * gary_poster sighs with relief [15:59] jujugui call in 1 [16:02] what's the hangout link? [16:03] nm [16:15] there is flash of 'add your new charms here' on trunk with rapi....is that expected or a bug with my code? [16:32] http://xkcd.com/303/ "tests are running" [16:34] http://xkcd.com/303/ "lbox is lboxing" [16:34] ;) [16:39] gary_poster: if you have a few minutes... https://codereview.appspot.com/8686047/ [16:39] I am pretty sure this is what you had in mind [16:41] bac: how are things going with that conversion? === matsubara is now known as matsubara-lunch [16:52] hatch, cool looking [17:00] hmm, I've been waiting for an ec2 instance in "agent-state: not-started" state for 25 minutes. I think it's not happy. [17:33] doh, all the UX folks are gone. [17:34] look on the bright side.... [17:34] ...now you can do whatever you want! [17:34] ;) [17:36] big purple dinosaur as the new juju gui background coming up! === deryck is now known as deryck[lunch] === matsubara-lunch is now known as matsubara [17:50] does anyone know how to get db.charms.add({id: charmId}).load() to respond properly in the tests? I can't seam to find that being tested anywhere [17:53] ^ jujugui [18:03] hatch, I think there are tests of the load method itself, aren't there? [18:04] that's a yui method [18:04] I know hatch [18:04] looking [18:04] I was hoping some kind of a shim on the connection or something [18:04] I may be totally missing it too :) [18:05] hatch, test_model.js it('must send request to juju environment for local charms') ? [18:05] (and following) [18:06] gary_poster: yep found that - I guess I could listen for that and then respond with the proper data [18:06] I think... [18:16] gary_poster, diff for read-only mode server enforced.. http://paste.ubuntu.com/5616764/ [18:16] looking [18:19] hazmat, short and sweet. funny that filter can be .startswith('get') but looks right :-) [18:22] hatch, LGTM with trivials, finally [18:22] haha np - I figured you were busy and started on the tests :) [18:22] :-) cool [18:23] gary_poster, if we were using 'status' it would be the exception, but we're not. [18:23] right [18:31] so how would I go about responding from stocketstub? [18:31] hatch, there are lots of examples of that, I think [18:32] looking [18:34] hmm I haven't found any yet...but still looking [18:34] hatch msg: conn.msg({op: 'login', result: true}); [18:34] hmm lemme try that - the socketstub code makes it look like that does nothing [18:35] because onmessage is empty [18:35] hatch, onmessage is the websocket api [18:35] if you want to listen to a websocket message then you mockeypatch onmessage [18:36] sure but conn.msg calls this.onmessage() which is empty, so I need to return that to the .load() method somehow [18:36] maybe I'm just not getting it... [18:36] :) [18:37] hatch, look at app/env/base.js [18:37] connect function [18:37] this.ws.onmessage = Y.bind(this.on_message, this); [18:38] in many tests, this.ws == SocketStub instance [18:39] ahh ok so it's firing a msg event with the data [18:39] right [18:39] ok I'll setup a logger in there to find out the format of the response [18:40] thanks [18:54] benji is charm broken for branches or something? [18:54] gary_poster: not that I know of. [18:55] benji cool (you've been using it that way a lot I assume). I got a start error that didn't look good [18:55] nope, it works fine for me [18:55] great [18:56] yeah ok I don't get it....for me to be able to fire an event from the socketStub i need it to be augmented with the yui event code [18:57] gary_poster, who should I speak to about the impact of a change to ServiceDeploy.ConfigYAML handling? [18:57] bac, do you have brain state from the above ^^^ or should I take it? [18:58] I guess I could just overwrite the modelLists load method [18:58] that would probably be the best [18:59] fwereade_, try me. :-) I can spread the word if needed [18:59] * bac looks [18:59] gary_poster, bac: we're not compatible with python and the fix got lost in the noise, but we're doing it now -- in short it needs to be a map with the service name as a top-level key and the config map as a value [18:59] gary_poster, bac: https://bugs.launchpad.net/juju-core/+bug/1167465 [18:59] <_mup_> Bug #1167465: service set (and deploy) uses wrong YAML config syntax [19:00] fwereade_, ah right. so how is that interpreted if the yaml has one name and ServiceName is another? [19:00] gary_poster, bac: I think the use case is "single config file for your whole environment", but it was originally implemented before my time [19:01] gary_poster, so if the service name is not present as a key, I think we would barf [19:01] ah ok [19:01] so ConfigYAML takes precedence over Config [19:01] and nonsensical ConfigYAML == barf [19:01] gary_poster, (given that use case, it's clearly crying out for a set-many-service-configs, butI derail) [19:01] :-) [19:02] fwereade_, happily atm that should not affect us: if we receive a yaml file we currently pass it to juju to handle [19:02] gary_poster: i can take this one next if you make a card [19:02] gary_poster, honestly I will probably cause Config and ConfigYAML to be mutually exclusive if I'm not given a really good reason not to [19:02] fwereade_, works for us. We treat them that way. [19:02] gary_poster, great, thanks [19:02] bac, do we actually need to make a change? [19:02] fwereade_: the gui tests and throws an error if they are both presented [19:03] bac, <3 [19:03] :-) [19:03] gary_poster: i'm not sure [19:03] bac, I don't think we do. We transparently send the file over [19:03] bac, you shouldn't need to change anything unless you know of people depending on broken-style ConfigYAML usage [19:03] right [19:03] gary_poster: ok. there was an inconsistency that i just handled in the gui and i couldn't tell if this was it [19:03] clearly i misread [19:05] ah. bac, I think this is all there is to it: http://pastebin.ubuntu.com/5616924/ [19:05] we pass through config_raw transparently [19:05] thank you for the heads up, fwereade_ ! [19:05] gary_poster, np, take care :) [19:05] :-) === deryck[lunch] is now known as deryck [19:09] I have two reviews up that are related to one-another. Both are small: https://code.launchpad.net/~benji/charms/precise/juju-gui/use-npm-cache/+merge/161477 and https://codereview.appspot.com/8686048 [19:12] benji, how much time do we save? [19:13] gary_poster: 1 and a half minutes [19:13] benji: ooh, that's sweet to have it push new versions up. [19:14] pretty much dead-on what we expected from the testing [19:14] we just end up having to keep a secnod branch, add the file, commit, push, etc [19:14] benji, cool. so 4 minutes -> 2.5 minutes? [19:14] gary_poster: do you feel that this test is a good enough way to determine that it's successful? https://gist.github.com/hatched/1556b19e5929742a846b [19:15] looking [19:15] gary_poster: in my testing the baseline was 11.5 minutes (so 10 minutes after); this was using an m1.small [19:16] woah email flood [19:16] I tried testing with an hs1.8xlarge instance (which has an SSD) but juju doesn't understand that instance type. [19:16] sorry hatch [19:16] :) [19:16] lol it's ok it was just like 'ddddddddddddding' [19:17] fancy email clients kill ya every time [19:17] notifications and such :P [19:17] yeah - honestly I don't think I can switch to linux fully until it gets a nice email client [19:17] turning off email notifications is one of the best things I have ever done [19:17] hatch: it's got a great one. mutt [19:17] benji is that from deploy, or after juju-gui-source-stable -> juju-gui-source=lp:juju-gui and look at logs? the former, I'm guessing/hoping? [19:17] runs in a tmux session just peachy, never bothers me. [19:18] I use postbox [19:18] gary_poster: yep, that is from the moment the deploy command returns until the moment agent-state is "started" [19:18] cool [19:18] I suspect the second option would be closer to the 4->2.5 [19:19] I really wanted to know what it would do with that mega instance (over 3 bucks an hour!) but since juju didn't grok it I decided to move on [19:19] benji: does npm have the same issue as pip though? Serial installations of deps? [19:19] rick_h_: postbox is great - it does threading, hiding 'quoted' emails, and it looks great to boot :) [19:20] oh and it has google, linkedin, and evernote integration [19:20] benji: I found that the d/l cache didn't help at all really over local pip mirror because most of the time was in running one setup.py install after another [19:20] hatch: the only thing I wish I could do in mutt is mute a thread. One day I'll break down and write some script that'll add that thread to my imapfilters or something [19:21] ahh yeah that is a great feature [19:21] especially for things like google groups which send an email every time a thread is updated [19:21] hatch, that looks good. (1) undo your .load monkeypatch when you clean up! [19:22] (2) assert that the charm doesn't exist before you wait on your promise [19:22] definitely :) [19:22] alright good idea [19:23] hatch, you *could* assert in the load callback that env strictEqual env [19:24] that would test a bit more of your code [19:24] That came from thinking of other approaches than the load monkeypatch [19:24] I can think of others, but that's the only real advantage I can see [19:25] rick_h_, lp:~juju-gui/juju-gui/default-all-the-things doesn't exist afaict! :-) [19:25] that's why my charm was puking [19:26] gary_poster: oh, sorry I thought we weren't using it so cleaned up the branched [19:26] branches that is [19:26] rick_h_, heh oh ok [19:26] gary_poster: good idea, added [19:26] cool hatch [19:26] gary_poster: once I get qa on the provider UX that'll land and the only two left are browser by default (not happening) and the filters which needs review still [19:26] gary_poster: the reviewed icons landed on uistage [19:27] alright taking lunch bbl [19:27] rick_h_, I thought you didn't need qa on provider UX? I can look if you want [19:27] gary_poster: oh, your last note was you wanted to qa so figured I'd wait :) [19:27] rick_h_: I'm not sure SSDs would help, but going from an m1.small to an m1.xlarge helped quite a bit (the m1.xlarge has "High" disk performance and the m1.small has "Moderate") [19:27] gary_poster: no, I think it's safe [19:27] gary_poster: so nvm, I'll land that as well so 2/4 for UX then [19:28] * benji resumes reviewing Rick's branch. [19:28] :-) [19:28] gary_poster: if you want the browser default back I can put something up. Sorry, kind of thought with the re-schedule things were changing [19:30] 2/4: cool rick_h_ . Yeah, sorry about miscommunication on qa. I said I wanted to do it this weekend, but you said today that you thought it was fine. I meant to let you land without waiting for me. [19:30] rick_h_, sure let's put it up--or I can, assuming the merge is trivial [19:30] gary_poster: yep, so far the merge has gone clean [19:30] cool [19:31] rick_h_, remind me what the url is of your ec2 manage instance? [19:31] gary_poster: just shut it down as staging and manage. are fixed [19:31] paying for 5 running boxes :( [19:31] rick_h_, oh, for good!!! [19:31] http://manage.jujucharms.com/api/0/charms/interesting [19:31] rick_h_, I mean, curtis thinks staging and manage are reliable now? [19:32] so they're up and the bugs are in progress to prevent from happening again. [19:32] gary_poster: so they should be stable in the next day/two. For now we're fragile on upstream changes to data we'll be protected against. So my ec2 won't be any more stable than them it appears [19:33] except I still swear canonistack if chaos-monkey'ing our staging instance [19:33] gary_poster: so why I suggest going with manage. [19:33] rick_h_, so manage works well enough for us? [19:33] gary_poster: yes [19:33] yay! [19:34] gary_poster: so I'll probably update config-prod to point to it at some point in the future here this week. [19:34] great. I will change charm too [19:40] * rick_h_ taps keyboard waiting for uistage to update... [19:55] gary_poster: you suggested moving endpoint.js handleServiceEvent into the modelController...but then we would need to pass along reference to the addServiceToEndpointsMap method as that should probably stay in endpoints.js so I'm not sure what we would gain by doing so....thoughts? [19:55] hatch, I personally would like that last bit to be handled with an event or something [19:55] to keep it separate [19:56] ok so once the charm is available, fire an event, which the endpoints.js would listen to [19:56] and then add it's endpoints [19:56] I like it [19:56] thanks for clearing that up [19:56] cool, thank you [19:57] * hatch didn't end up leaving to take lunch heh [19:58] :-P [20:12] "RETRY THIS TEST RUN!" [20:12] http://xkcd.com/303/ "ITS TESTING" [20:19] thanks benji, appreciate you bearing through it [20:19] my pleasure [20:31] hatch, :-) [20:31] benji, reviewed both of yours. Did the tests pass? Would you like me to qa it? [20:32] sorry benji, my last two questions were re the charm [20:32] gary_poster: the tests passed recently, but I was so excited to have it working I forgot to run them on the most recent incarnation; I'll do that now [20:32] cool benji thx [20:38] gary_poster: so I wrote the stuff to do it via the event...but then I just noticed/realized that once the charm data is available we don't know what service that corresponds to [20:39] if just going off of the charm populated attribute [20:39] gary_poster: I responded to your review comments. I'll be happy to discuss synchonously or via the review. [20:47] hatch, I'd make a closure [20:47] benji, looking [20:48] * gary_poster looked at the wrong one first apparently ;-) [20:49] * gary_poster is concerned that our chat room name is NSFW if you type too slowly in Google [20:49] benji guichat briefly? [20:50] sure [20:55] could I get another review [20:55] https://codereview.appspot.com/8686047/ [20:55] hatch fine with pushing to another branch, but you agree closure would solve trivially? [20:57] gary_poster: well not really - I only have the service with a charm name - and from that comes a populated charm so the only way I can listen for it is with CharmList.on('*.populatedChange') at which point any state is gone [20:58] hatch, but you have the service, so if you do an on with a function defined inline then the service will be in the function's enclosing scope [21:00] oh I see where you're coming from - I'm not sure I like that as much [21:00]