#juju-gui 2013-06-03
<gary_poster> hi everyone
<gary_poster> frankban, could you please beg/borrow/steal some juju-core reviews for your branches? :-)
<gary_poster> benji, you up for reviewing bcsaller's branch for #1185982?
<gary_poster> https://codereview.appspot.com/9906044/
<benji> gary_poster: sure
<gary_poster> thanks benji
<gary_poster> hi alejandraobregon.  Do you know when you will get a chance to have some of Charline's time for reviewing the user data questions?  I'd like to get that moving, but I do want to have her input and advice if we can.  If you want me to contact her directly I'd be happy to, but I also appreciate you talking with her about it.
<frankban> gary_poster: I'll do :-) https://codereview.appspot.com/9810044 would like to be reviewed by someone in the golden horde
<gary_poster> thanks frankban :-)  bac, you around for frankban's review request ^^ , by chance?
<bac> gary_poster: sure
<frankban> thanks bac
<gary_poster> thanks bac.  frankban, fwiw looks good to me, but I'd want to look at it more closely for an official review.
<bac> frankban: why do you consistently use the word 'machiner'?  is that just a typo for 'machine' or am i missing something?
<bac> machinery?
<frankban> bac: it's how the machine worker is called in juju-core, I have no problem in using "machine" if it makes it more understandable
<bac> machiner (plural machiners)
<bac> One who operates a machine.
<alejandraobregon> gary_poster: hi! nice weekend? Have a meeting booked in with Charline tomorrow to discuss user feedback :)
<bac> if that is the correct word for this context then please use it.  but i don't want to see something clumsy and juju propogated
<bac> frankban: ^^
<gary_poster> alejandraobregon, yes, nice weekend, thanks!  dad was in for a visit.  hope yours was nice too.  Charline meeting tomorrow: fantastic, thanks!
<frankban> bac: ack, 2 out of 2 reviewers got confused by machiner, enough to change it IMHO
<gary_poster> bac, you saw frankban's reply about juju core's nomenclature?
<bac> ok
<bac> gary_poster: you mean in this discussion or elsewhere?  i didn't read responses to other reviews yet.
<gary_poster> bac, simply above: """it's how the machine worker is called in juju-core, I have no problem in using "machine" if it makes it more understandable"""
<bac> gary_poster: yes, i read that
<gary_poster> I worry a bit about moving away from their names, even though I agree they don't make sense
<gary_poster> well, that's too strong
<gary_poster> but maybe it is reasonable to define their terms somewhere and then use them
<gary_poster> for instance, I think William has to translate in his head when he talks to us
<gary_poster> to handle our use of the "delta" term, for instance
<gary_poster> the more we have a shared understanding and vocabulary the better
<gary_poster> end of thought.
<gary_poster> fine with changing it to "machine worker" for this branch
<frankban> gary_poster: +1
<gary_poster> cool.  so another approach would be to start a "definitions" doc file.  <shrug>  Not advocating, brainstorming.
<frankban> gary_poster, teknico: when you have time, I'd like us to have a quick call re juju-test
<bac> gary_poster, frankban: i just looked at the juju-core code and they have a Machiner class.  it is a real conceptual thing, not just a passing odd word.  so i think we should use it.  i like the idea of defining it, though.
<gary_poster> frankban, cool.  I should have time within the next hour or so.
<gary_poster> bac, great, thanks for looking at that
<frankban> gary_poster: cool, thanks
<teknico> frankban, gary_poster: I'm ready
<gary_poster> thanks
<frankban> gary_poster, bac: on the other end, I don't like the idea of the charm having to deal with internal juju-core implementation concepts, like machiner or agent.conf. In this context, they were added as a temporary workaround. We still need those for backward compatibility but we will eventually get rid of those.
<frankban> s/end/hand/
<frankban> gary_poster, teknico: ready on the chat when you are.
<gary_poster> ok thanks.  still trying to finish something else up.  will ping/
<gary_poster> frankban, re machiner name: not sure.  I trust whatever decision you and bac agree on.
<hatch> good morning all
<gary_poster> morning hatch
<hatch> gary_poster: model/view databinding in yui functional prototype https://gist.github.com/hatched/285d3aadb0dbdd94b2db
<hatch> :)
<gary_poster> hatch, rock :-)
<gary_poster> thanks
<gary_poster> hatch, looks simple and very good.  I see you filled out the google doc too, thank you.  Maybe send demo and doc around to gui team + rick and jc?
<benji> Review available, 50% off: https://codereview.appspot.com/9953045
<jcsackett> orangesquad: going to be a moment late, fighting g+. 
<abentley> sinzui: ping for standup
<bac> benji: i was just about to do that one but couldn't find the url.  on it now.
<bac> benji: coincidentally, i have one ready for eyeballs too!
<benji> bac: thanks.  I'll take a look at yours as well.
<bac> benji: sorry, i couldn't get my bzr config set properly for lbox so it is an old school LP merge proposal
 * benji feels a rush of nostalgia.
<hatch> gary_poster: sure thing I'll put up a jsbin in a minute
<gary_poster> cool thanks
<gary_poster> frankban, teknico call in 14 minutes, at quarter past hour?
<jcastro> gary_poster: antonio and I have a call with mark this morning @ the same time as the site/GUI call; if you guys need anything from us just let us know
<frankban> gary_poster: sounds good
<teknico> frankban, gary_poster, works for me
<gary_poster> thanks frankban & teknico
<gary_poster> jcastro, will do, thanks.  I talked with Antonio about some topics, esp. the quality tab, that I'd like your ack on. Maybe we can catch up later today
<teknico> bac: I need to talk with you re: tarmac, got some time?
<bac> teknico: let me finish this review
<bac> won't take long
<teknico> bac: sure, thanks
<hatch> rick_h_: I finally remembered why I pinged you the other day :)
<rick_h_> hatch: party on
<bac> teknico: guichat?
<teknico> bac: I am in ongoing call there with frankban and (soon) gary_poster
<bac> teknico: oops, i see it is busy
<bac> teknico: ok, ping me when you want to talk
<teknico> bac: I will
<hatch> email sent
<hatch> or not....
<hatch-mobile> power went out 
<bac> jujugui: seeking one more review for https://code.launchpad.net/~bac/charms/precise/juju-gui/unified-ppa/+merge/167039
<hatch-mobile> glad I had a UPS heh 
<sinzui> orangesquad, charmworld r420 is deployed. we are waiting for ingest to do a full run to verify non-charmers promulgated is fix released.
<rick_h_> sinzui: rgr, awesome
<teknico> bac: coast is clear
<teknico> marcoceppi: hi, got a minute for a quick chat?
<marcoceppi> teknico: certainly
<teknico> marcoceppi: thanks, tinyurl.com/guichat ?
<teknico> uhm, http://tinyurl.com/guichat
<marcoceppi> teknico: works for me
<abentley> rick_h_ or jcsackett: Please have a look at this: https://code.launchpad.net/~abentley/charmworld/api-2-docs/+merge/167058
<rick_h_> abentley: looking
<hatch-mobile> man the power is still out 
<rick_h_> abentley: so I'd mention to sinzui you are headnig to api2 
<sinzui> there can be only 1
<abentley> rick_h_: I think you just did :-).  sinzui, docs are here.  https://code.launchpad.net/~abentley/charmworld/api-2-docs/+merge/167058
<sinzui> the spike is now a feature?
<abentley> sinzui: No, not implemented yet.  I wrote the docs to reflect our conversation.
<teknico> gary_poster: I summarized my chats with b.a.c and marco.ceppi in the card description; what's a better place for that info, if any? it's my card in Maintenance - Active - Branch start
<teknico1> bah, got disconnected
<benji> grr, after tweaking my code through review I now get test failures when run in phantomjs (but not Chromium)
<rick_h_> abentley: can you peek at https://code.launchpad.net/~rharding/charmworld/add-category-api/+merge/167078 when you get a sec please? Short/sweet
<abentley> rick_h_: sure.
<bac> thank you teknico1
<abentley> sinzui: For your work, when the author has not specified any categories, do you handle it as None, [] or no-such-attribute?
<hatch> guichat in 3?
<hatch> 2
<sinzui> abentley, I intended to return []. You can disagree now and tell me to return None.
<hatch> yay power just came back on
<abentley> sinzui: I like [].  rick_h_, how do you feel about changing categories to be [] when not supplied?
<rick_h_> abentley: fine by me. I went with the change that failed the least number of tests :)
<rick_h_> abentley: I'll change to [] and update the rest of the tests 
<sinzui> abentley, I have chosen to return None for no icon because an empty string is bad. the views/model will need to omit the attr from the json when icon is None
<sinzui> ^ rick_h_
<rick_h_> sinzui: there is no icon in the api any more 
<abentley> sinzui: ^
<rick_h_> sinzui: it's a direct check for the icon.svg in files
<sinzui> fab. I can remove it from my model.
<abentley> sinzui: I guess the problem is we haven't actually deleted API0.  jcsackett, were you able to figure out whether it's safe to delete API0?
<Makyo> jujugui Call now?
<bac> hey gary_poster, you coming?  benji?
<benji> coming
<rick_h_> abentley: it should be safe currently. 
<jcsackett> abentley: yes it is safe. thought i told you on friday. my apologies.
<rick_h_> abentley: uistage has been on api1 for a while
<gary_poster> jujugui I am coming
<abentley> jcsackett: Thanks.  It's entirely possible you did tell me and I forgot.
<jcsackett> abentley: well, either way. kill it. :-)
<abentley> sinzui: I will kill API0 and the icon as my next task.
<sinzui> understood
<Makyo> gary_poster, browser froze.  Going well.
<abentley> rick_h_: Did the API0 tests pass for your branch?  I would have expected them to break due to the introduction of categories.
<rick_h_> abentley: yes, all tests passed in the original branch. Getting some failures now in a couple of places. 
<rick_h_> abentley: So they passed because if there was no categories or it was [] I didn't return it.
<abentley> rick_h_: Ah, right.
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/fix-orphan-chunks/+merge/167084 ?
 * sinzui looks
<abentley> rick_h_: r=me.  Thanks!
<rick_h_> abentley: cool thanks, was just waiting for the diff to update 
<luca__> sinzui: gary_poster anyone: can you set constraints for a bundle?
<teknico> bac: what does "c-n-p" mean (re: your review of benji's branch)?
<gary_poster> rick_h_, do you want to be at tech discussion?
<rick_h_> gary_poster: loading now
<bac> cut-AnD-paste
<teknico> ooh, right
<bac> sorry
<luca__> bcsaller: can you set constraints for a bundle? or edit settings? Also, what settings would be available when your deploying a bundle?
<bcsaller> luca__: I'm in a meeting now but can reply after
<luca__> bcsaller: np, thanks :)
<hatch> ok I'm going to finish my breakfast now :)
<hatch> 11:13...more like lufast
<hatch> since it's more lunch than breakfast
<bcsaller> and luca is gone now :(
<hatch> bcsaller: so is it decided that we are sticking with d3 for the env then?
<hatch> I remember the discussion from oakland about alternatives
<hatch> but now with the request for more with d3 experience
<hatch> when the power went out the second time I learnt that my phone does not have enough processing power to run a hangout with 10 people :)
<bcsaller> hatch: we don't have a sufficient alternative at this point. There was some talk of rendering with WebGL but IE10 support is only via a plugin so its a no-go
<hatch> ahh and the canvas tools available were subpar?
<bcsaller> additionally we have UX that zooms, canvas is raster, svg is vector and scales
<hatch> ahh right right
<hatch> webgl would be so damn cool
<bcsaller> its different, we'd give up the CSS skinning, the DOM event model (for something similar but different)
<hatch> does IE10 auto update to 11 when it comes out? 11 will support GL :)
<rick_h_> hatch: quit talking crazy
<bcsaller> I don't know the plan there
<hatch> rick_h_: oh c'mon - webgl, occulus rift, nintendo powerglove, treadmill
<gary_poster> sinzui, do you have a few minutes to help me write the email to Mark about the quality metric for charms?  Or is there someone else who would be able to give me the context you think I might need?
<jcsackett> rick_h_: care to take the first review on https://codereview.appspot.com/9965044 ?
<gary_poster> rick_h_, was their discussion about including the charm tabs in the URL?  I have a use case for it right now. :-)
<gary_poster> there
<hatch> gary_poster: bcsaller should we have a chat about where to go from here?
<bcsaller> hatch: yeah, when ever you have time we can hope on g+ again 
<gary_poster> hatch, bcsaller was thinking something similar.  
<gary_poster> I'm on guichat now
<gary_poster> could talk now?
<hatch> okee
<rick_h_> gary_poster: yes, it's an open bug to add that feature in
<rick_h_> gary_poster: just lost some priority with recent api fixes/etc. 
<gary_poster> ok cool thanks rick_h_ 
<rick_h_> gary_poster: #1175149 if you care enough
<_mup_> Bug #1175149: URLs cannot take you to a particular tab in charm details <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1175149>
<rick_h_> jcsackett: looking
<rick_h_> jcsackett: actually, will look in a sec. Today's flown by and need to fetch lunchables.
<jcsackett> rick_h_: dig.
<sinzui> gary_poster, I think this summarises my understanding of the issue: https://docs.google.com/a/canonical.com/document/d/1I25jG9rcZY6K6x250LhY-8bfEy0KgDXZYrk9UgagFCo/edit
<gary_poster> thank you very much sinzui.  Incorporating
<benji> gary_poster: my branch is landed and I am hungry; after lunch I'll check with you about... whatever it was that you wanted me to do next ;)
<gary_poster> benji, ok thanks :-)
<abentley> sinzui: The 02 migration (removing periods from keys) has tests that now fail.  Should I remove the tests?  Remove the whole migration?
<sinzui> oh.
<sinzui> abentley, Yes is the immediate answer. Maybe we want to note this circumstance in the docs. We can remove migrations when we believe every supported site is migrated...and that is just mange.jujucharms.com
<abentley> sinzui: Cool.  For some reason I thought we'd have to support jujucharms.com, but of course we've already gone past it.
<abentley> sinzui: We don't currently have an elasticsearch migration tool.  Maybe we should add one, maybe we should migrate mongo and elasticsearch using the same tool, maybe we should just reindex mongo.  Thoughts?
<rick_h_> jcsackett: LGTM inbound with a couple of things to look at please. Small enough changes I think, but let's chat if I'm off base if that's cool
<sinzui> abentley, I favour reindex mongo...I think we had agreed that in the past
<abentley> sinzui: Oh, I don't remember that, but it works for me.
<rick_h_> sinzui: abentley didn't we talk about adding a function to the current migration code so that you could create a new migration file who programattically did a reindex in the upgrade function call?
<sinzui> abentley, I suppose I was jumping to conclusions in the past. 
<rick_h_> abentley: sinzui thus kind of re-using our "do it once when we need to" code already written without manual intervention on deployments?
<abentley> rick_h_: I don't remember that, but it makes sense.
<rick_h_> abentley: sorry, maybe I had the chat with sinzui along those lines. It's been a bit. 
<rick_h_> abentley: but yea, ideally I'd think we'd add a migration helper functino to do a re-index and just create a migration that touches ES using the helper. 
<sinzui> abentley, I assumed sync-index would be the way to update elastic search after ever mongodb change.
<abentley> The things we currently do are: in the charm, index mongo into ES as soon as both are available, and on change to the ES mappings, reindex ES into ES.
<sinzui> !
<sinzui> abentley, that reminds me...
<sinzui> abentley, rick_h_ ...I think I want to change that rule to know if the services have current data. I wait to wait for a new ingest when I brought up the app with the current db and search
<sinzui> s/wait to wait/had to wait/
<abentley> sinzui: So that was a case where we could have done a migration, and maybe should have.  Or else requested webops to do a manual ingest as well.
<sinzui> abentley, every time we remove and add db+search relations, we do a full ingest. That means adding a unit will try to do a full ingest (we ignore its attempt). If I bring up the db from a dump file, I only want sync-index to run
<jcsackett> rick_h_: replied, happy with most changes. working on those now.
<rick_h_> jcsackett: cool looking
<abentley> sinzui: When there is already a unit and we add a unit, I believe we don't do that.  It's only when there are no units and we add one.
<benji> gary_poster: I'm back
<gary_poster> hey benji thanks.  checking guichat...
<benji> gary_poster: it's not free
<gary_poster> benji, k, making room
<abentley> sinzui: I guess I'm not clear what the new rule would look like.  Never auto-ingest, because we assume there was a dump?  Have a new relation variable to indicate that there was a dump?
<sinzui> abentley, if config-changed could check both db and search have an agreeing set of data, then go right to the expose step
<sinzui> abentley, If just db, then sync-index and expose
<rick_h_> jcsackett: thanks, I'm pulling down the branch to play with the delegate. Hold off landing until I check that out please. 
<abentley> sinzui: I think we can make sync-index fast enough that we don't care whether it runs, by using bulk_index.
<sinzui> abentley, I am not proposing you do this config-change work. I was pondering it when we had the agent state non-sense last week.
<sinzui> abentley, oh, lovely.
<rick_h_> hah, forget fixing issues, just bypass with new tools ftw!
<rick_h_> jcsackett: hangout when you get a sec please?
<bac> jujugui: my isp just announced they are on their way to service our tower so i may drop off in a bit
<gary_poster> ack
<bac> gary_poster: i'm looking for a card to pick up.  you have any suggestions?
<gary_poster> looking
<gary_poster> bac I suggest the high from Story A, which I can describe, or one of the three maintenance high cards
<gary_poster> the first two are d3-related
<gary_poster> the first two maintenance I mean
<bac> gary_poster: so you mean the analytics story?
<gary_poster> yes bac.
<bac> i'm happy to look at that.  i'd like to see the names 'crazy egg' rejected.
<gary_poster> lol
<gary_poster> bac, ok want to come by guichat and we'll talk about it?
<bac> sure
<bac> gary_poster: i'm there
<benji> redirect loop between docs.google.com and accounts.google.com; whee!
<bac> i think
<gary_poster> oh, huh
<rick_h_> jcsackett: email back with notes. I can't replicate the currentTarget not working correctly
<gary_poster> "lunch": biab
<bcsaller> hatch: I'm back when you're ready
<hatch> alright one minute
<hatch> just grabbing something to drink
<bcsaller> no rush
<hatch> alrighty all ready
<hatch> just finished the Ghost in The Wires book that I was reading in oakland
<hatch> what a great book
<hatch> I have 40 books in my amazon wishlist and about 5 unread on my bookshelf - I'm not sure why I even bother lol
<bcsaller> hatch: in the chat room now
<bcsaller> gary_poster: are you free to join chat?
<sinzui> orangesquad: I might disappear. I am experiencing a heavy down pour and the water is now over the door sill.
<abentley> sinzui: Sorry to hear.
<sinzui> I have two weeks left in this house. \o/ this could be my last flood
<gary_poster> bcsaller, guichat?
<hatch> bac: did you have something to chat about?
<benji> a WYSIWYG editor isn't worth its salt unless it has orphan control
<hatch> what's orphan control?
<benji> it is a way to say "this chunk of text should not be separated by a page break from this other bit of text"; for example, a header should always be on the same page as the first paragraph of the section it heads 
<benji> gary_poster: It needs more work, but the vitals doc is in a good shape for you to take a look at it
<hatch> oh...I don't even think Word does that
<jcsackett> jujugui: if anyone's free, can i get one more review on https://codereview.appspot.com/9965044/
<benji> yep, in (the last version of Word I used in anger, about a decade ago) you could select a chunk of text and choose the "keep together" option
<benji> jcsackett: sorry, I need to run
 * benji runs.
<hatch> jcsackett: sure
<gary_poster> benji awesome thank you looking
<hatch> TIL my NAS doesn't turn back on when the power goes out
 * hatch just spent 15 minutes trying to debug the connection
<hatch> lol
 * hatch fail
<hatch> how many people here use lastpass?
 * gary_poster raises hand
<hatch> any issues you have found?
<gary_poster> benji added comments, thank you!
<gary_poster> hatch, mm, I wish it could accept both yubikey and google authenticator simultaneously
<gary_poster> hatch, otherwise +1
<hatch> man lastpass for android is bloody ugly
<jcsackett> hatch: i use it; i don't *love* the mobile app, but it works, and the service is good.
<hatch> I set it up on a site and now it auto logs me in
 * hatch is a little creeped out
<hatch> lol
<hatch> does the lastpass log in fail the first time intentional?
<gary_poster> hey huwshimi 
<huwshimi> gary_poster: Hello!
<hatch> gary_poster: I'm assuming green highlights are us?
<gary_poster> :-)
<gary_poster> hatch, no, we are everything that is not orange squad or Ecosystems
<hatch> alrighty
<gary_poster> hatch, so inspector, (bundles, containerization,) gray masthead, analytics
<hatch> gotcha
<hatch> OSCON sounds like something from Spiderman
<hatch> OSCORP
<gary_poster> huwshimi, I don't know if you are able to work on the gray masthead today, but I just noticed a few minutes ago that there appears to be two similar, related bugs: https://bugs.launchpad.net/bugs/1172735 and https://bugs.launchpad.net/bugs/1185006
<_mup_> Bug #1172735: Implement grey masthead with logout, alerts and get juju <blocker> <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1172735>
<hatch> cool I wish I knew about this sooner this conf looks packed
<gary_poster> the branch would assume that the right-hand search panel could just disappear in a cheap hack for now
<huwshimi> gary_poster: The masthead icons refer to Charm Browser masthead (and I've implemented them in a branch that I've been working on).
<gary_poster> huwshimi, ah!
<huwshimi> gary_poster: For the main masthead is the plan to implement that under the browser_enabled flag?
<huwshimi> gary_poster: If so, any hints on how to use that flag in index.html which is not a handlebars template?
<gary_poster> huwshimi, the plan is that, once #1175019 and #1186299 are fixed, we make the charm panel the default and rip out the flag
<_mup_> Bug #1175019: staging has issue with black bar at top of fullscreen charm details <charmbrowser> <juju-gui:Triaged by huwshimi> <https://launchpad.net/bugs/1175019>
<_mup_> Bug #1186299: The charm browser quality tab does not have data <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1186299>
<gary_poster> huwshimi, and the hope is that this will be extremely soon
<gary_poster> so you could simply change the main masthead directly in your branch huwshimi
<gary_poster> and if we somehow have issues with those two bugs
<gary_poster> then we will implement the flags our selves somehow (/me waves hands and hopes it doesn't happen)
<gary_poster> while you atre on vacation
<gary_poster> wdyt, huwshimi?  sound ok?
<gary_poster> huwshimi, also could you please subscribe to juju-gui-peeps, on bottom left of https://launchpad.net/~juju-gui-peeps
<huwshimi> gary_poster: That sounds ok, but there are three parts to replacing the header. 1. Style the header 2. Replace the Alerts Bootstrap dropdown with a YUI widget and 3. Remove the Charms search and panel button
<huwshimi> gary_poster: So I'm not sure if that can all really be done without breakage in one branch
<gary_poster> huwshimi, do we really need to to #2 right now?
<gary_poster> agreed we need 1 & 3 now
<gary_poster> huwshimi, but if you deliver incremental branches that is AOK.  Are you saying you'd like others to deliver 2 and/or 3?
<gary_poster> huwshimi, I am assuming you are subscribed to https://lists.ubuntu.com/mailman/listinfo/juju-gui , but if not please do
<huwshimi> gary_poster: I'm not sure if we can really do #1 without #2 without a lot of fighting with Bootstrap and having to use all their specific HTML. It something that we can do, it just makes things a lot uglier.
<gary_poster> huwshimi, oh I see :-/
<gary_poster> huwshimi, ok, so the order needs to be #2, #3, # 1?
<hatch> I was waiting until Friday but huwshimi we could look into http://purecss.io/
 * gary_poster steps away
<hatch> not sure if it helps much
<hatch> but it's yui's answer to bootstrap
<huwshimi> gary_poster: The cleanest scenario for me would be #2 and #3 (in any order) and then I can come along and do #1.
<hatch> huwshimi: did you have a module in mind for the alerts dropdown?
<huwshimi> hatch: I imagine it would just be an Overlay
<hatch> gary_poster: did we already know that uistage is broken?
<hatch> huwshimi: I wonder if we could do it all with css with a styled radio button
<hatch> OR
<hatch> we it could be as simple as a class toggle on the list
<hatch> and have the result list and button in a wrapper
<hatch> so they align
<huwshimi> hatch: I'm not sure what we really get with doing some kind of CSS implementation. We'd still need to build a YUI widget to handle building the menu items etc. and we may as well use something that is built in rather than making something ourself, right?
<hatch> yeah.............
<hatch> overlay just feels so heavy for such a simple thing
<hatch> blah it's past EOD and I'm just talkin garbage, feel free to ignore me :)
<huwshimi> hatch: Well, it's exactly and overlay :)
<huwshimi> *an
<hatch> well it IS but at its purest form it's really just a list of errors
<hatch> so as long as it can be turned on/off and aligned to the button that's all that's really necessary
<huwshimi> hatch: But that's pretty much exactly what an Overlay is designed for, it's just that someone's already made it for us :)
<hatch> well in reality an overlay is so much more code
<hatch> it's certainly a lot less work to use one though
<hatch> :)
<hatch> my hacking project tonight will be to try and make what I'm blabbing about
#juju-gui 2013-06-04
<hatch> huwshimi: ok done
<hatch> ;)
<gary_poster> hatch uistage isn't broken.  zoom out.  silly kids
<hatch> huwshimi: http://jsbin.com/itaqem/2/edit click the box :)
<hatch> gary_poster: lol Uncaught TypeError: Cannot read property 'browser_enabled' of undefined  is what I see
<gary_poster> hatch, wfm.  hard reload?
<huwshimi> hatch: Nice! Now you just need to make it close when you click outside of it, make it work with the keyboard and build a YUI widget to handle the creation etc ;)
<gary_poster> http://uistage.jujucharms.com:8080/ and http://uistage.jujucharms.com:8080/:flags:/browser_enabled/
<hatch> huwshimi: umm....yeah...about that.... :P
<huwshimi> hehe
<hatch> gary_poster: ohh here is what happened Application Cache Error event: Failed to parse manifest http://uistage.jujucharms.com:8080/juju-ui/assets/manifest.appcache
<hatch> we didn't properly set it to clear the appcache before we updated it
<hatch> so the index.html is still cached on my system
<gary_poster> hatch, ah.  so yeah, clear with chrome://appcache-internals/ and prob fine
<hatch> this brings up something curious to me....what is the proper way to remove appcache on a live site
<hatch> hmm
<hatch> ok gota run, will be back later to try and make 'click outside' to work with css :P
<hatch> ^ was a joke :)
<gary_poster> :-)
<huwshimi> :)
<gary_poster> hey bac, do the recent jenkins failures look like they have anything to do with images?
<gary_poster> doesn't look like it to me :-/
<bac> looking
<gary_poster> looks like random stupidity and a reminder that we should switch to a more production-centric system
<bac> gary_poster: yeah, it looks like a bunch of hooha to me.  CI should not require so much finger crossing and chicken sacrificing.
<gary_poster> yeah :-(
<bac> jujugui: so yesterday afternoon my ISP dudes couldn't find parking so they just left.  now they are circling the block again.  connectivity may (or may not) be flaky soon.
<gary_poster> I guess the only things stopping us moving to ec2 are (1) corporate account, or me taking one for the team; and (2) opening up the firewall from the test center to ec2.
<gary_poster> The first one is the one that slows me down the most. :-/
<bac> gary_poster: heck, i'll volunteer my AMEX.  think of the points!
<bac> no, really
<gary_poster> :-)
<gary_poster> but then anyone who can log into the machine can get your ec2 creds
<benji> bac: that's hilarious
<bac> oh
<bac> so, carlos is here to replace my radio.
<hazmat> bac, wow.. thats silly.
<bac> er?
<hazmat> bac, isp dudes leaving, cause they can't find parking..
<bac> oh, yeah, well...
<hazmat> afternoon cerveza sounds more apt
<bac> i would've gladly given them a cerveza
<benji> gary_poster: I'm in guichat
<gary_poster> benji, darn, ok
<gary_poster> coming
 * bac o/
<hatch> morning
<hatch> looks like canonistack errors on jenkins
<bac> hi abentley, do you have a moment to answer some bzr lightweight checkout setup questions?
<abentley> bac: Sure.
<jcsackett> orangesquad: should we move the green categories card into the coding lane? I think it is now bound on rick's card as the last thing that needs to land for it to be done, yeah?
<jcsackett> or does it just sit and go to done when we're done with other cards?
<rick_h_> jcsackett: seems strange to have a green card in coding without a face/etc on it
<jcsackett> rick_h_: don't disagree, but having it in "Next" when all activity on it is going seems weird too.
<jcsackett> rick_h_: : in the case of a review with lbox -req (i.e. a prereq branch) does lbox submit properly merge the branch, or does it just apply the patch set?
<rick_h_> jcsackett: oh hmm, I think since it's a req the other one needs to land first? It just builds the right diff/MP
<rick_h_> jcsackett: I don't think you can submit both in one swoop. 
<rick_h_> jcsackett: but I could be wrong, not tried it tbh
<jcsackett> rick_h_: yeah, i don't really think now's the time to experiment, since it'll break the build if it doesn't work. :-P
<gary_poster> benji, gustavo suggested that we use full ip address, not merely port.  Could you take a look at the only non-resolved comment on https://docs.google.com/a/canonical.com/document/d/14W14YAPYdivL9nF7Wvrb6kHX0xrsxV0fAEMfXNt7L3Q/edit# and see if you can see where to incorporate the idea, or the question (since I don't really understand where he is coming from) in the new doc?
<benji> gary_poster: I can't claim to understand the comment containing the explanation.
<gary_poster> benji, you and me both then.  Maybe add a comment in the new doc highlighting the fact that we still need to resolve this with Gustavo?
<sinzui> orangesquad. I was/am leaving the feature cards in the next lane because they remind us that the task/defect/improvement cards should relate to the features. I move the features to acceptance when I think we have delivered all the work. This is a bit risky since acceptance can find issues that will go into the next lane
<teknico1> bac: y u no put python-charmhelpers in juju-gui-charmers ppa? charm deploy sad
<sinzui> I don't think the story1 and story2 makes sense if we continue to let the feature cards define the theme of work
<teknico1> BradCrittenden: ^^
<hatch> gary_poster: so I'm reading through this doc from luca__ and I'm wondering how I give feedback, is there some way to comment on these points?
<luca__> hatch: which parts do you want to comment on?
<BradCrittenden> teknico1: sorry, the charm-tools in stable is from juju/pkgs and does not include the python-charmhelpers.  i am currently copying it from juju-gui-charmers/devel
<hatch> luca__: so far Route A and Route B - I feel that we should have some kind of 'setting up' indicator to indicate that it's being set up instead of just hanging around as a ghost for 15 minutes
<luca__> hatch: you can add that to the comments section at the bottom of the post
<luca__> hatch: if you click into it
<hatch> ahh ok
 * hatch votes to use google docs next time :P
<bac> teknico1: unfortunately it'll take at least an hour
<hatch> luca__: also """Is there ever a case where you just want to add charms without reading the details?""" yes I do with npm all the time
<luca__> hatch: https://sites.google.com/a/canonical.com/juju-meeting-notes/scenarios-1/buildinganenvironment
<teknico1> bac: the charm tries to install the "python-charmhelpers" package, it's not going to be happy if it does not find it in the ppa
<luca__> hatch: great :)
<teknico1> bac: or am I missing something?
<hatch> luca__: :) I coudln't comment on that section so I'll leave that to you
<bac> teknico1: i understand.  that's why i just told you my actions to rectify the problem.
<luca__> hatch: I've just changed the user needs to a separate post so it can be commented on
<hatch> oh ok awesome
<hatch> I've never heard of sites.google.com before
<teknico1> bac: then it's me the one who's not understanding :-) what do you mean by "the charm-tools [...] does not include the python-charmhelpers"?
<bac> teknico1: by "i am currently copying it" i mean on launchpad i have requested the package be copied from the devel PPA to the stable PPA
<teknico1> bac: but I don't see it in the devel PPA either...
<teknico1> that is, here: https://launchpad.net/~juju-gui-charmers/+archive/devel
<bac> teknico1: it's weird.  you have to click on 'details' and then look at charm tools.  it'll show you the packages withing that, uh, package
<bac> the charm-tools source package builds three different installation packages.  python-charmhelpers is one of them
<bac> last week the build recipe was changed to *not* build python-charmhelpers for ppa:juju/pkgs
<teknico1> bac: oh my gosh, I see it now, thank you. way to go hiding stuff :-)
<bac> teknico1: that was quite a mystery to unravel last week
<bac> teknico1: anyway, i screwed up i getting the charm-tools from the wrong spot for stable
<teknico1> bac: I wonder why that happened... (not building python-charmhelpers)
<bac> teknico1: marco changed his debian/control file to explicitly delete it.  unsure why.
<bac> teknico1: if you need to deploy a charm right now  you can set repository-location=ppa:juju-gui-charmers/devel
<bac> otherwise the copy from one ppa to stable will complete in an hour or so
<teknico1> bac: ok, thanks, at least I know what the problem is :-)
 * bac regrets having lost his PPA administration super powers
 * bac wonders if that is the cause of jenkins failures
<teknico1> it would seem likely
<teknico1> (bac: did you ask around? someone may have found them ;-) )
<gary_poster> bac, maybe follow up with marco about python-charmhelpers?  does this mean that he broke gui deployments?
<bac> gary_poster: i talked to him last week but decided to use my own build recipe for our devel and stable ppa.  while his recipe is no longer building p-ch it was not deleted from the juju/pkgs repo, though it is not visible via the UI.
<gary_poster> ok thanks bac
<gary_poster> bac, maybe clarify with him that deleting it Would Be Bad?  Or is it not possible to delete?
<bac> i erred by testing against our new devel ppa and not stable
<gary_poster> If it is possible to delete, maybe that would be an answer to our "what do you do if you have a package in devel that doesn't work out" question from yesterday?
<bac> gary_poster: it is not possible to delete unless he were to delete the entire charm-tools source package from that ppa, which he has no reason to do
<gary_poster> ok
<gary_poster> thanks
<bac> gary_poster: what is the risk you see now that our charm does not rely on juju/pkgs anymore?
<gary_poster> bac, old charms only.  but until you push the new charm with dependencies on the new ppa to ~juju-gui-charmers (did you do that?), the main charm is the old charm
<bac> gary_poster: that was done:  https://code.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk
<gary_poster> cool bac, thanks.
<gary_poster> bac, then I guess I'm not too worried.  Paranoid, but not worried. :-P
<bac> but i think it was premature and not following our guidelines
<gary_poster> because it was released prior to full testing?
<bac> it should gone to the old spot but due to my broken setup i pushed to lp:charms/juju-gui.  (so my new blog post is wrong)
<gary_poster> ah ok
<bac> yes, the official charm is currently broken until the PPA publishing for stable is complete
<gary_poster> :-/ k
<bac> soory
<gary_poster> you're on it
<gary_poster> you are fixing it
<gary_poster> I suppose we should have another "what can we do so this doesn't happen again" conversation, in which we all say "use tarmac"
<teknico1> bac: while you're at it, please also fix my head and my wall ;-)
<gary_poster> want to ask matsubara where we are on that but have not seen him
<gary_poster> hey luca__ , could you copy over the things you want us to comment on to google doc instead?
<gary_poster> I'd like to use the google doc line by line thing
<luca__> gary_poster: sure, I'll do that once I get out of this meeting
<gary_poster> thank you!
<bac> jujugui: to avoid the charm problem i just had, everyone should verify lbox is merging to lp:~juju-gui/charms/precise/juju-gui/trunk not lp:charms/juju-gui
<gary_poster> bac, I suggest we make a .lbox file in charm , like the one in gui
<gary_poster> instead of 
<bac> this blog post has bzr setup instructions if using lightweight checkouts: http://jujugui.wordpress.com/2013/06/04/bazaar-lightweight-checkouts-and-charm-development/
<gary_poster> propose -cr -for lp:juju-gui
<gary_poster> we would simply have
<gary_poster> propose -cr -for lp:~juju-gui/charms/precise/juju-gui/trun
<gary_poster> k
<gary_poster> and then anyone checking out the branch would have the proper lbox behavior immediately
<gary_poster> AIUI at least
<bac> gary_poster: ok, i'll add that now.  w
<gary_poster> thanks bac
<alejandraobregon> gary_poster: luca and i just had the meeting with charline
<gary_poster> alejandraobregon, cool!
<gary_poster> call?
<alejandraobregon> wrote up comments and suggestions beneath your current questions
<alejandraobregon> https://docs.google.com/a/canonical.com/document/d/1bSR1nfSsZs4XQoTv1IZu-so5FM-_R4JsvRsW3IAZyag/edit
<hatch> bcsaller: are you in yet?
<gary_poster> looking
<luca__> hatch: I've added google docs to the posts
<luca__> gary_poster: ^
<hatch> :) You didn't have to
<hatch> but thanks!
<hatch> :)
<hatch> I'll move my comments there
<bcsaller> hatch: I am now
<hatch> I am writing the viewlet too if that's alright - I can't really do much without it
<gary_poster> alejandraobregon, really fantastic, big thanks to you, Luca, and Charline.  I'll make a few small revisions, and then send it to the lawyer.
 * gary_poster needs to step away
<gary_poster> back in a few
<bcsaller> hatch: sounds good
<alejandraobregon> gary_poster: no wories
<alejandraobregon> worries
<hatch> bcsaller: https://gist.github.com/hatched/2463d15dd51d12e04258 got a sec for a guichat?
<hatch> gist updated
<gary_poster> congrats on landing core branch, frankban :-)
<bcsaller> hatch: I can hop in chat now
<frankban> gary_poster: \o/
<gary_poster> :-)
<hatch> bcsaller: ok there
<rick_h_> luca__: ping, any chance we can get these category icons in 160x160 for the full charm details icon view please? https://drive.google.com/a/canonical.com/#folders/0B1IM--9A1RkTMndkVG8zeHFlVmM
<luca__> rick_h_: I have no idea, let me ask the guy who made them :P
<rick_h_> luca__: thanks, appreciate it
<rick_h_> luca__: I had three sizes and ran with it and now see that we changed the sizes so I've got 2/3 I need to complete the category work
<luca__> rick_h_: He's going to make the new sizes, hopefully won't take too long. I'll add them to the drive and email you when you they are up.
<rick_h_> luca__: appreciate it
<gary_poster> jujugui kanban now call in 4
<gary_poster> jujugui call in 1
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-api-0/+merge/167324 ?
 * sinzui does
<luca__> rick_h_: I've just uploaded the 160x160px icons to that folder: https://drive.google.com/a/canonical.com/#folders/0B1IM--9A1RkTMndkVG8zeHFlVmM
<sinzui> abentley, is test_reindexed_no_client_charms testing that an error is not raised? There is no asserts.
<abentley> sinzui: Yes.
<abentley> sinzui: Should I add asserts or a comment?
<sinzui> A comment would be helpful
<abentley> sinzui: I've added a similar comment to test_create_replacement_misssing
<sinzui> thank you abentley. r=me.
<abentley> sinzui: Thanks.
<hatch> bcsaller: reasonable to assume that we could have something like https://gist.github.com/hatched/3876ff1fc8ca1bff5bb0 for the view-container?
<julianwa> jcastro: ping
<jcastro> julianwa: pong!
<julianwa> jcastro: hi, I had a problem to login juju-gui
<julianwa> jcastro: juju gui is deployed by charms in charm store, for python juju stable version
 * gary_poster listens
<julianwa> but failed to login with admin-secret key
<julianwa> 2013-06-04 11:56:22,399: juju.rapi.ws@INFO: Invoking method <bound method APIContext.login of <juju.rapi.context.APIContext object at 0x22940d0>> with {u'password': u'FDU2K9N7bsJZkfh6s6:829z85ytjayxqYKLPU:Tvmtbwcku9FsSyjuVWzPxmAEBUaBjA9E', u'user': u'admin'}
<julianwa> 2013-06-04 11:56:24,092: juju.rapi.ws@INFO: Returning results {'failure': 'Traceback (most recent call last):\nFailure: zookeeper.NoAuthException: not authenticated\n', 'request_id': 1, u'user': u'admin', 'err': True, 'op': u'login', u'password': u'FDU2K9N7bsJZkfh6s6:829z85ytjayxqYKLPU:Tvmtbwcku9FsSyjuVWzPxmAEBUaBjA9E', 'log': [('error', 'Invalid credentials')]}
<bcsaller> hatch: wouldn't it be a loop around viewlets where you put the container class use for switching around them automatically?
<julianwa> jcastro  gary_poster, any ideas?
<gary_poster> julianwa, do you have multiple environments in your ~/.juju/environments.yaml file?  We haven't encountered any problems like that ourselves, so my first guess woudl be that you used the wrong password for the active environment
<gary_poster> back in a sec
<julianwa> gary_poster: thanks, I will check :)
<BradCrittenden> jujugui: would like one review of the code backport just for sanity check: https://codereview.appspot.com/9975046/
<hatch> bcsaller: updated gist https://gist.github.com/hatched/3876ff1fc8ca1bff5bb0
<hatch> the specifics we can work out after design - but the concept should be similar
<bac> jujugui: python-charmhelpers is now properly in stable PPA: https://launchpad.net/~juju-gui-charmers/+archive/stable/+build/4641114
<gary_poster> thank you bac
<teknico1> bac: thank you
<bac> gary_poster, teknico1: can either of you do the quick review i requested?  i'd like to get this landed to finish cleaning up the mess.
<gary_poster> I will if teknico1 can't.  Otherwise trying to finish something up.  teknico1, are you already at EoD?
<teknico1> gary_poster: I'll squeeze it in, it seems simple enough
<gary_poster> thanks teknico1 
<teknico1> bac: it looks exactly the same as yesterday's branch, isn't it?
<bac> :)
<bac> i did say sanity check
<bac> that's the nature of a backport
<teknico1> bac: done
<bac> thanks
<rick_h_> jcsackett: sinzui can I get some review <3 please? https://codereview.appspot.com/9975047 note that it's blocked on kanban until we get the 160px category images but that doesn't effect the code at all. 
<rick_h_> hatch: ^^ as well if you have a chance
<hatch> alright
<rick_h_> hatch: ignore all the svg files :P
<rick_h_> #DiffsAreSmallerThanTheyAppearInMirror
<hatch> lol
<Makyo> gary_poster, bcsaller - would like to start "zoom to a service if any on first delta".  It sounds reasonable, but I'm game for a pre-imp call if either of you want.
<gary_poster> Makyo, don't need one from me :-)
<bcsaller> Makyo: not unless you want one
<gary_poster> bac, you done with your critical card in Maintenance?
<Makyo> gary_poster, bcsaller - Alright.  Will start for now.
<rick_h_> sinzui: ping, got a sec?
<hatch> rick_h_: review done
<rick_h_> hatch: cool, I'm changing it up right now :)
<bac> gary_poster: moved
<rick_h_> hatch: chat?
<gary_poster> thanks bac
<hatch> sure
<sinzui> rick_h_, I do. Sorry for the delay. I had a late lunch to argue with my ISP
<rick_h_> sinzui: invite inbound
<hatch> I am having an issue generating a new template file
<hatch> no matter what I do it doesnt' add the new .handlebars file into the rollup
<hatch> I tried make clean and then make again
<hatch> but no luck
<rick_h_> hatch: so when you run that make command I give you do you get any error output?
<rick_h_> hatch: if there's a syntax error in the template you'll get a one line in the make comment output that tells you 'something went wrong' and is partially helpful
<hatch> i just rm'd the whole dir's and then remade
<rick_h_> lol
<rick_h_> well, copy the output next time you  make build-shared/juju-ui/templates.js 
<rick_h_> I'll bet you have a mismatched tag or missing # or something
 * rick_h_ did that more than a few times the last couple of days
<hatch> rick_h_: yup it was a syntax error
<hatch> :/
<hatch> argz
<rick_h_> hatch: party on
<benji> ok, gary_poster, I'm out of time (plus some).  Do you want to review the draft together or just make changes and annonce?
<gary_poster> benji, I need to actually run and do something else.  Let's have lunch and then reconvene?  I'm not too worried about it since I kind of announced it already via the calendar announcement.
<gary_poster> does that sound ok to you?
<benji> k
<gary_poster> cool, thank you
<jcsackett> rick_h_: looking now.
<jcsackett> rick_h_: nm, just saw curtis's comments hit.
<rick_h_> jcsackett: yea thanks
<hatch> going to grab some lunch
<abentley> sinzui: It turns out my migration was bogus (it only updated a single document, and my tests only tested a single document).  Should I do a new migration or bugfix the existing one?
<sinzui> abentley, I think a new one.
<sinzui> abentley, Wouldn't a bug fix be more risky for a production deployment?
<abentley> sinzui: We'd have to manually futz with staging to force migration 5 to run again.
<sinzui> well, that is what I hoped a new migration would avoid.
<sinzui> abentley, how is a bug fix different?
<abentley> sinzui: I was describing a bugfix.  A bug fix would update migration 5.  If we introduce migration 6, we still have to have migration 5, though I can change it to a no-op.
<sinzui> I like a new migration. making migration 5 a no-op is fine since we reserve the right to choose which migrations are no longer supported
<abentley> sinzui: https://code.launchpad.net/~abentley/charmworld/really-remove-icon/+merge/167364
 * sinzui looks
<sinzui> ah, like the RE g option when doing substitutions. r=me abentley
<abentley> sinzui: Thanks.
<abentley> sinzui: I would like it if we could remove migrations that are no longer supported, but the current code requires an unbroken numerical sequence.
<sinzui> abentley, I think we can live with dummies that just document the historical intent.
<rick_h__> jcsackett: ping, did you want the background on the bar issue stuff at all or are you ok?
<hatch> bcsaller: around?
<bcsaller> hatch: yes
<hatch> have a moment for a screenshare?
<abentley> sinzui: tarmac appears to have gone on strike, and I can't find matsubara.
<sinzui> abentley, I see
<sinzui> abentley, the only option I can think of at this time is to test and merge ourselves, then call upgrade charm
<abentley> sinzui: I'm not rushed with this one.
 * benji_ cleans hundreds of messages about PyPI projects out of his inbox.
 * benji_ wonders when he grew a tail.
 * benji feels much better now.
<hatch> new yui bugfix release http://www.yuiblog.com/blog/2013/06/04/yui-3-10-2-released
<hatch> we should look into upgrading to 3.10 at some point :)
<hatch> jcastro: Great idea on the app infrastructure :)
<bac> gary_poster: i've learned more about google analytics and it doesn't look like it is going to work for us.  they expect a single tracking code to be tied to a specific web site, which is not our use case.
<gary_poster> bac, oh :-(
<bac> we want to track the use of an app that'll appear in lots of places
<gary_poster> y
<bac> gary_poster: for instance, they won't even begin gathering data until their robot finds the tracking code at the specficied url ... which cannot include a custom port, btw
<bac> so i cannot even test it on uistage
<gary_poster> bac, any other options you found for our use case?
<bac> not yet
<bac> crazy egg has the same setup
<gary_poster> ok :-/
<gary_poster> I see for-fee ones that would seem to work
<gary_poster> or maybe we have to set up our own app for this?  in which case this is a stretch goal
<gary_poster> that would be a shame
<gary_poster> bah, benji, neither of us pinged the other and I've been doing other things.  looking at your doc
<benji> k
<hatch> gary_poster: you use sublime text 3 right? Are there any reasons to upgrade?
<gary_poster> hatch, no, for me currently only anti-reasons.  hopefully better later
<hatch> alrighty :)
<hatch> I use this as my icon http://1024jp.deviantart.com/art/Sublime-Text-Icon-373837347
<hatch> thought you might like
<gary_poster> :-) cool 
<bac> gary_poster: it *may* be possible to use ga if we get it bootstrapped with a fixed location
<gary_poster> bac, how would that work?
<bac> gary_poster: it looks like a code that their robots have verified at a fixed location can be used from other sites if you turn off the url filtering
<gary_poster> oh
<gary_poster> well, we have jujucharms.com..
<bac> yeah, that's true.  we also have uistage.jujucharms.com if we were on port 80
<gary_poster> we have that bac
<gary_poster> http://uistage.jujucharms.com/
<bac> oh, we do don't we?
<bac> i've been going to 8080 out of habit and bookmarks then
<gary_poster> me too
<bac> benji: nm
<benji> I'm about to introduce a Y3K bug into the GUI.  I've made a note to myself to fix it in 2999.
<hatch> you better!
<gary_poster> benji, +1 on vitals proposal
<gary_poster> made some changes
<benji> cool
<gary_poster> benji, please review my last two comments/changes?
 * benji looks
<gary_poster> BradCrittenden, are you optimistic or pessimistic about GA working out for us at this point?
<alejandraobregon> gary_poster: hey
<hatch> typeof null === "object" just bit me ....ouch it stings
<gary_poster> alejandraobregon, hey
<hatch> TDD works pretty damn well once you get the hang of it
<hatch> has anyone ever had any issues with setStyle on elements in mocha?
<hatch> for some reason it's throwing on a setStyle claming the method doesn't exist when it clearly does (from stepping through and manually calling it)
<hatch> hmm it thinks nothing exists...
<hatch> blah
<hatch> figured it out - it was reporting the wrong line :/
<bcsaller> using a source map and pretty print at the same time does break the line numbers
<hatch> now to figure out why THIS line doesn't work
<hatch> heh
<hatch> well I'm baffled
<hatch> well I really wish I could solve this so I could commit this code and be done
<bcsaller> I know the feeling
<hatch> well I'm not getting anywhere it's pushed up lp
<hatch> have a good night
#juju-gui 2013-06-05
<gary_poster> hey bac.  thank you for looking into the GA stuff.  As soon as you know if it will work for us, please let me know: the information (whatever the answer is) will unblock another task.
<bac> gary_poster: yesterday afternoon i inserted the tracking code on uistage and could see it being served but no data was being collected.  chrome plugins showed that it was installed correctly.  that's all i knew at EOD yesterday
<rick_h__> luca__: thanks, I see the images in the folder and submitting the category changes now. 
<bac> gary_poster: i now see that we are collecting data.
<bac> 28 unique visitors for 31 visits
<luca__> rick_h__: excellent, many thanks Rick
<gary_poster> bac but that is for uistage only, right?  We now need to discover whether it will still work when deployed elsewhere?
<bac> gary_poster: my next step is to deploy the charm with the same tracking code and see if data are collected from those deployments.  from further research i'm pretty confident the data will be seen.
<bac> gary_poster: ack
<gary_poster> yay, bac!
<gary_poster> so...well, quick guichat call?
<bac> gary_poster: i'm not sure yet what the time delay is for reporting.
<gary_poster> ack
<gary_poster> bac, could I run something past you on guichat?
<bac> sadly their dashboard still shows the tracking slug is not deployed, which is misleading
<bac> gary_poster: sue
<bac> sure
<bac> don't sue
<gary_poster> sally
<luca__> gary_poster: sorry to pester, I should of asked in IRC but would it be possible for you to answer my latest bundles question I sent in email? Really sorry!
<gary_poster> luca__, yes reply started, will get out in a few
<luca__> gary_poster: thank you!
<gary_poster> luca__, could you give bac information on what the privacy policy banner thing needs to be?  If you have standard HTML/CSS that would be even better
<gary_poster> and JS
<luca__> gary_poster: the cookie thing?
<gary_poster> luca__, yeah
<luca__> bac: just asking the web guys what they have
<bac> luca__: thanks
<bac> "Error with ubuntu-doodoo" ... from uistage
<hatch> morning
<gary_poster> morning
<luca__> gary_poster: in regards to the feedback stuff, I'll have to complete this early next week as I'm flying out to Norway in a few hours
<gary_poster> luca__, ok cool, thanks for the heads up
<gary_poster> enjoy :-)
<hatch> jealous
<BradCrittenden> gary_poster: good news.  i was able to modify the tracking slug and am seeing reports from me hitting a locally running juju gui.  i deployed 'mysql-bac' and see it in the real-time reports.  the data available in real time is minimal (urls and location) so it'll be interesting to see what shows up later
<gary_poster> great, bac!  thank you for letting me know
<bac> but it looks promising
<gary_poster> excellent
<benji> I have a small branch up for review: https://codereview.appspot.com/9981044
 * gary_poster stepping out to son's school in about 8 minutes; back at about 20 or 25 past the next hour
<gary_poster> in time for vitals discussion :-)
<gary_poster> biab
<abentley> orangesquad: uistage.jujucharms.com is failing to load the browser.  It says "Failed to load editorial content.\nCharm API server did not respond"
<rick_h__> abentley: k, looking
<abentley> That was at http://uistage.jujucharms.com/:flags:/browser_enabled/
<rick_h__> abentley: http://uistage.jujucharms.com/:flags:/browser_enabled/ works for me
<abentley> rick_h__: Worked this time, failed three times before.
<rick_h__> abentley: :/ so we're wondering if this is a 504 on m.j.c issue?
<sinzui> abentley, I don't see any issue with uistaging or m.jc myself
<abentley> rick_h__: That seems plausible.
<sinzui> abentley, is it possible there was a 504 from m.jc that broke your uistaging app? Reloading doesn't help?
<abentley> sinzui: The first three times I loaded the page, I got a failure.  the fourth time, it worked.
<sinzui> oh, maybe we got a restart of elasticsearch from the rt I filed?
<abentley> sinzui: I think the simpler explanation is that we're still getting intermittent failures from m.j.c due to connection time-outs.
<sinzui> abentley, I'll talk to webops about what the timeouts are between the services in the stack
<sinzui> abentley, rick_h__ has evidence that interesting is not being caches and that there is a 3 second timeout between apache and elasticsearch
<rick_h__> abentley: yea, I was checking the cache headers and I got a 504 when the req time on the back end was just a hair over 3s
<rick_h__> abentley: and looking at the x-cache headers I'm not sold it's working right. 
<abentley> rick_h__: I see "Cache-control: max-age=0" in the headers, which would defeat caching.
<sinzui> oops
<rick_h__> abentley: looking, wonder if YUI auto adds that to the request. 
<rick_h__> hatch: ^ any inside knowledge there?
<abentley> rick_h__: That might be from me hitting reload.  I was doing it manually.
<sinzui> yep. I see that for every search I do
<hatch> reading the backlog
<rick_h__> abentley: sinzui ok, I'll file a bug and put it on the board to look at the requests going out and look at how to override that 
<abentley> rick_h__: Yeah, looks like that was my fault for hitting reload.
<sinzui> thanks rick.
<hatch> rick_h__: you wondering if yui auto adds cache-control to the request?
<rick_h__> hatch: rgr
<hatch> it doesn't
<hatch> you are free to set your own headers though
<rick_h__> hatch: ok yea, nvm. abentley thinks it was a reload force issue. 
<hatch> shouldn't that be allowed?
<hatch> this sounds like a mjc issue
<hatch> the user should be ble to reload and get a site within a second over and over and over
<rick_h__> hatch: so mjc is trying to cache things but if the client says "give me new stuff" it should skip the cache and never use it
<rick_h__> hatch: but by default, the stuff in interesting/search results/etc can't change but every 15min anyway
<rick_h__> hatch: so we're just looking at the caching and if it's in effect/helping/etc. 
<hatch> ahhh ok
<hatch> yeah that sounds like an issue on mjc side
<rick_h__> hatch: but nvm, I'm looking now and I don't see the header added. 
<rick_h__> hatch: well, it's on both ends. the gui has to make the requests with good headers and mjc has to respond approporaitely
<rick_h__> hatch: and by gui I mean the charmworld store class really
<hatch> well yes, but mjc should be smart enough to return the cached version if it's still valid regardless of what the client requests
<rick_h__> hatch: :P no, give the customer what they ask for 
<rick_h__> hatch: but anyway, we're all good. 
<abentley> rick_h__: One thing we probably should do is support ETags for charm/*/file/*  I see a lot of pointless icon retrievals.
<rick_h__> abentley: k, sounds like a good plan
<hatch> Makyo: which card did you just propose? so I can tag it
<Makyo> hatch, oh, sorry, just a sec.
<hatch> cool thx
<Makyo> hatch, zoom to service if any...
<hatch> Makyo: do you need a QA?
<Makyo> hatch, yeah, but give me a sec to revert config.
<hatch> hehe centroid
<hatch> sounds like a video game
<hatch> it's metroid's girlfriend
<rick_h__> hatch: can you link me to the assert node thing you showed me yesterday?
<Makyo> hatch, QA: add services, pan away from them, shift+0 to pan back.
<hatch> rick_h__: google node.js assert
<hatch> require('assert') it's part of the node core
<rick_h__> hatch: thanks, was doing javascript and failed
<hatch> and that's new?
<hatch> ooooo burn
<rick_h__> lol
 * hatch hands some aloe to rick_h__
<hatch> haha
<hatch> ^5
<frankban> gary_poster: do you have time for a quick hangout after the call?
<gary_poster> sure frankban 
<frankban> thanks
<gary_poster> jujugui call in 10; kanban now
<gary_poster> jujugui call in 2
<gary_poster> benji, call now
<rick_h__> sinzui: jcsackett can you guys look at https://codereview.appspot.com/10049044 when you get time please? sinzui in particular would appreciate wording and gramatic feedback :)
<hatch> Makyo: QA looks good
<Makyo> hatch, have a q on one of your comment,w ill ask after call
<hatch> deal
<hatch> jcsackett: I think you need a new machine :)
<jcsackett> hatch: google needs a new hangout app.
<rick_h__> says the man that needs a new machine because tests are too slow :P
<jcsackett> but! i get a new machine in 2 months. and it will have a webcam.
<hatch> lol noone else drops
<hatch> rick_h__: lol!
<jcsackett> hatch: bcsaller dropped at the start of this call.
<hatch> rumor has it the new MBP will be coming out next week so I should have a new one within a couple months
<hatch> me hopes
 * gary_poster has similar plans
<jcsackett> hatch: my problem is just that my laptop doesn't have a webcam, so i'm using the mobile hangouts app.
<jcsackett> oddly, it only really seems to have problems with y'all's standup. :-P
<benji> I so want the banner to say "This site uses cookies, but only to determine if you have dismissed this banner or not."
<gary_poster> lol
<hatch> benji hahaha
<Makyo> hatch, is your ATTRS comment with regards to this.get('component')?
<frankban> benji: where is your branch?
<hatch> Makyo: well we are 'getting' attributes but none are defined
<hatch> so someone coming in later will be like 'wth are these coming from' ?
<gary_poster> hey rick_h__ thank you for quality message change, awesome.  did luca direct/approve the presentation of that?
<benji> frankban: https://codereview.appspot.com/9981044/
<hatch> jcsackett: ahh yeah I found out the other day (when the power kept goign out) that the mobile app requires some serious mobile cpu power
<Makyo> hatch, just component.  The other attributes are on topology
<rick_h__> gary_poster: not really. It's a stab at "look at this, does this make people happy?"
<benji> hmm, I guess lp2kanban hasn't updated it; that's odd
<Makyo> hatch, component is set by the topology framework.
<rick_h__> gary_poster: e.g. it's not any worse and might just work so check it out.
<hatch> Makyo: hmm I thought the ATTRS was empty
<jcsackett> hatch: yeah. i plug it in for the standups, but that hasn't really helped.
<Makyo> hatch, app/views/topology/topology.js
<gary_poster> rick_h__, lol ok, cool.  unfortunately luca is out rest of week.  maybe ask alejandra for a once over in his absence?  she will be back tomorrow
<rick_h__> gary_poster: rgr, can do
<gary_poster> ty
<hatch> Makyo: oh right these things are used as extensions not individual modules
<Makyo> hatch, I mean, sure, I can add component to all the files and document it as being set by the d3ns.Module stuff?
<Makyo> hatch, but that's the only attribute.  Everything else is on topo, not this.
<Makyo> all the files ATTRS, that is.
<hatch> yeah - maybe just add component to the ATTRS
<Makyo> hatch, alright.
<benji> The power is flickering here.  I may drop off.
<hatch> heh ours never flickers, it just goes down without warning
<bcsaller> hatch: in chat again, branch pushed
<hatch> kewl
<frankban> gary_poster: call?
<gary_poster> sorry frankban 
<gary_poster> yes
<frankban> gary_poster: https://plus.google.com/hangouts/_/02bb45411739e441fe107c9f66e2a8cc36ba4ba7?authuser=0&hl=en
<rick_h__> abentley: have sec?
<abentley> rick_h__: sure.
<jcsackett> rick_h__, hatch: can you take a look at https://codereview.appspot.com/9964044/
<rick_h__> jcsackett: will do
<abentley> rick_h__: I tried a hyphenated category and it worked fine: http://staging.jujucharms.com/api/1/charms?categories=cache-proxy
<jcsackett> abentley, rick_h__: staging looks like it handles it, manage doesn't.
<rick_h__> abentley: hmm, so something is up wih that request then. http://staging.jujucharms.com/api/1/charms?categories=app-servers&series=precise&text=&type=approved is returning results not too
<rick_h__> jcsackett: ah!
<abentley> rick_h__: It's possible that the ES mappings didn't get updated properly on manage.  I guess we'll need some help from the ops of the web.  I'm going on lunch.
<rick_h__> abentley: ok, updating the bug to note the diff in staging/manage
 * gary_poster has lunch
<sinzui> orangesquad, gary_poster. Our tarmac is down. So is red's It appears all landing bots cannot ssh to launchpad. I will be in #is to learn how this will be resolved
<rick_h__> thanks sinzui 
<jcsackett> hatch: can i get a review on https://codereview.appspot.com/9964044/ ?
<hatch> yup doing now
<hatch> done
<jcsackett> hatch: awesome, thanks! :-)
<rick_h__> hatch: why have you not tried http://facebook.github.io/react/blog/2013/06/05/why-react.html yet :P 
<rick_h__> "React really shines when your data changes over time."
<gary_poster> thanks sinzui 
<hatch> rick_h__: haven't but I'll look into it
<hatch> I have so many libs/frameworks to review
<hatch> I need to take a month off to get caught up on everything
<hatch> hah
 * gary_poster restarts
 * jcsackett assumes rick was trolling with the react thing
<hatch> probably was but I always try to keep my finger on the pulse
<hatch> the pulse just moves damn fast
<hatch> haha
<hatch> oh jeeze they are confusing their lib with JSX
<rick_h__> hatch: yea, just a little bit. it's a new thing FB released in the last couple of weeks
<rick_h__> jcsackett: ^^
<hatch> it also re-renders the whole 'nontemplate' when data changes
<rick_h__> I had to laugh when I grabbed the quote out
<rick_h__> right, but it's got 'smarts' :P
<hatch> maybe, but on face value it misses the mark
<rick_h__> and they don't confuse it, but they support it in the html syntax
<hatch> sure but their examples use JSX....why the **** would you use another technology while trying to demo your new technology
<hatch> that's like someone using coffeescript to demo their new js framework
<rick_h__> because it solves the "ugh, html in JS strings sucks"
<rick_h__> and people run away
<hatch> yeah it's almost like we solved that.....with templates
<rick_h__> lol, but this is especially *not* templates :)
<rick_h__> templates are too static (in this lib's eyes)
<hatch> sure - why update values in a template when you can rerender the whole thing...
<rick_h__> lol, you're mixing templates in again
<rick_h__> their fiddle demo notes that it doesn't re-render since it didn't change :p
<hatch> <textarea onKeyUp={this.handleKeyUp} ref="textarea">
<hatch> O K I'm done
<rick_h__> lmao
<rick_h__> anyway, just joking that you didn't grab the absolute latest lib from a big company (FB) for your demo. 
<hatch> haha yeah I know :)
<hatch> angular has been around for a while though
<rick_h__> it's been out for weeks! 
<hatch> a couple years I think
<rick_h__> it's not been 'released' for multiple years has it?
<hatch> yep
<hatch> it was pretty basic before though
<rick_h__> ok, I mean it's only come across it more and more the last year. I figured it was internal and then open sourced just lately
<rick_h__> so v1 was a year ago, maybe that's what I'm thinking
<hatch> oh well yeah I think it only hit 1.0 last year - but 1.0 in js world is really like v100 because they all start at 0.0.1 lol
<rick_h__> I really need to use test-debug more. 13s for tests vs 30 (though I think it's skipping some setup time in that time)
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/stop-ingesting-icon/+merge/167613 ?
 * sinzui does
<gary_poster> rick_h__, I suggested other changes than what you had.  Fine with what Curtis gave you.  Was just giving ideas.
<rick_h__> gary_poster: See that. Not a problem. Thanks. 
<gary_poster> rick_h__, thank you very much for the changes.  great to have.  I am hopeful that Luca and/or Alejandra will bless with minimum/no changes
<rick_h__> gary_poster: yea, hopefully seeing will help make it click. I'm not a big fan of moving the UI around and would hate to remove a tab *sometimes*
<gary_poster> cool
<sinzui> abentley, I am not sure I understand the need for --prefix
<sinzui> abentley, well, the default rule looks like a filter that is not useful to this case
<abentley> sinzui: It's a convenience for testing, so that you can do enqueue --prefix '~charmers' and get charms with icons more quickly.
<rick_h__> sinzui: can I get a LGTM when you get a sec per your changes. Then I'd like to move this card nito acceptance vs landing so I can work on meeting with UX to get pre-landing acceptance per gary_poster if that's cool
<sinzui> abentley, okay, works for me
<abentley> sinzui: it was already using CHARM_IMPORT_FILTER, I just made it possible to override that.
<sinzui> abentley, r=me
<abentley> sinzui: But if you want, we can scrap CHARM_IMPORT_FILTER entirely.
<sinzui> abentley, I got confused for a moment. I was thinking about how the filter relates to the icon problem. It doesn't, and that is good because there are non~charmers charms with icons now
 * sinzui returns to rick_h__'s branch
<abentley> sinzui: Cool.
 * abentley emulates Tarmac
<sinzui> orangesquad. Looks like matsubara is a single point of failure. IS doesn't have access tot the machine.  I have pinged rfowler, my only lead. The loss of ssh though makes me ponder a firewall change
<sinzui> abentley, wasn't a firewall change the cause a issues in Feb/Mar?
<abentley> sinzui: Sorry, I don't remember.
<sinzui> oh, that change was between tarmac and staging.
<sinzui> abentley, I will add an options property to the Charm model in my next branch. *Every* use of config is to get to a dict names options in the code.
<abentley> sinzui: +1
<bac> gary_poster: i've added comments to https://docs.google.com/a/canonical.com/document/d/15o7YX4HFuuVuzYzKmhMRBfvKkca6Srwq8WdyR6YDL44/edit
<gary_poster> thank you bac
<benji> I have another small branch that adds yuidoc linting up for review: https://codereview.appspot.com/10045046
<hatch> benji: on it
<benji> thanks
<hatch> benji: is ther any way to make it lint the prefixed *'s on each line?
<benji> hatch: I can easily do that, but we would have to finish the argument about whether or not we want the *s first... or did we finish that?  I can't remember.
 * benji looks at the blog.
<hatch> I thought we did but I have seen new code with it hah
<benji> hatch: the blog doesn't mention it.  I vaguely recall us settling on /** to start, two space indents for the body, no star on prose lines, and /* (indented at the same level as the opening /**) to end.  Does that sound right?
<benji> I could make that happen pretty easily, but fixing all the existing comments might be a tad tricky.  Hmm, well maybe not; I might be able to do it relatively quickly.
<hatch> benji: I thought that's what we had agreed uppon as well
<hatch> there was some pushback because vim's commenting system
<benji> right, but I remember providing a setting tweak that fixed that objection
<hatch> holy schmoly blueprint emails batman
<benji> hatch: thanks for the review, I had a question for you about the read-only attribute.
<hatch> sure
<hatch> shoot
<hatch> oh I see in the email
<hatch> nope that just means that the initial value is provided by a function
<hatch> there is actually a setting for readonly attributes
<hatch> ^ benji
<hatch> http://yuilibrary.com/yui/docs/api/classes/Attribute.html#method_addAttr see readOnly
<benji> hatch: oh! ok; thanks for the explanation
<hatch> np - fixing the parser about those quoted functions would be great
<hatch> btw :)
<hatch> http://analytics.blogspot.ca/2013/06/google-analytics-becomes-robust-testing.html
<hatch> gary_poster benji: ^
<hatch> maybe something in these new changes we can take advantage of
<gary_poster> very cool hatch, thx.  bac, you also ^^
<hatch> so generators are coming to ES6, I figured you perlites would enjoy that
<hatch> pythonites I mean
<hatch> :)
<hatch> I actually had a use for them yesterday - then I worked around it
#juju-gui 2013-06-06
<rick_h__> alejandraobregon: ping, got a few min?
<benji> morning all; I could use another review on this small branch that adds a copyright linter: https://codereview.appspot.com/10045046
<rick_h__> benji: looking
<rick_h__> benji: why are some /** turned into /*? I thought /** was the rule? It's done in a few places not throughout.
<benji> rick_h__: /** means "this is a yuidoc comment", many of those were (reflexively, I assume) marked as yuidoc when they were in fact just regular comments
<rick_h__> benji: oh, I didn't realize we were distinguishing a doc block vs a yuidoc. 
<rick_h__> that sucks :/
<benji> (I just realized that that branch is about yuidoc linting, not copyright linting, but that's ok)
<rick_h__> yea, I was going to ask next about copyright :)
<benji> rick_h__: well, it's more that yuidoc distingushes
<rick_h__> benji: forgive my comment there. Honestly, I just learned something new today. I never realized there was any YUIdoc diff between /** and /*. Honestly couldn't recall seeing /* used before
<rick_h__> benji: but it appears it's something always been supported, just I've never used and didn't realize was there. 
<rick_h__> benji: never thought to distringuish 'types' of comments other than blocks/single line and caught me before my coffee today :)
<benji> rick_h__: no worries
<benji> heh
<rick_h__>  /** type comments goes all the way back to my PHP days years and years :)
<benji> I was out of coffee so I actually got up an hour before work to drive to the store to get coffee and heavy cream (which I have come to love in my coffee).
 * rick_h__ revisits bcsaller's branch from last night as I think I ding'd him on some /* that might be legit after all 
<benji> :)
<benji> It goes to show just how diverse the programming world is that people with years of widely varried experience can still see things new.  I guess it's one of the cool things about what we do.  That and the arguments about naming things. ;P
<jcsackett> jujugui: is uistage loading for anyone? i'm getting endless "connecting to environment".
 * benji looks
<frankban> gary_poster: ready for the call when you want, no rush
<gary_poster> thanks frankban, was in the depths of reviewing the UX stuff.  about to join
<benji> jcsackett: I see the same behavior as you.  There is an error in the console that looks suspect: Uncaught TypeError: Cannot read property 'browser_enabled' of undefined 
<bac> jcsackett: i see 19ws://uistage.jujucharms.com:8081/wsWebSocket network error: The operation couldnât be completed. Connection refused
<gary_poster> bac, you on it?
<bac> i. am. on. it.
<bac> like stink on rice
<rick_h__> heh, who flipped sandbox in their commit :P
 * rick_h__ hopes it wasn't him after that
<gary_poster> :-)
<gary_poster> frankban, I
<gary_poster> am looking at you :-)
<frankban> gary_poster: rejoining
<gary_poster> frankban, uh oh I can hear you
<gary_poster> but nothing on my side
<gary_poster> will try restarting, frankban 
<frankban> gary_poster: ok
<BradCrittenden> benji: so uistage should be running against rapi, no?
<bac> i don't see where the rapi process is started
<benji> bac: I think so
<bac> and it sure ain't running.
<benji> that could be it
<bac> i'll start it by hand and hope
<benji> there is probably a reason we don't run it in sandbox mode, but I don't know what that reason is :)
<bac> hazmat: uistage was just down b/c there was no improv running.  is there an init script for it?  i've started it by hand for now.
<bac> jcsackett: uistage should be good now
<jcsackett> bac: you're my hero
<bac> wow, low bar
<teknico> bac: you're my hero too! ;-)
<teknico> bac: I'd like your eyes on https://codereview.appspot.com/10020044/ , short'n'sweet
<bac> http://www.youtube.com/watch?v=JsWgG5v7A3A
<bac> teknico: did
<gary_poster> "wow, low bar": lol
<teknico> bac: thanks
<hatch> morning
<jcsackett> orangesquad: one sec, hangouts completely crashed this time.
<benji> gary_poster: I have put the finishing touches on the vitals edit.  Let me know when/if you want to discuss.
<benji> I loved that show.
<hazmat> bac, probably not
<gary_poster> benji, ack thanks, will put something on cal so I don't forget
<benji> k
 * benji adds tags to reviews that people forgot to tag, with as little passive-aggressiveness as he can muster.
<gary_poster> :-) go for aggressive-aggressive.  call out our names!  you!  there!  in the blue shirt!
<rick_h__> I'm wearing grey today
<benji> you know I'll do it
<gary_poster> lol
<benji> :)
<teknico> it's blue but it's not a shirt, nice try :-P
<gary_poster> heh
<gary_poster> oh, and speaking of teknico
<gary_poster> look, I'm late for our one on one!
<teknico> right :-)
 * gary_poster should just join when the alarm goes off
 * benji admires teknico's blue kilt.
<teknico> :-)
<benji> I want a utilikilt: http://www.flickr.com/photos/7474015@N08/2439813854/
<rick_h__> love that it's the guy with the beard wearing it
<benji> :)
<benji> gary_poster: when you get off your call I could use a reminder what the "scenarios" card is about.
<gary_poster> benji, off call.  which one?  should we just go to guichat directly? :-)
<benji> gary_poster: guichat it is
<bac> gary_poster: did you see i added you to the GA account yesterday?
<gary_poster> bac, yes thank you very much.  have not logged ibn.  should I?
<gary_poster> in
<bac> gary_poster: only if you're curious
<gary_poster> cool
<gary_poster> oh bac did you see the link jeff gave yesterday?
<gary_poster> looking
<bac> gary_poster: i've added some custom events to my local branch.  unfortunately GA divides reports into basic things it shows in 'real time' and other stuff that lags but 12-24 hours.  i think the events are in the latter.
<bac> gary_poster: so it may take a while to get feedback to whether i'm doing it right or not
<bac> gary_poster: i do recall jeff's link but didn't read it as i was addled
<bac> will find it now
<gary_poster> thanks
<hatch> if you can't find it I should have it in my history
<BradCrittenden> hatch: irclogs.ubuntu.com ftw
<hatch> aww man this is logged.... /me stops talking
<hatch> I do well enough of making of an idiot of myself in person, I don't need help by irc logs lol
<sinzui> abentley, do you have time review https://code.launchpad.net/~sinzui/charmworld/use-charm-model/+merge/167771
<abentley> sinzui: sure.
<rick_h__> jcsackett: hold off on anything else on that black bar please. I think I have some work with it here in my branch that might help once I figure it out
<jcsackett> rick_h__: dig. i'll continue on search goofiness then.
<rick_h__> jcsackett: I'll verify 100% in a bit here, but I'm having problems with the active tab because of multi-dispatch and finding that the charm details gets drawn/destroyed/drawn again in a single page load
<jcsackett> rick_h__: that jives with what i've seen, and is *very* likely the cause.
<abentley> sinzui: the options property returns a dict, but in some cases, this is a permanent dict and in other cases it is temporary.  This means that assignment (charm.options['foo']='bar') has undefined behaviour.  Perhaps it would be better to create the options dict if it doesn't exist?
<rick_h__> jcsackett: yea, and I've got to fix that to get this tab loading to work as well. Hopefully two birds/one stone
<jcsackett> rick_h__: i'm leaving the card on kanban in next as high/blocked. we'll delete it if you're work fixes it, and link your branch to the bug.
<rick_h__> jcsackett: rgr
<sinzui> abentley, ! absolutely
<sinzui> abentley, the model is read-only at this point and I don't see anything assigning to it in the code. I was expecting to allow changes when I make adjustments for ingest
<abentley> sinzui: Sure, it's fine to address in a follow-up.
<hatch> bcsaller: in yet?
<bcsaller> hatch: almost
<hatch> I see that your bind method takes a viewlet || array - when would I pass an array of viewlets in?
<hatch> or do you want me to that?
<hatch> (whenever you get in)
<abentley> sinzui: what is the stringification at 136 doing?
<sinzui> abentley, "lp:%s" % self.branch_spec
<abentley> sinzui: My 136 is " 'revision': str(charm.last_change['revno']),"
<sinzui> sorry, I am incompetent
<abentley> sinzui: nm, the original is the same, so we can ignore it.
<sinzui> it is just a accessor to the underlying dict
<bac_> hatch: thanks for the link.  that is very cool.
<hatch> no problemo sir
<abentley> sinzui: Oh, it's because revno is an integer.
<sinzui> that is right.
<sinzui> abentley, we could always treat it as a string. We never use it as an int in ingest or views
<abentley> sinzui: Maybe, but I hate to make a specific value more vague.
<sinzui> abentley, I think this is the only case where we explicitly cast the revno to a str to ensure the json encoding delivers a string
<abentley> sinzui: I think it's something we might fix in a future version of the API.
<abentley> sinzui: r=me.
<sinzui> thank you abentley
<bcsaller> hatch: if changes to the model update more than one viewlet you can pass them all in. For example service overview, service config, service constraints are 3 viewlets bound to a single service, when it changes they have the potential to update. If however nothing in the services change event touched any of the bindings in one of those  viewlets nothing should happen on its behalf  
<hatch> ok that's an excellent idea
 * hatch refactors....again
<hatch> :P
<bcsaller> hatch: if you need any adjustments let me know, I'm responding to the other review feedback now
<hatch> bcsaller: I think that's the only one that "caught me off guard"
<teknico> Makyo: ping
<Makyo> teknico, Hey.
<teknico> Makyo: time for a few questions in chat?
<Makyo> teknico, Sure
<gary_poster> rick_h__, are you planning to actually provide an official review of bcsaller's branch?  Should he be waiting on an LGTM from you?
<rick_h__> gary_poster: yes, I was going to see if that was ok and helpful. I had two big questions if I recall. /me remembers last night
<rick_h__> and maybe they're just "rick doesn't get it" things
<gary_poster> benji, I hadn't committed to be a true reviewer of ben's branch yet, which was why I had not signed up.  I think maybe rick felt the same way.  I am ok with being official reviewer now, though, so all's good :-)  rick_h__ +1 on you being reviewer
<benji> okk
<rick_h__> the polling on the polyfill, the key in the comment but not method arg, test passing in a node vs an object 
<teknico> bac: time for a quick hangout before the call?
<bac> teknico: yes, give me a minute
<teknico> bac: sure
<rick_h__> bcsaller: if you get a few min I'd appreciate a chat on routing with this issue I'm trying to get working.
<bcsaller> rick_h__: I can hop on chat
<rick_h__> bcsaller: cool /me checks if guichat is clear
<teknico> bac: https://plus.google.com/hangouts/_/02bb45411739e441fe107c9f66e2a8cc36ba4ba7?authuser=0&hl=en
<teknico> (guichat is busy)
<gary_poster> jujugui call in 10.  kanban now please
<bac> teknico: you're not there?
<teknico> oops
<teknico> I am now :-)
<gary_poster> jujugui call in 1
<gary_poster> bcsaller, starting without you
<BradCrittenden> i mean to mention: US-based people, tomorrow is free donut day at Krispy Kreme.  (Offer not valid in CT or PR)  :(
<gary_poster> lol
<hatch> jcsackett: want to chat now?
<hatch> it was camp day at Tim Hortons yesterday (where the $ goes to childrens camps) and some guy raged at the drive through people for asking for a donation
<hatch> those people in the drivethrough were people from one of the radio stations
<hatch> I bet you can figure what happened next :)
<hatch> the worst part of refactoring is fixing the tests...I'm convinced
<sinzui> orangesquad regarding bug 1187855, We are waiting for webops to deploy the new ES 0.90.0.release package. I think the beta package is below average
 * hatch votes to fix the template compiler to --watch files for changes
<rick_h__> hatch: thought it did. Which template isn't getting picked up?
<hatch> my new one
<hatch> I have to shut down the server and restart it
<rick_h__> hatch: what dir is it in?
<hatch> the same as the rest of the templates
<rick_h__> ah, it lists the files to watch. a new one isn't in the list
<hatch> ohh damn I missed that
<rick_h__> a single restart thogh to have it picked up should work
<gary_poster> bcsaller, would you rather reply to my questions in rietveld or a call?
<hatch> rick_h__: where is this list?
<gary_poster> or do as much as possible in rietveld and then decide if a call is necessary? :-)
<bcsaller> gary_poster: I was just getting to one that really could use a call, do you have a sec now?
<gary_poster> sure bcsaller .  trying jujugui
<gary_poster> sorry everyone
<gary_poster> I meant trying guichat
<hatch> haha ^5
<rick_h__> hatch: look at tempalte_dirs in config.js and how it's used in lib/templates.js
<gary_poster> :-P
<hatch> rick_h__: well the file was there
<hatch> so it would have picked it up when it first started
<sinzui> rick_h__, I updated the ES ticket explaining our need to get the new package soon.
<hatch> but any changes required a serverrestart
<rick_h__> hatch: so line 207 there does the watching I believe
<rick_h__> sinzui: cool
<hatch> rick_h__: yeah there is something wrong there
<hatch> will have to investigate
<hatch> when I have free time
<rick_h__> hatch: just imagine the time savings when you don't ahve to kill/restart :P
<hatch> damn rights!
<rick_h__> hatch: so in looking at that code, it uses ifValidFile to determine if it should restart and that's only for files checked into bzr 
<rick_h__> hatch: so make sure you bzr add the tempalte?
<hatch> yeah it's in there...iunno I'll investigate later
<rick_h__> hatch: ok
<hatch> I just wasted some time assuming that it was regening properly
<jcsackett> hatch: you have a moment to chat?
<hatch> I dew
<hatch> guichat is busy sec
<rick_h__> hatch: http://paste.mitechie.com/show/962/
<hatch> hahaha
<rick_h__> hatch: I could have sworn I fixed that weeks ago, but that should fix it
<hatch> annnnd fixed - thanks for taking the time :)
<hatch> bcsaller: I am documenting the viewlets now - is the format for binding [ { name: 'modelFieldName', target: 'querySelectorString' } ] ?
<bcsaller> hatch: I've added some docs around that to the binding engine, I can push the change in a second, but yes, the addition is that target can also be an array of selectors
<hatch> alright I'll update my docs
<benji> so many scenarios
<hatch> does anyone know the jslint command to shut off this error...
<hatch> The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
<rick_h__> hatch: heh, I broke down and put an if in there
<hatch> ugh
<hatch> to the googles!
<rick_h__>  /*jshint -W089 */
<rick_h__> hatch: http://jslinterrors.com/the-body-of-a-for-in-should-be-wrapped-in-an-if-statement/
<hatch>  /*jshint forin: false */
<hatch> oh that didn't work
<hatch> lol
<rick_h__> :P
<hatch> unforunately the W089 didn't either
<rick_h__> hatch: try jshint --verbose xxx.js and see what code it spits out
<hatch> app/views/view-container.js: line 252, col 16, Bad option.
<hatch>       /*jshint -W089 */
<rick_h__> jshint --version?
<rick_h__> that's for 1.0+ 
<rick_h__> hatch: and I've got 2.+ installed right now so assume it should work
<hatch> lol
<hatch> jslint --version $0.9.1
<hatch> er
<rick_h__> hatch: ah, this is jshint
<hatch> jshint --version $0.9.1
<rick_h__> ah, well upgrade that sucker :P
<hatch> how the heck was it so old!
<rick_h__> hatch: with your computer...who knows :P
<hatch> lol
<hatch> hey I fixerd the 0.0.0.0 thing didn't I? :P
<rick_h__> lol, yay
<hatch> aww crap it's still throwing that error
<rick_h__> you sure you're using the one that's upgraded?
<rick_h__> global install vs local install and all that?
<rick_h__> which jshint for instance
<rick_h__> `which jshint` that is
<hatch> ahh
<hatch> jshint is installed locally as well
<hatch> and is locked to version 0.9.1
<hatch>     "jshint": "0.9.1",
<rick_h__> ah, well then carry on the fight
<hatch> ugh it refuses to install the new version
<sinzui> rick_h__, your category info fix is now in production
<rick_h__> sinzui: very cool
<rick_h__> http://uistage.jujucharms.com/fullscreen/:flags:/browser_enabled/ to see it, open up some of the charm containers 
<rick_h__> ha-proxy at least on the front page
<rick_h__> jcsackett: ping, got a sec?
<jcsackett> rick_h__: sure.
 * hatch crys .... I just want to commit my code!
<rick_h__> hatch: then put the if in there :P
<rick_h__> jcsackett: invite on the way
<hatch> rick_h__: hah I'd rather get it to install the proper jshint
<bac> gary_poster: i just sent you an email showing a custom event
<rick_h__> jcsackett: http://paste.mitechie.com/show/963/
<hatch> I am getting a number of console logs saying "cannot create simulator" while running the tests
<hatch> they still pass but I'm guessing those shouldn't be there?
<hatch> ^ bcsaller
<bcsaller> hatch: IIRC it tries to start on but would have failed on the 'sandbox' check, I think we can remove the warning now that we always try to make the object
<hatch> alright
<hatch> today is just not my day, now I can't even diff trunk from my branch t
<hatch> benji: I can't seem to find my notes about the secret flag you told me about to create a proper diff
<hatch> do you happen to remember what that was?
<bcsaller> bzr diff -r ancestor:../trunk 
<bcsaller> hatch:  ^
<hatch> that's it
<hatch> thanks
<hatch> ImportError: No module named tornado.ioloop
<hatch> make: *** [test-misc] Error 1
<hatch> anyone seen that before?
<rick_h__> hatch: yes, check the hacking docs
<rick_h__> hatch: welcome to trunk :)
<hatch> you're going to have to be more specific
<hatch> :)
<rick_h__> bzr grep tornado 
<rick_h__> :)
<rick_h__> teach a man to fish...
<hatch> bzr doesn't have a grep command!
<hatch> silly kid
<rick_h__> :/
<hatch> lol
<rick_h__> did I install that as a plugin?
<hatch> you must have :)
<rick_h__> oh, guess I did
<rick_h__> handy bugger
<rick_h__> hatch:  bzr branch lp:bzr-grep ~/.bazaar/plugins/grep
<hatch> hmm
<hatch> can't find anything in the docs
<rick_h__> it's in HACKING on trunk
<rick_h__> after you install the grep plugin you can bzr grep tornado to find all occurances of the word in the project which is darn helpful in finding things
<hatch> I am just reinstalling python-tornado, see if that fixes it
<bcsaller> gary_poster: on the GUI work spreadsheet where is the new canvas UX? Is that just under inspectors or is that later?
<hatch> rick_h__ I must need to do a hard update on the repo - the only tornado stuff I have is it in the install docs in HACKING
<gary_poster> bcsaller, "environment power tools"
<hatch> sounds exciting :)
<bcsaller> ah ha, that wasn't clear to me, I thought that was about debug logs and such
<hatch> I was hoping for hammer drills and the like
<gary_poster> bcsaller, https://blueprints.launchpad.net/juju-gui/+spec/servercloud-s-juju-gui-environment-power-tools fwiw
<benji> sorry, hatch; I was lunching, but it seems you were taken care of
<bcsaller> gary_poster: thanks, sorry to bother about it 
<gary_poster> np
<hatch> benji: np :) thanks anyways
<hatch> 2013/06/06 12:52:13 error: Failed to send patch set to codereview: diff is empty
<hatch> *sigh* lol
<hatch> doh
<rick_h__> hatch: right, ti's a new dep that was added and you have to apt-get install it per the hacking docs. 
<hatch> yeah I already did, but something must have messed up
<hatch> thats why I was confused I was looking for some additional docs
<hatch> haha
<hatch> LF review https://codereview.appspot.com/10090045/
<rick_h__> abentley: conflicts in your MP 
<abentley> rick_h__: I'm fixing them now.
<hatch> rick_h__: have you picked up any games since you got your new machine?
<rick_h__> hatch: only been playing Left4Dead2
<rick_h__> picked up HL2 but not messed with it
<jcastro> HL2 ftw.
<hatch> http://store.steampowered.com/app/237430/ looks like it might be good
<hatch> and it's avail for linux
<jcastro> I just got: http://store.steampowered.com/app/58610
<jcastro> it's pretty fun
<hatch> cool
<hatch> I hope that more people choose ubuntu for gaming - more gaming, more people, more quality apps
<hatch> and boy do we need quality apps
<rick_h__> I've been really surprised how many people in my l4d2 games have been running linux
<hatch> yeah? that's great
<hatch> rick_h__: thx for the review...replying
<hatch> at least I'm attempting to...
<rick_h__> hatch: cool, I guess would be nice at first glance to see what's the API vs what's over writeable vs what required to be set
<rick_h__> jcastro: that looks cool
<hatch> rick_h__: you didn't happen to delete your comments? They were here....now it shows that there are comments but none are shown...
<rick_h__> hatch: not that I'm aware of :/
<rick_h__> hatch: in the email I guess?
<rick_h__> wtf..where did it go?
<hatch> oh good it's not there for you too
<hatch> heh I thought I was going mad
<rick_h__> ok, wtf. tried to LGTM again and no go
<hatch> hmm ok well maybe I'll take lunch now and hopefully it'll fix itself
<rick_h__> hatch: ok, so if I click the link in the email it loads correctly
<rick_h__> hatch: k, I'm going to EOD, have fun and hope it fixes itself as well :)
<hatch> alrighty, have a good night
<rick_h__> lawn mowing time yay me
<gary_poster> weird
<hatch> yay!
<gary_poster> comments in reviews not working for me either
<gary_poster> bcsaller, only important one lost so far:
<gary_poster>   92       if (typeof binding === 'string') {
<gary_poster>   93         binding.target = [binding.target];
<gary_poster>   94       }
<gary_poster> 92 should be binding.target I suspect
<rick_h__> and boom https://twitter.com/mjg59/status/342720383897718784
 * rick_h__ runs away after bomb dropping
<bcsaller> ahh, thanks, added back in better base class checking around model/modellist as well 
 * benji opens his arms and embraces the shockwave.
<hatch> tl;dr;
<hatch> it wouldn't be the first time someone got something wrong in a paper :P
<benji> snake_case (as the ruby guys call it) is easier to read
<hatch> harder to type
<benji> hatch: have you seen the meta study that shows that 50% of published medical results are not reproducable; kinda scary
<hatch> haha I have not...but wow
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/api-2-maybe/+merge/167830 ?
 * sinzui looks
<sinzui> abentley,  on line 81 I see
<sinzui> self._charm_result(charm, None, None)
<abentley> sinzui: Right.  API2 reimplements charm_result so that it doesn't retrieve provides/requires, which API2 doesn't need.
<sinzui> I think (from the diff) that API2._charm_result() has no call sites that use the second and third arg. Shouldn't the method just accept a charm?
<abentley> sinzui: It would be harder to test if API2._charm_result and API1._charm_result had different call signatures.
<sinzui> ah!
<sinzui> thank you. I put too much thought into this. I should have asked you sooner
<abentley> sinzui: I could make them optional parameters for API2.
<sinzui> abentley, please do. That is my only request. The tests were clear
<BradCrittenden> gary_poster: if you look at the real-time events, there are now a bunch of them.  i left a browser open with the event simulator running, so it pumped out a bunch.
<gary_poster> cool bac, looking
<abentley> sinzui: Thanks for the review.
<gary_poster> bac, but still no way to see the data we want to see till tomorrow, right?
<bac> i think not
<hatch> bcsaller: I was under the impression that show/hide set the visibility style not the display style
 * bcsaller checks
<hatch> nope looks like you were correct
<hatch> bcsaller: so is your branch ready to merge in?
<hatch> or do you need another review?
<bcsaller> I think so, but I don't have the +2 I need
<bcsaller> gary_poster: ^^? :)
<gary_poster> bcsaller, working on it.  sorry, wife left me home with children to take cat to vet
<bcsaller> gary_poster: ahh, no pressure. I'd suggest you make sure you're on the current rev in any case 
<gary_poster> will look in a sec.  almost done bcsaller
<hatch> gary_poster: you need some of these http://4.bp.blogspot.com/_li5GG5WIrnA/TReO3oBwivI/AAAAAAAACRE/Zl_IGQ6TdgI/s400/Playgro-Child-Harness-Wrist-Strap_lij9ph.jpg
<hatch> :D
<gary_poster> hatch :-P wouldn't help :-)
<hatch> lol
<hatch> annnnd submitting
<gary_poster> bcsaller, lgtm thank you
<abentley> rick_h__: Is http://staging.jujucharms.com/api/2/charms/interesting fast enough?
<hatch> niiiiice
<hatch> sure beats the 7s it was before eh? ;)
<hatch> has anyone see the jenkins error?
<hatch> looks like another one was auto started again
<hatch> i'll keep an eye on it
<hatch> O K so what's next
<hatch> we should probably merge them together
<rick_h__> abentley: cool, 1.5s and less in checking it out
<abentley> rick_h__: Cool.  I'll move "charms/interesting takes too long to retrieve" into Deployment/Ready.
<rick_h__> abentley: rgr, do we still have a card for looking into caching? I still think we can cache it for the 15min import cycle and get that way down sub 1s
<rick_h__> abentley: but that's icing on the cake at this point
<abentley> rick_h__: No, we have a card for "it's not fast enough".  If it's not fast enough, then I'll move the card back to Next.
<hatch> bcsaller: we should probably chat to plan the next step
<bcsaller> hatch: agreed, just submitted databindings
<bcsaller> well... its still running
<hatch> guichat?
#juju-gui 2013-06-07
<hatch> bcsaller: back
<bcsaller> hatch: let me push what I have but I know its your EOD
<hatch> cool - I'm just about to make some supper then I can take a longer look at it
<bcsaller> hatch: lp:~bcsaller/juju-gui/service_inspector behind :flags:/serviceInspector/
 * bcsaller takes a break
<hatch> bcsaller: I think I have c9 setup but need someone to try it out with....
<bcsaller> hatch: got a link on what I need to do?
<hatch> well you need to sign up
<hatch> which is very easy
<hatch> then I need your username to grant you permissions
<bcsaller> hatch: its bcsaller
<hatch> ok now to find out how to add you
<hatch> :)
<hatch> https://c9.io/hatched/juju-gui
<hatch> there is the url
<hatch> ok granted you read/write access
<hatch> open the COPYING file
<bcsaller> seems to be working though I don't seem to have an indicator of what you have open and are editing
<hatch> I Just typed under Preamble in COPYING
<hatch> hmm
<hatch> I just highlighted the to paragraph of the COPYING file....can you see that?
<hatch> according to the vids this should 'just work'
<bcsaller> hatch: doesn't seem to be showing edits
<hatch> well that's lame
<bcsaller> does the chat work on the right?
<bcsaller>  going to get back to debugging the rendering
<hatch> alrighty
<hatch> :)
<bcsaller> you know we could easily parse data-bind="name" out of rendered DOM, but we'd lose the easy programatic config
<bcsaller> well, not lose, be at odds with
<hatch> yeah I had that in one of my refactors
<hatch> but I was torn
<hatch> and reverted :)
<bcsaller> yeah
 * hatch goes to delete the c9 account
<hatch> thx for the help
<gary_poster> bac, looks like we have some stats.  now the question is. how do we read them :-)
<gary_poster> mysql-bac has average value of 14.72, mysql-x has average of 7.56, service (?) has average of 7.39
<gary_poster> bac, looks like we have some stats.  now the question is. how do we read them :-) mysql-bac has average value of 14.72, mysql-x has average of 7.56, service (?) has average of 7.39
<bac> oh interesting.
<bac> gary_poster: sadly i'm not a good scientist as for this round i didn't keep records.  i recall setting one to 15 units, so that would correspond with mysql-bac
<gary_poster> ok
<bac> gary_poster: and there was the simulator perturbing the data
<gary_poster> rt
<gary_poster> rogpeppe, hi.  I'd like to get your replies to the "Juju GUI API addresses handling" email thread (William said you had some plans in that regard) and to the "Juju core tasks for GUI project" thread (William and I both would like your thoughts on a reasonable way forward with the restricted mode that I mentioned and you prototyped.  Do you have a chance of replying to those this afternoon?  If not, np.  Those two ar
<gary_poster> e not immediately pressing, though I want us to agree on our way forward. I have a "ping Roger" to do item that I can fire off again next week sometime to try and get your thoughts :-)
<rogpeppe> gary_poster: yes, i should be able to do that
<gary_poster> thanks rogpeppe :-)
<gary_poster> fwereade__, thank you very much for your replies to us about the gui needs.  The set unit work would would ideally be implemented first of our juju core bits, but did I understand correctly that, even were we to decide to try to implement it ourselves, we need to wait for the same changes (a major version upgrade mechanism and/or moving the DB entirely behind API) that core would be waiting on?  that is, it is not m
<gary_poster> erely a matter of bandwidth but also technological infrastucture?
<bac> teknico: ping (or are you gone today?)
<bac> gary_poster: ^^ ??
<fwereade__> gary_poster, I'd like to chat to someone about that
<fwereade__> gary_poster, I had a suggestion that might not involve a schema change, and might make for a useful model
<gary_poster> involving SetMinimumUnits?
<fwereade__> gary_poster, yeah
<gary_poster> bac I think he is here today.  out wednesday this week only
<bac> ok
<bac> no rush
<fwereade__> gary_poster, can't chat today though, I'm afraid, just driving by
<gary_poster> fwereade__, ok, maybe I can try to get a meeting with you, me, and frankban sometime next week?  I'll propose on calendar?
<fwereade__> gary_poster, perfect, early monday is fine by me, I'm really keen to unblock you
<gary_poster> fantastic, thanks fwereade__ .  ttyl
<fwereade__> gary_poster, but whenever works :)
<fwereade__> gary_poster, cheers
<gary_poster> frankban, do you mind helping out with analysis of the concurrent set unit discussion Monday at 1430 UTC?  It might lead to you leading that implementation eventually, so be warned. :-)
<frankban> gary_poster: I am definitely interested :-)
<gary_poster> cool thanks frankban :-)
<rick_h__> jcsackett: morning, I'm still working on getting tests into the branch, but if you get a second can you QA it and make sure it does solve the black bar problem you saw? https://code.launchpad.net/~rharding/juju-gui/details-double-dispatch/+merge/168053
<rick_h__> jcsackett: I don't see it, but I want to make sure I'm doing the exact steps you did to find the issue.
<jcsackett> rick_h__: looking.
<jcsackett> rick_h__: it doesn't.
<teknico> bac: I'm back from lunch, what's up?
<jcsackett> rick_h__: going to this url http://jujugui.local:8888/fullscreen/search/precise/juju-gui-61/:flags:/browser_enabled/?series=precise&text=gui&type=approved still causes black bar horror.
<bac> teknico: not much, i was just wondering about the spelling for the config setting to disable GA.  i'm writing some docs
<bac> teknico: and my thoughts about exposing it in the charm were truly cracktastic.  please ignore.
<jcsackett> rick_h__: oddly though, if i move the ":flags:" bit to be the first bit (which i think is correct) no black bar.
<teknico> bac: the idea was to use "use-analytics: true|false"
<jcsackett> rick_h__: the latter url was the one i was actually using yesterday. so partial success at least. the flags thing may not be an issue, since i think flags are supposed to be the first component of a url anyway?
<bac> teknico: ok.  that works
<rick_h__> jcsackett: k, looking
<gary_poster> hey sinzui, I went to http://tinyurl.com/orange-standup but hangouts said the party was over.  what's the new daily url?
<rick_h__> gary_poster: https://plus.google.com/hangouts/_/cf491220dfb7736cee2876baf29110eeb52f5997?authuser=1
<gary_poster> thank you rick_h__ 
<sinzui> I think that old URL is from deryck's days time with orange.
 * sinzui deletes the url
<hatch> mornin
<bac> gary_poster: who is that hairy man kissing karen on facebook?
<gary_poster> bac, I dunno, but he's in some big trouble.
<benji> gary_poster: so, zooming in and out should be on the basis of a service, eh?
<bac> gary_poster: h.a.
<gary_poster> :-)
<gary_poster> benji, something like that, yeah.  Maybe scrolling should be on the basis of the center of the viewport instead?
<gary_poster> benji, goal is to handle case of services way  out from to pleft origin
<gary_poster> benji, current zoom is always from top left
<gary_poster> which doesn't work well in some cases
<benji> gary_poster: it has always felt wierd to me that zooming wasn't centered on the mouse cursor
<gary_poster> benji, I suggest having a pre-imp with Makyo when he is available, if you want to tackle it
<benji> gary_poster: ok (the card said you or Ben, and he out timezone-manuvered you)
<benji> [I need to learn to spell one day.]
<gary_poster> benji, heh, you talked with me to get the goal of the card (make env work better in that case, which is what happens with silly people on uistage
<jcsackett> hey hatch, do you recall where/what causes the second dispatch?
<hatch> deltas
<hatch> every time a delta comes in it will dispatch
<benji> Makyo: yo
<jcsackett> so if i just load '/', there's always a second dispatch. where in the code might i find the event handler (or whatever) that is doing the delta dispatching?
<hatch> grep for dispatch
<hatch> its in a method called on_delta_something_something
<hatch> it's similar to the "something_something_dark_side" method
 * jcsackett laughs
<jcsackett> thanks.
<hatch> :D np
<rick_h__> alejandraobregon: ping, any chance your around and available?
<alejandraobregon> hey rick, soo sorry, been flat out!
<alejandraobregon> rick_h__: will ping you when am out of my meetings
<rick_h__> alejandraobregon: np, I'd be great if we can just schedule something? 
<rick_h__> alejandraobregon: ok, yea just want to let sinzui know what time table I'm looking at on the branch. 
<rick_h__> alejandraobregon: have fun with your meetings :)
<Makyo> benji, yo.
<benji> Makyo: hi, can we have a pre-imp call about the "zooming in and out should be on the basis of a service" card
<Makyo> benji, sure, guichat's free.
<benji> sounds good
<teknico> Makyo: ping me when you're done?
<Makyo> teknico, ping. :)
<benji> gary_poster: it seems that zooming happens relative to the mouse cursor already so Makyo and I are not able to determine what the card is about (there is a bug that means that if the cursor is over a service no zooming happens, I could work on that) 
<teknico> Makyo: guichat?
<Makyo> teknico, yep
<frankban> gary_poster: could you please review my juju-test branch? https://codereview.appspot.com/9874050
<gary_poster> benji frankban on call will ping
<benji> thanks
<frankban> gary_poster: ok thanks
<gary_poster> benji, Makyo, what happens if you use the zoom controls on the bottom of the page?
<benji> good question; trying now
<jcsackett> rick_h__: is it valid for a url to have both '#' and '?'
<jcsackett> and if so, is ordering of those two important/specified?
<jcsackett> hoping you can save me a trip to URI specification docs. :-P
<rick_h__> jcsackett: yes
<rick_h__> jcsackett: no, I think usually the ? is first ,the # is second. JS makes location.hash available for the # part
<jcsackett> rick_h__: cool. thanks.
<rick_h__> jcsackett: sorry, other way aroud on the order
<Makyo> gary_poster, that's set to zoom around (0, 0), zooming around the center of the current view would be easier, but would rely on code from my branch.
<rick_h__> #someanchor?query=true
<jcsackett> rick_h__: yeah, was just writing a sample url the wrong way and thought, "this doesn't seem right". :-P
<gary_poster> Makyo, cool, thought it was 0,0.  +1 on zooming around center of current view.  Is that something you should slip into your current branch, ir that benji should work on as a follow on to your branch, or...?
<gary_poster> s/ir/or/
<Makyo> gary_poster, I can do that in my branch, once I get the scale stuff working properly.  There's still the issue of zoom events not bubbling
<gary_poster> Makyo, ok thanks.  benji ^^ s'ok with you?
<benji> yep
<gary_poster> thanks benji.  Makyo, benji, I'll combine text of benji's card with Makyo's and then delete card. :-P
<benji> Makyo: it shure looks like it zooms around the center when using the zoom slider
<benji> k
<Makyo> Cheers.
<teknico> Makyo: deleting all cookies wasn't a great idea :-)
<Makyo> teknico, oops :)
<Makyo> teknico, I found you can delete them from the console in the resources tab.
<gary_poster> benji, on uistage, zoom out.  drag canvas to left so services are just to the left of where you can see them.  zoom in.
<bcsaller> hatch: around?
<hatch> you bet
<hatch> just reading your branch
<bcsaller> hatch: and you got those emails last night?
<bcsaller> from last night :)
<hatch> yup
<bcsaller> ok cool
<gary_poster> frankban, fwiw, I don't have a lot of time.  I will review code but will not have time for qa till later today or Monday
<gary_poster> let me know how much you want me to do
<benji> gary_poster: (ui stage isn't working for me, but I used a local server) I'm not sure what that is supposed to prove.  If it zooms to the center of the visible part of the canvas (the current behavior and a good one, IMO) then if you follow those steps you will not be able to see any services, but that's not unexpected
<gary_poster> benji, want me to show you on guichat? :-)
<benji> gary_poster: sure
<gary_poster> benji oops it is busy
<gary_poster> 1 sec
<benji> heh, yeah I just noticed
<hatch> bcsaller: yeah I see the issue here
<hatch> we can get together after the calls
<bcsaller> hatch: sounds good
<hatch> we definitely need a flag to stop people from opening multiple of the same inspector
<bcsaller> hatch: we can do that with the tracking map in the env view, but I think we might want a better fix than just that 
<frankban> gary_poster: code review would be great, but please don't worry if you don't have time.
<gary_poster> cool
<gary_poster> jujugui call in 6
<gary_poster> kanban now
 * benji opens up the branch start check list.
<gary_poster> jujgui call in 1
<gary_poster> jujugui
<rick_h__> jcsackett: ok, try to break please lp:~rharding/juju-gui/details-double-dispatch :)
<jcsackett> rick_h__: works!
<rick_h__> jcsackett: party, now how the $#@#@ to test it all...
<rick_h__> hah, all existing tests pass...just lp-submit now in a hurry :P
<alejandraobregon> rick_h__: hi!
<alejandraobregon> rick_h__: so sorry, crazy day!
<alejandraobregon> hang out now?
<rick_h__> alejandraobregon: give me 3min (hopefully) in the middle of submitting another branch before I can switch over to dmeo
<alejandraobregon> rick_h__: no problem
<jcastro> rick_h__: do you have a live thing like uisearch but with trunk handy?
<rick_h__> jcastro: http://uistage.jujucharms.com/:flags:/browser_enabled/ ?
<rick_h__> alejandraobregon: invite coming in a sec
<rick_h__> alejandraobregon: https://plus.google.com/hangouts/_/129fd072762c185e15013cb63d854c7e87c68cd4?hl=en 
<alejandraobregon> rick_h__: sorry couldn't understand what you were saying...
<alejandraobregon> rick_h__: i have to leave shortly to pick up my 1YO from nursery...
<alejandraobregon> rick_h__: can we cover it in ten mins?
<rick_h__> alejandraobregon: yep, moved to my home connection sorry
<rick_h__> alejandraobregon: starting up a quick hangout, should take just a couple of min
<alejandraobregon> rick_h__: ah, there you are!
<alejandraobregon> cool!
<rick_h__> sinzui: gary_poster so we have the ok to land the quality tab changes for now with agreement to re-evaluate/discuss it with luca upon his return.
<sinzui> rick_h__, +1
<rick_h__> sinzui: gary_poster and if there's a meeting I'd be happy to sit in and present what we did and why I think it makes sense.
<gary_poster> yay, rick_h__ .  thank you to you and alejandraobregon .  rick_h__ would it be relatively quick to write up an email to juju-gui with the reasoning?  then we can see if we can luca agrees with basic idea without a meeting?
<rick_h__> gary_poster: I can, is everyone on that list then?
<gary_poster> rick_h__, yeah pretty sure.  cc luca and ale just to be sure
<rick_h__> gary_poster: do you have a direct list then? /me does't see ~juju-gui with a list
<gary_poster> oh!  yeah
<gary_poster> pretty sure you are on it but could be wrong
<gary_poster> rick_h__, Juju GUI Developer List <juju-gui@lists.ubuntu.com>
 * rick_h__ checks list membership
<gary_poster> rick_h__, it is an Ubuntu-style list, not LP
<rick_h__> gary_poster: ah, gotcha. 
<hatch> teknico: in guichat
<rick_h__> jcsackett: sinzui hatch bcsaller or anyone else that's intersted, can I get a couple reviews to defeat the great tabs-induced black bar of doom once and for all? https://codereview.appspot.com/10086045 referring to bug #1175019
<_mup_> Bug #1175019: staging has issue with black bar at top of fullscreen charm details <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1175019>
<benji> jsPlumb looks pretty cool
<jcsackett> rick_h__: looking.
<bcsaller> rick_h__: looking as well
<rick_h__> thanks guys
 * rick_h__ fetches remote food for lunch today
<hatch> trunk is broken with make prod
<hatch> oh wait
<hatch> ignore me :)
<Makyo> hatch, Done and done.
<hatch> :P
<Makyo> I kid, I kid :)
<hatch> bcsaller:  shall we chat?
<bcsaller> hatch: joining
<frankban> gary_poster: thanks for the review!
<rogpeppe> gary_poster: aargh, i realise i totally haven't replied to your request and i've reached eod. i will try to do it monday morning - please hit me over the head if i don't!
<hatch> gary_poster: do we have our call in 9?
<gary_poster> rogpeppe, :-) np thanks.  have a good weekend
<gary_poster> hatch yes
<hatch> great I didn't forget this time :)
<sinzui> abentley, rick_h__, the charmworld deploy script does not get the current charmworld charm, and since it is tainting the charm, the versions will never be synced. I am working to get the correct version of the charm installed now
<rick_h__> sinzui: interesting. So we need a long term solution for this then as we update the charm?
<sinzui> we do
<sinzui> I am currentl;y discussing branch tags to compare version
<rick_h__> gary_poster: email away to the list now that uistage is updated. 
<gary_poster> yay thanks rick_h__ 
<rick_h__> gary_poster: also heads up that the black bar issue is closing up. Should hopefully unblock some.
<bcsaller> hatch: currently we are not limited to a single panel, we should think about how we want to handle that. I'm tempted to add the YUI drag handler to the panels on creation so we can just move them around for testing
<gary_poster> yay rick_h__ !  ripping out charmbrowser flag today or next week?
<rick_h__> gary_poster: not sure, I don't know what the current checklist is for that. 
<rick_h__> jcsackett: ping, how goes it? Want to chat now that I've got this stuff landed?
<gary_poster> rick_h__, I think the checklist has been checked.  black bar, bad typing experience of -, and quality tab
<rick_h__> " bad typing experience of -" ?
<jcsackett> rick_h__: we can chat. i found the problem just before grabbing food.
<rick_h__> jcsackett: k
<jcsackett> rick_h__: but i would love to chat about best solution. :-P
<rick_h__> jcsackett: why don't you invite away 
<hatch> bcsaller: yeah I see no issue in that, you should be able to just add it to the view-container template
<sinzui> rick_h__, I think your dash bug is fixed in production: https://manage.jujucharms.com/api/1/charms?categories=app-servers&series=precise&text=&type=approved
<hatch> bcsaller: mind if I grab some lunch and then we can get back at it?
<bcsaller> hatch: go for it
<hatch> cool - i'll be here so just ping if ya need
<Makyo> jujugui Is uistage's improv down again?
<gary_poster> Makyo, not for me
<Makyo> gary_poster, Huh, will try again.  Getting "websocket is closed before connection is establised"
<Makyo> only spelled right.
<hazmat> looks okay on the server
<bcsaller> Makyo: w/o the :8080 wfm, the objects are off the canvas by default
<gary_poster> :-)
<Makyo> bcsaller, oh, derp.  Forgot we removed the :8080
<gary_poster> 8080 wfm too
<Makyo> gary_poster, I get the error only on :8080.
<gary_poster> <shrug> wfm.  just did a hard reload
<jcsackett> hatch: need to grab you for a quick chat when you're back from lunch.
<rick_h__> sinzui: yay!
<rick_h__> sinzui: so maybe you can get with gary_poster on the un-feature flagging of the browser. 
<rick_h__> sinzui: sounds like we're darn close and might be able to monday or tues.
<gary_poster> +1
<sinzui> yes
<rick_h__> sinzui: I'll add a card to the board to remind me to bring it up monday then. Should be a short 3 or 4 line change
<rick_h__> sinzui: so jcsackett is working through our routing/url dropping QS and #xxx issues. I'm giong to move on to api2 then for now and wait for his work to fall through if that's ok
<sinzui> +1 rick_h__
<bcsaller> hatch: give it a try when you get back, you can have multiple open bound draggable panels now
<hatch> will do
<hatch> bcsaller: awesomer
<bcsaller> hatch: what do you think about adding tabs for the viewlets next and then a second one?
<hatch> sure - just for prototype though right? UX will probably have something specific in mind
<bcsaller> yes
<hatch> ""Regenerated Templates"" haha friggen finally!
<hatch> I don't think I have EVER seen that before - that must have been broken forever
<hatch> bcsaller: w00t tabs work :)
<hatch> that was easy....
<hatch> lol
<hatch> mesa thinks all that planning made the coding a lot easier :)
<jcsackett> hatch: skip on needing to chat; can you look at https://codereview.appspot.com/10119043
<hatch> jcsackett: we needed to chat?
<hatch> oops sorry :) I missed the ping
<jcsackett> i pinged you earlier about talking when you got back from lunch. it's all good. :-)
<jcsackett> i'
<jcsackett> i'm not sure we actually needed to.
<hatch> reviewing
<hatch> jcsackett: guichat?
<jcsackett> sure
<bcsaller> hatch: you have a branch link I can merge?
<hatch> bcsaller: is this good enough? can bzr 'apply' diffs? https://gist.github.com/hatched/4bedc5bd0e9dceb96f32
<bcsaller> hatch: bzr push lp:~hatch/juju-gui/service_inspector and then I can merge it
<hatch> cool one sec
<hatch> bcsaller: done
<hatch> jcsackett: lgtm'd with comment as per the hangout
<jcsackett> thanks!
<bcsaller> hatch: cool, thanks
<hatch> bcsaller: I used data-attrs for the tabs as you can see - figured i'd follow the same convention as with the mappings
<bcsaller> hatch: yes, I think that makes sense 
<bcsaller> I improved the styling, changed it to inline-block
<hatch> yeah I just hacked some inline css in there haha
<hatch> so next step is to add some inputs to see if we can get the updating to work
<bcsaller> hatch:  should work out of the box
<bcsaller> but I can change the template now
<hatch> sorry I meant with the units side
<bcsaller> hatch: chat?
<hatch> yup
<abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/hide-same-series/+merge/168167 ?
 * sinzui looks
<jcsackett> bcsaller: can you look at https://codereview.appspot.com/10119043/ ?
<abentley> orangesquad: could you please review https://code.launchpad.net/~abentley/charmworld/migrations-tests/+merge/168170 ?
<jcsackett> abentley: sure.
<sinzui> abentley, jcsackett sorry, it was r=me
<abentley> sinzui: No, that's a second branch that jcsackett agreed to review.
<sinzui> oh, sorry. nm
<jcsackett> abentley: r=me.
<abentley> jcsackett: Thanks.
<arosales> folks saw ubuntu.com today right :-)
<hatch> OOoooo look at that
<gary_poster> hah!  cool :-)
<hatch> gary_poster: is there a reason why we don't have units as part of a service model?
<hatch> just wondering if there was a big architectural reason I'm missing
<gary_poster> hatch, probably because that's how they are modeled in juju.  Probably also because it is a bit relational-db-like the way it is.  Maybe because there's no guarantee that we will hear about a service before we hear about one of its units?  Maybe there is a guarantee like that.... Anyway, it was a decision from before my time, but I don't have an argument against it.  Do you?  :-)
<hatch> I do! :)
<hatch> but I think I have a workaround
<gary_poster> heh
<gary_poster> ok
<hatch> just an issue we are running into with the bindings
<gary_poster> feel free to send an email or make a card
<hatch> yeah will wait to run my idea past ben when he gets back
<hatch> *I will
<gary_poster> cool
<bcsaller> jcsackett: it seems like you could just put that code on nsRouter.split and it should work, no? I assume you tried that and hit an issue?
<bcsaller> hatch: back, btw
<hatch> that was quick
<hatch> guichat?
<bcsaller> there
 * gary_poster running
<gary_poster> have a great weekend
<hatch> you too cya!
<jcsackett> bcsaller: it's more that .split is implicated in more places and i'm cautious about what i modify without any understanding of this code.
<BradCrittenden> ok, benji your sphinx checks have bitten me trying to propose my branch.  hope you're happy.  :)
<benji> heh
<hatch> bcsaller: the events object in the view container should probably be user defined
<hatch> or....do we want people to subclass view-container instead of init directly?
<hatch> events and       var viewletContainer = container.one('.viewlet-container'); should be user defined IMHO so that it can match the templates
<hatch> and view-container can then be a general use wrapper
<bcsaller> hatch: are events even used/needed here?
<hatch> well it's the view container which houses the navigation
<hatch> so we should really be subclassing the view-container
<hatch> which is probably overkill :)
<bcsaller> hatch: agreed, at this time I dont' see the need either. The controller should configure that layer I think
<hatch> ok so I should make the events object user configurable?
<hatch> and the viewlet-container element
<rick_h__> hatch: I'd think the container element should be ok to be hard coded. Provides consistancy and you can always drop in your own node inside of it. 
<rick_h__> hatch: nvm, I was reading that as the container itself, but you're talking about the node inside the container already
<hatch> :)
<bcsaller> hatch: it works and its pretty cool, pushing.
<hatch> awesome - I'm just finishing up my changes to view-container and it's tests
<bcsaller> all pushed
<bcsaller> you can watch the inspectors of multiple panels update the unit viewlets with the simulator running
<hatch> excellent - lp:~hatch/juju-gui/service_inspector was updated
<hatch> so you can pull those changes
<hatch> I think my simulator is broken
<hatch> oh nm there it goes
<hatch> right on
<hatch> :)
<hatch> this is pretty damn cool
<bcsaller> yeah
<bcsaller> like I want other people to see this already :)
<hatch> haha
 * hatch ships a bunch of redbul to UX
<bcsaller> ha
<hatch> excellent I'm glad that idea worked out
<bcsaller> yeah, I thought you meant creating them on the fly at first and I was opposed, but I keep them up to date in the delta stream
<bcsaller> extended process_delta to be able to handle this case
<bcsaller> I'd get rid of the global list now :)
<hatch> I wasn't sure if that was being used anywhere
<bcsaller> only to select the subset by service
<bcsaller> we need a close button on these inspectors 
<hatch> yup
<hatch> I can do that
<hatch> did you merge in my changes?
<bcsaller> yes
<hatch> ok I'll blow this branch out and pull down a new one
<hatch> and then add that
<bcsaller> you can just merge mine back in and keep going
<hatch> ahh ok that'll be faster
<bcsaller> yeah, just pushed again
<hatch> cool - this is going to take a few minutes
<hatch> then I'll write the tests for it
<hatch> almost done
<bcsaller> aggregated status is computed and doesn't fire a change event. might make sense to aggregate as status_error: {Number}, etc so the binding will work with it
<bcsaller> directly on the service as attrs I mean
<hatch> bcsaller: lp:~hatch/juju-gui/service_inspector
<hatch> close button - I am pretty sure I removed it from the collection object properly
<hatch> feel free to modify
<bcsaller> hatch: I think it will be ok, setPanel should clean up in the overwrite case so for now this might leave an inspector in the env view index w/o a DOM unless I'm not seeing something else you did 
<bcsaller> hatch: did you merge back my changes as well?
<bcsaller> hatch: I think next I'd like to make the overview viewlet interactive in the sense that it applies mutation. To do that I think it would be good to take the exposed toggle slider and embed it, see how well things handle that 
<hatch> I haven't merged your changes yet
<hatch> I modified the setInspector method to add a remove functionality
<hatch> did you see that?
<hatch> and modified the show_service method in topology/service.js
<hatch> "exposed toggle slider" ?
<bcsaller> hatch: yeah, found it later
<bcsaller> hatch: on the normal service view there is a toggle for exposed
<bcsaller> hatch: I think you can see it w/o the feature flag
<bcsaller> hatch: top right
<hatch> ohh right right
<hatch> so is there anything I should be doing right now wrt the panels or shall I keep on the docs?
<bcsaller> hatch: I think the docs are going to be very valuable 
#juju-gui 2014-06-02
<rick_h_> I've been trying to just ignore it tbh
<hatch> weather been good?
<huwshimi> hatch: Will do!
<hatch> huwshimi thanks!
<rick_h_> hatch: heh, it's been on/off. The bugs are the things that keep messing things up
<hatch> ahh yeah that's a real constant problem for us - at night it hums from the mosquitos 
<hatch> There must be a lot of campers to feed all of them
<hatch> :)
<hatch> huwshimi hey how goes the battle with the ui tokens?
<huwshimi> hatch: Not bad, should have a review ready today.
<huwshimi> hatch: Depends on how long your qa takes :)
<hatch> coolio - I'm interested in the technique you took
<hatch> haha, I'm hoping my QA doesn't take too long :)
<rogpeppe> mornin' all
<jcsackett> morning all (or afternoon).
<jcsackett> how goes the PR work?
<anthonydillon> jcsackett, I did, deleted all the in needed files and moved the humans.txt
<jcsackett> anthonydillon: hm, ok. lemme double check the PR.
<jcsackett> not a lot of coffee yet this morning, i probably misread the diffstat. :p
<anthonydillon> jcsackett, Mmmm let me check
<jcsackett> ok.
<redir> morning
<bac> redir: you survived NC?
<anthonydillon> jcsackett, Ah thats more like it. I have just removed all unused files
<redir> bac: I did.
<kadams54> guihelp: I think my current card may already be fixed; having a hard time reproducing it. "Ghost inspector remains once service has been deployed" - anyone know if this is still an issue?
<bac> hey redir, you have access to os x, right?  would you have time to do a code review/qa of quickstart on os x?
<redir> bac: I have one yes
<redir> I think it is mavericks even
<redir> but a few years old HW-wise
<redir> I can dig it out and do a review -- but it probably won't happen until after standup, bac.
<bac> redir: ok
<redir> which where do I need to look
<redir> quickstart on osx?
<hatch> bac I can also give it a go if you need another
<bac> redir: oh, sorry, i got distracted.  the RV is https://codereview.appspot.com/102870043
<bac> hatch: that'd be nice if redir cannot.  just need one.
<hatch> kadams54 the bug you're currently working on #1325466 is likely do to the topology service.js click handler not ignoring the second click - AIUI we no longer have a differnt action for double click vs single
<_mup_> Bug #1325466: Sidebar breaks with il flag after double click <juju-gui:In Progress by kadams54> <https://launchpad.net/bugs/1325466>
<kadams54> hatch: Good to know. It also looks like the GhostServiceInspector is not removing its DOM elements on destroy
<hatch> ahh it might need a `this.get('container').remove()` in the destructor
<hatch> I thought that was fixed already though
<hatch> maybe a bad merge removed it heh
<kadams54> I thought I fixed it as well, but may have only been for a non-ghost inspector.
<bac> redir: can you see rietveld's now?
<kadams54> hatch: the other card I have, "Ghost inspector remainsâ¦" I can't reproduce. Do you know if that's still a problem?
<hatch> umm I didn't see, one sec
<redir> bac I can see them without my canonical login I think
<redir> using personal one
<hatch> kadams54 Makyo fixed that one already
 * redir starts digging mac out from under a pile
<kadams54> hatch, Makyo: woot!
<hatch> heh, that card should have been removed....tisk tisk :P
<rick_h_> redir: PM
<redir> rick_h_: oui
<bac> redir: the RV i linked is wrong.  correcting.
<redir> bac: cool just got mac out and plugged in 
<redir> lemme get her up and running and have a look
<rick_h_> kadams54: I thnk that bug is fix committed not released as we've not done a release yet
<kadams54> Oops, yeah, will fix.
<bac> redir: actual RV at https://codereview.appspot.com/101980050
<bac> redir: prelim instructions at http://paste.ubuntu.com/7573466/
<redir> bac k
<redir> relurk -> instructions http://paste.ubuntu.com/7573466/ 
<redir> relurk: https://codereview.appspot.com/101980050 <- RV
<redir> bac me needs to install brew
<hatch> jujugui call in 10
<hatch> kanban now
<hatch> jujugui call now
<bac> kadams54: will you be live-blogging here?
<kadams54> Wasn't particularly planning on it - don't want to spam the channel :-)
<redir> bac is it known to not work without brew?
<hatch> kadams54 I just REALLY hope they don't make OSX look like IOS 
<kadams54> But if hatch's summary is wrong, I'll update :-)
<bac> redir: brew is required.  we're going to distribute as a brew package
<hatch> those 'leaks' look like garbage
<redir> bac oic
 * bac wants a new set of Beats made from a single block of aluminum
<bac> full disclosure: /me does not have beats.  does not want beats.
<hatch> bac lol!!
<redir> def linux people behind brew
<redir> brewing python
<redir> bac yt?
<bac> hola
<redir> so brewed python installed 
<redir> next it says running juju-quickstart
<redir> do I need to DL something or check something out?
<redir> clone?
<redir> ~bac/juju-quickstart/platform-settings-2
<redir> ?
<redir> brew installing bzr
<bac> redir: "next it says running jj-qs" -- what does that mean?
<bac> redir: wanna chat?
<relurk> sure
<redir> bac I mean sure
<bac> redir: paste link?
<redir> https://plus.google.com/hangouts/_/g3zrk7v2262aeqkfirmalgk2kma?authuser=3&hl=en
<kadams54> guihelp: https://github.com/juju/juju-gui/pull/357 is ready for review/QA.
<kadams54> hatch__: You know if anyone's looked at your il branch in a real env yet?
<hatch__> kadams54 I don't think they have
<redir> bac. done. argparse.SUPPRESS who knew...
 * redir lunches
<hatch> kadams54 are you trying it in a real env?
<kadams54> hatch: yup
<hatch> cool thanks, all good so far?
<hatch> nice I'm up to 18% of the tests passing
<hatch> lol
<kadams54> Well, having problems getting my real env setup againâ¦ so not making great progress yet.
 * rick_h_ *cough cough*ec2 azure hp cloud and canonistack are real envs that you can get for free or expense and  get around lxc issues *cough*
<kadams54> rick_h_: I'm actually trying to bootstrap my ec2
<kadams54> Using juju-quickstartâ¦
<rick_h_> kadams54: and having issues?
<kadams54> rick_h_: Not entirely sure. It seems to be taking much longer than I remember
<rick_h_> kadams54: well ec2 takes a while to bootstrap, 5-10min ish
<rick_h_> then the gui should be up in another 1-2min
<kadams54> OK, I probably just need to be more patient :-)
<rick_h_> it's the joy of lxc, but if lxc gives grief it's nice to have a backup
<hatch> sometimes ec2 hangs for no reason
<hatch> like it can't provision a machine
<hatch> it eventually will
<hatch> but I've had times where ec2 takes 20m to make a machine
<hatch> this is an ec2 issue not a juju one
<kadams54> Hah: OS X Weed
<kadams54> "oddly enough, this name had large pockets of support within the product marketing group"
 * rick_h_ bac howdy, got a sec?
<rick_h_> bah
<bac> bah?
<rick_h_> see pm
<kadams54> Next Safari will support Javascript Promises!
<kadams54> Who else is excited?
<kadams54> ;-)
<rick_h_> now let's just hope they're not A+ promises :) kadams54 
<hatch> 381 failures to go!
<bac> kadams54: ha, big red box next to AAPL in the stocks widget he just showed.
<hatch> Safari is becoming IE with their slow updates :)
<hatch> although it is by far the most battery efficient :)
<kadams54> hatch: not sure if you caught it, but the next Safari will run Netflix video natively, no Silverlight plugin. More battery savings.
<kadams54> But yeahâ¦ slow.
<kadams54> (with the updates)
<kadams54> Need to decouple browser updates from the OS
<hatch> kadams54 no I'm not watching - I don't care for the Apple hype conference - I'll catch the summary :)
<hatch> now if it was a Google hype conference.... WELL THEN
 * rogpeppe is done for the day
<hatch> that's a different story
<hatch> :P lol jk
<rogpeppe> g'night all
<hatch> rogpeppe have a good night
<hatch> oo the tests are refreshing the browser now
<hatch> fancy!
<redir> kadams54: natively being flash or html5+codec w/ DRM?
<kadams54> redir: HTML5 premium video extension
<redir> premium, sounds fishy
<redir> gourmet, deluxe, pro
<Makyo> hatch, I'm timeboxing this branch.  I'll make a card for updates to the overlay-indicator stuff to help make a smoother caching experience.
<kadams54> redir: premium = DRM
<redir> mmmm yes pay more for less that is a premium:)
<hatch> Makyo sure np
<hatch> kadams54 I really hope you can turn off that transparency they are showing in all the OSX windows
<kadams54> I'll reserve judgement until I actually use it.
<hatch> looks like they copied Alfred with their new search box
<hatch> and now added hangouts like support to it
<hatch> typical copy and call it new stuff here
<redir> kadams54: netflix is something I miss on linux
<hatch> good to see Apple keeping up the trend
<hatch> cloning all of the great stuff from Ubuntu and third party apps and calling it new and innovative 
<kadams54> Good to see hatch keeping the Apple tropes alive and well ;-)
<hatch> haha
<kadams54> Right now the interesting things look like iCloud Drive (Dropbox + iCloud) and Continuity. Not sure if there's anything quite like Continuity on the Android side.
<hatch> not sure - what is it?
<hatch> tldr (I just scrolled through a liveblog)
<kadams54> Integration across phone, ipad, and desktop
<hatch> you mean like google drive? dropbox?
<kadams54> No
<kadams54> You can take/make calls coming into your phone from your desktop
<hatch> ohh, like google voice
<kadams54> Your text messages are sync'd from your phone to your iPad and computer, so now it's not just iMessage users that you see across all three, but any messages.
<hatch> which doesn't work in Canada :(
<kadams54> I think it's a step beyond google voice
<hatch> kadams54 I bet that feature is VERY carrier specific
<hatch> it likely won't be coming to Canada
<kadams54> I don't think it has anything to do with the carrier
<hatch> well it has to get the sms messages from somewhere
<hatch> so it's reading all your sms's and uploading them to a server so it can distribute them
<kadams54> It's more that the phone is communicating over the network to the desktop or iPad
<kadams54> So the carrier is abstracted away.
<kadams54> The phone itself is the proxy
<hatch> ahh yeah there are apps for that on Android
<kadams54> ANd the desktop/iPad don't care about the carrier
<hatch> they just upload all your sms's to their server
<kadams54> I don't think that happens either
<hatch> well how else does it get from the phone to the desktop?
<kadams54> I suspect it's peer-to-peer
<hatch> I doubt it
<hatch> turn the computer on and then the phone uploads all of the sms's ?
<kadams54> They didn't really address what happens with the phone and desktop aren't on the same LAN
<hatch> my phone is almost never connected to my wifi
<bac> redir: can we chat re: the customer work you were doing before your vacation?
<hatch> so yeah
<hatch> my LTE Is faster than my home internet lol
<redir> bac sure
<bac> redir: daily-standup hangout
<redir> k
<kadams54> The problem with pushing SMS out to a server is privacy. In the few places where they are transmitting data out to a server, they've been very careful to address the question of privacy.
<kadams54> On the other hand, they didn't say anyhting like that when demo'ing the message sync'ing across devices.
<hatch> right, but without that server the awesomeness is really reduced
<kadams54> I'm skeptical
<kadams54> I suspect you're an edge case :-)
<kadams54> Most people have their phones on the lan with their other devices.
<kadams54> Continuity goes beyond just phone and message though - it's also workflow stuff
<hatch> why though? 
<kadams54> Because LAN > cell
<kadams54> Besides, I don't have to choose
<kadams54> If you start an e-mail message on your phone, your desktop knows what you're working on
<kadams54> And you can resume the e-mail on your desktop
<kadams54> Ditto for web browsing
<hatch> yeah that would be pretty cool 
<hatch> so they are basically packaging up applications and workflows that other platforms have into one name
<hatch> which I suppose would be nice
<hatch> hopefully they will provide an api for that
<kadams54> It's hard without knowing the tech details about how far and deep the integration goes - do they provide 3rd party APIs?
<hatch> :)
<kadams54> But that's the purpose of WWDC :-)
<hatch> you sure? All I'm seeing on these images is advertising 
<hatch> :P
<kadams54> My guess is that the newer techs, like Continuity, won't
<kadams54> Not until next year
<kadams54> Apple likes to get real world experience before bringing out a 3rd party API
<kadams54> hatch: not during the keynote. The sessions afterwards :-)
<kadams54> https://developer.apple.com/wwdc/schedule/
<hatch> oh I thought the wwdc was this keynote
<hatch> lol
<hatch> ugh I have to log into their walled garden just to see the schedule...sheesh
<hatch> oh most of the sessions are about new stuff that's not released yet
<hatch> I was like 'wtf no titles?'
<hatch> haha
<kadams54> Yeah, not many conferences have sessions that are only revealed *after* the keynote :-)
<hatch> well they have to keep their NEW....umm.....infinite search app store listings SECRET
<hatch> lol
<hatch> Makyo can you plz make a card for the follow-ups so we can easily see what's blocking the il release
<Makyo> Yep, on it now.
<hatch> thank yas
<hatch> kadams54 do you use the touchid?
<kadams54> all the time
<hatch> everyone I know doesn't - they use the pin pad, claim the pin pad is faster
<hatch> true?
<kadams54> Absolute malarkey
<hatch> yeah? Like I'm not kidding, the 4 people i know who use iphones do not use it
<hatch> they say its a couple seconds to unlock with it, so the pin is faster
<kadams54> It's possible individual mileage varies, but I'm skeptical they gave it any serious usage
<hatch> that's possible
<kadams54> Most of the time it's maybe a tenth of a second
<hatch> yeah that seems odd then that all 4 don't use it
<hatch> haha
<hatch> maybe they were doing it wrong
<hatch> lol
<hatch> one taught the others incorrectly
<kadams54> There's a rare occasion where it takes longer, usually when I don't use my primary finger or have the finger at an odd angle
<kadams54> That happens maybe once a week
<kadams54> Which I suspect is very small percentage of the numerous times I unlock the phone during the day
<kadams54> I setup the max number of fingers it allows
<kadams54> Which helps make it more useful
<hatch> the middle finger?
<hatch> :D
<kadams54> :-)
<hatch> I'm just happy that OpenGL is now in Safari
<kadams54> I'm skeptical that the problem is learning how to use it incorrectly, mostly because it's very easy to use.
<hatch> Safari has bleeding fast JS so hoping the OpenGL stuff is equally as fast
<hatch> maybe they have all set up the fingers wrong or something
<kadams54> I suspect the problem is more that most geeks are inherently skeptical of fingerprint users, so it ends up being a self-fulfilling prophecy
<kadams54> One bad experience and it confirms all pre-conceived notions, so they're back to the pin
<hatch> haha true
<hatch> my favourite is still the swipey pattern unlock
<hatch> some people take it overboard though
<kadams54> Here's how fast TouchID usually works for me
<kadams54> I just push the home button
<kadams54> And in the time it takes me to complete the push, my fingerprint is read and recognized
<hatch> yeah that would be awesome
<kadams54> So I unlock my phone and pop out of the current app back to the home screen in one click
<kadams54> Hmm. Apple's announcing a new programming language. "Objective-C without the C." Called "Swift".
<hatch> It's just Objective now
<hatch> lol
<kadams54> Swift seems like a mashup of Python/Ruby-esque syntax with Go's native compilation.
<kadams54> + all of the iOS/OSX libraries, of course
<hatch> Makyo rofl I just posted the same thing you retweeted
<hatch> haha
<Makyo> hatch, which? :D
<hatch> https://twitter.com/FromAnEgg/status/473537267764457472
<Makyo> Hahaha
<Makyo> Watching my twitter feed have a meltdown on that, currently.
<redir> a new  programming language
<redir> heh
<Makyo> Also liking http://live.gizmodo.com/our-wwdc-liveblog-starts-monday-june-2nd-at-12pm-et-1-1582090802 "Some other swifts you may care about"
<hatch> like seriously....ANOTHER language
<hatch> there wasn't a SINGLE language currently available that would have worked
<Makyo> We just need a catchy Go+iOS mashup word.
<Makyo> iGo, I guess.
<hatch> nah Swift has Generics
<hatch> it's Modern....bahahaha
<Makyo> Last retweet for you, hatch :D
<hatch> haha
<redir> swiftfiddle
<Makyo> Hahah
<redir> but it is all clang/llvm loving
<redir> they've prolly been working on it for a long time too
<Makyo> I've yet to dig into all that.  I got QTimeLapse to build on OS X, but haven't done any real coding outside of python on the thing.
<hatch> redir from golang ""We also considered using LLVM for gc but we felt it was too large and slow to meet our performance goals.""
<hatch> :D
<redir> hatch: their needs are pretty different than a systems language
<redir> s/than a/as a
<hatch> yeah - they needed something pretty 
<Makyo> "Cook stressing that Apple engineers platforms, devices, and services together in a way that others (*cough* android *cough*) can't." What about US?!
<redir> Makyo: US?
<hatch> Makyo we use all our energy to innovate, then they just copy and repackage
<Makyo> us, sorry,.
<redir> juju-gui?
<Makyo> Canonical, not U.S.
<hatch> we being everyone not apple
<redir> ahh
<Makyo> Since we've been touting convergent design for a while now.
<redir> I can't buy an ubuntu tablet or phone yet
<Makyo> Well, not OEM, no.
<Makyo> But I've got an Ubuntu Nexus 10 right here.
<redir> for that matter the preinstalled linux laptop experience isn't great either
<redir> Makyo: exactly
<Makyo> Works fantastic on the S76, but I've not played with much else OEM.
<redir> I give apple credit for this
<hatch> hahaha I just added #swift to Tweeddeck I've never seen a column move so fast
<redir> I no longer provide 8 hours a week tech support to my family.
<redir> ubuntu can't reproduce that yet.
<hatch> redir my family uses Windows....I also don't provide tech support :D
<redir> I prefer it... but I couldn't point my fam at it
<hatch> tbh I want to put them on Ubuntu but none of the software runs on Ubuntu
<Makyo> Different markets will always be a thing :P
<redir> right
<Makyo> Dad uses windows because he has to use autocad, mom uses an iPhone because she bought my old one then upgraded.
<Makyo> Don't think she has a computer anymore.
<hatch> haha 
<hatch> it's getting close to that with mine too
<Makyo> She finally moved across state borders, and with that got rid of a ton of stuff.  She borrows her boyfriend's computer for Quicken, and that's it.
<hatch> I recently looked at quickbooks to see if they had a web version....they do...but serious $ and no mention of what happens with your data when you stop paying
<Makyo> Yep.
<Makyo> I just use paper.
<Makyo> And file with turbotax online.
<Makyo> But I'm simple. 
<Makyo> Er...my usecase is simple.
<Makyo> But also, I'm simple.
<hatch> it would be really nice if there was a quickbooks online which only charged for filing
<hatch> so you enter all your bills etc then pay $50 or whatever to file it
<Makyo> That's rather like TurboTax online.
<hatch> yeah - but turbotax doesn't do expenses and stuff does it?
<hatch> it's been a while, honestly
<hatch> lol the website for the language Swift from Apache is down
<hatch> they probably took it down
<hatch> :)
<hatch> that's going to cause some issues when searching
<Makyo> They have an additional service for that.  I used to use Mint, until I realized that even that was too much for me.
<hatch> Makyo https://twitter.com/RinHugs/status/473540713062596608 hehe
<hatch> ahh we all think we r so smart
<Makyo> Yeah :)
<hatch> I really hope that Google unveils golang support for android at IO
<hatch> would be quite comical 
<redir> Society for Worldwide Interbank Financial Telecommunication (SWIFT)
<redir> apparently one could have 41 years of swift experience
<hatch> oooo
<hatch> ugh these tests!!!!
<hatch> these tests!!!
<hatch> rick_h_ you're probably not here but I am running into the same darn simulate bug :/
<hatch> (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<kadams54> guihelp: anyone available to review/QA https://github.com/juju/juju-gui/pull/357 ?
<kadams54> Also: I know I've done this one other time, but how do I get my EC2 instance running a specific build of juju-gui (i.e., hatch's branch)?
<hatch> kadams54 `s
<hatch> bla
<hatch> `juju set juju-gui juju-gui-source="path-to-source"`
<hatch> and then you wait
<hatch> kadams54 that of course assumes you named your service juju-gui
<kadams54> thanks
<kadams54> hatch: haven't noticed any problems yet playing around with your branch
<hatch> awesome
<hatch> I'm still fighting tests
<hatch> I may have one figured out
<hatch> the one that's plagued all three of us
<hatch> the simulate() causing a "script error"
<hatch> victory!
<rick_h_> hatch: :( have to narrow it down. I had too big a diff to figure it out
<hatch> rick_h_ I got it
<rick_h_> hatch: cool
<hatch> the simulate() was trapping the real error
<hatch> so I stepped through......EVERYTHING
<hatch> turns out the inspector rendering code didn't have a node to render to
<hatch> ....
<hatch> trivial one line fix
<hatch> days of debugging wasted to find it lol
<rick_h_> ugh
<rick_h_> so you updated the inspector to throw a giant fit if it didn't have acontainer to render into?
<hatch> rick_h_ it wouldn't have helped - the simulate() captured everything
<hatch> throw + mocha + chai === issues
<hatch> throw + mocha + chai + simulate === issues
<hatch> I mean :)
<rick_h_> ugh and ugh, it can at least console.log?
<rick_h_> or pre-check for the container?
<rick_h_> there must be some way to not get caught in that again?
<hatch> oh it can console log
<hatch> I'll do that
<rick_h_> console.error 
<hatch> done
<rick_h_> ty
<hatch> I'm really trying to get all these tests done because the qa's are going well
<hatch> so hopefully I can get it landed first thing tomorrow
<huwshimi> Morning
<huwshimi> hatch: If you're available for some questions sometime let me know.
<hatch> huwshimi sure
<hatch> shoot
<huwshimi> hatch: We seem to have broken a bunch of code somehow. In the machine view we do something like machine = env.addMachines(...) and then we do env.placeUnit(unit, machine.id), however with the changes being stored in the ecs the machine.id in that case no longer exists.
<huwshimi> hatch: So our unit placing code on drop etc. no longer works
<hatch> huwshimi well the code to create the UI was removed because it was very broken
<hatch> or do you mean the drop doesn't work at-all?
<huwshimi> hatch: Well, we can't placeUnit on a newly created machine/container as we don't have an id to place to until after the machine/container has been deployed.
<huwshimi> hatch: At the moment our code is doing env.placeUnit(unit, undefined)
<hatch> lets have a hangout
<huwshimi> ok :)
<hatch> https://plus.google.com/hangouts/_/g47b4s6lnwuixacn75z4hx7ic4a?hl=en
#juju-gui 2014-06-03
<hatch> huwshimi rockin huge diff on that branch :D
<huwshimi> hatch: I panicked for a second there, I wondered what I'd broken :)
<hatch> haha
<hatch> it's been +1'd
<huwshimi> thanks
<huwshimi> I hope the tests pass.
<hatch> haha - if they don't then it'll fail on the merge
<frankban> morning rogpeppe: are we in the middle of the git migration?
<rogpeppe> frankban: i'm guessing so
<rogpeppe> frankban: i haven't seen much activity recently tho
<rogpeppe> frankban: well, go get github.com/juju/core/... works, so i guess it's all go
<frankban> rogpeppe: yeah I see they are probably fixing some remaining bits (lbox stuff etc) I guess a message will be sent when the migration is done
<rogpeppe> frankban: i'm going to submit PRs anyway :-)
<frankban> rogpeppe: :-) I am trying to figure out our next steps
<rogpeppe> frankban: me too
<frankban> rogpeppe: I ended up with this schema: http://pastebin.ubuntu.com/7579583/ do you want to chat about next moves?
<rogpeppe> frankban: i can't quite see why utils/ssh is factoring in there
<frankban> rogpeppe: I think it's ssh.ParseAuthorisedKey in testing/environ.go
<rogpeppe> frankban: but we don't need anything that's in that file, do we?
<frankban> rogpeppe: FakeHomeSuite
<frankban> rogpeppe: unless we decide to replace that with something else. my schema just reflects the current status
<rogpeppe> frankban: i don't think FakeHomeSuite uses FakeAuthKeys or FakeConfig, does it?
<frankban> rogpeppe: charm uses testing.CustomEnvironConfig, which in turn calls FakeConfig(). however, it seems in that file ssh is only used for a check done in init(). perhaps that can be removed and we just assume FakeAuthKeys to be valid
<rogpeppe> frankban: i think we could make charm avoid using CustomEnvironConfig
<frankban> rogpeppe: that would be great
<rogpeppe> frankban: just going for lunch. i may be in patchy contact this afternoon - will let you know when i am online
<frankban> rogpeppe: ok hanks, I'll try to extract some action items from that document, I'll send you an email later
<frankban> thanks even
<frankban> rogpeppe: for when you are back: here is a lst of actions we can work on in parallel, please let me know what do you think: http://pastebin.ubuntu.com/7579844/
<rogpeppe> frankban: that all looks good
<kadams54> guihelp: still looking for review/QA on https://github.com/juju/juju-gui/pull/357
<frankban> kadams54: looking
<kadams54> Thanks!
<jcsackett> morning (or afternoon), all.
<frankban> kadams54: LGTM
<frankban> morning jcsackett 
<kadams54> frankban: Super. Another one bites the dust.
<kadams54> morning jcsackett 
 * redir broke unity
<jcsackett> i break unity with some regularity.
<rogpeppe1> frankban: am online for 30 mins now, then away for an hour, then back again for 3 hours (working a bit later to make up for breaks)
<frankban> rogpeppe1: ack
<rogpeppe1> frankban: do you want to make sure that there are tasks for those things on the kanban that you mentioned?
<frankban> rogpeppe1: I'll create cards for each item
<rogpeppe1> frankban: there are already cards for some
<frankban> rogpeppe1: ok
<rogpeppe1> frankban: e.g. "migrate juju utils package"
<rogpeppe1> frankban: what are you on now? i will get on with something other than that :-)
<frankban> rogpeppe1: I'd start with filetesting, not sure if we can start working on the github project yet, asking
<rogpeppe1> frankban: ok, if you create filetesting in github/juju/testing, then try a PR against github/juju/core...
<rogpeppe1> frankban: it looks like CI is going, and everything seems like it's working, so might as well give it a go
<frankban> rogpeppe1: I'll try to move the testing package preserving the git history. This means I will use the git commits in github.com/juju/core as a base, that's why I asked on the channel if the project is ready to be used
<rogpeppe1> frankban: ah, i see
<rogpeppe1> frankban: what's the procedure for doing that?
<frankban> rogpeppe1: wait looking
<rogpeppe1> frankban: (i haven't done that when moving other pieces to github/juju)
<frankban> rogpeppe1: well, for small pieces I am not sure it's worth the effort, but when migrating a whole package/subdir then it's nice to preserve the history, and should also be easy enough
<rogpeppe1> frankban: right; i have no idea how to do that - i presume there's a tool to help, or do i have to do it manually?
<frankban> rogpeppe1: I guess "git filter-branch --subdirectory-filter $folder -- --all" should do the trick
 * rogpeppe1 reads up on filter-branch
<frankban> rogpeppe1: and then, for importing the tree into testing, something like "git subtree add --prefix=filetesting $branch master"
<frankban> rogpeppe1: see #juju-dev, we need to wait
<bac> hey jcastro, i may be doing a barcamp talk tonight.  you have a favorite bundle for doing demos to a group of people who've never heard of juju?
<jcastro> bac, other than the simple wordpress ones? 
<bac> jcastro: those would probably work.
<jcastro> I like mediawiki:scalable
<jcastro> complex enough to get the point across, but not too complex
<jcastro> https://jujucharms.com/sidebar/search/bundle/~charmers/mediawiki-scalable/8/mediawiki-scalable/?text=mediawiki-scalable
 * rogpeppe1 leaves. back in an hour.
<bac> thanks jcastro
<kadams54> guihelp: currently looking at the "adding unit to undeployed service and clicking machine view gets you 'stuck' in machine view" card and not seeing the same behavior. My guess is that I'm just not going through the right steps to duplicate.
<kadams54> Anyone know more details?
<hatch> frankban thanks for trying that bug - did you fix the machine to machine.id first?
<frankban> hatch: no, I didn't see the initial error
<kadams54> hatch: getting selenium timeouts in my merge build. Should I retry, or does jenkins/selenium need to be kicked first? http://ci.jujugui.org:8080/job/juju-gui-merge/367/console
<hatch> frankban oh ok, sorry I wasn't clear - that needs to be done 'machine' is a string so 'machine.id' is always undefined so it will always place a new machine
<hatch> I'll update the bug
<hatch> kadams54 you can re-run it in jenkins
<frankban> hatch: I'll take another look with the bug and dupe instructions updated
<kadams54> hatch: do I re-run by deleting the comments on the PR?
<hatch> frankban thanks!
<hatch> kadams54 no you log into jenkins and re-run it manually
<hatch> do you know your jenkins account info?
<kadams54> Yeah
<kadams54> I thought that was the case for builds on the PR branch, but not for merge/shipit builds.
<hatch> merge builds you can just delete the comment which says that the merge has been accepted
<kadams54> Ah yes, OKâ¦
<frankban> hatch: so machine in that code is not a model instance, it's just an ecs record key... 
<hatch> frankban correct
<frankban> hatch: what placeholder name do we give to new ghost machines?
<Makyo> jujugui call in 10
<hatch> well I figured we should use the record id's
<frankban> hatch: _createMachine does not create a ghost machine and just passes null as modelId: that does not seem correct
<frankban> hatch: we should create a ghost machine in the db (e.g. by using an incremental placeholder name, like new1, new2 etc...) and pass the id to both addMachines and placeUnit
<frankban> hatch: then, when everything is committed, ecs code already handles replacing the placeholder name with the real one returned by juju-core IIRC
<frankban> rogpeppe: cards created/updated
<rogpeppe> frankban: cool, ta
<rogpeppe> frankban: one thing wasn't clear to me about migrating history: how do you get the commits out of the bzr commit format and into git commit format?
<hatch> frankban lets chat after the standup
<frankban> rogpeppe: FWIW, while waiting for the migration to be completed, we could start working on 1) moving FakeHomeSuite and 2) moving testing/http.go
<frankban> hatch: cool
<rogpeppe> frankban: i think the biggest part of this work is creating the stuff in github/juju/testing. changing juju-core to use the new location should be quicker and easier.
<frankban> rogpeppe: if the migration is done today then we don't have to do that, because we use the git repository.
<rogpeppe> frankban: i don't quite get that. surely we still need to move testing/http.go, because we don't want circular repo deps?
<hatch> jujugui call in 1
<frankban> rogpeppe: let's talk after the daily standup
<bac> redir: that guy working on private charmworld seems to happy, fwiw
<redir> bac: nice:)
<bac> i blue myself
<redir> uh, yeah
<bac> http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCQQyCkwAA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DaxHe_BVY_9c%26feature%3Dkp&ei=0OSNU_ilF6fJsASh-4GIAw&usg=AFQjCNFOnonlQH_qGbp2nJ7-hPjvffx73g&sig2=f0q5Q1iPJJnsMWkBOvB-Yg&bvm=bv.68191837,d.cWc
<redir> blue team
<bac> nice, url, google
<bac> jujugui: sorry, i said "i sat in on the HR presentation.  only took 30 minutes. "
<rogpeppe> frankban: are you still busy?
<frankban> rogpeppe: done now
<frankban> rogpeppe: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<kadams54> hatch: let me know when you get a chance to look at the "stuck in machine view" card. I'm also looking for more workâ¦ maybe getting started on the document Luca and Spencer created, turning those into cards/bugs?
<hatch> kadams54 looking
<hatch> kadams54 I am pretty sure that issue was the UI equivalent to this bug https://bugs.launchpad.net/juju-gui/+bug/1319549
<hatch> kadams54 so maybe if you could try and dupe this in the UI if not, comment on this bug that it's not reproducible in the UI
<hatch> and that can be this card
<hatch> I haven't had a chance to look at the list from UX but I want to be careful that any changes there don't push the release back or cause conflicts for my branch
<kadams54> hatch: Sure. First step would be to get the items in the doc turned into bugs and cards. No code changes.
<kadams54> hatch: I don't think this card is about Chrome freezing. I remember we both had that problem. The way I read this card is that the tabs to switch between Service and Machine Views stop working. (Which has also happened to me in the past.)
<kadams54> But I'll investigate https://bugs.launchpad.net/juju-gui/+bug/1319549 nonetheless.
<hatch> kadams54 yeah I remember that - but when the tabs stopped working the whole UI was locked - I don't remember if refreshing worked though...
<kadams54> No, refreshing did not work
<kadams54> It wasn't just the Chrome tab, but all of Chrome
<kadams54> I had to kill -9 it when that happened.
<kadams54> It was bad.
<hatch> ahh right right
<kadams54> But I've also seen where the tabs stop working - I can still do stuff in MV, just can't get out of it. Usually due to an uncaught exception.
<hatch> hmm yeah I also remember that
<hatch> I cannot remember how to reproduce - I created a friday card about cards which are incomplete
 * redir may have to put the a/c units in the windoes
<redir> real soon now
<hatch> redir what? They aren't built into the wall?
<redir> hatch: bwahaha
<redir> not in buildings from the 19th century
<hatch> lol serious - all condo's and apartments here have them cut in the wall
<hatch> ahh maybe they don't want to cut into old buildings
<hatch> :)
<redir> hatch: yeah, historic area
 * hatch hands you a saw
<hatch> git-r-dun! 
<redir> hatch: brick buildings.
 * hatch hands you a brick saw
<redir> heh
<redir> going to 30 today
<hatch> yikes - I've had the AC on for a bit now - but it only turns on during the afternoon still 
<hatch> my limit is about 25C
<hatch> any hotter and I dig a hole in the garden and lay in it
<kadams54> It's an almost perfect 23C here
<kadams54> With a breeze
<kadams54> Too bad the mosquitoes are TERRIBLE!
<hatch> frankban card created in Project 1 fyi
<hatch> kadams54 ahh nice, we are 19 now which is about perfect. very few biting bugs still, the flies are out in force though
<hatch> kadams54 do they spray for mosquitos there?
<kadams54> I don't believe so, no.
<kadams54> We've had some heavy rains recently and it seems like they really came out in force afterwards.
<hatch> darn - they do it here - we have a bunch of standing water in the ditches and stuff
<hatch> I -think- it helps
<hatch> ahh yeah I bet
<kadams54> We're going to bomb the yard
<hatch> youtube it!!!!
<kadams54> I don't think it's going to be that dramatic ;-)
<frankban> hatch: thanks
<hatch> kadams54 then you're not using enough explosive! 
<hatch> ugh the poplars are seeding
<hatch> bloody white fluffs everywhere
<hatch> they are nice big trees but boy do they make a mess
<hatch> pretty much the worst in-yard tree anyone could plant haha
<hatch> kadams54 thanks for doing the review and qa on Huw's branch - if he can land it after making your changes you can ":+1: with above mentioned changes" or something along those lines
<kadams54> OK, updated my comment to clarify
<hatch> working across timezones can be challenging sometimes :)
<kadams54> hatch: Commented on https://bugs.launchpad.net/juju-gui/+bug/1319549 - I can't reproduce in develop using the console commands.
<kadams54> I'm tempted to remove my current card - we can always add it back in if needed.
<hatch> kadams54 thanks, and yeah I agree
<rogpeppe> frankban: https://github.com/juju/testing/pull/9
<frankban> rogpeppe: looking
<rogpeppe> frankban: i haven't changed one byte :-)
<frankban> rogpeppe: :-) LGTM
<rogpeppe> frankban: thanks
<hatch> kadams54 have you found something to do?
<kadams54> Yes.
<kadams54> Eat lunch
<redir> rogpeppe: given a current clone of juju-core + godeps -u ... should the full test suite be passing?
<kadams54> hatch: But that's wrapping up :-) Got any suggestions? If not, I'll work on going through the feedback from Luca and Spencer.
<rogpeppe> redir: i think so, but it's always a bit fragile. what's failing for you?
<redir> rogpeppe: a bunch, but hard to tell there is no summary
<redir> dumping into a file for review
<rogpeppe> redir: could you paste the full output?>
<hatch> kadams54 yeah that might be best - there are other cards but I really want to get my branch landed first
<redir> rogpeppe: yes
<redir> rogpeppe: not so bad without all the logs. summary: http://paste.ubuntu.com/7581747/
<redir> http://paste.ubuntu.com/7581756/
<redir> full output ^^
<redir> I like the jujubot avatar
<rogpeppe> redir: hmm, i don't recognise those failures
<redir> boo
<rogpeppe> redir: i have to stop for the day, but one thing to look into: are you using the right mongod?
<redir> rogpeppe: prolly n ot
<hatch> yuss I found some cascading failures
<redir> but I think I have the charmworld one today
<hatch> I can get to 50% now without a failure lol
<rogpeppe> redir: some folks on #juju-dev should be able to help
<redir> hatch: *applause*
<rogpeppe> g'night all
<redir> rogpeppe: k tx. have a great eve
<hatch> kadams54 maybe you could also give Makyo a hand with his CSS issues (if they still exist)
<Makyo> hatch, kadams54 it appears to be a thing with the sticky headers taking a bit to generate, not what I'd thought.
<kadams54> ok
<Makyo> It allocates space for them, then generates them at the end of loading.
<hatch> down to 107 failures *sigh*
<bac> jujugui: anyone have access to safari to do a quick test?
<hatch> bac yep
<bac> cool, hatch, can you try connecting to my juju-gui at https://ec2-107-22-137-117.compute-1.amazonaws.com/ with safari?
<hatch> bac ok I get the ssl warning
<bac> hatch: i get 'connecting to the juju environment' but it hangs there
<bac> ssl warning or certificate warning?
<hatch> yeah this is a known bug
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1322596
<bac> thanks hatch, hadn't seen that bug.
<hatch> now you have :)
<bac> well, in that case, juju-quickstart on os x is now working.  whee!
<hatch> yippeee
<bac> must be packaged
<bac> hatch: you still using atom at all?
<hatch> bac nope back to sublime
<hatch> I probably won't switch from sublime to anything for quite a while
 * redir applauds
<redir> and you wrote it swiftly in swift!
<hatch> lol what
 * hatch thinks redir is drunk
<redir> lolwut
<redir> redir wishes
<redir> more just trying to do stuff but can't blame in bzr in sublime 
 * redir means praise or annotate
<hatch> haha, I mean why are you applauding me for using sublime?
<redir> hatch: juju quickstart on osx
 * redir applauds bac for juju-quickstat on osx, hatch
 * redir backs up GOPATH and starts fresh...
<hatch> :)
<bac> redir: thanks.  how about a review and qa?
<redir> à² _à² 
<redir> bac: OK
<redir> need to get the mac back out
<redir> moved it to put the AC in
 * redir now sees his notebook cpu at 48C instead of 78C
<hatch> haha that's probably for the best
<bac> redir: i'm doing QA on linux to ensure i didn't mess up there.
<bac> redir: will bug you shortly
<redir> k
<Makyo> Man, another stupid branch with a one-line fix.  I guess it's good that we had all these useful methods in there, just need to know where to use them.
<Makyo> jujugui little tiny PR https://github.com/juju/juju-gui/pull/361
<hatch> Makyo that's not guna work :(
<hatch> the reason is that we dont' want to re-render the whole sectionA every time the state changes
<hatch> we only want to do that when the component changes 
<hatch> I've commented in kind in the PR
<Makyo> Fuck.
<Makyo> This state thing is an enormous mess.
<hatch> sorry - I can take another look at it, I think I am on my final test (which of course is causing huge issues)
<hatch> just need to grab some food first
<Makyo> We switch everything over to views, then decide we can't treat them like views.  We need to destroy what's there in order to render what needs to be there, but somehow need to do it without destroying what's there?
<Makyo> I worked through lunch too, I'm gonna take a break.  We can talk after.
<hatch> sure, ping when you're back
<bac> redir: https://codereview.appspot.com/105810043 por favor
<redir> k
<Makyo> hatch, alright, fed and calmer.  Sorry for the outburst.
<hatch> tis O K :)
<redir> Mayko channel the  stateless whisperer
<redir> roy would be proud
<Makyo> So, the problem is that changeState doesn't clean up the inspector or the charmbrowser when the state changes.  All emptySectionA does is clean up lingering inspectors and charmbrowsers.  We need to be able to either destroy, or have the subapp be able to clean up without destroying.
<Makyo> Right now, the state code and its events take approximately 750ms to change state.  Rendering is fast, sticky headers are quick, and the spinner is negligible.  In all, it winds up being about 780ms.
<hatch> wow, why does it take so long?
<hatch> it should be damn near instant
<Makyo> It's either state or navigate that's being such a drag.
<hatch> ok that's definitely not acceptable because with everything running through state for user interactions it needs to feel instant
<Makyo> But either way, the inspector/charmbrowser needs to be cleaned up on navigate.  The spacing is caused by lingering elements.
<Makyo> Let me prefix everything with timestamps and I can get back to you.
<hatch> when it switches components it should be calling the empty bit
<hatch> oh great databinding doesn't work on the il flag for the unit details
<redir> cloning juju with git from gh is so way faster than bzr from lp
<hatch> redir are the repos the same size?
<hatch> I have mixed experience with github and network speed
<redir> well it is juju from today in both
<Makyo> hatch, it's looking like navigate, not state.  Almost a full second to get through navigating.
<hatch> hmm ok so...
<hatch> hmm
<redir> hatch: roughly 19700 commits 
<redir> bot thso ...
<hatch> Makyo ok so we need to track that down I guess
<hatch> it has to be something from pretty recently
<hatch> it didn't used to do that
<Makyo> It did, it was just hidden by the fact that we didn't cache anything.
<hatch> I mean before the switch over
<Makyo> To il?
<hatch> yeah
<hatch> I wonder if our navigate modifications don't mesh with the state stuff
<Makyo> Because that time difference was clicking the home button from a search, not dismissing the inspector.  Can poke around, though.
<redir> s/bot thso/both so
<hatch> Makyo right but I think that the same delay happens when switching between ghost and service inspectors too
<Makyo> Okay.  Hmm. Maybe in the ns-routing-app-ext?
<Makyo> Conflicting with state, I mean
<hatch> yeah that's what I mean
<Makyo> Okay, I'll dig in there.
<hatch> I'm fairly close to getting this monstrosity of a branch up for PR then I can lend a hand
<hatch> Makyo when you navigate around the charmbrowser and the url changes, does it change really fast, THEN hang?
<Makyo> hatch, I put console loggers in and everything's twice as fast.  It's my new solution.
<hatch> rofl
<Makyo> URL changes quickly, then it slows down, seems to be between either _navigate and _dispatch in ns-routing or _cleanup and _loadCurated in charmbrowser
<Makyo> But seriously, I'm getting half the times I was before, to the point where it looks almost fixed.
<Makyo> I'll keep digging, the sticky headers are definitely part of the problem, almost 100 ms
<Makyo> hatch, here's the times I'm looking at https://gist.github.com/makyo/0cf154d2d9996de7d45b
<hatch> ahh so maybe because we aren't emptying out the token list soon enough before it calls _loadCurated
<hatch> there is a _cleanUp method in there
<hatch> maybe it can be purposed to fix that up
<hatch> (almost PR'ing)
<Makyo> Yeah, I'm poking around.
<Makyo> Let me know when you're ready, I owe you a review.
<hatch> Makyo you mean this 1900 line one? https://github.com/juju/juju-gui/pull/362
<hatch> :)
<hatch> Makyo maybe we get this one landed and then work from it?
<hatch> then we are working with more 'final' type code
<Makyo> Yeah, totally.  I'd rather rebase than not.
<Makyo> Or just start over and trash this branch of mine
<hatch> we probably should have done state and then il
<hatch> merging them was a bad idea it's looking like
<hatch> live and learn I suppose :)
<hatch> kadams54 I re-sorted your new cards - cards after the il green card are required for relase
<Makyo> Yeah.  Two flags is a good limit, but each flag could have been more limited in scope.  State, then il.  ECS, then mv.
<hatch> if you disagree with any of my moves feel free to lemme know
<hatch> Makyo yeah good point
<hatch> I suppose I'll create a card friday to discuss how we got here and what we can do in the future to make sure it doesn't happen again
<hatch> it took almost 3 full days to remove the il flag haha, that's no good :)
<redir> bac: LGTM
<bac> thanks redir
<rick_h_> feature flags always seem to take a bit. We've had a few chats on trying to help with that but I don't think we did all the stuff we've mentinoed
<rick_h_> mentioned
<hatch> rick_h_ wb
<hatch> :)
<rick_h_> :P
<hatch> I created a friday card - just so we can spitball some ideas 
<rick_h_> coolio
<hatch> while it's still fresh
 * rick_h_ loads up leankit for the first time
<rick_h_> hatch: why do flags need to be more than 2 char? it's always flags.il ?
<hatch> rick_h_ there were instances (albeit not many) where grepping flags.il wasn't enough
<hatch> as in, flags: { il: ...
<hatch> very hard to find
<hatch> it never should have passed review...but things happen
<rick_h_> then il:  didn't work out? 
<rick_h_> yea, I guess when I suggested it I was thinking it'd be flags.il and easy to spot
<hatch> il : 
<hatch> that did
<hatch> :)
<hatch> but yeah I figured that because the urls are often 'cached' we could stand to use more grep-able ones and not lose much on the typing
<hatch> this isn't exactly a problem, but did waste time which could have been avoided if it was something wako like 'ispl' or something easy to grep for 
<hatch> rick_h_ mv is probably not going to be as much of an issue because m and v aren't usually beside each other in English, whereas il....well....heh
<rick_h_> yea
<rick_h_> gotcha
<hatch> Makyo are you reviewing/qaing that branch? 
<hatch> the il one
<Makyo> hatch, yeah
<hatch> ok cool
<hatch> thx
<hatch> I'm not looking forward to the databinding bug
<Makyo> -1513!  I like it.
<hatch> Makyo there is probably at least another 1000 in there which are left in but not used 
<rick_h_> hatch: which databinding bug?
<hatch> :)
<hatch> rick_h_ somewhere in the il work, databinding stopped working for the unit details breakout panel
<hatch> I'm guessing it has something to do when it got moved to the right.....but yeah....it's broken
<hatch> can we switch to react yet? kehehe (kick a man when he's down)
<Makyo> Fired...you are...no job.  Anymore.
<Makyo> hatch, going to walk dogs, I'm getting stomped.  Promise I'm reviewing.
<hatch> :) np take your time
<hatch> these past few days have not been enjoyable
<rick_h_> bac: can you link that bug and fix to hazmat in case he's interested please? 
 * rick_h_ goes back to vacation mode uploading tons of pictures
<rick_h_> new camera means lots and lots of pics
<hatch> Makyo I just updated the PR with another commit so if you had pulled it down and were QA'ing you'll want to pull again
<Makyo> hatch, alright, thanks
<Makyo> rick_h_, awesome
<Makyo> hatch, QA looks good.  Good to get rid of all that code.
<hatch> yay!
<hatch> and CI passed
<hatch> Makyo so can i land it?
<Makyo> hatch, crap, yeah, sorry!
<Makyo> Forgot.
<hatch> haha ok
<hatch> Makyo ok so once this merges in we will use that as the source of truth
<Makyo> hatch, +a lot
<Makyo> Reboot for updates
<hatch> Makyo so when I do a search then click back, the url changes and the UI updates, hangs for about a second, then snaps to the actual cached results 
<hatch> huwshimi morning
<huwshimi> Morning
<hatch> I had a chat with frankban about the bug and we came up with a good fix for it - he will be starting on it at his start of day
<Makyo> hatch, yeah.  That second is spent on a couple of operations.  Finishing routing, building tokens, and building sticky headers.
<Makyo> All of that was there originally, just hidden by the lack of a cache.
<hatch> Makyo I'm thinking there is some problem in the charmbrowser because it's getting the operation to switch view types, then hangs
<Makyo> hatch, it's not hanging, it's doing plenty of work, it's just not very efficient work.
<hatch> haha right, hanging to the user I mean
<Makyo> Yeah :)
<Makyo> One solution would be for the spinner to stick around and properly indicate loading.
<Makyo> That done, we could work on efficiency.
<Makyo> As two iterations, I mean.  The spinner wouldn't be the fix.
<hatch> it looks like it only hangs when going from search to curated
<Makyo> Search doesn't have as many sticky headers.
<hatch> 1 less :)
<rick_h_> huh? there's only 3 sticky headers
<hatch> damnit you just pop in here
<hatch> lol
<Makyo> Yeah, I just mean that search is less complicated. 
<rick_h_> the sticky headers is very light, shouldn't be a perf issue. Never has been and we did have a working cache when it was working
<hatch> like on the show 'The Office' haha
<huwshimi> hatch: Ah great, thanks for chasing that up.
<rick_h_> hatch: heh, yea bad timing. Tired and crabby and I look and go 'wtf'
<hatch> huwshimi hopefully we'll be ready for your start of day tomorrow
<hatch> to unblock you
<rick_h_> Makyo: so the thing is that the result rendering isn't async any more since it's not part of an async ajax call? 
<huwshimi> hatch: Thanks. I've been landing some chunks of work from that branch anyway
<rick_h_> and has turned blockign?
<Makyo> rick_h_, It's hard to pick apart, but yes, I think so.  The combination of load and render (and all the component steps) seem to be tripping over themselves.  Here's the timings: https://gist.github.com/makyo/0cf154d2d9996de7d45b
<hatch> now that we have a more stable base to work from can take a peek in the AM to give you a break Makyo 
<Makyo> Load takes a while, the two render steps take a while.
<rick_h_> 400ms in routing?
<rick_h_> Makyo: is this taking into account double dispatch? e.g. are these times doubled up somewhere?
<Makyo> rick_h_, no, that's the entire log for clicking 'home' from search results (i.e.: loading curated from cache)
<rick_h_> hatch: huwshimi is the issue with the padding in the categories on comingsoon known?
<hatch> rick_h_ refresh
<hatch> kadams54 landed a fix yesterday
<huwshimi> hatch: It still happens for me
<hatch> hmm comingsoon might need a clean-all
<rick_h_> hatch: cleared browser cache reloaded and still has an issue
<rick_h_> ok
<rick_h_> ok, so that's not a full second but is annoying. Definitely need to show a loader and hide the UI while it updates. 
<rick_h_> yea, css on comingsoon is toast. inspector is a mess
<Makyo> rick_h_, yeah.  At the very least, it needs the spinner while it's churning.  Optimal fix would be to get rid of the delay, but that's proving tough to track down.
<rick_h_> Makyo: yes, I think making the UI transition smooth is a good easy goal
<rick_h_> Makyo: I think that you're right that there's a tree of code to take the models, create the tokens, etc and it's not instant
<rick_h_> is kadams54 around today? I don't see any card on the board for him?
<hatch> lemme check develop
<hatch> yeah local develop looks fine
<hatch> and comingsoon is broken
<hatch> so looks like it could use a kick
<hatch> rick_h_ he was - last I heard he was reading the comments from luca and making cards for them
<huwshimi> Can anyone else not get into canonical IRC?
<hatch> huwshimi I'm in now
<huwshimi> hatch: What happens if you try to reconnect?
<hatch> works fine
<hatch> check that you accept the ssl cert
<huwshimi> hmm... it isn't asking me to, it just says it has expired.
<hatch> might be your client?
<huwshimi> hatch: It doesn't even work with "accept invalid ssl certificate"
<hatch> hmm odd
<huwshimi> worked fine up until now.
<hatch> yeah works fine for me, not sure what's up
<huwshimi> Oh, I did just do some Ubuntu updates which included some ssl packages. Might reboot.
<huwshimi> Nope
<huwshimi> And now all my builds are failing :)
<hatch> haha
<hatch> yeah I saw that
<huwshimi> hatch: It's "origin/pr/360/merge" to kick of a new "shipit"?
<huwshimi> (for pr #360)
<hatch> nope just delete the merge request accepted msg
<huwshimi> ah
<hatch> that other method is for the non-merge case
<huwshimi> oh ok
#juju-gui 2014-06-04
<hatch> Makyo I found the culprit 
<Makyo> hatch, oh yeah?
<hatch> yep it's the tokens
<hatch> the delay was so odd because it was locking up the UI layer
<Makyo> What was causing the problem within the tokens?
<hatch> I haven't quite narrowed it down but the Widget/WidgetParent/WidgetChild stuff seems to be draining a ton of cycles
<hatch> these will probably need to be converted to views
<hatch> it takes up to 300ms per token to render
<hatch> instantiation is fast though so it might not be related to the widget bits
<hatch> still  need to do more digging there
<Makyo> Yikes, yeah.  I was wondering where those cycles were disappearing, since it didn't seem to be any of the blobs I'd debugged.  Lets sync up tomorrow morning after the call or something to try and nail this down further.
<hatch> 1.21s PER frame when it's doing that lol
<hatch> high perf man
<hatch> haha
<hatch> yeah definitely, we now have a starting point
<Makyo> Yep!
<Makyo> I'm crashing, though, damn meds.  Catch up tomorrow morning?
<hatch> fo sho!
<hatch> I'm also done for the night
<rogpeppe> hmm, i'm getting this from the canonical irc servers:
<rogpeppe> The certificate authority's certificate is invalid
<rogpeppe> The root certificate authority's certificate is not trusted for this purpose
<rogpeppe> The certificate cannot be verified for internal reasons
<rogpeppe> anyone else seeing the same thing?
<huwshimi> rogpeppe: I'm seeing the same thing, but I've asked a couple of other people and they seem to connecting be ok.
<rogpeppe> huwshimi: ok. so it's not just me. the bad guys are selectively targeting us :-)
<huwshimi> :)
<rogpeppe> huwshimi: so did you just continue to connect anyway?
<huwshimi> rogpeppe: I can't connect at all.
<rogpeppe> huwshimi: hmm, i have a "Continue" option, but I don't want to use it, as it potentially gives a middle man total access to canonical IRC
<huwshimi> rogpeppe: I've just done without today.
<rogpeppe> huwshimi: the odd thing is this line "The root certificate authority's certificate is not trusted for this purpose"
<rogpeppe> huwshimi: i wonder what purpose it's trying to verify against
<rogpeppe> huwshimi: what IRC client do you use?
<huwshimi> rogpeppe: xchat-gnome
<rogpeppe> huwshimi: hmm, bang goes that theory :-)
<huwshimi> rogpeppe: Which tells me the certificate may have expired.
<rogpeppe> huwshimi: the cert is valid until 2015
<huwshimi> rogpeppe: Oh :)
 * rogpeppe wishes that certificates were more humanly readable, rather than entirely obscure ASN.1
<huwshimi> Well, I'm done for the day, hopefully they resolve it tonight!
<huwshimi> rogpeppe: Have a good day :)
<rogpeppe> huwshimi: see ya :-)
<frankban> rogpeppe: morning, git migration completed! could you please move the card you are working on in the code lane? oh, also, the card from yesterday (http.go) should be moved to daily accomp. thanks. FWIW, I used this quick and dirty script to check packages' deps: http://pastebin.ubuntu.com/7586126/
<rogpeppe> frankban: just FYI, you could do {{join .$2 "\n"}} rather than the range loop (well, modulo some quoting issues :-])
<rogpeppe> frankban: nice script BTW
<frankban> rogpeppe: thanks, it seems I have to work on a JS branch this morning, hope to be able to switch back to our migration plan asap this afternoon. 
<rogpeppe> frankban: ok
<hazmat> woot, bzr installable via pip
<hazmat> iotl == internet of things light ;-)
<redir> morning
<kadams54> morning
<rogpeppe> frankban: your script didn't quite do what i was after (i wanted it a little more scriptable), so i took 30 minutes to write a slightly different version. http://paste.ubuntu.com/7587381/
<frankban> rogpeppe: nice! bash also looks better in your version ;-)
<bac> hi frankban.  did you see my change to quickstart re: tls?
<frankban> bac: yeah, that's awesome, good to see the solution was that simple. thank you!
<bac> frankban: i wish it were so simple for jujuclient...  it uses websocket.create_connection, which has no sslopt.
<bac> not sure how much surgery would be required to replace with WebSocket object use
<bac> s/WebSocket/WebSocketConnection/
<frankban> bac: it should be similar to what we do in quickstart (and originally we did that for other reasons, logging stuff IIRC). perhaps we can contribute upstream by adding the sslopt to create_connection
<bac> frankban: that's a thought...
<jcsackett> morning (or afternoon) all.
<frankban> bac: actually it seems you can already pass sslopt to create_connection: https://github.com/liris/websocket-client/blob/v0.12.0/websocket.py#L198
<bac> frankban: silly me, i believed the docstring
<bac> options: current support option is only "header".
<bac>              if you set header as dict value, the custom HTTP headers are added.
<bac> and didn't think the sslopt was part of the headers
<frankban> bac: yeah that docstring was never updated :-/ and no longer reflects reality: it seems it used to in a very old version: https://github.com/liris/websocket-client/blob/v0.9.0/websocket.py#L172
<frankban> bac: so it actually seems your solution can also fix jujuclient \o/
<bac> frankban: so it should be quite easy to update jujuclient.  i'll update the bug and make a slack card.  it is no longer directly affecting us, afaict.
<frankban> bac: no, since we use a customized way to establish the ws connection it doesn't affect us now
<frankban> bac: so +1
<hatch> bac can you kick comingsoon? It's not updating the css again
<bac> hatch: i will.  should i not be around recall that you can too.
<hatch> oh? 
<hatch> are instructions in the wiki?
<bac> hatch: instructions?
<bac> hatch: try it now.  is it still messed up?
<hatch> yeah - like how to log into the server and whatnot
<bac> it's the whatnot that always bites you
<hatch> bac yesh it's still broken
<bac> urhg.
<bac> hatch: ok, doing a make clean build-prod now
<hatch> thanks
<hatch> any idea why it does this?
<bac> hatch: now?
<hatch> bac yep fixed, thanks
<hatch> luca comingsoon is ready
<bac> hatch: we're missing some dependency in the css generation part of the makefile
<bac> hatch: i'll make a card
<luca> hatch: thanks
<hatch> bac great thanks
<hatch> luca there are a couple known bugs - no databdinging on unit details breakout, and slow rendering when switching between views in the sidebar, anything else that you find that should block release lemme know!
<hatch> databinding 
<luca> hatch: thanks
<luca> hatch: Iâll check it out
 * rogpeppe goes to grab some lunch
<frankban> guihelp: I need two reviews and QA for https://github.com/juju/juju-gui/pull/363 . Anyone available? thanks!
<hatch> on it
<kadams54> frankban: I can take a look.
<hatch> thanks for picking this up frankban!
<frankban> thank you both!
<bac> hatch: hey, it was already there.  including the whatnot: https://wiki.canonical.com/CDO/Juju/GUI/CI?highlight=%28comingsoon%29
<hatch> oh look I have access
<hatch> lol
<bac> hatch: give it a run sometime and let me know if that doc is incomplete
<hatch> sure I'll try and get to it today
<frankban> rogpeppe: are you migrating utils?
<rick_h_> Makyo: around?
<rogpeppe> frankban: yup
<rogpeppe> just trying to figure out how filter-branch works
<redir> rogpeppe: what are you trying to do?
<rogpeppe> redir: factor utils out of juju-core
<redir> what have you tried?
<redir> or what are you trying
<hatch> rick_h_ not sure if you saw the scrollback but last night I found the perf issue
<rogpeppe> redir: this (suggested by frankban) seems to have worked: git filter-branch --subdirectory-filter utils -- --all
<redir> rogpeppe: http://pastebin.ubuntu.com/7587828/ notes from my brief look at removing store
<rogpeppe> redir: i just wanted to have some idea of what it was actually doing
<hatch> frankban comments made - could you check them out and reply before I hop on QA'ing 
<frankban> rogpeppe: great! redir: yeah that's the same command, and we no longer need bzr-export since we start from a git repo
<rogpeppe> hmm, apparently i no longer have permission to create repos in github.com/juju
<redir> right so clone, promote, add remote, push
<frankban> rogpeppe: could you please take notes while doing the migration, so that we can follow those when moving other parts (and eventually also merge those notes in juju docs)? Also, when you actually start, could you please send an email to juju-dev saying we are migrating a utils/*?
<redir> oh, I missed something
<redir> clone, promote, add remote, push promoted, whatnot in core, commit, push updated core
<redir> the all important whatnot
<frankban> redir, rogpeppe: I imagine it would be 1) create juju/utils in github, 2) fork in github 3) clone the fork 4) add juju/utils/ as remote upstrem 5) create a new local branch 6) migrate 7) push to origin 8) propose the branch
<frankban> then remove the moved parts and fix imports in core
<frankban> (and also update dependencies
<luca> hatch: the charm details link in the IotL doesnât work
<redir> frankban: can you rewtrite history only in a local branch? won't that affect the whole repo?
<hatch> luca what does IotL stand for?
<hatch> I know it means Inspector Left but the letters are all garbled
<hatch> lol
<luca> hatch: Inspector on the Left
<hatch> luca, confirmed - can you create a bug plz
<luca> notâ¦garbledâ¦
<hatch> ohhh :)
<hatch> brb
<frankban> hatch: replied on your comments
<rogpeppe> so, a git weirdness - i thought git checkout updates all the files in the current working directory, but after doing the above filter-branch command (in a new branch), i did "git checkout master" to revert to the original juju master, and no files changed
<frankban> redir: not sure if I understood your question: we need to split the juju/juju history, then create a juju/utils branch with the history obtained by splitting out utils. At that point we just propose a local juju/utils branch (with the history) to be merged into the newly created (and empty) upstream, right?
<rogpeppe> i then tried removing all the files other than .git, and it is still not checking out the files
<frankban> rogpeppe: git reset --hard?
 * frankban bbiab
<redir> rogpeppe: that may only have an effect on the INDEX so you may need to reset --hard to make the directory reflect the changes to the index
<redir> like frankban said
<rogpeppe> pwd
<redir> rogpeppe: /irc
<rogpeppe> hmm, git reset --hard did bring some files back (why didn't checkout do that?) but it brought back the files from the new branch, not master
 * rogpeppe doesn't understand the subtle difference between checkout and reset
<hatch> frankban thanks
<rogpeppe> redir: i don't know about INDEX
<rogpeppe> redir: is that a manifest of files on disk?
<redir> frankban: I think we are saying the same thing. I was interpreting your steps as all in the same repo with different local branches and remotes for different upstream repos, which I don't think would work. However, reading your clarification I understand you are working in two repos
<hatch> frankban I was under the impression that the ghost service callback converted the ghost service into a real service 
<redir> rogpeppe: something like that, I don't really get into git that deeply usually as I don't need to
<rogpeppe> redir: i was just trying to understand the git-reset help page, which mentioned the "index" all over the place
<redir> rogpeppe: index is like the staging area
<redir> so you make changes in the directory
<rogpeppe> redir: ah, that's where "git add" puts stuff to i guess
<redir> then you git 'add' it and that tells the index to stage the change
<redir> so a lot of the filter-branch and fast-import and other bits actuall just update the index
<redir> letting you commit later
<redir> also impying that your directory isn't up to date when only the index is altered
<redir> or something like that
<rogpeppe> redir: i don't think that can be the case with filter-branch, because it's rewriting all of history
<rogpeppe> redir: so it surely must update HEAD and everything it points to?
<redir> rogpeppe: idk, because I haven't had to use filterbranch much -- mostly only to remove sensitive info from repos:)
<redir> and usually I am in a panic at that point, so not much sticks other than get it out get it out
<Makyo> jujugui call in 10
<redir> but I think head is just like a sticky note pointing at the place you are working (most recent commit)
<redir> rogpeppe: ^^
<redir> so adding a commit just moves the sticky note to point at then newly added commit (new head)
<rogpeppe> redir: yeah, but if i do "git checkout master", it should bring me back to where i was
<redir> rogpeppe: if you rewrote history it would bring you back to where you were rewritten to
<redir> or somehtign
<redir> rogpeppe: I try hard not to peek under the git porcelin
<rogpeppe> hmm
<rogpeppe> the odd thing is, i haven't done a single commit
<rogpeppe> and everything seems to have changed on master and on my checked-out branch
<rogpeppe> this is what my reflog looks like
<rogpeppe> http://paste.ubuntu.com/7587997/
<redir> rogpeppe: I think you noted that if you fitler-branch --some-filter it rewrites history for you. If you want to pair for a minute, I can pretend to know more about git than I really do
<rogpeppe> redir: let's do that after the standup
<redir> ok
<rogpeppe> redir: or actually, let's join the standup now and see how far we get :-)
<rick_h_> hatch: didn't see it. What was up?
<rick_h_> Makyo: reping
<Makyo> rick_h_, oops, missed the earlier one, what's up?
<rick_h_> Makyo: got a sec for a call?
<hatch> rick_h_ the perf issue is somewhere in the token widget parent/child rendering
<Makyo> Sure
<redir> brt, biobreak pre stanup
<bac> jujugui: was my audio less awful today via the phone?
<rogpeppe> redir: i fixed the issue by manually resetting to a revid i found in the reflog
<rogpeppe> redir: but i have no idea how i ended up in the state i did
<redir> rogpeppe: cool
<redir> rogpeppe: that will prolly happen several more times:)
<rogpeppe> redir: it looks like filter-branch changed two branches at once
<redir> rogpeppe: I think it does
<rogpeppe> redir: really?!
<redir> rogpeppe: have you read this http://bit.ly/1i0DBcw
<rogpeppe> redir: i've read something pretty similar in the past. nice summary.
<redir> rogpeppe: right so if you rewrite a commit, that commit is used in several branches -- because it is all one graph -- then both branches h ave changed
<rogpeppe> redir: i don't think that quite gets into why filter-branch changes two branches at once rather than just affecting the current branch
<rogpeppe> redir: um, i was under the impression that commits weren't really rewritten, but just that a whole new history was fabricated and HEAD changed to point to that new history
<redir> history rewritten equal new different commits in the graph and new trees under those commits
<redir> rogpeppe: so why wouldn't it affect all branches?
<redir> they aren't clones like in bzr
<rogpeppe> redir: but doesn't each branch have an associated revid?
<redir> I think revid is a bzr term
<rogpeppe> redir: SHA-1 hash
<rogpeppe> redir: whatever the term is
<redir> ahh
<redir> a sha1 hash its a commit
<frankban> rogpeppe, redir: so the lesson here is that when we split packages we have to use an ad-hoc juju clone right?
<redir> which points at a tree (dir structure)
<redir> rogpeppe: ^^
<redir> frankban: yes I think so
<frankban> thanks redir 
<rogpeppe> redir: what's the right git name for the SHA hash that you see 
<rogpeppe> ?
<redir> rogpeppe: I think they are just ids for commit objects that you are dealing with
<rogpeppe> redir: right
<redir> so they are just commiits
<rogpeppe> redir: so each branch points to a particular commit object, right?
<redir> right but more than one branch can point at the same commit object
<rogpeppe> redir: and if you operate on a branch, it updates the commit object pointed to by that branch, yes?
<rogpeppe> redir: but the branch points to the commit object via its id, no?
<redir> it should create a new commit object pointing at the associated tree and blob objects
<rogpeppe> redir: rather than pointing to a mutable thing
<redir> the id is a hash of the object and an header (commit msg, etc)
<redir> each commit updates the graph and points the branch at the new commit
<redir> fo rthat branch
<redir> but if you change an existing commit it changes it for anything in the graph that uses that commit
<redir> hopefully I am making some sense
<rogpeppe> redir: the point i'm finding odd is "changing an existing commit"
<rogpeppe> redir: that implies that branches have some kind of a symbolic reference to the commit rather than just storing a hash of it
<redir> rogpeppe: rewriting history updates the graph, the blobs, trees, commits, and tags
<hatch> frankban should I be able to drag and drop a token on a container with a service in it?
<rogpeppe> redir: and if so, that turns everything i *thought* i knew about git on its head
<rogpeppe> redir: but it doesn't *change* any of the existing blobs, does it?
<rogpeppe> redir: it just adds new ones, no?
<redir> rewriting history changes them
<redir> depending on what is rewritten
<rogpeppe> redir: i'm not sure how it's possible to change a blob, because everything is content-addressed
<frankban> hatch: drag a token on a container?
<redir> well if you want to remove a password from a file you rewite history
<redir> which changes a file
<hatch> frankban yeah so drag and deploy mysql to a machine, confirm, then drag another token to the bare metal on that machine
<hatch> it throws an error notification now
<redir> rogpeppe: and that blob then hash a different hash value
<rogpeppe> redir: so if i do "git branch --list -v", i see the branches and the hashes of their commit objects
<hatch> this may have always been broken but I'm pretty sure you can deploy to a container
<hatch> with something else in it
<rogpeppe> redir: are you saying that if i do a filter-branch on one branch, the hash of the commit object for another branch can change?
<frankban> hatch: it does not work, and needs to be fixed
<redir> rogpeppe: that is my understanding
<hatch> frankban but that's out of scope of this branch right?
<redir> because it is not it's own repo
<frankban> hatch: is it a regression introduced by this branch?
<redir> rogpeppe: should be easy enough to do an experiment:)
<rogpeppe> redir: wow. so even though i've done "checkout -b" to try and isolate my changes, the original branch gets mutated anyway.
<rogpeppe> redir: so if you use filter-branch, you'd *always* need to use the reflog to rewind that other branch
<redir> rogpeppe: if you do it in one repo yes
<hatch> frankban ahh I don't know - yours makes it error, whereas before it would just create a new machine haha
<hatch> I'm going to say - out of scope for your branch :)
<frankban> hatch: ok cool then :-)
<redir> rogpeppe: if I am understanding everyting we are talking about correctly I think the answer is yes
<hatch> +1'd
<frankban> hatch: now that a pattern is established, it shouldn't be hard to fix all the variations
<hatch> frankban yeah true true
<hatch> who knew ECS would end up being so complex :)
 * rick_h_ raises hand
<rick_h_> :P
<rogpeppe> redir: wow, you're right.
<redir> rogpeppe: there's a first
<rogpeppe> redir: that is so counter-intuitive
<redir> quick record this moment!
<rogpeppe> :-)
<rogpeppe> so i guess a branch must be more than just a (SHA hash) pointer
<redir> rogpeppe: when you do those kinds of perations it does tore a back up somewhere in .git but I don't know the details of the top of my head
<redir> rogpeppe: just different from bzr
<rogpeppe> redir: when i did the operation again, it said this:
<rogpeppe> Cannot create a new backup.
<rogpeppe> A previous backup already exists in refs/original/
<rogpeppe> Force overwriting the backup with -f
<redir> yeah there
<redir> I usually do rewrites in a whole seperate clone
<redir> and keep a pristine copy in case something happens later
<redir> and I need it
<redir> at least for a reasonable period
<rogpeppe> ah! i got it!
<rogpeppe> i think
 * rogpeppe checks
<frankban> rogpeppe: git supports both clones a-la bzr and branches. IIUC with checkout you just navigate the tree, and that's why they are so fast, and maybe that's also the reason why when you rewrite history you really rewrite history. it does not seem that weird to me. in our case, we need to use clones
<redir> rogpeppe: branches with different histories in bzr don't make sense to me
<redir> it is very rare that I need a seperate clone (bzr branch) 
<redir> rogpeppe: frankban nailed it there
<redir> I htink
<rogpeppe> redir: actually, i think i was right :-)
<rogpeppe> redir: the culprit was the --all argument to the filter-branch command
<redir> I thought I was wrong, turns out I was right
<redir> ah all branches
<rogpeppe> redir: which was specifically asking to rewrite history on *all branches*
<frankban> redir: in bzr some of us works with lightweight checkouts which mimic named branches and allow us to always work in the same directory
<rogpeppe> redir: if you just specify the current branch, it works just as i'd thought
<rogpeppe> phew
<redir> frankban: yes but it still creates real branches in real directories somewhere else
<rogpeppe> frankban: FWIW when you rewrite history, you don't really rewrite history
<frankban> redir: yes, that's true, well, real branches, you can init your repo with --no-tree so that no files are written on disk, but yes, they are not as lightweight as git ones
<hatch> kadams54 I
<hatch> bah
<rogpeppe> frankban: you just rewrite the history of the current branch
<hatch> kadams54 I'm thinking that the cards you created should probably go in On Deck or Pool until we put a priority on them
<rogpeppe> frankban: or whatever branches you've specified
<hatch> thoughts?
<kadams54> Sure
<frankban> rogpeppe: cool even better then
<redir> rogpeppe: I'd be wary of thinking that you are at the bottom of it:)
<rogpeppe> redir: i am still very wary :-)
<rogpeppe> redir: but at least experiment seems to support that point of view :-)
<Makyo> jujugui tiny branch https://github.com/juju/juju-gui/pull/364
<frankban> rogpeppe: I'd be still inclined to use a disposable clone for this kind of work ;-)
<redir> rogpeppe: I think you are right, but I can imagine scenarios where things end up different than you expect
<hatch> Makyo on it
<rogpeppe> frankban: BTW, what was the reason you gave the --all flag to filter-branch?
<redir> also in the case of promoting a sub project I would want all branches to be done
 * rogpeppe tries to understand "
<rogpeppe>            Pretend as if all the refs in refs/ are listed on the command line
<rogpeppe>            as <commit>.
<rogpeppe> "
 * redir tries to understand quote
<rogpeppe> ah, got it!
<frankban> rogpeppe: heh, I don't remember, maybe because I was converting from bzr and I had just a single branch in the target
<rogpeppe> jeeze, they don't write for people that don't understand the internals, do they?"
<rogpeppe> so the "refs/" there is referring to the .git/refs directory, where branch references are held (amongst other things)
<redir> rogpeppe: perl people
<hatch> Makyo +1'd
<kadams54> frankban: QA and review finished on your PR. Didn't have anything to add to what hatch had.
<redir> rogpeppe: I was using all because I wanted to capture the tags and anything else that came over from bzr
<frankban> kadams54: thanks
<redir> maybe that isn't necessary for working solely within git but I think I'd still want tags and branches preserved in the new repo
<redir> rogpeppe: ^^
<redir> bbiab
<rogpeppe> redir: i can see why --all would be useful if you *really* wanted to rewrite history, rather (say) creating a new repo
<redir> rogpeppe: TMTOWTDI 
<rogpeppe> redir: that is a severe understatement when talking about git :-)
<rick_h_> Makyo: lint issue, any reason it's faster to remove the cache than to tie the indicator into there? 
<Makyo> rick_h_, Yeah, fixed the lint issue.  Re the cache - the entire UI thread is hanging, so the indicator would hang as well.
<rick_h_> but a hanging spinner > odd non readable ui
<redir> rogpeppe: frankban http://pastebin.ubuntu.com/7588475/ are aliases I use a lot. Particularly tr and missing 
<rick_h_> Makyo: ok cool, just curious
<redir> rogpeppe: dunno if the colors work without bash and don't know about acme and shells...
<rogpeppe> redir: colours are for colouring books :)
<Makyo> rick_h_, The spinner was being put in there, but was hanging before it could even render.  We're looking at ways to lighten the render load on charm tokens.
<hatch> this is coming from the guy who doesn't even use syntax highlighting rogpeppe ;)
<rick_h_> Makyo: gotcha. 
<rogpeppe> hatch: you gottit :-)
<hatch> haha
<redir> rogpeppe: tell that to tufte 
<hatch> rick_h_ the solution may be to write them as Views or remove the Parent/Child bit (still too early to tell)
<hatch> that'll be post release though
<redir> rogpeppe: replace --pretty with --no-color
<rick_h_> frankban: http://ci.jujugui.org:8080/job/juju-gui-merge/376/ test failure. Odd one, not see it before. It's not one fo the usual temp errors
<hatch> noooo more renderTo!!!!
<redir> rogpeppe: nm that doesn't work you'd need to remore the colors from the foramtting
<hatch> I thought I got rid of youuuuu
<rick_h_> hatch: ugh and ugh. The parent child has worked out so well and worked when we had a cache. 
<hatch> rick_h_ we are just too fast now :)
<rogpeppe> redir: thought so
<rick_h_> hatch: will take a look in a bit
<rick_h_> hatch: then it's easy to slow things down in a smooth way :P
<rick_h_> hatch: or even just cache the rendereted html node tree and replace it on home. There's got to be a better way to move forward than rewrite all the code
<frankban> rick_h_: weird this comes after two passes, without no changes other than rebasing
<rick_h_> frankban: yea, not sure. 
<hatch> it's too early to tell what the actual problem is - but it's definitely in the token rendering - it might be as simple as blowing away the old list and re-rendering, it spends a ton of time in rendering/gc
<rick_h_> hatch: huh? isn't that what it does now? 
<rick_h_> I guess what is getting cached? It should just be the model list
<hatch> the json is being cached
<rick_h_> the api json?
<hatch> yeah
<rick_h_> then what's not 'blown away'?
<hatch> the DOM when switching from search results to curated
<rick_h_> the old cache was the models generated. There was the _cache and _cache.interesting
<hatch> right
<hatch> Makyo and I decided that making the view caching aware was odd and that it should just be sent data and render it. We know that the model caching bit needs to be done, but the quickest way was to cache the response 
<rick_h_> yea, not a fan of the api layer caching at all
<rick_h_> that's at the browser/web service layer
<rick_h_> the view isn't, it's the application (browser.js)
<rick_h_> or the state
<rick_h_> which is a fine place to cache data that is used across state renders/etc
<hatch> right - the view shouldn't be concerned about the data - it should request it from the same place - that place should return the data, be it cached or not
<rick_h_> well, the view is updated with new data, and should destroy/redraw based on the new data. /me goes to look at what the view does 
<rick_h_> Makyo: I'd vote to not comment that out but kill it
<rick_h_> we know it doesn't work well and isn't a good path forward
<rick_h_> it doesn't address the caching of individual charm models and doesn't fit the cards on the board for a new cache module that could be shared across views in the app
<rick_h_> it looks like a single purpose hack to speed up the home button click but fails to do that
<hatch> that is a valid point - however a proper cache will take time to implement 
<hatch> it speeds it up dramatically if you remove the rendering issue
<rick_h_> sure, but we've commented out this anyway
<rick_h_> so what does leaving this in help us with?
<hatch> like 300ms response time
<hatch> once we solve the render issue we can re-implement this cache and not have to schedule the proper one right away if time doesn't permit
<rick_h_> but the only reason we're seeing a rendering issue is that teh cache isn't working correctly it seems to me? 
<rick_h_> you've traded one chunk of work for two
<hatch> no it's the rendering, if you comment out the rendering of the tokens it's very fast
<rick_h_> ok fine, but those same tokens rendered with a browser.js cache of ._cache and ._interesting didn't exhibit an issue that I recall
<rick_h_> you're still trading two problems for one
<hatch> the rendering needs to be fixed regardless - we 'can' push caching off with the api cache 'hack' 
<rick_h_> it seems to me the rendering iss, and some 400ms delay during a change of state is something that can be smoothed over much easier
<hatch> the state change is instant, <10ms 
<rick_h_> ok, I understand that, but there's no useful 10ms UI update for users
<hatch> maybe we should have a hangout :) it'll be much easier to discuss haha
<rick_h_> sure thing :)
<hatch> sec
<hatch> https://plus.google.com/hangouts/_/canonical.com/daily-standup
<rick_h_> Makyo: ^
<frankban> rick_h_: another branch, similar failure: http://ci.jujugui.org:8080/job/juju-gui-merge/377/console
<redir> rogpeppe: frankban you guys using precise or trusty?
<rogpeppe> redir: i'm using trusty
<frankban> redir: trusty
<redir> for splitting out the juju-core bits?
<redir> rogpeppe: frankban ?
<frankban> redir: git version 1.9.1 here, on trusty
<frankban> redir: git tr is very cool
<redir> frankban: it is like a you are here directory for the repo:)
<bac> hey frankban, i'm trying to create a brew recipe based on the lastest tgz we have released.
<bac> frankban: but 1.3.2 has the problem with not specifying the 0.12 for websocket-client, thus it grabs the wrong one
<bac> frankban: so, any chance of cutting a release soonish?
<frankban> bac: looking
<frankban> bac: we can release a 1.3.3 if required, after a proper QA with the new juju stable (1.18.4 IIRC). Why are we working on the brew formula now? I supposed that's the very final step for osx support. If that's not the case, I'll try to prepare a new release tomorrow
<hatch> not going to lie.....every breakout panel shouldn't be working right now heh
<hatch> that might mean this card won't be huge
<hatch> :)
<rogpeppe> redir: ok, another little git question...
<hatch> uh oh
<redir> rogpeppe: I'm ready to provide another wrong answer:)
<hatch> lol
<hatch> teamwork!
<redir> partially wrong answer...
<rogpeppe> redir: if i want to take a subdirectory out of an existing project (juju/juju), keep its history and the same directory, then merge it with another project, essentially merging two different branches with no shared root
<rogpeppe> redir: is that possible?
<redir> rogpeppe: yes
<redir> wait
<redir> me rereads
<rogpeppe> redir: i want to take juju/juju/testing/filetesting and add it to juju/testing, with all its history intact
<redir> so
<rogpeppe> redir: i guess i could use filter-branch twice
<redir> I think the answer is yes
<rogpeppe> redir: once with --subdirectory-filter, then with --tree-filter moving the directory back to its original place
<rogpeppe> redir: and then kinda hope that git merge works when the two branches share no common history
<rogpeppe> hatch: does that sound like a feasible approach?
<redir> rogpeppe: I know that you can have more than one commit with no parent
<rogpeppe> redir: ok, that's good
<hatch> rogpeppe no idea I've never needed to do that
<hatch> sorry
<redir> rogpeppe: which means that two projects merged and have separate starting points
<redir> but I don't know what that means for keeping the full history of the branch being merged in
<redir> rogpeppe: 
<redir> rogpeppe: I think I would add repo getting merged in as a remote for the one being added to
<redir> then work out how I wanted them to be merged
<redir> they don't share a time line so you might just cherry-pick commits 
<redir> or do a subtree merge
<redir> rogpeppe: 
<rogpeppe> redir: ok, we'll see
<redir> yeah so
<redir> rogpeppe: something like
<redir> rogpeppe: http://pastebin.ubuntu.com/7589025/
 * redir googles for magic incantation
<redir> rogpeppe: in the filter-branch man page
<redir> http://pastebin.ubuntu.com/7589077/
<redir> rogpeppe: NB: I haven't done that before and it seems very magical
<rogpeppe> redir: ah, update-index is not a command i've come across before
<redir> rogpeppe: index-filter only updates the index not everything
<redir> also  see subtree merges
<redir> I don't know if that will keep history how you want though
<rogpeppe> redir: yeah, update-index seems to be magic that allows us to manipulate stuff without actually checking things out
<redir> rogpeppe: http://bit.ly/1kCOYwh
<rogpeppe> redir: what's a "tree-ish"
<rogpeppe> ?
<redir> rogpeppe: a branch I think
 * rogpeppe thinks git would be quite a bit simpler without the index concept
<redir> rogpeppe: I don't think that keeps full history though
<redir> rogpeppe: I haven't ever needed most of this stuff before this.
<redir> filter-branch for removing things from history is about it
<redir> rogpeppe: from the read-tree man page it looks to me like you won't get history just a merge, so I think if you want history you need filter-branch with magic
<rogpeppe> redir: i think filter-branch with the update-index --index-info magic seems like it might do the trick
<rogpeppe> redir: i'm guessing that it's expecting me to set $GIT_INDEX_FILE to my_repo/.git/index
<redir> rogpeppe: note that I think that will change the hashes in history which is bad if other people have it checked out...
<redir> rogpeppe: git might do that itself
<rogpeppe> redir: i'm not quite sure what you mean there
<redir> rogpeppe: I would guess it would
<redir> when you run the git command it reads the repo it is in and sets env variables
<redir> rogpeppe: maybe
<redir> git env
<rogpeppe> redir: ah, so that command will have the env var set
<redir> rogpeppe: maybe
 * redir is guessing
 * rogpeppe misses the inferno shell, which did commands-as-arguments with no quoting necessary
<redir> damn, where'd the day go
<rogpeppe> redir: hey, it seems to have worked!
<redir> angels sing, trumpets blare!
<redir> world peace is at hand
<rogpeppe> redir: my specific version of the update-index magic was this: http://paste.ubuntu.com/7589371/
<rogpeppe> i actually feel like i understood most of what was going on there
<rogpeppe> except i still get confused around remote branches and fetch vs checkout vs reset
<redir> hehe
<redir> git fetch, uh, fetches named heads or branches, tags, and the associated trees, blobs, commits etc
<redir> and puts them into .git/FETCH_HEAD
<redir> git merge merges them into a local branch
<redir> git pull does both
<redir> fetch then merge
<rogpeppe> redir: what's the significance of .git/FETCH_HEAD there?
<redir> rogpeppe: it is non local copies of stuff
<rogpeppe> redir: anyway, review appreciated: https://github.com/juju/testing/pull/11
<redir> or copies of non local stuff
<rogpeppe> hmm, it's a pity that none of the resulting history includes the commit comments that are actually important
<redir> checkout (and reset) update the files in the working tree to match the index or a specified tree (specified by a commit)
<redir> git reset has --soft, --mixed and --hard
<redir> I think --soft updates the index to match some specified tree
<redir> and --hard updates the working directory and index
<redir> rogpeppe: ^^
<rogpeppe> redir: i still haven't got my head around the difference between reset and checkout
<rogpeppe> i'm done for the day
<rogpeppe> gotta go and make chicken and wild mushroom and tarragon pie
<redir> rogpeppe: that sounds tasty
<redir> later
<rogpeppe> redir: hopefully :-)
<redir> don't git reset your oven
<kadams54> guihelp: looking for review and QA on https://github.com/juju/juju-gui/pull/365
<kadams54> guihelp: Bueller?â¦ Bueller?â¦ anyone?â¦ anyone?â¦ --^
<kadams54> ;-)
<Makyo> kadams54, on it.
<kadams54> Thanks :-)
<hatch> nice the footer is FINALLY being used
<kadams54> lol
<hatch> I added it in in the beginning....thinking that it will probably be used at some point haha
<kadams54> Gotta run to pick up my kids from school, but will be back in about 30 minutes.
<redir> rogpeppe: LGTM, all the tests pass with your PR merged, but I don't know the QA or merge process for it
<bac> this is a nice touch i'd never noticed. when brew successfully installs something you get a little mug o' beer:
<bac> ðº  /usr/local/Cellar/juju-quickstart/1.3.3: 2 files, 40K, built in 2 second
<rick_h_> bac: :) 
<hatch> :)
<hatch> rebooting
<huwshimi> Morning
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey
<rick_h_> having fun huwshimi ?
<huwshimi> rick_h_: Today, I'm writing tests... yes, lot's of fun! :)
<hatch> huwshimi hey, frankban landed the branch to fix that bug
<huwshimi> hatch: Yay!
<hatch> huwshimi you can pretty much follow the same pattern for doing the container stuff if you end up going that far
<hatch> here is the pr https://github.com/juju/juju-gui/pull/363
<huwshimi> hatch: I'm not sure what you mean about following the pattern for container stuff. This looks like it handles machines and containers.
<hatch> huwshimi there is an issue with placing a unit on an existing container 
<hatch> I wasn't really sure where your cards were taking you
<huwshimi> Ah I see
<hatch> I got to run but hopefully that gets you un blocked
<huwshimi> hatch: Thanks, looks like it. Thanks!
<hatch> no probelm
#juju-gui 2014-06-05
<frankban> morning rogpeppe: how are you doing?
<rogpeppe> frankban: hiya
<rogpeppe> frankban: not too bad
<rogpeppe> frankban: just reading the leader election thread
<frankban> rogpeppe: are you migrating filetesting?
<rogpeppe> frankban: yes, i have a LGTM and can merge it
<rogpeppe> frankban: i'll do that now
<frankban> rogpeppe: ok I moved the card in coding and assigned to you, please put it in daily accomp. when done.
<frankban> rogpeppe: do you have notes on the migration steps?
<rogpeppe> frankban: hmm, i thought i had a card
<rogpeppe> frankban: i haven't made the notes yet, but i've got all the shell history :-)
<frankban> rogpeppe: cool, could you please share it? you have a card for utils, I believe you switched to filetesting because some packages in utils depend on it, correct?
<rogpeppe> frankban: yup
<rogpeppe> frankban: zip/zip_test.go
<rogpeppe> frankban: that seems to be the only one
<frankban> rogpeppe: cool, I guess I am going to migrate schema
<rogpeppe> frankban: that should probably go inside utils, i think
<rogpeppe> frankban: i don't really think it justifies its own repo
<rogpeppe> frankban: then again, i don't mind much
<rogpeppe> frankban: if you think otherwise
<frankban> rogpeppe: I proposed the same last week and David said: "Yes to migrating it, no to renaming it. Schema is useful as a top
<frankban> level project, rather than buried in an amorphous utils repo."
<rogpeppe> frankban: ok, fair enough
<frankban> rogpeppe: ugm. it seems I don't have permission to create a repo in juju :-/
<frankban> rogpeppe: when you can, could you please 1) create a juju/schema repo (I don't have permission) and 2) send me the commands you used to split filetesting?
<rogpeppe> frankban: 1) is now done
<rogpeppe> frankban: for 2) you won't need the more complex commands that i used
<rogpeppe> frankban: because you're not merging into an existing repo
<rogpeppe> frankban: and you don't need to rewrite pathjs
<frankban> rogpeppe: 1) thanks
<frankban> rogpeppe: github says https://github.com/juju/schema is empty and I cannot fork it
<rogpeppe> frankban: utils is now factored out; here's a trivial PR that adds README.md and LICENSE: https://github.com/juju/utils/pull/1
<rogpeppe> frankban: you'll need to push directly to it initially
<frankban> rogpeppe: ah, so initial push with an empty repo or with the actual repo generated by "git filter-branch"?
<frankban> rogpeppe: LGTM
<rogpeppe> frankban: the latter
<frankban> rogpeppe: ERROR: Permission to juju/schema.git denied to frankban.
<frankban> rogpeppe: any idea?
<rogpeppe> frankban: sorry, missed your earlier comment
<rogpeppe> frankban: looking
<frankban> thanks
<rogpeppe> frankban: what command did you use?
<frankban> git remote add upstream git@github.com:juju/schema.git
<frankban> git push upstream master
<frankban> rogpeppe: ^^
<frankban> rogpeppe: in https://github.com/juju/schema I only see:
<frankban> This repository is empty.
<frankban> Care to check out the GitHub Channel on YouTube while you wait?
<rogpeppe> frankban: does it behave differently if you do: git remote remove upstream; git remote add upstream https://github.com/juju/schema.git ?
<frankban> rogpeppe: it asks for user and password and then exits with: fatal: unable to access 'https://github.com/juju/schema.git/': The requested URL returned error: 403
<rogpeppe> frankban: hmm, weird
<rogpeppe> frankban: i'll try pushing a branch to it
<frankban> rogpeppe: https://github.com/juju/schema/settings/collaboration ?
<frankban> rogpeppe: now I see your branch but I cannot fork
<rogpeppe> frankban: ah, i hadn't seen the collaboration settings
<rogpeppe> frankban: you should be able to push now
<frankban> rogpeppe: done, could you please remove the testing branch?
<rogpeppe> frankban: yeah, just trying to work out how to do that
<rogpeppe> frankban: hmm, it's not obvious...
<frankban> rogpeppe: I did it
<frankban> rogpeppe: git push upstream :testing
<rogpeppe> frankban: ah yes, i'd forgotten that idiom
<frankban> rogpeppe: https://github.com/juju/schema/pull/1
<rogpeppe> frankban: LGTM
<frankban> thanks
<frankban> rogpeppe: could you please create a juju/names repo and give me write permission?
<rogpeppe> frankban: yup
<frankban> thanks
<rogpeppe> frankban: done
<frankban> rogpeppe: thanks
<frankban> rogpeppe: could you please review https://github.com/juju/juju/pull/25 ?
<rogpeppe> frankban: LGTM
<frankban> rogpeppe: do you know if in the new git world dependencies.tsv changes are handled by the bot?
<rogpeppe> frankban: i don't - best ask on #juju-dev
<frankban> rogpeppe: yeah, already done
<frankban> rogpeppe: thanks for the review, I guess I'll try to $$merge$$ it
<rogpeppe> frankban: good plan
<frankban> rogpeppe: and now names
<frankban> rogpeppe: FWIW, these are the notes I've taken while migrating schema: http://pastebin.ubuntu.com/7593938/
<rogpeppe> frankban: BTW your "fix import paths" step can be done automatically by running "govers -m github.com/juju/juju/schema github.com/juju/schema" in the schema directory
<rogpeppe> frankban: what's the difference between an https remote and a git@github remote?
<frankban> rogpeppe: https vs ssh
<rogpeppe> frankban: is one preferred over the other?
<frankban> rogpeppe: not sure, I prefer ssh because https asks me credentials
<frankban> rogpeppe: ssh uses the ssh key
<rogpeppe> frankban: hmm, i guess i can tell github about my ssh key
<frankban> rogpeppe: https://help.github.com/articles/generating-ssh-keys
<rogpeppe> jeeze my network is stupidly slow today
<rick_h_> ssh is faster and uses the key vs password. 
<frankban> rogpeppe: trivial https://github.com/juju/names/pull/1
<rogpeppe> frankban: LGTM
<frankban> rogpeppe: thanks
<frankban> rogpeppe: could you please take a look at https://github.com/juju/juju/pull/27 ? (mechanical)
<rogpeppe> frankban: did that previous branch merge ok?
<frankban> rogpeppe: yes
<rogpeppe> frankban: or did you have to do something manually to update the deps?
<frankban> rogpeppe: no it seems they are handled automatically now
<rogpeppe> frankban: great!
<frankban> yeah
<rogpeppe> frankban: LGTM
<frankban> rogpeppe: great thanks
<bac> hi rick_h_ -- i got an email from the LocalCharmGuy asking how to ingest local bundles.  afaik we've not tried that before but it should be similar.  shall i finish my current task and then help him?
<kadams54> morning all
<jcsackett> morning kadams54.
<kadams54> rick_h_: you around?
<redir> morining
<redir> I have to go get a blood test.
<redir> bbiab
<rick_h_> kadams54: kinda what's up?
<kadams54> rick_h_: Just wondering what needs working on next. I could start tackling all the feedback from design or I could move into the cards for MV. Very hesitant to start in on an IL card until hatch is in, to make sure we aren't setting up painful merge conflicts.
<rick_h_> kadams54: yea, any MV card, especially that was part of our planning poker for this sprint is good
<rick_h_> kadams54: there's some wire cards that might work out
<rick_h_> kadams54: did you move all the cards you had created in there? 
<kadams54> Yeah, going to start in on the one for choosing constraints
<rick_h_> ah cool, thanks for moving those to the pool. I think on deck would be good as well
<kadams54> rick_h_: I moved them into the Pool for Project 1, per hatch's suggestion yesterday.
<rick_h_> but nice to split out back down to our planned work for the sprint
<rick_h_> +1
<kadams54> Also setup a metatask card for the design feedback
<rick_h_> I'll be doing card gardening today/tomorrow
<kadams54> I did real gardening yesterday.
<kadams54> I suspect you'll end up with fewer mosquito bites.
<rick_h_> awesome, had enough of those to last me a while this week :)
<kadams54> Though I suppose that depends on where you're camping :-)
<kadams54> I have NEVER seen mosquitos this bad
<rick_h_> did you see my pics?
<kadams54> No, where at?
<bac> hey frankban, we've also got to do a quickstart release to get the OS X support...my brew recipe works but it installs 1.3.2 and then promptly fails b/c it doesn't have the new work.  i'll be glad to start on the QA, do the release, whatever.
<bac> rick_h_: your pics were good.  liking the new camera?
<rick_h_> bac: <3 I upgraded from the kit lense yesterday and got a tripod so looking forward to playing with it some more
<rick_h_> kadams54: https://www.flickr.com/photos/7508761@N03/14300218662/ and https://www.flickr.com/photos/7508761@N03/14115492088/
<kadams54> moving up from a kit lens is such a *huge* improvement
<bac> rick_h_: which tripod? there some cool, lightweight travel ones out now
<frankban> bac: ok, I'll make the deb packages in quickstart beta, then I'd appreciate your help for QA
<rick_h_> bac: mefoto one, the middle one
<rick_h_> bac: it'll do a monopod as well which I liked for travel
<bac> rick_h_: yeah that's one of the ones i was thinking of
<kadams54> rick_h_: Yeah, that's about right. The only thing I've ever seen that's even close is the swarm of mosquitoes above the latrine at Minnesota camp sites in the Boundary Waters.
<bac> frankban: great!
<rick_h_> ok, car is ready...out for a bit
<kadams54> Have fun!
<bac> rick_h_: i hope you got the purple
<frankban> rogpeppe: is juju/utils usable?
<rogpeppe> frankban: it should be
<frankban> rogpeppe: ok thanks
<frankban> rogpeppe: I'll tackle the FakeHomeSuite next
<rogpeppe> frankban: i'll change charm so that it doesn't use environs/config
<frankban> rogpeppe: sounds good
<frankban> rogpeppe: don't we need to remove some packages from utils in core?
<rogpeppe> frankban: ah yes, and most of utils itself
<rogpeppe> frankban: i'll do that too
<rogpeppe> frankban: along with making juju use utils
<frankban> rogpeppe: yeah thanks, so that you can move your current card to done
<frankban> rogpeppe: names removal landed in core
<frankban> bac: quickstart packages pending
<frankban> bac: https://code.launchpad.net/~juju-gui-charmers/+recipe/juju-quickstart-daily
<bac> frankban: so we will qualify the .deb, then release to pypi, and then i can qualify on os x, and try to get the brew formula accepted.  sound about right?
<frankban> bac: sounds good
<frankban> bac: do you have a saucy vm?
 * bac looks
<bac> frankban: i do.  i collect them like baseball cards
<frankban> bac: heh
<bac> lucid, quantal, raring, saucy, trusty ... and some from lesser OSes
<frankban> bac: so QA can be something like: verify lxc envs work, verify ec2, verify idempotence, check bundle deployments work.
<frankban> bac: the above on trusty and saucy, and that should be enough
<bac> frankban: how is the idempotence step done?  you mean uses existing bootstrapped env?
<frankban> bac: quickstart must be installed from the PPA, and the machine should not have juju-core installed (so that we can also verify juju installation)
<frankban> bac: yeah, running on an existing environment, perhaps also running on an existing environment without the GUI deployed
<rick_h_> bac: red :P
<rick_h_> bac: frankban a doc of qa for a release like that would be useful as things get more complex. I'm not sure how to look into automating test/qa across OS and systems like that now. 
<bac> rick_h_: i'm starting a QA doc.
<rick_h_> bac: rock on! 
<bac> will do google doc for now and we can move it to the tree if we want
<rick_h_> yea, in tree ftw so it's easy to update it as required as the code changes
<rick_h_> and easier to hand off next ccyle
<rick_h_> cycle
<bac> rick_h_: even though you are not here, did you see my question regarding local bundle ingestion?
<frankban> rick_h_, bac: +1 on a doc that will be merged into HACKING, but I'd really love if quickstart had functional tests which can be run by the juju CI against current and devel juju releases
<rick_h_> bac: no, I didn't see it sorry
<rick_h_> frankban: yea, definitely +1 on working with QA on that. Not sure how much OSX QA they can setup but maybe there's others around we can ask about these sorts of issues. 
<bac> our friend has local charm ingestion working.  he'd now like to do local bundles.  i've never tried it so i'd have to get it to work then document.
<rick_h_> what is a 'local bundle'?
<rick_h_> ah, a bundle with local charms...not going to happen right now. 
<bac> he wants his bundles to show up in the sidebar of juju gui
<rick_h_> yea, that's not currently supported. 
<bac> well...if he's running his own charmworld (he is) and has ingested local charms as he has, then ingesting bundles should just work, for some amount of config/poking.
<bac> unless i'm missing a failure point regarding the charm store or something
<rick_h_> well we'll have to walk him through getting those bundles ingested as he doesn't want to submit them to lp charms/bundles
<rick_h_> and honestly we've got a really nice chunk of time sunk into this 
<hatch> now that core has switched to GH and is getting an email per comment......holy smokes lots of emails hah!
<redir> rogpeppe: frankban am I missing something here? http://juju-ci.vapour.ws:8080/job/github-merge-juju/23/console
<redir> how can there be panics and FAILs and pass?
<frankban> redir: uhm, it seems tests run a first time and failed, and then a second time successfully
<redir> mmm yes I missed the + go test -p 2 ./...
<frankban> redir: so the first time they failed using all the cpu cores. subsequently the lander switches to using 2 cores
<redir> -p is cores? and not -cpu?
<redir> jujugui standup in 10
<frankban> redir: the number of builds that can be run in parallel
<frankban> redir: from "go help build"
<Makyo> hatch, ping
<hatch> yesm
<Makyo> Just curious if our branches are going to collide.  Is the solution you're working towards the fact that there are two div.left-breakout elements and the fillSlot code is not grabbing the right one?
<hatch> Makyo yes ish - I'm still trying to determine the right approach
<hatch> there are left-breakouts which aren't used
<hatch> then there is the bws-data elements which are
<hatch> but they are using the wrong ones
<hatch> this stuff is really borked
<hatch> chat after the standup?
<Makyo> hatch, yep, that sums it up nicely.  We'll talk then.
<Makyo> jujugui call in 2
<bac> jcsackett: i'll be glad to look at your charmworldlib MP
<jcsackett> bac: oh, it's coming. but it'll have to be slack.
<bac> jcsackett: ok.
 * rogpeppe wishes that you could see the comment that was being replied to in git code review comments.
<hatch> rogpeppe you can
<rogpeppe> hatch: ... by going to the web page, right?
<hatch> yeah - unless they rebased it away
<hatch> then it only has the few lines surrounding it
<hatch> rogpeppe it could be worse, it could be LP which doesn't even give you a link to the repo in it's emails lol
<redir> change is hard
<kadams54> hatch: you available to chat?
<hatch> just feeding the dogs, 2 mins
<kadams54> redir: Yeah, that's why I decided to be a programmer. A nice, comfy career secluded from change. ;-)
<redir> :)
<redir> kadams54: at least for several minutes at a time
<hatch> kadams54 ok - standup room should be empty
<hatch> blah it dropped
<hatch> one sec kadams54 
<kadams54> maybe I'm not the one with bandwidth/lag issues ;-)
<frankban> bac: quickstart packages are ready
<redir> rogpeppe: is there a command to create the juju lxc container templates ?
<rogpeppe> redir: no AFAIK. i think they should be created automatically by juju.
<redir> rogpeppe: I mean without deploying something
<rogpeppe> redir: what are you trying to do?
<redir> I am trying to get consistent test  passage
<redir> I have 2 machines with lxc containers that have nothing but juju core on them 
<redir> one passes all tests with -p 2 flag and the other fails lxc-test 
<redir> oh well. 
<redir> it works on one, I'll work on that machine:)
<hatch> kadams54 ok review done - feel free to take a look and lemme know where you want to go from here
<kadams54> ok
<frankban> bac: resulting package is broken, missing "python-websocket-client". I'll try to fix that.
<frankban> bac: re-building...
<frankban> bac: packages should be ready in ~30mins. I am not sure about "websocket-client" in saucy and precise (maybe we will need to create backports) BTW if they install correctly feel free to proceed with QAing and release. Releasing involves steps in http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/HACKING.rst#L101
<hatch> kadams54 so thoughts on my comments?
<kadams54> hatch: oh yeah, sorry, they look good, working on implementing right now
<hatch> ok great - you'll need to close Huw's and re-PR unfortunately
<hatch> I wish people could do coop PR's
<rogpeppe> i'm done for the day
<rogpeppe> g'night all
 * bac misses having LP super powers to bump up build farm priority...
<hatch> bac haha, I thought you had those up until recently
<hatch> when did they get taken away?
<Makyo> YES
<Makyo> Got it.
<Makyo> Finally.
<Makyo> There are so many tiny little parts to the viewlets system.
<Makyo> It's pretty cool when it works right, though!
<hatch> Makyo YAY! 
<hatch> Makyo I would be interested in hearing ways to make it easier to follow 
<Makyo> Probably could've used some RTFM on my part :)
<hatch> lol
<hatch> I'm also pretty pumped about this cache system
<hatch> little concerned noone else will be though haha
<Makyo> I promise I will be sufficiently pumped.
<rick_h_> :) why would no one else be pumped hatch?
<hatch> rick_h_ because it's magical!
 * rick_h_ raises eyebrows at the word 'magic' in the area of coding
<rick_h_> as long as it's not so magical that only a wizard can figure it out later after years of additional study :P
<hatch> haha
<hatch> https://github.com/hatched/juju-gui/blob/caching-charmbrowser/app/utils/cache.js
<hatch> ^ rick_h_  Makyo 
<Makyo> TWO underscores! That really is magic.
<kadams54> That's python-agical.
<kadams54> Dunder here we come!
<hatch> lol - the more underscores is the importance of the dev not using it directly
<hatch> at two you BETTER know what you're doing :P
<hatch> three...well three....wow
<hatch> just no
<hatch> just FYI that code doesn't run, I had a bug in there :)
<rick_h_> huh? one public method, no tests to follow expected working/use :P
<hatch> I'm writing the rest of the tests now
<Makyo> JDD - Jeff Driven Development.
<hatch> lol
<hatch> WWJD
<hatch> What Would Jeff Do
<hatch> <sub>Is probably not what you want to do</sub>
<hatch> lol
<hatch> so our linter gets confused by functions in comment blocks
<hatch> yay....
<hatch> lol
<hatch> jujugui looking for a review of the new cache object https://github.com/juju/juju-gui/pull/368
<redir> If I knew JS I would look at it and say __LGTM__, alas the joke falls flat
<bac> hatch: i'm not sure when my wonder-powers were removed.  probably when they noticed all of my PPAs hogging the build farm. :)
<hatch> redir lol
<hatch> bac haha
<hatch> so.......anyone able to do that review? jujugui.......beuler? 
<jcsackett> hatch: sure.
<redir> hatch: __UNQUALIFIED__ :)
<hatch> jcsackett sweet thx
<jcsackett> hatch: no tests?
<hatch> umm
<hatch> crap
<hatch> one sec
<jcsackett> k.
<hatch> ok tests :)
<hatch> man I'm fast at writing tests eh? :P
<jcsackett> superfast. :p
<jcsackett> hatch: this is really hard to review absent its use; two things stand out to me: why are we bothering with supplying special setters/getters? is there a use case already?
<hatch> jcsackett interesting and search
<hatch> well search*n for each search query
<hatch> it's a highly generic cache layer which allows you to do with it what you want
<jcsackett> hatch: yeah, i'm just saying it seems overly generic. but that's not a big deal.
<hatch> correct it is
<jcsackett> my bigger question is also a comment in the PR. that whole autogenerating setters/getters thing.
<jcsackett> i don't see how that's desireable--i would much rather cache.set(key, data) than cache['get'+key](data) if i'm doing caching of arbitrary objects, which seems likely.
<hatch> sure, replying
<jcsackett> hatch: ok. wasn't sure if you preferred here or in github, given the long convo in the other channel we had earlier. :)
<jcsackett> but i guess that was more python questions than code review.
<hatch> oh haha yeah that was mostly pythony related
<hatch> ok replied
<rick_h_> replied :)
<jcsackett> he emerges, from the deeps.
<rick_h_> builder just got through telling me my $30k screened porch should be a $90k+ addition :/
<rick_h_> so disclaimers and all that 
 * jcsackett laughs
<hatch> rick_h_ did you tell them that they can do whatever they want as long as it's $30k? lol
<rick_h_> heh
<jcsackett> hatch: assuming i'm swayed on the custom getter/setter thing, i think i can be convinced this is all lovely if you make the "getnameofthing" functions "_getnameofthing" and give me a get(key, data) function that grabs the goofy name and calls that.
<jcsackett> but that's a workaround if i'm swayed on the custom bit.
<hatch> jcsackett if we want it to be super basic we can just use a global object and call it a day
<hatch> then if you want a custom getter/setter hang it off the object
<hatch> this was an attempt to formalize access of the cache
<jcsackett> i mean, i'm pro a uniform cache for everything; and i like a wrapper protecting access to an internal __storage object that deep copies.
<rick_h_> hatch: so the requirements are a shared object with a single modellist for all cached charm models + a flexible list of defined/named modellists (interesting, search_term1_term2) or the like?
<jcsackett> hatch: i'll be back to continue looking at this soon--have to make an emergency run to the store.
<hatch> rick_h_ replied to your request for the use case
<rick_h_> hatch: ty
<rick_h_> reviewing more thoroughly now
<hatch> jcsackett I think I might agree with your get('nameofthing') to _getnameofthing() conversion
<hatch> thinking through it 
<rick_h_> hatch: replied and reviewed
<jcsackett> hatch: cool. 
<hatch> it makes it cleaner to interact with, I see no down side to it
<hatch> back from the store already?
<hatch> wow
<jcsackett> On my phone. It beeped as I was getting in my car. 
<hatch> oh :)
<jcsackett> Call my name and I shall appear. Assuming my IRC notifications aren't all hacked up. :p
<rick_h_> beatlejuice beatlejuice jcsackett 
 * rick_h_ checks if it worked 
<jcsackett> Oh, to do that it has to be in a mirror in the dark. 
<jcsackett> Hatch: with the change to the customs being _ and a get/set db that looks up the customs, my chief complaint is addressed. 
<jcsackett> rick_h_ clearly has several that I think are valid. 
<hatch> rick_h_ lol!!
<hatch> rick_h_ replied to the long thread again :)
<hatch> replying to the rest now
<rick_h_> hatch: ok, replied back one more time. I've got to run at the moment sorry. 
<Makyo> jujugui https://github.com/juju/juju-gui/pull/369 databinding for unit details + viewing charm details PR for review and QA
<hatch> Makyo sure I'll hop on that
<hatch> Makyo heh it's such a good idea that we didn't work on this at the same time - there was so many conflicts haha
<Makyo> Right? :P
<hatch> Makyo your branch also fixes the charm details panel fyi
<Makyo> hatch, yep, that was the goal.
<Makyo> Just poorly named.
<hatch> dun and dun
<Makyo> Cool, replied and prepping for another push.
<Makyo> Should be landable, though
<hatch> rick_h_ jcsackett  ok I'm not entirely sure where to take the caching branch - do I remove the functionality and just go for a 'dumb' key/value object store or add the generic get('key') like methods and leave the advanced functionality?
<rick_h_> hatch: I think it's worth this discussion. I see your idea about the database, but I feel like that's the wrong place (thus the cache) since the db can be modified by env and such
<rick_h_> hatch: the results form charmworld are static, unchanging, pure cache
<hatch> right - but I am trying to figure out where removing the functionality makes it a better tool
<rick_h_> not live models for modifying/etc. They get copied on deploy, and I agree we should not re-request them, but we should be copying them from the cache into the db via that code I think
<rick_h_> I'm for a lighter cache to get started and adding complexity as required by use cases. I think that helps keeps this from being that big chunk of work as well for now. 
<rick_h_> but that's how my head works, interative development
<hatch> I'm not sure I agree with you on that cache to db stuff :) 
<hatch> right, but it's already written
<rick_h_> and I'm just not sold on the bigger picture cases so far.
<hatch> so removing the functionality is actually more work :)
<rick_h_> hatch: yea, but it's overhead. long term maint. overhead
<rick_h_> every time someone tries to figure out 'how does this work' overhead
<rick_h_> it's 10x the 'let's clear it up now' work levels
<hatch> ok then all of this is simply WAY to good, might as well just create an instance of Y.Attribute and call it a day
<rick_h_> lol
<rick_h_> well I think we can chat on the db point, that seems to be the heart of this. You've got a use case I'm not following yet
<hatch> but really, then it has getters and setters, and it's an object store
<hatch> the app.js can just go this.cache = new Y.Attribute() and it's done
<hatch> lol
<rick_h_> well I don't even know getter/setters are required. What do they get us? We're not waching/eventing on this
<rick_h_> hatch: heh, except we want to pass the object instance around down to views/etc. and I think it might belond on state tbh
<hatch> so then we don't need a new class at all
<rick_h_> kind of like that one bit of state that's out of band already, /me tries to recall it
<hatch> just create an object
<rick_h_> hatch: maybe not, the main goal was to get it out of browser.js
<rick_h_> so that it's not so smart and center of the world with stuff so it can be shared better
<rick_h_> what use case does an object on state fall apart at?
 * rick_h_ is trying to think this through 
<hatch> I wouldn't put it in state because I think it's bringing stuff along with it that is unnecessary, I'd definitely keep it separate
<rick_h_> ok 
<hatch> so now the question is....why won't a dumb object work
<hatch> it's not a very 'clean' approach 
<rick_h_> so for the use case of charm/bundle models it seems sensible. a dumb object of model lists
<hatch> impossible to test
<hatch> there isn't anything 'to' test
<rick_h_> ok, so a simple get/set api on top of a dumb object makes it a cleaner api?
<hatch> it does, because then you can see 'ok here we have a cache' 
<rick_h_> hatch: well, that's kind of the nice thing. You test things that are cache-enabled. And make sure they read from the cache data without making a new request, or that they update the cache data 
<hatch> right but there is no 'cache' it's just an object
<rick_h_> ok, so I can +1 a get/set but without the magic method per cache key
<hatch> there is no implicit.... I am a cache, hear me roar
<rick_h_> hatch: right, but that's what makes it easy to test :) 
<hatch> (i'm just talking it out btw)
<hatch> get and set without any bonus kind of feels like a waste 
<rick_h_> so maybe calling it a cache is a bad word? Is there a better way of calling it "hey view, here's some existing useful data to help speed things up for you"
<hatch> (which is a cache) :P
<rick_h_> well you're saying an object is no cache, that it's ugly without an api, so I'm trying to figure out how to do it in a light weight way that provides and api and 'feels' cachy (aside from the name of the argument being cache or modelCache)
<hatch> an object will work just fine as long as nobody touches it
<jcsackett> i mean, caches frequently are dumb, so a protected storage thingy with get and set and ensurance that we're deep copying doesn't sound like a waste to me.
<hatch> when you wrap it inside an instance it's much harder to touch
<hatch> you have to be explicit about accessing it
<rick_h_> hatch: ok, so then the thing to figure out is how to update teh cache
<rick_h_> in the old system the Views fired a cacheUpdate event with the new data to cache
<hatch> I think the cache should be passed in
<hatch> but then everyone can access the object
<hatch> without going through a setter/getter
<hatch> they could accidentally empty it too
<hatch> so that's the issue with a basic object
<hatch> no protection at all
<rick_h_> well, I think we can unblock ourselves with a simple object for now and move forward towards release. And keep in mind the tools available if a more complex use case presents itself. However, we don't currently have those to drive the decisions on what to implemnt
<rick_h_> and if it's simpler now, it's less to update/replace down the road when a real use case does jump out and hit us
<hatch> ok I'll scrap this branch
<hatch> the cache will live in the browser though
<hatch> I don't think this cache needs to be passed from the app
<hatch> at least for now
<rick_h_> why in the browser? How does that work with the inspector and other use cases? 
<hatch> like browser.js 
<rick_h_> that's been a limitation of the last work. If the inspector loads up a charm details it can add it to the cache
<hatch> it should be adding that to the db
<hatch> not to the cache
<hatch> it's a fully populated model then
<huwshimi> Morning
<hatch> that's where grabbing keys for the search/interesting makes more sense
<rick_h_> ok, but before it's added to the db is can get an initial default values/etc from the cache
<hatch> morning huwshimi 
<huwshimi> hatch: Hey
<hatch> lol I really don't agree
<rick_h_> but it needs access to that, I guess the inspector is in the browser at this point but it feels like it's not the right place to keep it out
<hatch> ok I think I got something
<hatch> put the cache in the db
<rick_h_> hatch: call?
<hatch> everything has access to the db already
<hatch> sure
<hatch> I think it's aus call time too
<rick_h_> but the browser never ever touches the db, now all that code needs a db instance passed down which allows it to touch a bunch of stuff it never should need to
<hatch> im in the aus room
<rick_h_> huh? the charmresults has db access currently?
<hatch> no browser.js does
<hatch> kadams54 did you end up re-proposing huwshimi  branch?
<hatch> huwshimi so kadams54 took over your branch (the one he closed) to apply the changes from my comments. I don't see anything in his fork about that so maybe you want to take those comments and run with them today?
<hatch> huwshimi this is the PR in question https://github.com/juju/juju-gui/pull/366
<huwshimi> hatch: OK, was there a reason he needed to pick it up (was it blocking something)?
<hatch> huwshimi he was going to take it, fix the comments, then add the functionality to the container as well
<huwshimi> Ah I see
<hatch> so yeah...if you're blocked on that not landing then maybe you can continue on your own branch
<hatch> sucks to be duplicating work but I'm not sure where it's at
<huwshimi> hatch: Do you know if he started working on the container constraints?
<hatch> huwshimi no idea, sorry
<hatch> huwshimi maybe you can ping kadams54  periodically over the next few hours :P
<huwshimi> :)
<kadams54> actually i'm here now
<hatch> it worked!
<kadams54> for about 5 seconds :-)
<hatch> :P
<kadams54> location change
<hatch> kadams54 where are you with huwshimi's branch?
<kadams54> and then we can talk more
<hatch> oh ok
<kadams54> hatch, huwshimi: back. Here's the update: I'm fixing tests that broke in refactoring. My plan was to push once those tests were fixed.
<kadams54> Unfortunately I won't be able to resume work on them for another 45 minutes. So hopefully it's not blocking?
<huwshimi> kadams54: That's fine, not blocking me!
<kadams54> huwshimi: great.
<kadams54> huwshimi: your branch implemented about half of the card I picked up, which is how I ended up on it in the first place :-)
<huwshimi> kadams54: Ah yeah, are planning on re-using that view and using it in the containers column?
<kadams54> Yes
<huwshimi> kadams54: Great, I assume you'll do the container type card at the same time?
<kadams54> huwshimi: "wire deployed unit token UI for choosing container type" - that card?
<kadams54> I was planning on tackling that next :-)
<huwshimi> kadams54: Yeah
<huwshimi> kadams54: Well, it's the step before the constraints are show...
<huwshimi> *shown
<huwshimi> kadams54: Might make sense to do them at the same time, or do the container type card first (if it can be broken out)
<kadams54> I was going to do it after the constraints work because that was already in progress on your branch.
<kadams54> So the plan was to wrap up your branch, get it landed, and then start on container types.
<kadams54> That said, we'll see how things go once I get the kids settled in bed ;-)
<huwshimi> kadams54: OK, well, whichever way make sense, I guess either way you need to do a bit of refactoring.
#juju-gui 2014-06-06
 * huwshimi heads to cafe
<rick_h_> morning party people
<frankban> hi rick_h_: welcome back
<frankban> rogpeppe1: I am looking at FakeHomeSuite. It seems we can either 1) embed IsolationSuite in it: this means we can safely assume all the JUJU_* env variables are empty as expected by the tests, but also means lots of tests will explode in core (and need to be fixed) due to the fact they do not use complete paths when calling external commands.
<frankban> rogpeppe1: or 2) just use Logging and Cleanup suites in FakeHomeSuite. This means we'll need to move the JUJU_* en var resetting logic (currently in BaseSuite) to FakeJujuHomeSuite
<rogpeppe1> frankban: hmm
 * rogpeppe1 goes to look at BaseSuite
<frankban> rogpeppe1: basically FakeJujuHomeSuite tests need os.Setenv(osenv.JujuHomeEnvKey, "") stuff (currently in BaseSuite)
<frankban> rogpeppe1: but most of them also need PATH to not be empty (and I guess this should be fixed)
<rogpeppe1> frankban: the worry i have moving the JUJU_ env setting stuff to BaseSuite is that tests that currently use BaseSuite won't get the benefit of that
<frankban> rogpeppe1: JUJU_ env setting stuff is already in BaseSuite
<frankban> rogpeppe1: and that does not seem right BTW
<rogpeppe1> frankban: sorry, i meant "away from BaseSuite"
<bac> hi frankban
<rogpeppe1> frankban: it does seem kind of "right" that the JUJU_ env stuff should be in FakeJujuHomeSuite though
<frankban> rogpeppe1: I am not suggesting to remove those from BaseSuite. I guess eventually BaseSuite will embed IsolationSuite, which removes all the env vars, but for now that's not my goal
<rogpeppe1> frankban: can't FakeHomeSuite embed BaseSuite?
<frankban> rogpeppe1: yeah, but the problem now is that FakeJujuHomeSuite embeds FakeHomeSuite, which in turn embeds BaseSuite. I am moving FakeHomeSuite to github.com/juju/testing and I have two choices: 1) make FakeHomeSuite embed IsolationSuite and 2) make FakeHomeSuite just embed Logging and Cleanup suites (without removing env vars)
<frankban> rogpeppe1: 1) means we need to fix all the FakeJujuHomeSuite and FakeHomeSuite tests which rely on PATH to be set
<rogpeppe1> frankban: what's the problem with "FakeJujuHomeSuite embeds FakeHomeSuite, which in turn embeds BaseSuite" ?
<rogpeppe1> oh, i see, sorry
<rogpeppe1> frankban: i think that 2) seems a reasonable way forward currently
<frankban> rogpeppe1: 2) means we need to have the JUJU_ resetting logic in FakeJujuSuite
<frankban> sorry FakeJujuHomeSuite, darn!
<rogpeppe1> frankban: that seems fine
<rogpeppe1> frankban: and actually quite appropriate
<frankban> rogpeppe1: sounds good. So do you mean moving that JUJU_* logic from BaseSuite to FakeJujuHomeSuite or just make them share the same logic?
<frankban> bac: morning
<rogpeppe1> frankban: perhaps duplicate for the time being, to ensure we don't regress, adding a TODO to make BaseSuite embed IsolationSuite
<frankban> rogpeppe1: sounds good thanks. today lesson: always use complete paths
<rick_h_> frankban: rogpeppe1 if you guys get a second wonder if we can do a quick hangout to catch up on where the store extraction stands please. I'm not 100% clear looking at the board. 
 * rogpeppe1 generally only wonders once
<rick_h_> :)
<rogpeppe1> rick_h_: happy to have a hangout whenever
<rick_h_> it's that second wonder that provides true clarity 
<rick_h_> rogpeppe1: frankban https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
<bac> frankban: i think doing the backport of 0.12 to saucy and precise is cleanest.  should be straightforward.
<bac> frankban: but changing the quickstart packaging branch between PPA builds is not sustainable.  :)
<bac> frankban: but if we're going to do a backport of 0.12 we could make the package name python-websocket, as in trusty, and the whole problem goes away, right?
<frankban> bac: then you have jujuclient which still depends on "python-websocket-client" on saucy and precise
<frankban> bac: so, I guess the plan is: 1) trusty is ok 2) backport python-websocket 0.12 as python-websocket-client on saucy and precise 3) add the backported packages to the quickstart-beta ppa and to the juju-stable ppa
<bac> frankban: but do we still have a build issue? or is the current code, with websocket in test-requirements, a-ok?
<frankban> bac: it should be ok, right now quickstart installs on trusty and saucy. we only need a newer websocket-client on precise and saucy
<bac> frankban: ok
<jcsackett> morning, all.
<rogpeppe1> argh, wrong upstream
<redir> morning jcsackett 
<redir> aweful lag:((
<kadams54> guihelp: Anyone else here make heavy use of buffergator in vim?
<rick_h_> never heard of it
<rick_h_> lustyjuggler user here
<redir> what's vim?
<rick_h_> redir: that's it, you're fired :P
<kadams54> :-b
<kadams54> LOL
<jcsackett> i use lustybuffer, rather than juggler. juggler would crash periodically on me for reasons i never bothered to investigate.
<jcsackett> buffergator looks nice.
<redir> Is it this http://bit.ly/Tm8jat ?
<kadams54> :-)
<kadams54> No way am I touching that link
<redir> sure youren't 
<redir> it's calling you
<kadams54> Hah!
<kadams54> Like a siren
<kadams54> I should make a chrome extension that pre-examines target pages for shortened URLs and when it finds a rickroll/goatse/whatever on the other side instead displays a "stop being a putz" message.
<redir> kadams54: I'd use it
<kadams54> I think there's a real market for it ;-)
<rogpeppe1> woo, testing/filetesting changes finally merged
<rick_h_> rogpeppe1: yay!
<rogpeppe1> hmm, i'm seeing this message when committing a merge:
<rogpeppe1> # It looks like you may be committing a merge.
<rogpeppe1> # If this is not correct, please remove the file
<rogpeppe1> #	.git/MERGE_HEAD
<rogpeppe1> # and try again.
<rogpeppe1> does anyone know how/why i might be seeing that and if it's a significant problem?
<kadams54> http://git-scm.com/book/ch3-2.html
<kadams54> See at the very bottom of the page
<rogpeppe1> kadams54: oh, right, so it's just normal behaviour
<rogpeppe1> kadams54: thanks
<kadams54> It's not necessarily a problem, if you are in fact committing a merge 
<kadams54> Yup
<redir> sheesh so there are already like 5 swift meetup groups in new york I have gotten emails about.
<rick_h_> yay swift :P
<redir> silly
<hatch__> such facepalm
<hatch__> it's actually a pretty cool language
<hatch__> but its so high up in that tower over there
<redir> yay doge meme, now that will by stuck in my head for another week, thanks hatch
<redir> I'll be in Pisa muttering *such historic* *very tilting*
<Makyo> jujugui call in 10
<hatch__> :)
<hatch__> woah
<hatch__> I think I was lagged huge there
<hatch__> did everyone get the 10min warning?
<rick_h_> got it here
<hatch> ok cool, that was odd
<hatch> it just stopped responding and booted me so I wasn't sure
<rick_h_> well, I got Makyo's 10min warning
<hatch> oh...
<hatch> https://twitter.com/FromAnEgg/status/474927316846403585 hehe
<rick_h_> jujugui call in 2, get your kanban ready and prepare for a long poker call wheeee
 * hatch plays with his chips
 * hatch puts his hoodie and sunglasses on
<rick_h_> kadams54_: as well :P
<rick_h_> rogpeppe: call time
<frankban> rogpeppe: when you have time: https://github.com/juju/testing/pull/12/files
<bac> hatch: English words with 'mv':  http://paste.ubuntu.com/7602348/  -- we're pretty safe.
<rogpeppe> frankban: reviewed
<frankban> rogpeppe: thanks, I agrre with you, perhaps in these cases not rebasing before the proposal can be a good idea
<rogpeppe> frankban: yeah, definitely
<rogpeppe> frankban: could you revert and re-push, in fact?
<rogpeppe> frankban: i.e. revert to before your rebase
<frankban> rogpeppe: not sure. BTW, the suite itself and the test file is new code. so basically home.go from line 83 and the whole home_test.go
<rogpeppe> frankban: i'd still like to see the diff, if poss
<rogpeppe> frankban: just to see what the old code looked like
<rogpeppe> frankban: i guess i could just look in my editor :-)
<frankban> rogpeppe: original code is in /testing/base.go
<rogpeppe> frankban: still LGTM
<frankban> rogpeppe: cool thanks
<bac> rick_h_: paste here please
<rick_h_> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0ApyaFXSrLF38dGVCYUhGLTRXMXRaVXBCMUFjQlJMTkE&usp=drive_web#gid=4
<hatch> rick_h_ I can take a look at the review board thing if you like
<rick_h_> hatch: coolio, I'll send an invite to your email
<hatch> thx
<rick_h_> bac: still have power and water?
<bac> both!
<rick_h_> woot!
<hatch> on that topic - we are getting the new 'smart' gas and power meters sometime over the next month
<rick_h_> hatch: I've got mine, it just means they get to tell me how much a power hog I am over my neighbors
<hatch> rick_h_ lol
<frankban> rick_h_: I filed my summer holidays in the new hr site
<hatch> we have a coal power plant....they can't burn less if they wanted to!
<hatch> not sure what the smart meters will do lol
<rick_h_> frankban: looking
<rick_h_> frankban: interesting in checking ot the reviewboard stuff? You were interested in the side by side reviews? 
<rick_h_> anyone else?
<frankban> rick_h_: sounds interesting
 * rick_h_ goes to get some lunch
 * frankban biab
<hatch> hey who's cHilDPROdigY1337 ?
 * redir blinks
 * redir actually bL1Nk5
 * redir goes to grab some lunch
<hatch> lol!
<hatch> I'm not convinced about this new hr portal lol
<hatch> jujugui looking for a very quick review on the new cache https://github.com/juju/juju-gui/pull/371
<kadams54> On it
<kadams54> Ow my eyes!
<kadams54> They burn, they burn!
<hatch> yeah it's so basic
<hatch> sorry...lol
<hatch> hmm I was sure I had a card to hook up the cache in project 1
<hatch> rick_h_ ^
<kadams54> The PR looks good and I'll reply as such in the commentsâ¦
<hatch> ahh found it
<rick_h_> hatch: yea sorry, sidetracked atm
<hatch> np
<hatch> I found the related card/bug
<kadams54> hatch: one thing that I wondered is if the cache needs to support expiration.
<hatch> ugh I friggen hate test failures under prod
<kadams54> I suppose you could expire to a certain extent by setting a key to null
<hatch> kadams54 no this cache is one step above a manilla folder 
<rick_h_> reload the page :P
<rick_h_> it's something we can look into, but since the cache is charm/version specific it can't change 
 * kadams54 ponders a world where one step above a manilla folder is 126 lines of javascript
<hatch> 90% of which are comments
<kadams54> Still. I think we're more than a few steps above a physical world object ;-)
<hatch> haha maybe a few
<hatch> kadams54 I am going to continue working on my other cache class though - how would YOU do expiration? able to supply a timestamp or a fn which is called periodically? 
<hatch> lazyPower hey, this is me poking you about my Ghost charm again :) I want to put out a blog post et all but can't until it's in the store :)
<lazyPower> hatch: bcsaller is on rev this week
 * lazyPower politely redirects
 * hatch puts on his hunting cap and goes hunting him down
<hatch> jujugui recently there have been a lot of test failures around the 49th test - has anyone looked into why this is happening?
<rick_h_> hatch: what's the 49th test?
<hatch> rick_h_ well it's -around- there, sometimes it's more, sometimes less
<hatch> I think you and frankban also saw this
<rick_h_> hatch: if it's that one no. I just saw it for the first time on frakban's branch trying to land
<hatch> can we create an investigate card?
<rick_h_> hatch: by all means, put it in maint. Make sure to have links to the failures we know about to debug
<hatch> created! Here is the failure rick_h_ https://saucelabs.com/jobs/2ce12db7af234450af18a44b6327e9c7
<hatch> the merge run on the other hand is running without issue
 * hatch punches test suite
<hatch> I am developer hear me roar!
<hatch> jujugui is there documentation for quickstart? The readme is pretty sparse 
<rick_h_> bac: jcsackett ping when you get a sec would like to chat please
<hatch> can quickstart be used to fire up the GUI into your active environment?
<hatch> juju quickstart -e amazon
<hatch> boom browser opens?
<rick_h_> jujugui board is loaded up with work items for the next two weeks. Let me know if anything looks off/unclear
<rick_h_> hatch: yep
<hatch> thanks
<rick_h_> wow, scheduling work for 9 devs now. Moar points of work!
<hatch> haha that is a lot of points
<bac> rick_h_: update: the backport packages are coming along.  since it wasn't a simple backport, but required changing the binary name, none of the simple tools like backportpackage could be used.  hopefully i'll have it up on the PPA for building very soon now.
<rick_h_> bac:  very cool
<bac> rick_h_: also, the brew formula is done and works with jj-qs 1.3.2.  but, of course, that version doesn't actually work with osx, but brew can install the hell out of it
<rick_h_> lol, that's good
<rick_h_> bac: got time to chat for a sec?
<bac> sure
<bac> let me grab my headphones
<rick_h_> sure thing
<rick_h_> https://plus.google.com/hangouts/_/g5f5fs3tejaybejaqipregrldma?authuser=1&hl=en
<rick_h_> jcsackett: ^ as well if you're around or get in
<hatch> I'm stepping away for lunch, ding if ya need me
<bac> jcsackett: overheated after five minutes.  back inside.
 * jcsackett laughs
<jcsackett> yeah, it's getting that bad here too. i basically can only go work on the porch in the morning.
<kadams54> It's the skeeters here.
<kadams54> It's sunny and 22C so I'd LOVE to work outside
<kadams54> But it's a veritable cloud outside
<kadams54> of bloodsucking beasties
<kadams54> hatch: the caching libraries I've worked with in the past usually had an optional param for expiration in milliseconds. So cache.set('foo', 4000) would expire 'foo' in 4 seconds.
<kadams54> Well, cache.set('foo', {timeout: 4000});
<kadams54> They also usually supported a cache-wide expiration that could be set in the constructor: cache = new Cache({timeout: 4000});
<bac> i love this advice on backporting:
<bac> Why Backport?
<bac> Short answer: Don't.
<rick_h_> lol
<hatch> kadams54 cool
<hatch> 13C here right now...brrrr
<hatch> it almost froze last night
<rick_h_> 25C here :/
<rick_h_> speaking of, I'm going to head out and get the boy from school. Have a good weekend all. 
<hatch> enjoy!
<redir> later rick_h_ 
<hatch> lol Makyo nice favourite 
<Makyo> Wow, hah.  Do you use tweetdeck?
<hatch> yeah lol
<hatch> some interesting stuff flows in there sometimes haha
<Makyo> Tweets scroll down from the top (like I suppose they do for most clients), had a tweet show up before I clicked.
<hatch> haha yeah that can be irritating
<Makyo> Loomy, alas, is on his own :)
<hatch> haha
<hatch> Makyo you're on the rendering bug right? Even with the new updated cache the issue still persists 
<hatch> just fyi
<Makyo> hatch, yeah, but I'm having a hard time nailing it down.  It is being rendered outside the dom, then added all at once, so I'm digging into sticky headers.
<hatch> Makyo hmm, you may find some insight in the rendering timeline
<hatch> I'm pretty confident it's within the token render cycle
<Makyo> Yeah, let me add more logs.
<hatch> because there is lots of GC around there
<Makyo> Okay.
<Makyo> It just shouldn't be touching the dom.  We're adding it to a new node.
<hatch> I mean the Timeline tab in  devtools
<Makyo> Ah!~
<Makyo> Good chance to learn it.
<hatch> there is a Frames tab in the top left
<hatch> you want that one
<hatch> yeah this is invaluable, lots of great info in here
<hatch> there
<Makyo> Man, that Object.observe polyfill is annoying.
<hatch> maybe we should evalutate doing a unidirectional data flow on that stuff instead of 2way binding
<Makyo> Yeah.  We're using it for the databinding on units, right?
<hatch> I have no idea hah
<Makyo> I think everything else is based on change events.
<hatch> ahh you are probably right
<hatch> yay caching works
<hatch> tests on the otherhand
<hatch> if you were to empty a cache
<hatch> cache.expire() ? 
<hatch> cache.empty() ?
<hatch> cache.happyPants() ?
 * hatch is thinking happyPants
<Makyo> cache.freeeeee()
<hatch__> not sure if everyone got that last msg
<hatch__> jujugui I have hooked the cache up to the charmbrowser and the charm details views here is the WIP (only tests are next) comments appreciated https://github.com/juju/juju-gui/pull/372
<Makyo> Alright, heading to the new house.  See you all next week.,
<hatch> cya Makyo 
#juju-gui 2014-06-07
<hatch> Makyo jcsackett if you guys are around, mind taking a look at the comments from the Ghost blog charm review and lemme know what you think
#juju-gui 2015-06-02
<lazyPower> rick_h_: ping
<rick_h_> lazyPower: /me isn't here but pong
<lazyPower> ah, i'll bug a subordinate if one is around - https://bugs.launchpad.net/charms/+bug/1461144
<mup> Bug #1461144: bigdata-charmers charms not showing up on jujucharms.com <Juju Charms Collection:New> <https://launchpad.net/bugs/1461144>
<lazyPower> Is there something special about certain namespaces in launchpad we've used as aliases for mature charms? like ~bigdata-charmers
<lazyPower> thats teh gist of that bug, is some branches were pushed yesterday and not showing in the store.
<rick_h_> lazyPower: yea, please bug folks. file the bug here: https://github.com/canonicalltd/jujucharms.com/issues
<rick_h_> and guys can look into it in the store
<lazyPower> ta
<rick_h_> I'm back tomorrow and will catch up and help make sure things are cleared up.
#juju-gui 2015-06-03
<frankban> marcoceppi: morning, do you have an estimated time for the redis charm review?
<asanjar> question for juju-gui experts, how a user should load a page (by clicking on ip_address: port ) for a subordinate service from juju-gui panel . There isn't "Running units" link on the side bar.
<asanjar> is that a bug ^^ or a feature :) 
#juju-gui 2015-06-05
<stokachu> rick_h_: is the charmstore down?
<rick_h_> stokachu: not atm, what's up?
<jcastro> hey hatch 
<jcastro> or frankban 
<frankban> jcastro: hey
<jcastro> http://askubuntu.com/questions/630361/juju-quickstart-failed-immediately-with-attributeerror-nonetype-object-has-n
<frankban> looking
<hatch> hey jcastro 
<hatch> frankban: that's quite odd that we never ran into that in our qa
<frankban> hatch: yes
<frankban> I wonder what's his output from /usr/bin/ssh-agent
<hatch> frankban: you can add a comment to his question and then hopefully he will reply 
<hatch> and hopefully file a proper bug in launchpad heh
<frankban> hatch: yeah I am doing that
<frankban> hatch: done
<hatch> frankban: technically that should have been a comment and not an answer...;)
<frankban> hatch: oops
#juju-gui 2016-06-08
<fabrice> 595470
#juju-gui 2016-06-09
<arosales> Hello, just as an fyi openstack charmers are hitting this issue with charm push in their workflow:
<arosales> https://github.com/juju/charmstore-client/issues/72
<arosales> beisner: ^
<beisner> thx arosales - actually that turned out to be this:  https://github.com/juju/charm/issues/201
<arosales> beisner: ah ok, looks like marcoceppi has the issue called out and its in the right repo. Thanks for reporting
