[11:40] <gary_poster> hey luca.  I suddenly have 20 minutes free. :-) I have a few follow-up questions about your reply (whicvh I really appreciate).  Do you have a moment, or are you lunching?
[11:41] <luca> sure, guicaht?
[11:41] <luca> guichat^
[11:45] <gary_poster> luca thanks yes
[11:45] <gary_poster> sorry didn't see
[12:25] <rick_h> luca: got a sec?
[12:30] <frankban> guihelp: I need to retrieve the env object from within a viewlet. Is there a way for viewlets to access their own viewContainer?
[12:31] <rick_h> frankban: shouldn't the view container give the viewlet anything it needs? Pass down cfg or helpers?
[12:31] <bac> frankban: i need to do the same thing and have modified the call to render to accept it.  hold on and i'll paste my changes
[12:33] <bac> frankban: http://paste.ubuntu.com/5804591/
[12:34] <rick_h> bac: why not just pass in the db? Seems like this connects the two classes a lot now for testing and such?
[12:34] <frankban> bac: very nice, thank you
[12:37] <frankban> rick_h: how to retrieve, e.g., the env from the db then? However, perhaps we could just pass ViewContainer.options?
[12:37] <rick_h> frankban: yea, I was seeing that. This is added to the root class vs a class that's later inheriting I guess. 
[12:38] <rick_h> frankban: I like the idea of an optional cfg second param instead 
[12:38] <rick_h> render(model, options)
[12:39] <bac> frankban: but i'm passing the viewcontainer.  can't you get options and env from it?
[12:39] <frankban> sounds good, also extended to the other viewlet methods I guess. what is options? viewContainer.options?
[12:39] <frankban> rick_h: ^^^
[12:39] <bac> frankban: yeah
[12:40] <rick_h> bac: render(model, {db: ciewContainer.get('db')})
[12:40] <bac> rick_h: sorry i didn't see your comment
[12:40] <rick_h> frankban: options is just a arg name. 
[12:40] <rick_h> frankban: call it cfg, foobar, whatever. Basically a space for passing in any optional data?
[12:40] <rick_h> frankban: I guess I'm just looking at this diff and not the big picture of how it's working. So ignore me if it doesn't apply I guess. 
[12:40] <bac> rick_h: bcsaller, hatch and i discussed this yesterday and thought it may need to be broader, but i see your point
[12:41] <rick_h> I just get twitchy when I see something getting the full instance of something else as those two classes are now tied at the hip vs something more generic
[12:41] <frankban> rick_h: AFAICT this is a framework, our render is called for us, so I guess we must decide what to pass as second arg
[12:42] <rick_h> frankban: right, then nvm I guess. I've not used it yet so was looking at things like a Y.View calling another Y.View where it has control over how render is called
[12:42] <rick_h> frankban: is the init custom then?
[12:42] <rick_h> frankban: e.g. could the viewlet be given optional init config and then it's already there for this.render()?
[12:45] <frankban> rick_h: you can pass options to the viewContainer initializer (an Y.View). a viewlet is more a configuration object, with hooks/methods called by the viewContainer. It seems nice to me if the viewlet can receive (or store, as you suggested) those option values. I am also fine with Brad;s solution of passing the whole viewContainer, even if I guess we will be mostly interested in its options
[13:01] <luca> rick_h: I'm in a meeting now for an hour but can we catch-up after?
[13:02] <rick_h> luca: sent an email on your way. Feel free to reply to that or we can chat after your meeting. 
[13:02] <luca> rick_h: ah brilliant, cheers :)
[13:02] <frankban> BradCrittenden, rick_h:  what I described: http://pastebin.ubuntu.com/5804671/
[13:04] <rick_h> frankban: cool. I like that way it's limited to bits of data vs the whole class and the temtation to try to share methods/etc across. Seems less 'dirty'. 
[13:07] <BradCrittenden> frankban: looks good
[13:16] <teknico> anyone up for a second review of https://codereview.appspot.com/10677043/ ?
[13:28] <gary_poster> teknico, any takers?  if not, please invoke j u j u g u i :-)
[13:29] <gary_poster> luca, I don't understand this line from inspector behavior:
[13:29] <gary_poster> "You can scroll the inspector but the scroll goes underneath the dark grey divider line"
[13:29] <teknico> gary_poster: nope, proceeding with deployment of Secret Weapon
[13:30] <gary_poster> cool teknico :-)
[13:30] <gary_poster> luca, and that line seems key :-)
[13:30]  * gary_poster goes to another call, but more explanation would be great
[13:30] <BradCrittenden> gary_poster: we up?
[13:31] <bac> brb
[13:31] <gary_poster> we are bac
[13:31] <gary_poster> cool
[13:31] <teknico> `juju deploy jujugui`: anyone up for a second review of https://codereview.appspot.com/10677043/ ?
[13:31] <gary_poster> heh
[13:31] <benji> teknico: hi, I'll take it
[13:32] <bac> gary_poster: am i in the wrong place?
[13:32] <teknico> benji: I mean, thank you ;-)
[13:32] <teknico> whoops
[13:32] <gary_poster> bac, maybe.  1c5347001459ec985658a81e5c3a019abc715e05 ?
[13:33] <gary_poster> bac from calendar
[13:33] <bac> no, did it change with the new calendar invite?
[13:33] <teknico> benji: thank you
[13:44] <benji> rick_h: have a minute for some browser wierdness discussion?
[13:46] <rick_h> benji: sec, finishing up standup
[13:46] <benji> l
[13:46] <benji> k
[13:46] <benji> now everyone knows I'm using a QWERTY keyboard
[13:46] <rick_h> doh!
[14:00] <gary_poster> bac, you still here?
[14:00] <teknico> is anyone able to "make code-doc" successfully in trunk?
[14:01] <rick_h> teknico: nope
[14:02] <rick_h> benji: free now, guichat?
[14:02] <benji> rick_h: I figured it out. Your contribution will be noted for posterity.
[14:03] <rick_h> woot! I love being awesomely helpful by not attending!
[14:03] <rick_h> I guess 'by absence' would fit better
[14:05] <gary_poster> rick_h, hatch, either of you have idea on what to grep for for that yuidoc failure (http://pastebin.ubuntu.com/5804801/)
[14:05] <gary_poster> ?
[14:07] <rick_h> gary_poster: looking
[14:08] <gary_poster> thx
[14:16] <hatch> gary_poster: try subapp
[14:16] <hatch> er
[14:16] <hatch> subclass
[14:16] <hatch> just thinking
[14:17] <gary_poster> hatch you mean grep for subclass?
[14:17] <hatch> yeah sorry
[14:17] <hatch> it's possible that the class isn't defined if ther is a subclass of juju.something
[14:18] <hatch> brb
[14:24] <hatch> gary_poster: any luck?
[14:24] <gary_poster> hatch, if you comment this out then yuidoc stops complaining
[14:24] <gary_poster> http://pastebin.ubuntu.com/5804847/
[14:24] <gary_poster> but
[14:24] <gary_poster> then there is nothing in the yuidoc directory (if you move any old ones aside first)
[14:25] <hatch> yeah that's definitely not right
[14:25] <hatch> umm can you bisect to find the failure
[14:25] <hatch> er...
[14:25] <hatch> check out the last revno
[14:25] <gary_poster> I can't--more mtgs--but maybe teknico? :-)
[14:26] <rick_h> I'm looking at where the error is thrown in node_modules/yuidocjs/lib/docparser.js and it makes no sense :/
[14:26] <rick_h> console.log(modules) [get a nice fancy list] console.log error'ing module [it's not in the previous list...]
[14:28] <rick_h> for some reason it's trying to find a 'juju' module but there isn't a 'juju' module file. 
[14:28] <teknico> hatch: when can we have a one-on-one about viewlet/databinding?
[14:28] <hatch> nevvvaaaa
[14:28] <teknico> nice :-)
[14:28] <hatch> ok but really pretty soon
[14:28] <hatch> just waiting for the morning rush to slow down around here :)
[14:29] <teknico> rick_h: the first doc comment gary_post3r pointed out, in apps/subapps/browser/browser.js , says "@module juju"
[14:31] <hatch> bac: are you able to make a branch and commit with that view-container update? I can if you arent' able to
[14:31] <bac> hatch: frankban has come up with an alternative that looks better
[14:32] <hatch> oh? I thought that was pretty clean :) what's the alternative?
[14:32] <bac> http://pastebin.ubuntu.com/5804671/
[14:32] <bac> i haven't integrated his change yet
[14:32] <rick_h> teknico: gotcha. Yea, guess there's not really a juju module to be a part of. Ends up just a namespace. 
[14:34] <rick_h> teknico: do the docs go anywhere? 
[14:34] <rick_h> I must be blind today
[14:34] <hatch> bac: frankban hmm I don't really like that as much because then you don't have access to the viewlet for anything
[14:35] <teknico> rick_h: they should go in the top level yuidoc/ dir
[14:35] <teknico> rick_h: but it does not get created anymore
[14:35] <abentley> sinzui: Can we do a mid-imp review of https://code.launchpad.net/~abentley/charmworld/config-storage/+merge/171801 ?
[14:35] <rick_h> teknico: so I changed it to https://pastebin.canonical.com/93510/ and no error
[14:35] <rick_h> teknico: but no docs
[14:36] <rick_h> hatch: other way around? 
[14:36] <rick_h> hatch: isn't this the viewlet getting access to the viewContainer?
[14:36] <bac> hatch: it gives what we need with less coupling.
[14:36] <hatch> yeah.....ok you're right I read this wrong
[14:36] <hatch> the context will still be the viewlet
[14:37]  * hatch goes to grab his coffee
[14:37] <teknico> rick_h: yeah, something else is amiss
[14:37] <luca> gary_poster: the divider line is the dark grey line under the "upgrade" available notification.
[14:42] <hatch> http://gizmodo.com/how-a-fridge-full-of-beer-that-only-unlocks-for-candian-596858353
[14:42] <hatch> rofl
[14:43] <hatch> teknico: ok want to chat now?
[14:44] <hatch> I have another call in 15 but we can probably get it done in time
[14:44] <teknico> hatch: yes please
[14:44] <hatch> guichat is open
[14:47] <adeuring> sinzui, abentley, jcsackett, rick_h could one of you review these two small MPs: https://code.launchpad.net/~adeuring/charmworld/1192559-forgotten-jenkins-results/+merge/171825 https://code.launchpad.net/~adeuring/charmworld/1192544-dont-hide-charms-with-processing-errors/+merge/171756
[14:47] <abentley> adeuring: looking.
[14:47] <adeuring> thanks
[14:49] <abentley> adeuring: could FailingStoreProviderResults be a function?
[14:50] <abentley> adeuring: You're replacing a function, so that seems intuitive to me.
[14:50] <adeuring> abentley: no, when you pass a function to patch.object(), it is called during the call of patch.object()
[14:50] <abentley> adeuring: Not in my experience.
[14:51] <adeuring> abentley: well, I tried it...
[14:51] <abentley> adeuring: See test_store.py for some examples.
[14:51]  * adeuring is looking
[14:55] <gary_poster> bcsaller, when you are here, could you take bug 1195354?  made card in miscellaneous
[14:55] <_mup_> Bug #1195354: Export exports relations incorrectly <juju-gui:Triaged by bcsaller> <https://launchpad.net/bugs/1195354>
[14:55] <gary_poster> teknico, is "Broken tests for pyJuju sandbox" landed yet
[14:56] <teknico> gary_poster: it is, just yet
[14:56] <teknico> moved the card
[14:56] <adeuring> abentley: got it. I misunderstood the parameter "new"
[14:57] <bcsaller> gary_poster: kapil's email said  relations:                                                                                                                                                                                                                                                                    
[14:57] <bcsaller>         - [blog, [db, memcached]]           
[14:58] <bcsaller> one line change either way I think
[14:58] <abentley> adeuring: The changes you've made to the tests in 1192544-dont-hide-charms-with-processing-errors look wrong to me.  You should be testing that charms with errors are not hidden, not changing them to refer to store errors.  I believe the store error stuff already has tests.
[14:58] <gary_poster> bcsaller, xchat might have eaten what you said, I am afraid, but I think you are saying that this will be easy :-) .  Maybe also that you need to clarify something with Kapil?
[14:59] <bcsaller> both those things. My orig email suggested what the bug says but he offered back that its a list rather than ':' delimited
[14:59] <adeuring> abentley: OK, having tests that charms with errors are shown make seinse. But I could not find tests for the store_error case. Maybe I missed them though...
[14:59] <bcsaller> I can do either though, like I said, one line change :)
[15:02] <abentley> adeuring: in search.py: test_api_search_charm_with_store_error, test_search_charm_with_store_error.  In models.py, test_find_charms_default
[15:03] <gary_poster> hey hazmat, could you connect with bcsaller on list vs bug above?
[15:03] <adeuring> abentley: ok, so I'll just change the originals tests that charms with processing errors are not hidden.
[15:03] <abentley> adeuring: +1
[15:04] <bac> gary_poster: canonicaladmin for you
[15:04] <abentley> adeuring: r=me on 1192559-forgotten-jenkins-results
[15:04] <adeuring> abentley: thanks
[15:05] <gary_poster> sinzui, am I right that manage.jujucharms.com will integrate with SSO?
[15:05] <rick_h> gary_poster: it does already. The login function should work for anything in ~charmers
[15:05] <gary_poster> sinzui, and are there any others on the charm side of the world that you know of?
[15:06] <gary_poster> rick_h, when I click on login, I get a 503 Service Unavailable
[15:06] <gary_poster> No server is available to handle this request.
[15:06] <rick_h> gary_poster: hmmm wfm
[15:06] <gary_poster> rick_h, ok worked that time
[15:06] <rick_h> gary_poster: looks like new SSO layout/etc
[15:06] <gary_poster> yeah
[15:06] <sinzui> gary_poster, I am logged in
[15:07] <gary_poster> bac, accepted :-)
[15:07] <bac> gary_poster: oh, and another.  my sick day from a while bak
[15:07] <bac> back
[15:07] <sinzui> gary_poster, I just logged in
[15:08] <sinzui> gary_poster, I think the bug here is that we did not test what someone who has not role to login sees
[15:08] <gary_poster> sinzui, ack works for me now as I said.  could you please add manage.jujucharms.com to bug 1184961
[15:08] <gary_poster> so it gets an icon
[15:08] <gary_poster> doe SSO
[15:08] <gary_poster> for
[15:08] <sinzui> gary_poster, ~charmers and the m.jc.com developers can loggin
[15:09] <sinzui> gary_poster, logging in lets you do charm QA.
[15:09] <gary_poster> sinzui, ack cool thanks.  my main point is that icon bug.  could you add yourself to the bug?
[15:09] <gary_poster> I mean, mj.c
[15:10] <luca> rick_h: free to talk?
[15:10] <rick_h> luca: sure thing
[15:10] <rick_h> luca: taking over guichat
[15:11] <sinzui> gary_poster, yellow/ui group appear to be the only staff that are NOT in https://launchpad.net/~juju-jitsu/+members
[15:11] <gary_poster> sinzui, lol
[15:12] <gary_poster> sinzui, you saw the icon bug request, right? :-D
[15:12] <sinzui> gary_poster, I think your people would be helped by membership...and I will look into what happens when you are not permitted to sign in
[15:12] <hazmat> bcsaller, re emai. those are separate services..         - [blog, [db, memcached]]    is two relations in one line.. no qualifiers.. qualifiers are done as 'service:rel_name' 
[15:12] <sinzui> gary_poster, No I didn't see it
[15:12] <sinzui> number?
[15:12] <bcsaller> hazmat: ah, must have misunderstood, thanks
[15:12] <gary_poster> sinzui, bug 1184961
[15:13] <sinzui> thank you. I will look into this.
[15:14] <gary_poster> thanks sinzui
[15:15] <sinzui> ha ha, the deploy was so fast it happened as I was testing login/logout
[15:16] <sinzui> abentley, your login/logout link staste bug still exists and somewhat confusing when a deploy happens
[15:16] <adeuring> abentley: i updated the branch
[15:17] <abentley> adeuring: r=me then.
[15:17] <adeuring> abentley: thanks
[15:23] <abentley> adeuring: I had already approved it, conditional on fixing the tests.
[15:25] <abentley> sinzui: That's weird.  I couldn't reproduce it.
[15:26] <sinzui> abentley, It happened during the rollout. It was fast. I cannot make it happen now
[15:27] <abentley> sinzui: Can we do a mid-imp review of https://code.launchpad.net/~abentley/charmworld/config-storage/+merge/171801 ?
[15:27] <sinzui> oh, and it just did... abentley. I just logged out. I had to force reload to see login again
[15:27]  * sinzui reads
[15:28] <teknico> gary_poster: jenkins failed but it seems unrelated to my branch, can we retry?
[15:29] <gary_poster> teknico I will retry if you look at video and see if you learn anything, and maybe doc in fole. :-)
[15:29] <gary_poster> file
[15:30] <teknico> gary_poster: oh, the video, I keep forgetting that. what do you mean by "doc in file"?
[15:33] <teknico> I guess "document in a file anything I learn"
[15:36] <gary_poster> teknico, I was thinking like your FIXMEs
[15:36] <gary_poster> Makyo, coming to meeting sorry
[15:41] <hatch> rick_h: got a minute for a chat?
[15:44] <rick_h> hatch: rgr
[15:44] <hatch> in guichat
[15:45] <rick_h> hatch: trying
[15:50] <Makyo> jujugui call in 10 kanban now
[15:56] <abentley> sinzui: how's that review going?
[15:58] <sinzui> abentley, In the last in your branch (# This is not acceptable to Elasticsearch, because config is a list.) you demonstrate that 'e' was not found. I think it was deleted by the exception block. Should it be? If the config options is already in the right format, I would have indexed it after a no-op
[15:59] <sinzui> Oh
[15:59] <sinzui> it was options that was a list
[15:59] <sinzui> abentley, we have configs that that a list?
[15:59] <sinzui> do we also have configs that are a string?
[15:59] <frankban> hatch: do you have a minute for a chat after the call?
[16:00] <jcsackett> sinzui: can i grab you to chat right after the juju gui standup? probably 15 min?
[16:00] <sinzui> jcsackett, yes
[16:00] <jcsackett> cool, thanks.
[16:02] <teknico> gary_poster: the underlying problem with the Jenkins failure is a timeout with "Charm API server did not respond", so maybe a network hiccup
[16:03] <sinzui> abentley, I think my questions are moot. We don't support config being anything other than a dict with a single item of 'options': {}. Anything else is ignored now. your branch continues to ignore it, but we also get an exception in ingest to document the charm is bad
[16:03] <gary_poster> teknico, ah ok.  I think they had a deployment
[16:03] <gary_poster> jujugui sorry got lost in irc and mail.  coming
[16:03] <abentley> sinzui: I forget what the precise mapping issue I ran into yesterday was.  But we had something that is supposed to be a map in our format, and instead it was a list.
[16:04] <abentley> sinzui: This originally just aborted the migration, which is unacceptable.  So I handled it by swallowing the exception.
[16:05] <abentley> sinzui: But since this is a migration, any existing document would be in the old format.  So we should not retain it.  We should delete it.
[16:05] <sinzui> abentley, understood and agreed. We let users craft the yaml by hand. I suppose proof should/does callout this issue
[16:07] <abentley> sinzui: Right.
[16:08] <sinzui> abentley, the migration script does a print. Shouldn't it be a log because for webops to investigate.
[16:08] <sinzui> or maybe you expect webops to check the juju-log
[16:09] <abentley> sinzui: I don't think that migrate has logging enabled.  I should check that.
[16:09] <abentley> sinzui: yeah, no references to 'log' at all.
[16:10] <sinzui> abentley, I think all stdout is captured by the juju-log. I think I saw the issue in the log when we had migration 007 bow up
[16:10] <sinzui> blow up
[16:10] <abentley> sinzui: Right.  I meant that I don't think the migrate script has python logging enabled.
[16:11] <sinzui> okay. I follow. That is a nice to have. I think your branch is in a good state. and +1 for documenting what a DISTRO_CHARM_DATA looks like
[16:12]  * sinzui thinks bzr_branch leaked through, but is nice ti see as an addition
[16:12] <abentley> sinzui: Cool.  Yes, DISTRO_CHARM_DATA allows me to justify the changes to the old JSON API.
[16:13] <abentley> sinzui: Okay, can we talk about how we would re-implement migration?
[16:14] <sinzui> yeah
[16:20] <hatch> frankban: i'll be right back then we can chat
[16:20] <frankban> hatch: thanks
[16:20] <bac> thanks hatch.  i had not merged from trunk and didn't have ghost-inspector yet
[16:20] <bac> to look at event handling
[16:20] <jcsackett> sinzui: want to join me in tinyurl.com/guichat?
[16:21] <sinzui> jcsackett, in a few  minutes, I am in another hangout
[16:21] <jcsackett> ok.
[16:23] <hatch> bac: you'll also want to create your own object similar to the one on line 126 of ghost-inspector.js and then include it into the controller
[16:24] <hatch> you do that by adding it to the array on views/service.js:1176
[16:24] <hatch> I can outline in more detail if needed
[16:24] <hatch> frankban: guichat?
[16:24] <frankban> hatch: sure
[16:25] <jcsackett> sinzui: when you're free ping me and i'll send an invite; guichat was needed. :-)
[16:26] <bac> hatch: i'm working on the service inspector so i think your point about adding to the array is not right
[16:26] <bac>  s/right/required
[16:37] <hatch> bcsaller: are you around?
[16:37] <hatch> can you join guichat with frankban and I
[16:37] <bcsaller> yes
[16:39] <jcsackett> sinzui: i've got to run out. i'll ping you when i'm back, see if you're free then.
[16:39] <sinzui> okay. sorry jcsackett
[16:50] <rick_h> sinzui: ping, got a sec to chat?
[16:56] <rick_h> sinzui: jcsackett can I get reviews on this short branch please? https://codereview.appspot.com/10691043/
[17:02] <bcsaller> hatch: that did fix it :-/
[17:04] <frankban> bcsaller: how to add that formatting function for each value in constraints? I'd like to use that to convert undefined to an empty string
[17:05] <bcsaller> frankban: did you try using constraints as the name, I'm not sure that would work but maybe I can make that happen
[17:06] <bcsaller> because you're right, we don't want to have to repeat that everywhere and we don't always know all the key names in the code anyway
[17:07] <benji> rick_h: I have a charm-token-related question for you when you have a minute
[17:08] <frankban> bcsaller: it does not work with just 'constraints', yeah it would be a nice functionality
[17:08] <abentley> sinzui: Notes on our chat: https://docs.google.com/a/canonical.com/document/d/1hYCZWzTdtyv9IfZ1wdx82COrYSMwRRfeIRkVTfNMQvw/edit
[17:08] <bcsaller> frankban: ok, I'll look at hacking something up. 
[17:09] <frankban> bcsaller: great
[17:12] <jcsackett> sinzui: i am back, are you free?
[17:15] <rick_h> benji: hey, sorry I missed your ping
[17:16] <rick_h> benji: what's up?
[17:17] <hatch> bcsaller: darn....oh well those things happen :)
[17:18] <rick_h> jcsackett: hatch can you guys peek at this short one please? https://codereview.appspot.com/10694043 fixes a bug that annoys hatch so I can earn brownie points to disagree with something else later on :P
[17:18] <bcsaller> hatch: adding support for hierarchical  bindings to deal with nested key paths. So methods on 'constraints' will be used for 'constraints.foo' if that doesn't define the method in question.
[17:19] <benji> rick_h: I want to talk about svg icons and .small .medium and .large 
[17:19] <benji> guichat?
[17:19] <rick_h> benji: sure thing
[17:31] <hatch> bcsaller: I'm not sure what you're saying
[17:31] <bcsaller> hatch: I can explain it in chat or show you in a bit in code
[17:32] <hatch> ok ummm i'll make a hangout
[17:32] <hatch> calling
[17:32] <hatch> not sure if I picked the right account :)
[17:36] <gary_poster> rick_h, LGTM
[17:38] <rick_h> gary_poster: ty much
[17:40] <rick_h> jcsackett: thanks as well. You caught me trying ot make sure each test failed/passed lol
[17:41] <rick_h> I need to do better at that
[17:52] <hatch> oh man there is a lot of drama around X and MIR
[17:52] <rick_h> hatch: welcome to canonical
[17:52] <hatch> why are people so resistant to change haha
[17:53] <jcastro> ok fellas
[17:53] <hatch> "RAWR don't event attempt improve my linux RAWR"
[17:53] <jcastro> so the drag and drop is pretty much awesome
[17:53] <hatch> (thats'a how I read these comment threads)
[17:54] <rick_h> jcastro: benji is working on some browser tweaks and such to it now
[17:54] <jcastro> nod
[17:54] <sinzui> hatch. All developers believe it is fine for themselves to introduce change, but distrust anyone else proposing a change that might topple their changes
[17:54] <hatch> jcastro: yes that is awesome :)
[17:54] <rick_h> jcastro: so send beer his way and hold off if something's not quite right yet
[17:54] <jcastro> I was like "ok if this doesn't land it's no big deal"
[17:54] <jcastro> now after using it it's like, why would I ever click the add button ever?
[17:54] <hatch> sinzui: lol
[17:54] <hatch> these developers need to work on a webapp haha
[17:55] <sinzui> hatch, indeed.
[17:57] <rick_h> howdy sinzui can you peek at https://codereview.appspot.com/10691043/ real quick and I wanted to see if you had time to chat on priority/next
[17:57]  * sinzui looks
[17:57] <sinzui> I do have chat time. I am all talk and no action
[17:57] <rick_h> woot
[17:58] <sinzui> 17px? are you mad. Why choose a prime number of a dimension (other than 2)
[17:58] <rick_h> it's what the ratio worked out to be going off the other images. 16.8px actually
[17:59] <rick_h> .35 * charm icon size ish
[17:59] <sinzui> 17 px is a poor input when scaling images designed for 64/128/256
[17:59]  * sinzui looks for crack pipes
[17:59] <rick_h> .35 * 48px
[17:59] <rick_h> the large one is 57px :P
[18:00] <rick_h> and that came from UX 
[18:02] <benji> rick_h: it seems that after('render') is indeed called after render() is called, but not after it is really, really rendered by the browser.
[18:02] <bac> "17px? are you mad"  ha!
[18:02] <rick_h> benji: oh shoot me 
[18:02] <benji> however, if instead of after('render', myFunc) I use setTimeout(myFunc, 1000) it works
[18:02] <benji> :/
[18:03] <sinzui> rick_h, LGTM.
[18:04] <sinzui> rick_h, my daughter only sets the volume of the TV to increments of 5. She sites a study that 57% of the population are bothered by displays that accept odd numbers. I now set the TV to prime numbers only. I like to watch her twitch.
[18:07] <hatch> prime numbers only....so the tv is either very loud or very quiet? haha
[18:07] <rick_h> benji: ah ffs, it's a race since the actual rendering is done off the same event. 
[18:07] <rick_h> hatch: go smack someone on YUI around for the widget renderer crap
[18:07] <hatch> what widget renderer crap?
[18:08]  * hatch gets his pimp hand ready
[18:08] <rick_h> http://yuilibrary.com/yui/docs/api/files/widget_js_Widget.js.html#l579
[18:08] <rick_h> ^^ wtf, why is the actual DOM rendering done off the event RENDER?
[18:08] <rick_h> I guess so they can enforce the fireOnce-ness of it...ugh.
[18:08]  * benji hands hatch an animal print fedora.
[18:09] <rick_h> benji: ok, hack time. 
[18:09] <benji> yay! I get to add a setTimeout to the code base
[18:09]  * benji greps
[18:09] <rick_h> benji: no no no
[18:09] <benji> darn! I'm not the first one
[18:09] <benji> :P
[18:09]  * hatch puts my pimp hand away
[18:09] <hatch> actually that's how I'd write it too
[18:09] <hatch> :)
[18:10] <hatch> well not exactly
[18:10] <hatch> but close haha
[18:10] <rick_h> hatch: I think what we can do is change the event to after(renderedChange)
[18:10] <hatch> I don't know what the problem is so I can't say what to do :)
[18:10] <rick_h> benji: http://yuilibrary.com/yui/docs/api/files/widget_js_Widget.js.html#l583 is after the actual rendering, the ATTR for RENDERED ('rendered') is set to TRUE
[18:11] <rick_h> benji: so we can add an event watch for that, since we KNOW it's after the REAL rendering.
[18:11] <rick_h> benji: and then do your work
[18:11] <benji> ooh, I like it
[18:11] <benji> that'll be  this.on('renderedChanged', myFunc), right?
[18:11] <rick_h> benji: so to watch for ATTR changes you'll have to use the event syntax renderedChange I believe
[18:11]  * rick_h goes to dbl check attr event watch syntax
[18:12]  * benji wonders where those docs are.
[18:12] <hatch> use after
[18:12] <benji> yep, after would be better
[18:12] <benji> well, I guess it doesn't matter in this case, but generally "after" is what I want for attribute changes
[18:12] <rick_h> benji: yea, so per http://yuilibrary.com/yui/docs/attribute/#events looks right
[18:12] <sinzui> bac, do you have a few minutes to review these my text changes to the juju-gui charm? https://codereview.appspot.com/10698043/
[18:13] <rick_h> sinzui: ok, have tmie to chat now, sorry. benji is distracting me :P
[18:13] <benji> :)
[18:13] <bac> sinzui: y
[18:13] <rick_h> sinzui: invite on the way
[18:14] <hatch> benji: 'on' will allow you to prevent the attribute change value, 'after' you can be sure that it hasn't been prevented by anything else
[18:14] <hatch> mind if I ask what the issue is?
[18:14] <benji> ah, that's a good point
[18:14] <bac> sinzui: in HACKING you are telling them to get the released version of the charm to start work, not the devel branch.
[18:14] <benji> hatch: this doesn't seem to work for me:
[18:14] <benji> this.addEvent(this.after('renderedChanged', Y.bind(this._addDraggability, this, container)))
[18:15] <bac> ~juju-gui-charmers is release, ~juju-gui is devel, sinzui
[18:15] <hatch> Change
[18:15] <hatch> no d
[18:15] <benji> I need to inspect some element dimentions after they are rendered
[18:15] <benji> ah!
[18:15] <hatch> benji: this.after('render', function() {}) doesn't work?
[18:16] <hatch> that's kind of the purpose of the after render :)
[18:16] <hatch> event*
[18:16] <benji> hatch: nope because that event is (apparently) fired after all the render() methods are called, not when the nodes have actually been rendered by the browser
[18:17] <sinzui> bac, I think I am asking them to hack on the dev version
[18:18] <bac> sinzui: line 22 of HACKING refers to lp:~juju-gui-charmers
[18:18] <sinzui> bac: I think that is wrong then
[18:18] <bac> yeah, i think so
[18:18] <hatch> benji: I don't think so, reading the code here
[18:18] <hatch> are you sure you used 'after' and not 'on'
[18:19] <hatch> after fires /after/ the defaultFN is run
[18:19] <hatch> whic is aftter the elements are in the dom
[18:19] <benji> if I put a debugger call in the event handler I can't the elements on the screen
[18:19] <benji> and they have no computed style
[18:19] <benji> (which is what I really want)
[18:20] <hatch> oh, I htink that's because the renderUI isn't attaching the element to the contentBox
[18:20] <hatch> can you see if the content/boundingbox is in the dom?
[18:21]  * benji looks
[18:21] <hatch> sorry for the q's I just want to know where the real issue lies
[18:21] <hatch> so, this.after('render', function() { debugger; });
[18:22] <hatch> then there should be a yui3-charmtoken element in the dom
[18:22] <benji> basically (there is more in there, than just the debugger call
[18:22] <benji> here is the renderUI funciton: 
[18:22] <benji> http://paste.ubuntu.com/5805499/
[18:22] <hatch> yeah that isn't the proper place to put that
[18:22] <hatch> that's why it's not working
[18:22] <hatch> guichat real quick?
[18:23] <benji> hatch: sure
[18:23] <hatch> cool
[18:23] <rick_h> benji: hatch guichat? I can tell you right where this is
[18:23] <hatch> yup
[18:23]  * rick_h just went through the widget source
[18:23] <sinzui> bac, I propose reverting my changes to HACKING.md. I think it is fine as it is.
[18:24] <bac> sinzui: yep
[18:36] <hatch> great chat guys :)
[18:36] <rick_h> man, that is some crazy stuff
[18:58] <sinzui> bac, sorry about the deplay. I reverted the HACKING.md changes: https://codereview.appspot.com/10698043
[19:48] <hatch> bcsaller: reviewing
[19:55] <hatch> bcsaller: so am I to understand that by default it will always apply the child binding? and then if no child binding is applied then it'll look for a parent one?
[19:55] <hatch> the code reads like it only applys the parent binding
[19:55] <hatch> so curious as to where the child binding is assigned
[19:58] <bcsaller> hatch: on call, one sec
[19:59] <hatch> np I put the comment in the review
[20:00] <bac> hatch, when you have a moment would you grab my branch and see if i've done anything untoward wrt events?  lp:~bac/juju-gui/inspector-settings
[20:00] <hatch> sure thing
[20:00] <hatch> checking out
[20:02] <hatch> now that i Know how to do diffs in bzr this is a lot easier haha
[20:04] <hatch> bac: don't use ID's - then we won't be able to have multiple inspectors
[20:06] <bac> hatch: do you even know about 'bzr diff -c'?
[20:07] <bac> that one eluded me for way too long
[20:07] <hatch> nope
[20:07] <hatch> I use bzr diff --old ../trunk --new branch-name | subl (to pipe to sublime)
[20:07] <bac> 'bzr diff -c 500' shows you the diff of what was changed in rev 500
[20:07] <hatch> ohh that's cool but I usually commit to much for that and want to diff from trunk
[20:08] <bac> if you're using lightweight checkouts that can be shortened to: diff -r ancestor::parent
[20:08] <hatch> ohh cool!
[20:09] <hatch> I think I am using light weight checkouts because they check out pretty fast
[20:09] <hatch> bac: if you're going to change var dd = to var _ = you can just delete the var assignment
[20:09] <bac> hatch: but then the linter complains
[20:09] <hatch> oh I didn't know that
[20:09] <hatch> alright
[20:10] <bac> yeah "Don't use new for side effects"
[20:10] <bac> which is what we're doing
[20:10] <hatch> yeah I suppose that's....sort of valid heh
[20:10] <hatch> ok so your code looks good with the exception of the id's
[20:10] <bac> hatch: so you're suggesting replace the id with a one-off class?
[20:11] <hatch> yup
[20:11] <bac> cool
[20:11] <hatch> id clash bugs are damn near impossible to track down hah
[20:25] <benji> rick_h and hatch: the "set the dragImage when the drag starts" approach worked!
[20:25] <hatch> ^5!!!!!
[20:26] <hatch> thats the best approach yet! :)
[20:34] <benji> I'm a little surprised it worked because the drag is already happening at the point.  But I'm glad it worked.
[20:35] <benji> Now I just have to rework all the tests and figure out if I can fix chromium's crazy clipping of the category and generic icons.
[20:39] <hatch> I am surprised as well for the same reason, can't wait to see the code :)
[20:49] <hatch> cmd+w and cmd+s are way to close to eachother
[21:00] <bac> hatch, benji, bcsaller: I'm going to have to turn-over my critical card (OSCON: Build service settings inspector page) since I'll be out until Tuesday.  Would one of you put your face on it to at least ensure someone takes it?  I can do a call later if anyone volunteers.
[21:01] <hatch> bac: what do you anticipate the time to complete to be?
[21:01] <hatch> I 'might' be able to pick it up but I'm also out monday
[21:01] <benji> bac: I'm afraid I have to run, but if you don't get any other takers you can send me an email with the brain-dump and I'll adopt it.
[21:01] <bac> benji: thanks
[21:02] <bac> hatch: another day?  the config file control and the expose section are undone
[21:02] <hatch> ahh ok
[21:02] <hatch> well I can probably take it then
[21:02] <bac> hatch: feel free to pawn it off on benji or someone else.
[21:03] <hatch> pending no more odd issues with the current thing I'm working on
[21:03] <rick_h> benji: yay!!!!!!
[21:03] <bac> fat chance
[21:03] <hatch> lol
[21:03] <bac> ok, kthxlater
[21:05] <hatch> rick_h: HTC released the source for the One Google Edition yesterday and someone has already compiled it into a usable rom so you can get native android on a HTC One :)
[21:06] <rick_h> hatch: cool
[21:06] <hatch> that was the only thing holding me back from buying a new phone
[21:06] <hatch> soooo HTC One next week possibly? :)
[21:07] <hatch> http://forum.xda-developers.com/showthread.php?t=2341395
[21:07] <rick_h> Contract End Date: 12/15/2013
[21:07] <rick_h> I'll have to wait until the end of the year to switch my phone off verizon and go with a phone from google
[21:07] <hatch> I thought you had an N4?
[21:07] <hatch> a*
[21:07] <rick_h> hatch: no, galaxy nexus
[21:08] <hatch> ahh, well by then the new N4 will likely be out
[21:08] <hatch> but not on a contract so it'll probably cost you $400 or something
[21:08] <rick_h> yea, hoping to buy the phone straight out and move to a GSM carier 
[21:10] <hatch> we used to be CDMA here but they recently switched to GSM and it's been awesome
[21:10] <rick_h> yea, all good. I'll have held onto the GNex for 2 full years and ready to spend $$ for my own phone and hopefully save some $$
[21:10] <hatch> unfortunately on my carrier you don't get a discount if you don't get a phone
[21:10] <rick_h> I'll keep my verizon mifi though. <3 the LTE and network. Figure worst case I'll use that to help my phone with coverage on a smaller carrier
[21:10] <hatch> so might as well get a sub'd phone and root it
[21:10] <rick_h> right, why I have to switch carriers. 
[21:10] <rick_h> I'm not sticking with verizon. 
[21:12] <hatch> the plan I'm on http://www.sasktel.com/search/controller/_/R-Product_Services_Talk%26%2344%3B_Text_%26amp%3B_Data_Plans the Ultimate 65
[21:12] <hatch> pretty good plan imho
[21:18] <hatch> http://techcrunch.com/2013/06/27/immigration-reform-passes-senate-house-leadership-calls-bill-a-pipe-dream
[21:18] <hatch> so.... in the Senate can do all this work to draft and write a bill, which the house then ignores and makes their own?
[21:19] <hatch> is that the typical process?
[21:42] <hatch> man I friggen love this app
[21:42] <hatch> maybe I'm bias
[21:42] <hatch> but it's friggen cool
[21:49] <bcsaller> hatch: got a sec to chat?
[21:49] <hatch> oui oui
[21:49] <hatch> guichat?
[22:09] <hatch> bcsaller: email sent to peeps so you should get it soon
[22:10] <bcsaller> hatch: thanks
[22:23] <huwshimi> Morning
[22:24] <hatch> morning
[22:25] <hatch> meeting in 5?
[22:29] <hatch> jujugui weekly meeting aus edition now?
[22:29] <Makyo> Is that in guichat?
[22:29] <huwshimi> Yeah, I think so
[22:29] <hatch> sure thin
[22:30] <hatch> I'm live streaming a paul van dyk set in guichat
[22:30] <hatch> so join up :)
[22:30] <gary_poster> jujugui call now :-)
[22:32] <gary_poster> bcsaller, if you can join that would be cool
[23:23] <hatch> gary_poster: maybe some combination of the two always-on-sticky-headers with the ability to accordion if wanted :)
[23:24] <gary_poster> hatch feel free to follow on in thread :-)
[23:25] <hatch> who's Jamie? Haven't seen that name before :)
[23:26] <hatch> ahhh gooooo directory
[23:26] <hatch> it's Master Chief's real name
[23:34] <huwshimi> gary_poster: Ready