[03:21] <hatch> bcsaller: hey if you're in - I am getting chunk missmatch on your code review
[03:26] <bcsaller> hatch: on which file? When I self reviewed it things looked ok
[03:26] <hatch> yeah that's the odd thing
[03:26] <hatch> hah
[03:26] <hatch> oh did you use the unified diffs?
[03:26] <hatch> it's the side/side ones that are messed up
[03:27] <bcsaller> very odd
[03:27] <hatch> I can do the review on the diff itself no problem
[03:27] <hatch> yeah, right?
[03:27] <hatch> red on white is not the most contrasting colour however :)
[03:28] <bcsaller> heh
[03:28] <hatch> so how's your night?
[03:34] <bcsaller> oh, off in the other room cooking dinner mostly :)
[03:35] <bcsaller> what about you? why you still working?
[03:37] <hatch> just checking in :)
[12:42] <bac> benji: care to have a look at https://codereview.appspot.com/14036044
[12:42] <bac>  ?
[12:43] <gary_poster> bac, you need two or is one sufficient?
[12:43] <benji> bac: sure
[12:44] <bac> gary_poster: one is sufficient.  it is 422 lines but a lot of those are s/api/API/ in comments
[12:45] <gary_poster> bac cool.  Why do we even need to filter things out in in transformResults?  What else is in the original result list?
[12:45] <gary_poster> Maybe worth commentng the answer in case it is not obvious to others in the future
[12:45] <gary_poster> but also I'm curious :-)
[12:45] <bac> gary_poster: goodish question.
[12:46] <bac> i'm not sure if that was originally there just to be super safe or if there are other things that we expect to be in that reply
[12:46] <gary_poster> it seems like it used to filter out nundles, but we don't need to do that anymore
[12:46] <gary_poster> bundles even
[12:46] <bac> hey, i like nundles better.  or cundles, which is charms + bundles
[12:47] <gary_poster> heh
[12:47] <bac> gary_poster: i'll do some archeology and see when that filtering was addded
[12:47] <gary_poster> cool bac thx
[12:48] <frankban> guihelp: could anyone please review and QA https://codereview.appspot.com/14033043 ? thanks!
[12:48] <gary_poster> frankban, on it
[12:48] <frankban> gary_poster: thanks
[13:15] <gary_poster> frankban, LGTM with trivials and QA ok
[13:17] <gary_poster> luca__, hey.  Huw noted something about the new bundle icon for the token: "I forgot to mention that the icon asset supplied seems to be black instead of light grey as it is in the mockup. I've included it as is, but not sure why it is different."  We'll use the black, but if you want to give us a gray one, send it over. :-)
[13:17] <luca__> gary_poster: ah, it's meant to be grey...
[13:17] <gary_poster> luca__, cool.   send it over and I'll replace it in the branch
[13:19] <frankban> gary_poster: thanks! getUnchanged... so I also started to name functions in reverse meaning :-/
[13:20] <gary_poster> frankban, :-) an easy mistake to make in context.  Nice branch though.
[13:21] <gary_poster> back in a few.  cat needs meds
[13:24] <bac> thanks benji
[13:25] <benji> my pleasure
[13:25] <bac> benji: before i go digging, do you know anything about the filtering being done in that method?  was it there just to toss bundles?  gary was curious.
[13:25] <bac> i mean if we really only expect charms and bundles now i could remove the screen
[13:26] <benji> bac: yeah, I added the filtering because of the bundles.  +1 on just removing it
[13:26] <bac> rt
[13:26] <bac> gary_poster: ^^
[13:33] <gary_poster> cool bac, benji, thx
[13:34]  * benji notes to himself that he should have commented the code so that the question didn't have to be asked.
[13:43] <bac> lots of saucy updates today
[13:59] <gary_poster> frankban, interesting about Object.create(null).  thanks for info.  I may start doing as well, though I wish it were more concise
[14:02] <frankban> gary_poster: yeah, a = {} is far more expressive and concise
[14:03] <hatch> they are different
[14:03] <hatch> Object.create(null) has null as a prototype
[14:03] <hatch> whereas a = {} has Object.prototype as a prototype
[14:03] <hatch> just FYI
[14:04] <frankban> hatch: yes, {} == Object.create(Object.prototype), right?
[14:05] <hatch> in modern browsers yep
[14:05] <hatch> tbh I really have no idea why you would want to do Object.create(null)
[14:05] <hatch> I'm really not sure when not having Object.prototype is a good idea
[14:05] <hatch> but I'm totally open to ideas :)
[14:06] <frankban> hatch: I did that in a branch currently in review
[14:06] <hatch> ohh ok - why?
[14:06] <hatch> any specific reason?
[14:07] <frankban> hatch: pasting from the review comments: it seems to me more clean and lightweight in the cases you will use the result only as a "dict" data structure.
[14:07] <hatch> ahhh I suppose there is a case to be made for that
[14:07] <hatch> although it might be a micro optomization
[14:07] <hatch> optimization even
[14:09] <frankban> hatch: also being able to iterate over the object without having to do the hasOwnProperty dance is convenient sometimes imho
[14:09] <hatch> this is true, this is true
[14:13] <frankban> hatch: also intersting: http://www.devthought.com/2012/01/18/an-object-is-not-a-hash/ and http://jsperf.com/object-create-null-iteration/2
[14:15] <hatch> so the 'props' on the perf are almost identical
[14:15] <hatch> as are the emptys
[14:15] <hatch> so there really isn't much of a perf gain
[14:16] <hatch> although some interesting numbers on FF though
[14:17] <frankban> hum, did not try with FF
[14:18] <hatch> scroll down the page to the results
[14:18] <hatch> you can see what others have done
[14:20] <gary_poster> bah, firefox :-P :-)
[14:21] <frankban> heh, if I read that correctly, FF is the only one where the literals are far faster
[14:23] <gary_poster> right
[14:23] <hatch> yep so that means you should always use literals because the perf hit on Chrome/Safari is minimal (at best) and way more performance on FF
[14:23] <hatch> :P
[14:24] <gary_poster> wellll
[14:24] <gary_poster> disagree: optimization opportunity
[14:24] <gary_poster> if you see a problem, or have an inner loop, sure
[14:24] <gary_poster> but cleanliness of empty instance is pretty compelling IMO
[14:25] <hatch> but it's a huge performance hit, not an opportunity for FF
[14:26] <hatch> so you pick the best for everyone :)
[14:26] <frankban> hatch: we might suppose that stats will change, Object.create(prototype) seems the new trend for OOP in js
[14:26] <hatch> (i realize that I'm talking about 100ths of a ms here)
[14:27] <hatch> I'm pretty curious as to where Google is going to go with Android development
[14:27] <hatch> I see them switching to either Go or Dart at some point
[14:27] <hatch> if they choose Dart, and if Dart lands in Chrome
[14:27] <gary_poster> but it is not best for everyone.  point of other artickle is that empty instances have better semantics.  switching from better semantics of empty instance to better performance of {} is an optomization opportunity, if you as I do, prefer to code towards better semantics as a starting position
[14:27] <hatch> that's going to push it's adoption rate huge
[14:28] <hatch> oh I didn't read the article yet :)
[14:29] <gary_poster> well, I only skimmed it ;-)
[14:29] <gary_poster> I'm skeptical of Dart's chances myself
[14:29] <hatch> I am pretty sure it's better at a technical level
[14:29] <hatch> it's the adoption which will kill it
[14:30] <hatch> or make it
[14:30] <gary_poster> sure
[14:31] <hatch> I think Go probably has a better chance of making it into Android
[14:31] <hatch> if they are going to be moving away from Java - which I'm sure they have at least discussed
[14:32] <gary_poster> Go has better broader mindshare it seems yeah.  Switching from Java?  ISTM that would be a huge disruption, but what do I know
[14:33] <hatch> it would - but aren't they fighting Oracle all the time in the courts about it
[14:33] <hatch> Java - that is
[14:34] <gary_poster> yeah, but without Java wouldn't it be essentially a new OS?
[14:35] <hatch> AIUI Java compiled into something else
[14:35] <gary_poster> well, a new development platform 
[14:35] <gary_poster> that's just another Java compiler, hatch?  the JVM is pretty integral to code that targets Java AIUI
[14:36] <hatch> ahh you might be right - they might just use a special compiler
[14:36] <gary_poster> I don't know if that would actually get them away fromOracle, but maybe
[14:37] <hatch> all I know is that I don't enjoy Obj-C or Java so I'm relegated to making mobile apps in webivews :P
[14:38] <gary_poster> heh
[14:38] <hatch> bcsaller: odly enough I ran 'make lint' on your branch and it failed - how did it get proposed? heh
[14:39] <hatch> oh, it's way early for him yet :)
[14:39] <gary_poster> I'm trying to review it too hatch.  side-by-side diffs are hosed for me so I am using  other view, so I can see his comments. same for you?
[14:39] <hatch> yep, I lgtm'd the code, just qa'ing now
[14:39] <gary_poster> cool
[14:40] <bcsaller> hatch: trying it now, worked for me here
[14:40] <hatch> while doing (hopefully) the final qa on my branch
[14:40] <frankban> hatch: alternatives are http://kivy.org/#home and the ubuntu sdk ;-)
[14:40] <hatch> they were 'unused variable' errors
[14:40] <hatch> frankban: haha - ok but I NEED curly brackets
[14:41] <hatch> lol
[14:41] <frankban> hatch: oh... that's why you also prefers object literals :-)
[14:41] <hatch> haha....bingo!
[14:41] <hatch> bracket all the things!
[14:42] <hatch> bcsaller: if yours doesn't pick it up https://gist.github.com/hatched/034dd267a139da6ded9f
[14:43] <bcsaller> maybe I still have an old global install of jshint or something
[14:44] <hatch> oh maybe - the new version is far better
[14:44] <hatch> (and faster)
[14:45] <hatch> frankban: I've been meaning to look at the Ubuntu SDK
[14:45] <bcsaller> gjslint needed an update, had to clean out the virtualenv in the branch
[14:48] <hatch> sandbox qa looks ok for your branch
[14:49] <hatch> but I can't test the go side for about an hour
[14:50] <gary_poster> jujugui call in 10
[14:50] <hatch> lol - I was JUST about to hit enter
[14:50] <gary_poster> :-)\
[14:51] <Makyo> A race! A race!  It's a race!
[14:51] <hatch> haha
[14:51] <Makyo> Now I want to watch Rat Race again :P
[14:52] <gary_poster> heh
[14:56] <gary_poster> bcsaller, "LGTM with largely irrelevant comments."
[14:57] <hatch> those are the best kind!
[14:58] <gary_poster> :-)
[14:58] <gary_poster> jujugui call in 2
[15:59] <hatch> gary_poster:  https://plus.google.com/hangouts/_/effdeeca8cca6ceeeb46d444ea075113f1f80f89?hl=en when you can
[16:18] <gary_poster> luca__, you around by chance?  we could use your input on a bug resolution.  https://plus.google.com/hangouts/_/effdeeca8cca6ceeeb46d444ea075113f1f80f89?hl=en
[16:25] <benji>  /lastlog benji
[16:25] <benji> heh
[16:25] <benji> Just checking to see if I missed anyone talking to me.  Move along.
[16:26] <gary_poster> jujugui notes on bug tracker conversation: http://jujugui.wordpress.com/wp-admin/post.php?post=422&action=edit&message=6&postpost=v2
[17:12] <jcastro> I can't deploy stuff from jujucharms.com site
[17:12] <jcastro> in the mock environment I mean
[17:12] <jcastro> I deploy 2 things, then I try to deploy redis-master and it just works
[17:15] <gary_poster> jcastro, I can deploy anything other than redis-master on jujucharms.  you?
[17:17] <gary_poster> jcastro, known bug, if so, and fixed on coming soon: we had a bug deploying charms without options.
[17:17] <gary_poster> we will have a rollout next week with a bunch of fixes
[17:24] <hatch> bcsaller: has anyone been able to QA your branch on core yet?
[17:25] <hatch> nm I see it's submitted
[17:25] <hatch> :)
[17:25] <bcsaller> err... sorry
[17:25] <bcsaller> I had the 2 lgtm and I'd run through it here, but not with core
[17:25] <hatch> np - I'll just blame you for every core bug that comes up
[17:25] <hatch> :P
[17:25] <bcsaller> of course
[17:25] <hatch> haha
[17:26] <jcastro> oh man, redis-master
[17:27] <jcastro> yeah that's the one I got caught up on
[17:47] <hatch> Makyo: were you able to find where the 'button popup' event was attached?
[17:51] <Makyo> hatch, yeah, ConflictMixin
[17:51] <Makyo> app/views/inspector.js:1180
[18:17] <hatch> in trying to merge trunk it's conflicting on charm-panel.js and service.js
[18:18] <hatch> so I deleted the THIS files
[18:18] <hatch> and resolved
[18:18] <hatch> but it won't resolve
[18:18] <hatch> it says that the files don't exist :/
[18:18] <hatch> any ideas on how to force resolve this?
[18:19] <bcsaller> bzr rm them
[18:19] <bcsaller> not sure, I didn't hit that when I merged it
[18:20] <hatch> thanks
[18:20] <hatch> looks to have worked
[18:24] <hatch> hehe this looks so odd
[18:24] <hatch> '*:agent_stateChange'
[18:27] <hatch> oh poo
[18:27] <hatch> we can't listen to changes to arrtributes on a lazy model lists's model
[18:27] <hatch> becasue it's a pojo
[18:28] <hatch> so unless we 'revive' it first then set the config
[18:28] <hatch> ^ bcsaller am I on the right track here or am I missing something totally obvious
[18:28] <bcsaller> hatch: have process delta for the services sub-list fire 'change'
[18:29] <hatch> ewww
[18:29] <hatch> :)
[18:30] <hatch> but ok I dont' see any other way around it
[18:30] <bcsaller> it makes sense, we know when we update a given service list and it is scoped to only units of a given service 
[18:32] <hatch> right but then I need to parse the unit lists for agent_state's which are 'error'
[18:32] <hatch> which I suppose isn't horrible
[18:46] <hatch> jujugui when destroying a service on comingsoon it throws an error: Uncaught TypeError: Cannot call method 'get' of null handlers.js:127
[18:46] <hatch> I think this was introduced recently?
[18:47] <Makyo> hatch, isn't that covered by one of bcsaller's branches?  There was a card for it, after all.
[18:47] <Makyo> But maybe I'm going crazy.
[18:48] <bcsaller> that does appear to be related to the changes I made, I didn't tests the pyDelta path very much, but the code looks sane
[18:48] <bcsaller> it seems like the unit delta is getting handled after the service remove for that to happen
[18:48] <hatch> odly enough it's on the go sandbox
[18:48] <bcsaller> I can take a look at it
[18:48] <Makyo> go sandbox sorts deltas fyi
[18:49] <Makyo> Services go first, otherwise units go into oblivion on add/change
[18:49] <bcsaller> Makyo: but in the case of remove the opposite should be true, no?
[18:50] <Makyo> bcsaller, apparently :)
[18:50] <bcsaller> heh
[18:50] <Makyo> I just added the sort because core was broken.
[18:50] <Makyo> And it was eminently important that core not be broken.
[18:50] <bcsaller> I recall that
[18:51] <bcsaller> yeah, I'll take a look, I can either shore up that code, or make a service destroy explicitly clear its own units model list and then bypass the error
[18:51] <bcsaller> investigating
[18:52] <hatch> bcsaller: I found a bug with your test server changes - I can't start a test server on my vm and open it on my desktop
[18:52] <hatch> oh wait
[18:52] <hatch> nm
[18:53] <hatch> my fault
[18:53] <hatch> carry-on  :)
[18:58] <hatch> Makyo: so I'm waiting for my core env to come up - anything you need a hand with on your branch to get it out the door?
[19:03] <benji> bac: do you want to do a quick review (https://codereview.appspot.com/14031045) and then sync up via hangout?
[19:03] <bac> benji: sure
[19:04] <hatch> sweet finally caught all edge cases while destroying these services
[19:04] <hatch> man there are a lot of interactions
[19:07] <bac> benji: done
[19:08] <benji> bac: I'll create a hangout.
[19:09] <bac> so much beeping
[19:09] <benji> bac: https://plus.google.com/hangouts/_/a4803e143faddd68f8c7ceb02e589d0054ab5b37?hl=en
[19:09] <benji> heh
[19:13] <Makyo> hatch, Sorry, need to run and deposit housemate's rent before he overdraws his account, I may ping when I get back, but it's just a matter of getting everything set back up in the viewlet.
[19:15] <benji> hatch: are you around and available for a quick bundle planning call?
[19:16] <hatch> Makyo: ok cool np, lemme know if you need a hand
[19:16] <hatch> benji: yeah, can you give me a few I just have some review comments to file
[19:16] <benji> k
[19:19] <hatch> gary_poster: bcsaller if you have a moment plz :) https://codereview.appspot.com/13938043/
[19:19] <gary_poster> on call will look soon
[19:20] <hatch> benji: ok ready whenever
[19:30] <benji> hatch: https://plus.google.com/hangouts/_/a4803e143faddd68f8c7ceb02e589d0054ab5b37?hl=en
[19:33] <bac> gary_poster: what is the status of huw's card in review lane?  can i help get it landed if readyish?
[19:33] <gary_poster> bac, sorry it is landed.  move the card
[19:33] <bac> oh, yay
[19:35] <hatch> bcsaller: around?
[19:35] <hatch> https://plus.google.com/hangouts/_/a4803e143faddd68f8c7ceb02e589d0054ab5b37?hl=en
[19:35] <hatch> just about the bundle card
[19:35] <bcsaller> ahh, ok, one sec
[19:35] <gary_poster> hatch looking at your review now
[19:35] <hatch> thanks
[19:35] <gary_poster> yw
[19:42] <hatch> gary_poster: so looking for the next task whenever you're available
[19:43] <hatch> I'm*
[19:43] <gary_poster> hatch, hook up the bundle token, if benji says it is visible now?
[19:43] <gary_poster> hatch, I mean, make the charm tokens visible and stuff like that
[19:43] <hatch> I think that's done?
[19:44] <hatch> ^ benji
[19:44] <gary_poster> hatch not quite.  Card is "Make bundle token  realer" (sorry :-P )
[19:44] <hatch> with no description.....lol
[19:44] <bac> benji: so how do i see a bundle in search results?
[19:44] <hatch> gary_poster: oh I should probably fix this https://bugs.launchpad.net/juju-gui/+bug/1231487
[19:45] <_mup_> Bug #1231487: Error while trying to destroy a ghost service from the inspector <juju-gui:Triaged> <https://launchpad.net/bugs/1231487>
[19:45] <gary_poster> hatch, benji added the do-nothing bundle token.  huw customized it to show stuff
[19:45] <gary_poster> hatch, oh, yes should be urgent, please
[19:45] <hatch> ok updated and will do that now
[19:46] <gary_poster> hatch "LGTM with rambles."
[19:47] <hatch> thnks
[19:47] <gary_poster> wlcm
[19:47] <bac> benji: nm
[19:47] <hatch> lol
[19:49]  * benji never minds.
[19:49] <gary_poster> bac, what is answer?  search for bac?
[19:50] <bac> gary_poster: after using charmworldv3 flag
[19:50] <bac> so with that flag turned on most of the normal charm icons are broken.
[19:50] <gary_poster> not good
[19:51] <bac> gary_poster: http://localhost:8888/sidebar/search/:flags:/charmworldv3/?text=wiki
[19:51] <bac> search for 'wiki' to get two bundles
[19:51] <gary_poster> cool thanks bac
[20:11] <bac> http://manage.jujucharms.com/charms/precise/liferay
[20:11] <bac> not *that* is a logo, dammit
[20:11] <bac> no beating around the bush
[20:12] <bac> we are LIFERAY...deal!
[20:15] <hatch> haha
[20:18] <bac> gary_poster: turns out charmworldv3 is simply not returning the default icon if none an icon is not available for the charm.  if an icon is there it is returned.
[20:20] <gary_poster> bac, ok.  thank you for investigating.  easy fix, yeah?
[20:20] <bac> gary_poster: should be.
[20:20] <gary_poster> cool bac will make card
[20:20] <bac> gary_poster: already did
[20:20] <gary_poster> thanks bac :-)
[20:23] <bac> i guess charmworld needs to put size constraints in the image css like juju-gui does...
[20:29] <bac> huh, preview won't open svg files.  silly.
[20:32] <hatch> preview is a silly problem
[20:43] <hatch> Makyo: qa'ing again
[20:43] <Makyo> hatch, thanks again.
[20:43] <Makyo> Look over code, too, please.  I found an easy route, but eh..
[20:43] <Makyo> If it really was that easy, great.  I just wonder.
[20:44] <hatch> ok will do
[21:23] <hatch> Makyo: there is a very odd bug with your branch
[21:23] <Makyo> hatch, you're a very odd bug :/
[21:23] <hatch> can you see if you can repro... instructions...
[21:23] <Makyo> hatch, what is it?
[21:23] <hatch> lol
[21:23] <hatch> deploy liferay
[21:23] <hatch> use console trigger
[21:23] <hatch> click 'reload'
[21:23] <hatch> go to 'config'
[21:23] <Makyo> Flag or no?  I just realized I forgot testing without :(
[21:24] <hatch> change the top input to 'asd'
[21:24] <hatch> this is w/o
[21:24] <Makyo> Ahhh butts.
[21:24] <hatch> then click 'save'
[21:24] <hatch> the large input gets wiped out
[21:24] <hatch> then fills again
[21:24] <hatch> but doesn't on comingsoon
[21:25] <hatch> Makyo: actually you don't need to use the console trigger
[21:25] <hatch> it just happens
[21:26] <Makyo> hatch, Think that might be from the changes from your diff, where we were re-attaching the events to textareas?
[21:26] <Makyo> (I can't enter asd there without an error because it's a numeric field)
[21:26] <hatch> Makyo: I think it's the databinding being re-attached
[21:26] <hatch> sorry I mean't 123
[21:26] <hatch> :)
[21:26] <hatch> meant
[21:26] <Makyo> hatch, but the databinding isn't being re-attached, the entire view is being re-rendered.
[21:26] <Makyo> But I'm not destroying the old.  Crap.  Sorry.
[21:27] <Makyo> Uh...hmm.  I can't repro.
[21:27] <hatch> hmm
[21:27] <hatch> lemme try again
[21:28] <hatch> Deploy liferay, click wrench, focus top field, type 123, save changes -> bottom input gets emptied, minimizes, then gets filled again and expands
[21:28] <hatch> try those, less steps
[21:29] <Makyo> hatch, Wait, I see what you mean by large input.
[21:29] <Makyo> Yeah, okay, that I can repro.
[21:29] <hatch> it actually looks pretty cool haha
[21:29] <hatch> but I'm guessing it's probably doing some nastyness under the hood :)
[21:30] <Makyo> hatch, Yeah.  I'll poke around at destroying first.
[21:31] <bac> gary_poster: charmworld icon fix is easy.
[21:31] <Makyo> hatch, Still all sorts of frumpy that 'render' is just the slightest nod at view.render, but I don't have the bandwidth to normalize all viewlets.
[21:31] <gary_poster> yay, thanks bac
[21:31] <hatch> Makyo: yes - this viewlet is virtually a Y.View
[21:32]  * bac -> walkies
[21:32] <Makyo> hatch, just that all of the viewlets work differently.
[21:32] <Makyo> Oh, crap, I should walk dogs D:
[21:33] <hatch> yeah!
[21:33] <hatch> Makyo: yeah - the convention hasn't really been enforced on that regard
[21:33] <Makyo> (also, new meds are making me all sorts of jittery and talkative, sorry for the last few days)
[22:13] <Makyo> https://groups.google.com/forum/#!msg/net.unix-wizards/8twfRPM79u0/1xlglzrWrU0J
[22:13] <Makyo> Thirty years ago today.
[22:52] <Makyo> I kind of hate databinding.
[22:53] <Makyo> hatch, would you be amenable to making this a separate branch?  It's less than ideal, for sure, but I'd like to be able to focus on just that.
[23:51] <hatch> Makyo: which part? I'm concerned that we are introducing a bug into the system which didn't exist before - maybe what we need instead is to push this branch and land a branch which solves the underlying issue first
[23:56] <Makyo> Fine.  Whatever.  Lets do something.  I've been stuck on this damn thing since April and I want it done.
[23:57] <Makyo> I'd love to have done this in a much more incremental manner, but the lack of docs and any defined pattern of behavior make that a little hard.