[00:07] <gary_poster> hatch you still around?  should I bother with a review?
[00:14] <gary_poster> hatch gave you a quick LGTM with small comment anyway. :-) thx
[00:14] <gary_poster> night
[00:14] <gary_poster> all
[12:28] <benji> frankban: have you succesfully run the charm functional tests recently?  I can't get past "agent-state: pending" 
[12:29] <frankban> benji: no, not recently, maybe teknico run them for his last branch?
[12:33] <frankban> benji: are you using pyjuju? if so, you can try to run them with juju-core. what's the status of the juju-gui machine?
[12:33] <benji> yep, I'm using pyjuju; I guess I could try that
[12:35] <gary_poster> frankban, does marco's test framework treat pyjuju as a first class supported environment, or is it second class, after juju core?
[12:39] <frankban> gary_poster: I believe they are both supported at the same level; juju-test automatically retrieves the version in use and reacts accordingly.
[12:39] <gary_poster> ok cool, thanks frankban
[12:41] <frankban> gary_poster, hazmat, teknico: I'll schedule a meeting in the calendar to talk about the deployer; does tomorrow at 1500 UTC work for you?
[12:42] <gary_poster> frankban, not for me.  Thursdays are horrible for me :-) s'ok can meet without me and summarize if you want to
[12:42] <frankban> gary_poster: Friday would work as well, perhaps at 1400 UTC
[12:43] <gary_poster> frankban, that works well for me
[12:44] <gary_poster> oh frankban I am taking Friday off :-P
[12:46] <gary_poster> frankban, btw, and maybe relatedly, would you and teknico mind permanently moving our weekly calls one hour earlier?  frankban's would be 1300 UTC and teknico's would be 1330 UTC.  Is that lunch time?  if it doesn't work, np
[12:49] <frankban> gary_poster: isn't our call at 1300 UTC already? anyway, no problem for me with moving the call one hour earlier. starting from tomorrow?
[12:49] <gary_poster> our call is currently 1400 UTC, if google can be trusted
[12:51] <frankban> heh, it's 15:00 – 15:30 in my calendar, and we are currently in CEST time (utc+2)
[12:52] <gary_poster> heh
[12:52] <teknico> gary_poster: our call is currently 16:00 local, 14:00 UTC. the new time would be half an hour earlier for me
[12:53] <teknico> gary_poster: it's not lunch time now, it will be once DST is off and local is back to UTC+1, in November, but it would still be ok for me
[12:54] <teknico> benji: I did repeatedly run "make ftest" on the charm successfully recently, but only with juju-core, I'm having problems bootstrapping with pyjuju
[12:54] <benji> thanks for the info, teknico 
[12:54] <gary_poster> teknico, frankban, I am utterly confused, particularly with what teknico said :-P, but will make the adjustments in Google calendar and hope they all work out all right :-)
[12:55] <teknico> gary_poster: sorry about that :-)
[12:55] <frankban> gary_poster: they will work, and I'll set up a possible deployer meeting after talking with you tomorrow
[12:55] <gary_poster> frankban, teknico, cool, thanks :-)
[12:56] <gary_poster> hey bac, it's 8:56 for you right now, right?
[12:57] <bac> 8:57
[12:57] <bac> :)
[12:57] <gary_poster> :-P
[12:57] <gary_poster> :-)
[12:58] <bac> fwiw, and you needn't bother remembering, PR is ATC which is always UTC-4
[12:58] <bac> AST
[12:58] <gary_poster> cool
[12:58] <gary_poster> thanks
[12:58] <bac> +1 for consistency.
[12:58] <gary_poster> yeah
[12:59] <teknico> gary_poster: Google Calendar now says that our call tomorrow is at 14:30 local, which means 12:30 UTC, is that intended? if it is, it's ok for me
[12:59] <gary_poster> so, anyway, sorry was going to ask you to move meeting time but nm
[12:59] <bac> my campaign: dump daylight savings time.  buy all dairy farmers Tivos
[12:59] <teknico> bac: yeah, DST is madness
[12:59] <gary_poster> teknico, yeah.  I think my issue is that Google says that my timezone is UTC -5, but they really mean I'm UTC-5+1DST
[13:01] <teknico> gary_poster: right, ok
[13:01] <gary_poster> benji! hi.  you may be noticing a pattern here :-P .  May I move your call to the morning, UTC 1300 (now but tomorrow)?
[13:02] <benji> gary_poster: sure
[13:02] <gary_poster> thank you
[13:02] <benji> gary_poster: is that perminent?
[13:02] <gary_poster> benji yes
[13:02] <benji> k
[13:02] <gary_poster> still ok?
[13:02] <gary_poster> k
[13:02] <gary_poster> thanks
[13:02] <benji> yep
[13:02] <gary_poster> cool
[13:03] <sinzui> orangesquad. I will be distracted by charmworld's prodstack mongodb
[13:03] <rick_h> sinzui: rgr
[13:03] <abentley> sinzui: ACK
[13:04] <gary_poster> thank you sinzui.  if you want anyone from GUI to pair, lemme know
[13:11] <rick_h> hatch: when you're around wonder if you have time to chat. 
[13:20] <sinzui> abentley, rick_h. production mongo shows evidence that mongodb has grown beyond our intent
[13:21] <abentley> sinzui: Do we have an idea what collections are eating the space?
[13:21] <gary_poster> hatch, Makyo, bcsaller I adjusted our one on ones permanently.  My Thursdays were unpleasantly insane, plus I had a new conflict with Matt and Jeff's time.  lemme know if these times are ok for you please
[13:22] <sinzui> abentley, rick_h: there are two more dotted collections in production than we have in staging and the are 2 and 4 x larger than the collection we use: 513M juju.3, 1.1G juju.4
[13:22]  * benji weeps softly into his keyboard.
[13:22] <rick_h> sinzui: well that's interesting. :/
[13:22] <benji> Why is getting juju-core to run so hard.
[13:22] <gary_poster> heh
[13:23] <gary_poster> benji, dunno.  we've got two resources to help ready now, at least, and Matt later
[13:23] <abentley> sinzui: Are those databases, not collections?
[13:24] <sinzui> abentley, rick_h: I would like to rm them, but I know little of mongodb operations.
[13:24] <benji> gary_poster: who would be the best person to ask?
[13:24] <sinzui> abentley, right, db backups/something
[13:24] <gary_poster> benji, frankban probably.  teknico and Makyo also have a working juju core installation.
[13:25] <abentley> sinzui: I don't know much about this either.  So these are files, not db names?
[13:25] <sinzui> abentley, nm, I see. mongodb scales its used from 64 to 128 to ... It has scaled up twice beyond staging
[13:25]  * benji waits for one to volunteer... before choosing a victim.
[13:26] <frankban> benji: what's the problem? :-)
[13:26] <sinzui> abentley, they are named juju.x so I think they are the db, but I believe mongodb is preallocating storage in the files.
[13:27] <benji> frankban: the problem is I don't know where these things are written down, but the immediate problem is "error: no tools available"
[13:28] <rick_h> sinzui: have you tried to run a mongo db compact on the db?
[13:28] <sinzui> rick_h, that takes the db offline (I thnk)
[13:28] <rick_h> sinzui: I'm curious if it's pre-allocating and messing with things if a compact would correct 
[13:28] <rick_h> sinzui: true, can we test on staging to get an idea of the length of time?
[13:28] <sinzui> rick_h, I think you are right
[13:28] <frankban> benji: that's a new one... does it occur running juju bootstrap --upload-tools?
[13:28] <rick_h> sinzui: if we have to bring up a new instance we'd have to go offline as well. 
[13:29] <benji> frankban: nope, that's a bare bootstrap; I'll try with --upload-tools
[13:29] <rick_h> sinzui: but this is something we've known we'd have to figure out at some point. I'm not sure if we can backup, bring up a new mongodb instance, and swap the front end over to it
[13:29] <sinzui> rick_h,  you mean bring up a new unit, compact the old.
[13:29] <rick_h> sinzui: if we can, maybe we can get an idea of the size of the same data, but on a fresh mongo, and at least tell if this is a compaction issue vs a "you have too much data" issue
[13:30] <rick_h> sinzui: on the newly brought up instance, while leaving things running, for now, on the old
[13:30] <sinzui> actually, if we bring up a new unit, we will see if the juju db was given gigs instead of megs
[13:30] <rick_h> sinzui: rgr
[13:30] <rick_h> sinzui: that's my only thought atm. I don't know enough mongodb to help much beyond exploring things a bit. sorry
[13:30] <abentley> sinzui, rick_h: running compact will not delete any files and apparently temporarily increases disk space.
[13:30] <sinzui> well we don't want to do that on this unit then
[13:31] <rick_h> sinzui: right, but does backup/restore on a new instance shrink the size down to closer to what we expect?
[13:31] <rick_h> abentley: :(
[13:32] <benji> frankban: --upload-tools appears to have helped
[13:33] <abentley> sinzui: kapil seems very knowledgeable about mongodb disk usage.
[13:33] <frankban> benji: are you running juju-core from the compiled trunk?
[13:34] <benji> frankban: yep (although I can't be sure it is up to date, as I am not sure I did the right thing to update it)
[13:34] <sinzui> abentley, yes
[13:34] <benji> frankban: if by "compiled trunk" you mean a trunk checkout that I compiled
[13:35] <sinzui> I am going to query collection sizes and ask for the same from production to verify if the data is about the same
[13:35] <sinzui> damn, this is a new unit. my mongo query history is gone
[13:36] <abentley> sinzui: This page has some queries: http://docs.mongodb.org/manual/faq/storage/
[13:37] <sinzui> abentley, I had queries in my history that iterated over our collections and gave me the counts
[13:37] <abentley> sinzui: That page has queries that iterate over collections and give you counts.
[13:37] <frankban> benji: yes, I was trying to understand that error. anyway, when you compile and run juju from trunk, it makes sense to always use --upload-tools
[13:43] <benji> frankban: thanks for the help, I appear to have the tests running succesfully now.  We'll know for sure when the first test finishes.  How long do they normally take?  (I
[13:43] <benji> (I'm running them in EC2.)
[13:43] <frankban> 30min IIRC
[13:44] <frankban> benji: ^^
[13:52] <benji> yay! passing tests!  Thanks much frankban.
[13:54] <frankban> great
[13:56] <frankban> I wonder if pyjuju is having intermittent machine provisioning problems.
[14:00] <gary_poster> luca__, hey,  guichat?
[14:01] <luca__> gary_poster: give me 2 mins! :D
[14:01] <gary_poster> luca__, cool :-)
[14:06] <hatch> morning
[14:15] <jcsackett> rick_h: do you have a moment to chat?
[14:16] <rick_h> jcsackett: sure thing
[14:50] <hatch> brb
[14:55] <abentley> benji, bac: Remember to run "make lint" before landing on charmworld.  I just fixed a bunch.
[14:55] <adeuring> orangesquad: could one of your review this mp: https://code.launchpad.net/~adeuring/charmworld/1199790-last-change-error/+merge/177865 ?
[14:55] <benji> abentley: I'll certainly try.  We should add that to the CI.
[14:55] <abentley> adeuring: looking.
[14:56] <bac> abentley: will do.  thanks.
[15:00] <hatch> bak
[15:00] <abentley> benji: I am hesitant to add something to CI that will prevent working code from landing.
[15:01] <abentley> benji: For example, we lived for a long time with a lint error because one file was doing "from x import *".
[15:01] <benji> It seems to me that the only way to get something we want is to enforce it.  Automatic enforcemnt would appear cheaper.
[15:03] <abentley> benji: I think social pressure is sufficient here and avoids the inflexibility of automatic enforcement.
[15:05] <benji> It comes down to how we weigh the costs, benefits, and probabilities.  I weight the cost of someone having to resubmit a branch because of a lint error low (partially because I would propose a make target that would lint and propose), the cost of someone else having to deal with my lint errors high, and the probability of "trying harder" to materially increase compliance as low.  I can understand others having different weights/probab
[15:06] <hatch> also the possibility of a lint error causing an obscure issue...... +1 benji....sorry abentley :)
[15:06] <hatch> luca__: you're back! wb
[15:07] <abentley> benji: How about we start with the make target?
[15:08] <benji> sounds good to me
[15:13] <abentley> sinzui: The Kanban card "Implement new primary key for charms" should not have gone into Archive.  It's unlanded work (that I'm about to land).
[15:13] <sinzui> abentley, yes, but oh
[15:14] <sinzui> I believed you were done with that card, you were going to land the branch merged into another branch...tracking the other card all the way to the end of the board
[15:14] <hatch> rick_h: sorry I missed in the backscroll that you wanted to chat?
[15:15] <rick_h> hatch: yea, guichat?
[15:15] <hatch> ypup there
[15:17] <abentley> sinzui: Oh.  I thought we would handle that situation by moving the card when the follow-on branch landed.
[15:18] <sinzui> abentley, I had planned that originally, but since we were vacating the board, I decided to treat the issue as "the work is done because any developer can build of the branch".
[15:19] <sinzui> abentley, sorry, you were off when I made the decision. I talked to everyone by you.
[15:19] <sinzui> I suck
[15:19] <abentley> sinzui: Nah, I understand what happened now.
[15:19] <abentley> sinzui: All good.
[15:20] <abentley> sinzui: No need for a 1x1 today, right?
[15:21] <sinzui> abentley, +1
[15:21] <luca__> hey hatch, thanks :)
[15:43] <jcsackett> jujugui: can i get two reviews on https://codereview.appspot.com/12029045 ?
[15:43] <benji> jcsackett: I'll do one.
[15:43] <jcsackett> benji: thanks!
[15:43] <bac> jcsackett: yep
[15:43] <jcsackett> bac: thanks. :-)
[15:52] <Makyo> jujugui calli n 8 kanban now
[15:58] <bac> jcsackett: done but i haven't qa'd yet
[15:59] <Makyo> jujugui call in 1
[16:01] <Makyo> jcsackett, Starting now
[16:16] <hatch> gary_poster: comingsoon is 13 versions behind trunk
[16:18] <sinzui> mongodb people, this is a summary of what I know about manage.jujucharm.com's db https://pastebin.canonical.com/95291/
[16:22] <jcsackett> no one be alarmed if you heard a crashing noise as i signed off. my dog just discovered the side table is rickety and falls over if you nose it. :-P
[16:22] <hatch> lol
[16:23] <abentley> sinzui: Our canonistack instances have /dev/vdb mounted at /mnt, giving us 10 GB of space.  Are the prodstack instances similar?
[16:25] <bac> gary_poster, hatch: comingsoon is now r914.  the cronjob step 'make build-prod' was failing due to the switch to the new version of d3.  it needed a 'make clean' to get the cruft out.
[16:25] <hatch> ahh great thanks bac
[16:28] <hatch> hey luca__
[16:29] <sinzui> abentley, I am asking. I know production has 10G but logs are on a another disk
[16:29] <luca__> hatch: heya
[16:30] <gary_poster> bac, awesome thanks
[16:31] <gary_poster> jcsackett, if you want me somewhere I'll come by, otherwise will go back to planning world domination, or something
[16:31] <jcsackett> gary_poster: i think we're good for now.
[16:31] <gary_poster> cool jcastro 
[16:31] <jcsackett> wrong name, dude. :-P
[16:31] <gary_poster> sorry tab completio n :-P
[16:31] <gary_poster> cool jcsackett :-P
[16:33] <hatch> crap
[16:33] <hatch> guess I'm taking my engineer-license again
[16:33] <hatch> :P
[16:34] <hatch> gary_poster: if you change something and then hit the toggle it'll reset the values and that's what they will stay
[16:34] <hatch> oh he's back
[16:34] <hatch> and he's gone
[16:34] <hatch> lol
[16:36] <gary_poster> hatch, +1
[16:44] <gary_poster> debug hooks in juju core: https://codereview.appspot.com/12019043/
[16:45] <gary_poster> someone working on core for 2 weeks :-)
[16:56] <hatch> check out this css rule `input#use-default-toggle:checked ~ label .handle`
[16:56] <hatch> OOOOOeeeeee
[17:21] <sinzui> jujugui, I moved my notes to a gdoc so that we can all comment and edit. https://docs.google.com/a/canonical.com/document/d/1AoMhTdrominYLBS8iHbZLW_Ji2OH3mNhUzoHjetnD9w/edit#
[17:49] <rick_h> jcsackett: got a sec for a chat?
[18:12] <hatch> gary_poster: I think this is completed https://bugs.launchpad.net/juju-gui/+bug/1201023
[18:12] <_mup_> Bug #1201023: Charmbrowser sidebar elements all have scroll bars in IE10 <charmbrowser> <juju-gui:In Progress by huwshimi> <https://launchpad.net/bugs/1201023>
[18:14] <jcsackett> rick_h: sure. was grabbing lunch.
[18:14] <jcsackett> rick_h: still need to chat?
[18:14] <rick_h> jcsackett: no, I'm ok now. I follow what's up. Got confused by the jujucharms browser view setup
[18:15] <jcsackett> rick_h: ah, yeah. i could see that.
[18:15] <jcsackett> rick_h: i *think* maybe we can kill that? since we've launched, and i've heard nothing about doing a proper landing.
[18:15] <rick_h> jcsackett: yea, I was tempted to but I can work around it for now
[18:15] <rick_h> was the basis of the conversation request
[18:17] <jcsackett> rick_h: dig.
[18:51] <hatch> ugh handlebars drives me friggen bonkers sometimes
[18:56] <hatch> rick_h: you might be able to help me out here
[18:56] <rick_h> hatch: what's up?
[18:56] <hatch> service-configuration.partial has a {{#settings}} loop
[18:56] <hatch> and within that loop I need to access a parent property
[18:56] <rick_h> ../
[18:56] <hatch> I tried ../ghost (ghost being the property)
[18:56] <hatch> but no luck
[18:56] <hatch> {{#if ../ghost}}disabled{{/if}}
[18:58] <rick_h> hmm, app/templates/unit.handlebars uses it
[18:58] <rick_h> are you sure that there's a ghost one scope level up?
[18:58] <hatch> yup, logged it out
[18:58] <rick_h> heh {{debugger}} ftw?
[19:01] <rick_h> hmm, I wonder if it's because of the scope block of an #if
[19:01] <hatch> yeah checking that now
[19:01] <hatch> I upgraded the debugger fn
[19:02] <hatch> ok the #if must have busted scoping?
[19:02] <hatch> to #YUI!
[19:03] <rick_h> hatch: so yea, I'd drop a debugger in the YUI handlebars code in the if block helper and see wtf 'this' is in there. I'm betting it's not the loop scope any more?
[19:03] <rick_h> hatch: otherwise, I'd go about it a different way and try to get the var into the loop scope. Sucks, but that's why we have some buildTemplateData type helpers lying around. 
[19:03] <hatch> if that was the case then `ghost` would work, but it doesn't either
[19:04] <rick_h> yea, the only way to tell is to break in the if block helper and look
[19:04] <hatch> http://stackoverflow.com/questions/11562612/handlebar-context-lost-after-passing-handler
[19:04] <rick_h> I don't recall using a block with a ../ up scope variable reference. 
[19:05] <rick_h> hatch: yea, that makes sense 
[19:05] <rick_h> so does ../../ghost help you out?
[19:05] <hatch> nope, maybe I need three
[19:05] <rick_h> or ../../this.ghost
[19:05] <hatch> yup three
[19:05] <rick_h> but yea, basically a bunch of wheee to figure out how to get out of the context in the block helper
[19:05] <hatch> ugh...
[19:05] <rick_h> yea
[19:06] <hatch> handlebars totally does not follow the path of least astonishment
[19:06] <hatch> haha
[19:06] <rick_h> well, you're in the base context, then the loop context, then the if context
[19:06] <hatch> then the wtf am I doing context
[19:06] <rick_h> yea, I'm a 'give me my code or give me death' camp on templates myself. Unfortunately Mako hasn't been ported to JS yet :)
[19:06] <rick_h> lol
[19:06] <rick_h> time for a doc to explain wtf ../../../ is for :P
[19:07] <hatch> :) thanks for the help
[19:07] <hatch> lol
[19:07] <rick_h> hah, np. "Keep adding ../ until it works darn it!" coaching is here for you
[19:07] <hatch> hahaha
[19:11] <rick_h> ugh, that damn showView made some stuff magically work. 
[19:15] <hatch> rick_h: so depending on how many if blocks your in, you need more or less ../'s
[19:15] <hatch> oy vey
[19:15] <rick_h> hatch: but of course, each is another context
[19:15] <rick_h> you need good tests on those. If someone moves the if blocks around then things will go nuts
[19:16] <rick_h> hatch: but if it's getting too crazy maybe it's time to rethink?
[19:20] <hatch> rick_h: Yeah I think I'll switch it to a helper
[19:20] <hatch> but helpers don't have access to the full stack though I don't think
[19:20] <hatch> so maybe just some comments
[19:24] <hatch> lunching
[20:28] <gary_poster> hey bac, you actually here, or juts pretending to be?  I've got wedgwood in webops saying that he wants to rip out some of our old stuff from charm-helpers
[20:28] <gary_poster> my memory is that we tried to get some stuff approved
[20:28] <bac> hi gary_poster
[20:29] <gary_poster> but he didn't like test helpers or something like that
[20:29] <gary_poster> hey
[20:29] <gary_poster> you don't have to be here if it is past EoD  :-)
[20:29] <bac> yeah, he didn't promote the test helper stuff, saying it was client code
[20:29] <bac> gary_poster: no, it is just 16:30
[20:29] <bac> same as you
[20:30] <gary_poster> yeah I know but don't know when your start time is anymore :-P
[20:30] <bac> gary_poster: i've been starting at 8
[20:30] <gary_poster> cool
[20:30] <bac> gary_poster: anyway he wants to remove the non-promoted stuff?
[20:30] <gary_poster> bac, yeah
[20:31] <gary_poster> we still are not using it anyway, right?  I didn't see it anywhere
[20:31] <bac> i think that code is useful and deserves to live some place
[20:31] <bac> gary_poster: huh, i thought our tests used it
[20:31] <bac> gary_poster: or was it just from buildbot?
[20:32] <gary_poster> bac no I meant we are not using wedgwood's library yet
[20:32] <bac> gary_poster: that is true
[20:32] <hatch> bcsaller: can you think of a way to reset all of the settings fields to their defaults using current code? I was thinking something in the databinding maybe to reset to the default model values?
[20:32] <bac> gary_poster: if it is the OneTrueWay we'll need to spend some time converting our charm
[20:33] <bac> but that is tech debt for us now, so i'm not sure when we'll carve out the time
[20:33] <bcsaller> hatch: off the top of my head, viewlet.model.set(viewlet.model.getAttrs())
[20:34] <bcsaller> oh, defaults
[20:34] <hatch> oo good idea lemme try that
[20:34] <bcsaller> not prev value though
[20:34] <bcsaller> defaults come from the charm, not the values in the service
[20:34] <bcsaller> model.set('config', charm.options)
[20:35] <bcsaller> should work though
[20:36] <bac> rick_h: why would 'make testid' produce non-contiguous numbers?  i'm seeing things like 1..16, 420, 17, 18, 421
[20:40] <hatch> bcsaller: ahh actually we aren't databinding the ghost config so that approach wont' work :(
[20:40] <hatch> will need to just loop through I guess, oh well
[20:40] <bcsaller> hatch: I thought we changed it to db everything now though?
[20:41] <hatch> ohh hmm lemme look further maybe I broke something
[20:45] <hatch> bcsaller: do I have something wrong here https://gist.github.com/hatched/beee9956434d9ff6be5f the update fn is never being called when I update options
[20:47] <bcsaller> hatch: you're sure its options and not config now, I'm not sure the current state of that 
[20:47] <bcsaller> but the structure looks right
[20:48] <hatch> well regardless of what it is - changing that object 'should' fire that update method
[20:48] <bcsaller> no, update in bindings is called when that binding changes 
[20:48] <bcsaller> so if the name is wrong it doesn't happen
[20:48] <hatch> ok but there is an attribute called 'options'
[20:49] <hatch> which I am setting
[20:52] <bcsaller> we have options, config, settings, depending on which model you have I'd guess the name was wrong but I don't know how far you've gotten tracking it down 
[20:55] <hatch> I'm just going to loop through the default values
[20:55] <hatch> I think this is a bug, I'll document it later and see if we can resolve sometime
[20:56] <bcsaller> is the model is question a POJO? it might be that observe isn't triggering change on a nested complex object
[20:56] <hatch> ohh wait a second
[20:56] <hatch> I think this is a bug from the charm model stuff
[20:57] <hatch> charm model changeover
[20:57] <hatch> all of the fields are undefined
[20:57]  * hatch shakes fist at jcsackett
[20:57] <hatch> lol :P
[20:57] <jcsackett> hatch: i qa'ed against service inspector and didn't see anything.
[20:58] <jcsackett> options.options seems weird, if options is charm...the charm attr should be get('options')
[20:59] <rick_h> bac:  not sure, just how it works. I've not looked at the implementation
[20:59] <rick_h> bac: the test runner usually loads tests and runs them alphabetically and such. SO maybe something with loading/running
[20:59] <hatch> bcsaller: jcsackett ahh I found the bug....the fields have been renamed in the charm model and now the template bings on the wrong object
[20:59] <hatch> easy overlook
[21:00]  * bcsaller coughs
[21:00] <bcsaller> thats what I said
[21:01] <hatch> yeah well I had no idea what you were trying to say
[21:01]  * hatch blames internet
[21:01] <hatch> lol
[21:02]  * bcsaller blames unicode
[21:02]  * hatch blames timezones
[21:03] <hatch> (all developers can agree timezones are to blame so it's an easy scapegoat)
[21:03] <bcsaller> yeah, we should get rid of those
[21:04] <hatch> aww man I got up so early. Yeah what time? oh like 5pm
[21:04] <hatch> hehe
[21:07] <jcsackett> hatch: which fields were renamed? i was trying to avoid doing that where possible and am concerned something may have been landed that shouldn't.
[21:08] <hatch> jcsackett: it's no big deal it's just a discrepency between the ghost and service models and their resulting structure
[21:08] <hatch> I think it's done properly now so I'm taking another approach
[21:08] <hatch> I was just blaming you because your current task sucks
[21:08] <hatch> ;)
[21:08] <jcsackett> hatch: :-P
[21:09] <gary_poster> :-)
[21:09] <gary_poster> go jcsackett! sis boom bah! :-)
[21:20] <gary_poster> sinzui, how goes the MongoDB war?
[21:21] <sinzui> webops are considering my recommendations to move the db files to a larger mounted partition. This suggest means 0 down time
[21:33] <hatch> bcsaller: so I don't think that setting an object to the same value as it is triggers the databinding
[21:35] <hatch> it's ok, I'm looping through the fields
[21:36] <hatch> but just thought I'd point that out
[21:40] <gary_poster> sinzui, cool.  do we know why the data is more than we expected?
[21:41] <sinzui> mongodb perallocates ever increasing files when there is lots of activity
[21:41] <sinzui> gary_poster, This is the summary: https://docs.google.com/a/canonical.com/document/d/1AoMhTdrominYLBS8iHbZLW_Ji2OH3mNhUzoHjetnD9w/edit#
[21:43] <gary_poster> sinzui, ugh.  thank you.
[21:44] <hatch> Jeff Pihach has been assigned to the Card [(1201024) IE 10 drag and drop bug] by Gary Poster.   NOOOOOOooOOOOoooooooooo
[21:44]  * hatch curls up under the desk
[21:44] <hatch> :D
[21:44] <gary_poster> hatch lol, that was the one you fixed before
[21:44] <gary_poster> hatch, I moved that to archive and gave you credit
[21:45] <gary_poster> there is still the new one :-)
[21:45] <hatch> ohh haha ok well then that's better :D
[21:45] <gary_poster> which I have not assigned to you...yet...
[21:45] <hatch> lol
[21:45] <gary_poster> who displeases me, among you?!! mwa ha ha ha.  etc.
[21:48] <hatch> hahah
[21:50] <gary_poster> benji, where is the charm branch?
[21:50] <gary_poster> was hoping we could have that ready today
[21:51] <gary_poster> by "where is"  I  mean "what's going on with the."  By "benji" I mean "benji, who is past EoD,"
[22:03] <hatch> :D
[22:03] <hatch> gary_poster: have a second to try out my toggle branch? lp:~hatch/juju-gui/use-def-config
[22:04] <gary_poster> hatch, I think so, unless pulled away suddenly :-P one sec
[22:07] <hatch> cool thanks!
[22:11] <gary_poster> hatch, pulled away :-P will look asap after
[22:12] <hatch> haha np
[22:22] <benji> gary_poster: https://code.launchpad.net/~benji/charms/precise/juju-gui/fix-cache-headers/+merge/177958
[22:22] <benji> darn, I'm in the right channel
[22:22]  * benji goes to a channel far, far away
[22:35] <Makyo> hatch, (new Array(3)).map(function(d) { return 0; }) [22:35] <Makyo> Or anyone, really.
[22:36] <hatch> magic!
[22:36] <hatch> wait
[22:36] <hatch> that's gota be d3 code
[22:36] <hatch> because it's impossible to read
[22:36] <hatch> I think I know what's happening
[22:36] <Makyo> hatch, From a friend, just asking around.
[22:36] <hatch> it creates a new array with 3 empty slots
[22:37] <Makyo> Just curious because [undefined, undefined, undefined].map(function(a) { return 0; }) [22:37] <hatch> it then loops through each one returning 0
[22:37] <hatch> so each one will be [0,0,0]
[22:37] <hatch> Makyo: it's probably some wako way to test for map functionality
[22:38] <hatch> or proper functioning map functionality
[22:38] <Makyo> The result should be [0, 0, 0] since (new Array(3)) [22:38] <hatch> I would love to know the real reason behind the code
[22:38] <Makyo> hatch, not from an open source project, friend works elsewhere.
[22:38] <hatch> right, but if map wasn't working properly then it 'could' be an indicator
[22:38] <Makyo> So I'm assuming there's some more intermediary stuff, probably conditional.
[22:39] <hatch> right....still odd
[22:39] <Makyo> Well, those results are from my console.
[22:40] <Makyo> Oh, huh.  (new Array(3)).map(function(a) { return typeof a; }) [22:40] <Makyo> but [undefined, undefined, undefined].map(function(a) { return typeof a; }) [22:40] <Makyo> So the constructor is just sort of...doubly undefined :P
[22:41] <hatch> [undefined, undefined, undefined].map(function(d) { return 0; })
[22:41] <hatch> gives what one would expect
[22:41] <Makyo> returns [0, 0, 0]
[22:41] <hatch> right
[22:41] <hatch> as it should
[22:41] <hatch> my guess is this is some edge case from using the array constructor
[22:41] <hatch> which they say never to use :)
[22:41] <Makyo> Hahaha
[22:41] <Makyo> Yeah
[22:42] <hatch> I'm intrigued now
[22:42] <Makyo> Ohhh, he found it: http://stackoverflow.com/questions/5501581/javascript-new-arrayn-and-array-prototype-map-weirdness
[22:43] <hatch> ahhhhh
[22:43] <Makyo> There's a difference between undefined pointers and pointers to undefined.
[22:43] <hatch> makes sense
[22:43] <hatch> well, sortof
[22:43] <hatch> lol
[22:43] <hatch> I mean, I accept the reasoning :)
[22:43] <Makyo> Hah, yeah.
[22:45] <hatch> thats probably why devtools shows it as [undefined x3] in a different style when using new Array(3)
[22:46] <gary_poster> hatch looking at your branch quickly...
[22:46] <hatch> thanks
[22:52] <gary_poster> hatch branch looks great.  only problem from UX perspective to me is that the "Use the default configuration" slider doesn't clearly show on/off to me.  Could we remove the checkmark when it is off?  I also wonder about turning it gray but I think that actually doesn't follow the intended design language
[22:52] <hatch> yeah grey feels like it woudl be 'disabled'
[22:52] <hatch> I can remove the check though
[22:53] <gary_poster> awesome thanks
[22:54] <hatch> no prob, thanks for looking,
[22:54] <hatch> i'll propose after that change
[22:54] <benji> hatch: it's because the function passed to .map is only called on array elements that have a value and (new Array(3)) creates an array with pre-alocated space for three elements, not a three element array
[22:54] <benji> oops, Makyo I mean ^^^
[22:54] <hatch> benji: welcome to 10 minutes ago
[22:54] <hatch> oooburn
[22:54] <hatch> :P
[22:54] <Makyo> It's well put though.  Thanks benji 
[22:55] <benji> heh
[22:55] <benji> that's what I get for being in the right channel
[22:55] <gary_poster> lol
[22:55] <hatch> lol
[22:55] <hatch> I wonder the purpose of the two methods
[22:56] <hatch> using the constructor doesn't restrict pushing more information into it
[22:56] <gary_poster> looking at your branch fwiw benji.  will ask west coast or frankban/teknico to review in an email so you can hopefully land tomorrow morning.  then we can make a release, test, and hopefully launch jujucharms in afternoon
[22:56] <gary_poster> s/launch/update/
[22:57] <benji> gary_poster: thanks, that's what I was hoping for
[23:00] <gary_poster> hatch, I've seen that approach used in other languages as a micro-optimization opportunity.  I would assume it is the same here.
[23:01] <gary_poster> in a fast inner loop that kind of thing can make a diff
[23:01] <hatch> gary_poster: yeah I suppose - I could see if it was in a typed language where you would create an array of a specific size to reserve memory
[23:02] <gary_poster> also used in clojure, which is untyped.  you are reserving space for pointers.
[23:02] <hatch> does clojure allow you to alter the size of the array as well?
[23:02] <gary_poster> if elements of pointers already exist (flyweights like numbers or strings, or existing objects)...
[23:02] <gary_poster> then can still make a big diff
[23:02] <huwshimi> Morning
[23:02] <gary_poster> yes, hatch
[23:03] <gary_poster> morning, huwshimi!
[23:03] <hatch> interesting
[23:03] <hatch> morning huwshimi
[23:03] <gary_poster> strings are typically flyweights not numbers; whatever :-P
[23:04] <gary_poster> huwshimi, I assigned you bugs.  They are for first half of August not urgent, though if you are looking for something to do, or comment on, cool.  also feel free to decline assignment :-)
[23:04] <gary_poster> huwshimi, I know you have plenty to do thogh anyway
[23:04] <gary_poster> though
[23:04] <huwshimi> gary_poster: OK, I'll take a look
[23:05] <hatch> *disclamer* declining the assignments may also decline checks
[23:06] <hatch> guess noone gets checks
[23:08] <gary_poster> :-P
[23:09] <gary_poster> benji approved with no changes, but with follow-on warning about where/how to land.  very nice, thanks!
[23:09] <benji> gary_poster: I was unsure about that bit; I proposed to the ~charmers branch because I figured that's where we would land it first
[23:10] <benji> ok, dinner time; I'll see y'all tomorrow
[23:10] <gary_poster> benji wait
[23:10] <gary_poster> benji wrong brancgh
[23:10] <gary_poster> not lp:~charmers/charms/precise/juju-gui/trunk
[23:10] <gary_poster> lp:~juju-gui-charmers/charms/precise/juju-gui/trunk
[23:11]  * gary_poster sends another message
[23:12] <hatch> gary_poster: the top right card in Inspector Ready to Code is no longer valid - at least it appears to work as expected
[23:12] <hatch> Collapsed inspector does not...
[23:12] <hatch> properly set its maximum...
[23:12] <gary_poster> hatch checking
[23:13] <gary_poster> weird...bac said that he fixed comingsoon update mechanism but it is still old
[23:13] <hatch> refresh
[23:14] <hatch> I just thought the same thing
[23:14] <hatch> lol
[23:14] <gary_poster> heh
[23:14] <gary_poster> ok thanks
[23:15] <gary_poster> hatch agree, great!  you fix that?
[23:15] <hatch> jujugui lf two reviews and a QA on https://codereview.appspot.com/12205043/ plz and thx
[23:15] <hatch> I did yup
[23:16] <gary_poster> hatch, moved with credit given :-) thanks
[23:16] <hatch> :)
[23:17] <hatch> it's past my EOD Now but anything specific you want me on tommorow morning?
[23:17] <hatch> I was thinking the ghost config importer? as it's red
[23:19] <gary_poster> red just means defect: claims to work but doesn't.  still not a bad idea...header images would be cool too.  I'll see if huwshimi has time for that.  hatch I vote for sticky headers before that :-P
[23:20] <gary_poster> hey huwshimi, one probably easy thing to do...if you start up serviceInspector and add a service
[23:20] <gary_poster> We have these five controls
[23:20] <gary_poster> ← S C E D
[23:20] <gary_poster> We need to remove "E" and "D" and then replace the other three with icons
[23:21] <huwshimi> gary_poster: OK
[23:21] <hatch> sticky headers.....uuuuugh
[23:21] <hatch> ooooo kkkkaaayyyy
[23:21] <hatch> :)
[23:21] <gary_poster> hatch use the hack from ant
[23:21] <gary_poster> easy, yeah?
[23:21] <hatch> I don't think his technique will work with dynamic content
[23:21] <gary_poster> huwshimi, finding icons one sec
[23:21] <hatch> I'll have to test
[23:22] <gary_poster> hatch oh :-( ok timebox it to an hour
[23:22] <gary_poster> huwshimi, https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1Zm8ya3NIcENyZnM
[23:23] <hatch> gary_poster: ok can do - it might work alright but every time we update we'll need to recalc the header positioning....so I'll timebox the hour to see how difficult it'll be and then we can revisit
[23:23] <gary_poster> hatch resolve retry replace instead, if you want?  that's one of the few remaining bigger tasks
[23:23] <gary_poster> hatch we can push the sticky header to the end I guess.  It's not awful without it :-P
[23:23] <huwshimi> gary_poster: Do you want these icons in today?
[23:24] <hatch> ok resolve retry replace it is then!
[23:24] <gary_poster> thanks hatch
[23:24] <gary_poster> huwshimi, if easy and doesn't take much time, yes.  what are you on now?  I know I am supposed to know but have forgotten
[23:25] <huwshimi> gary_poster: Just checking the sass builder with the files from ant and then moving onto something new... which can be the icons.
[23:26] <gary_poster> huwshimi, cool thanks.  if ant's files work, land the sass thing, if I wasn't clear.  forgot what I said :-P
[23:26] <huwshimi> gary_poster: No problems.
[23:26] <gary_poster> thanks :-)
[23:26] <hatch> huwshimi: if you have time add the icons to the spriting so that we can reduce our http requests
[23:26] <hatch> then we don't have to go back and do it later
[23:27] <gary_poster> oh yeah that would be cool
[23:27] <hatch> not sure if you were aware of that or not
[23:27] <gary_poster> if not clear how to do, just ask
[23:27] <hatch> (the spriter)
[23:27] <gary_poster> huwshimi, after all that continue on the sass
[23:28] <huwshimi> hatch: Can we have dynamic sprites (hover, active etc)?
[23:28] <huwshimi> hatch: That's the one thing I haven't been able to figure out
[23:28] <gary_poster> huwshimi, just change class, yeah?
[23:28] <gary_poster> oh that doesn't work I see
[23:28] <hatch> huwshimi: yeah, you would specify a different background position for the :hover :active psudo class parts
[23:28] <gary_poster> you break out of css
[23:29] <gary_poster> oh yeah
[23:29] <huwshimi> hatch: But how do I know what those positions are supposed to be?
[23:30] <hatch> in the sprite.css file
[23:30] <huwshimi> hatch: As in, if the sprite image changes (which it frequently does) then the hovers etc. have to be manually calculated and updated
[23:31] <hatch> hmm
[23:32] <huwshimi> hatch: One approach is to have all the different sprite images inside the node and on hover/active use CSS to hide/show the correct image...
[23:32] <hatch> well the sprite is only a single image
[23:33] <hatch> which is made up of a bunch of smaller ones
[23:34] <huwshimi> hatch: Oh, I mean have something like <a href=""><i class="image-one sprite"></i><i class="image-two sprite hidden"></i><i class="image-three sprite hidden"></i></a>
[23:35] <hatch> ohh then you would go a:hover .image-one { display: none } a:hover .image-two { display: block; }
[23:35] <hatch> ?
[23:36] <huwshimi> hatch: Yeah
[23:36] <hatch> hmm
[23:36] <hatch> it works.....feels hacky
[23:36] <hatch> can't think of a better alternative
[23:36] <hatch> SHIP IT!
[23:36] <huwshimi> hatch: Yeah...
[23:37] <hatch> my actual alternative is to patch node-spritesheet to add :hover classes :)
[23:37] <hatch> but who has the time!
[23:37] <hatch> although
[23:38] <huwshimi> hatch: It's built dynamically, so you'd have to have another script to modify it after it was built
[23:38] <hatch> well I was also thinking looping through the sprites twice
[23:38] <hatch> once like normal, then another config to generate the hovers
[23:39] <hatch> https://github.com/richardbutler/node-spritesheet#simple-example
[23:40] <hatch> thinking maybe the `selector` property could be .selector:hover on this second pass
[23:40] <hatch> or
[23:40] <hatch> could be
[23:40] <hatch> yeah....that's it
[23:41] <hatch> I don't know if it's even possible without patching it
[23:42] <hatch> image1.png image1-hover.png image1-active.png could then be turned into psudo's
[23:42] <huwshimi> hatch: Well it would have to be customisable depending on what you want to do. The selector depth might be .something li.active a {}
[23:42] <huwshimi> hatch: Not necessarily just the standard :hovers
[23:43] <hatch> oh I suppose yeah becuase you wouldn't always be hovering over just the icon
[23:43] <huwshimi> hatch: Yeah exactly
[23:43] <hatch> alright so yeah your approach works the best then with the dynamic generated styles
[23:43] <hatch> else it'll be to fragile
[23:43] <huwshimi> hatch: Exactly
[23:44] <hatch> oh well...I tried :P