[00:01] <hatch> oh ok
[00:22] <hatch> gary_poster: just ran it through on ec2 and it completed successfully with ie and firefox both failing the unit tests first then retrying
[00:22] <hatch> so...yay!
[00:22] <hatch> now....canonistack....
[00:25] <gary_poster> hatch, heh, weird, but kinda good.
[00:26] <hatch> I just forwarded you the response from sauce labs
[00:26] <hatch> basically saying that it can't be caching
[00:27] <hatch> but now....haircut :)
[00:27] <hatch> have a good night
[00:27] <gary_poster> you too hatch, thx
[11:27] <teknico>  rogpeppe, hi, are you landing your lp:~rogpeppe/juju-core/259-charm-relation-name branch soon? it's conflicting with trunk in state/state.go, and I'm not confident enough to fix it myself
[11:32] <rogpeppe> teknico: yeah, i was planning to land it any time now. would you like me to hold off for a bit?
[11:34] <teknico> rogpeppe, uh? not at all, why would I? please go ahead :-)
[11:34] <rogpeppe> teknico: oh, cool; sorry i misunderstood.
[11:35] <teknico> rogpeppe, my command of the English language is definitely not up to these kinds of nuances :-)
[11:36] <rogpeppe> teknico: your english is great! i wasn't quite clear what you wanted though.
[11:45] <teknico> rogpeppe, since the AddRelationResults struct is now going to contain just Endpoints []state.Endpoint , I wonder whether I even need to define it
[11:46] <rogpeppe> teknico: the result of an api call must always be a struct
[11:47] <teknico> rogpeppe, oh, ok then
[11:47] <rogpeppe> teknico: i think i was thinking it would probably be better as Endpoints map[string]state.Endpoint
[11:48] <teknico> rogpeppe, oh right, sorry, I neglected that part
[11:48] <teknico> thanks for reminding me
[11:51] <teknico> rogpeppe, uhm, actually yesterday you suggested returning map[serviceName]charm.Relation, I wonder which one's best
[11:51] <rogpeppe> teknico: sorry, that's what i mean
[11:51] <rogpeppe> teknico: you can't return state.Endpoint
[11:51] <teknico> right
[11:57] <rogpeppe> teknico: that branch has now landed
[11:58] <teknico> rogpeppe, awesome, thanks again for all your work!
[11:58] <rogpeppe> teknico: np
[12:48] <gary_poster> rick_h_, hi.  I haven't been looking too carefully at the latest css changes, but please don't break the degree of responsiveness we had before.  Things look more or less ok right now, but I get nervous when I read "The new header is not yet responsive." from huwshimi.  Note that I do currently see a regression on the behavior when I resize the window: the right and bottom scrollbars are in place when calculations a
[12:48] <gary_poster> re made, add then removed when the new size is set.  This leaves gray bars at the right and bottom when it happens.  The way we solved that in the past was to shrink the interface to the smallest acceptable size before calculating dimensions, and then expanding it back out.
[12:48] <bac> guihelp: last week did we agree to not require "one 'var' per variable" or to forbid it?
[12:48] <rick_h_> gary_poster: definitely, I make sure to qa these before they ok'ing them. I'm also nervous as he's trying to start big picture where I'd prefer if he worked from our browser code up
[12:48] <bac> except in the case where it is multiline
[12:49] <gary_poster> bac we agreed to have multiple single line variables per "var"
[12:49] <bcsaller> bac: for simple assignments I think we made it optional, for complex (multiline) assignments its required
[12:49] <gary_poster> but one "var" per multiline variable
[12:50] <gary_poster> yeah, would be fine with what bcsaller said, though I don't remember that specifically.
[12:50] <rick_h_> gary_poster: yes, hatch caught the width issue and noted it in the MP but ok'd it. I'll create a bug and assign it to Huw. I asked him last night to create bugs where appropriate from the comments made in the last MP
[12:50] <bac> in cases of ambiguity defer to bcsaller is my rule
[12:50] <bcsaller> ha
[12:51] <gary_poster> cool thanks rick_h_ .  It is pertinent to both width and height.  sounds good.
[13:03] <benji> gary_poster: am I making a "Stable" release or a "Developer" release?  My guess is "Stable" but... development doesn't seem all that stable right at the moment. :)
[13:09] <gary_poster> benji why not?
[13:10] <benji> it's just that we are undergoing very active development, which I suppose is reflected in the 0.x nature of the verison numbers.  I just wanted to be sure I was doing the right thing.
[13:13] <gary_poster> stable and dev both benji, but let's have a quick guichat to make sure I am on the same page with you
[13:13] <benji> k
[13:18]  * frankban lunches
[13:19] <rick_h_> hatch: bcsaller looking to include a markdown converter, any opinions on a library? Currently looking at PageDown https://code.google.com/p/pagedown/wiki/PageDown
[13:20] <bcsaller> rick_h_: you mean different from the gallery one we already provide in a handlebars helper?
[13:20]  * gary_poster was just trying to connect those dots
[13:21] <rick_h_> bcsaller: /me goes peeking in the tree for something that might already be ther
[13:21] <bcsaller> app/views/utils.js markdown helper
[13:21] <rick_h_> bcsaller: never mind :) 
[14:01] <hatch> gary_poster: any ideas what to do when canonistack fails?
[14:02] <gary_poster> hatch, weep?  consider tackling other tasks?  stare out the window?  rotate in chair?
[14:03] <hatch> lol
[14:04] <gary_poster> hatch :-P for your branch just keep getting that prepped for review.  I have a plan for at least killing the canonistack failures faster
[14:04] <gary_poster> I sketched it last night
[14:04] <gary_poster> the only problem is a dependency
[14:04] <hatch> gotcha ok I'll get this up right away
[14:04] <gary_poster> cool
[14:14] <teknico> gary_poster, hi, sorry, I'm late
[14:14] <gary_poster> teknico, oh hai :-)
[14:15] <gary_poster> teknico, one sec
[14:15] <teknico> sure
[14:23] <hatch> ugh I hate it when I commit and forget to run make lint before lbox :)
[14:23] <hatch> we should change lbox so that it runs lint before check :D
[14:26] <hatch> proposed
[14:29] <gary_poster> jujugui call in 2
[14:29] <benji> noooooooooooooooooooooo
[14:29]  * benji reboots
[14:46] <bac> hatch: the modellist bubble event did work as you described.  thanks.
[14:46] <hatch> excellent
[14:55] <Makyo> It's a hard life.  http://ubuntuone.com/gallery/56atUQ5IHr3CkOXeT605zL/IMG_20130328_084932.JPG
[14:58] <frankban> rogpeppe: re apiinfo in the uniter agent.conf, do we have a bug for that, or do you want me to file one?
[14:58] <hatch> Makyo: hehe
[15:06] <rogpeppe> frankban: yeah, if you could file one, that would be great. but perhaps phrase it slightly differently: "we want our charm to know the address of the API. we're currently doing it like this. this solution (in uniter agent.conf) might be better"
[15:12] <frankban> rogpeppe: filed bug 1161443
[15:12] <_mup_> Bug #1161443: Make the API address easily accessible by charms <juju-core:New> <juju-gui:Triaged> < https://launchpad.net/bugs/1161443 >
[15:13] <rogpeppe> frankban: thanks! (and i added a comment giving my preferred solution - i'm still not sure if fwereade will go for it though)
[15:13] <frankban> rogpeppe: thanks, an env var would be great
[15:21] <gary_poster> hey frankban, where is the charm log in juju- core
[15:21] <gary_poster> I found charm
[15:21] <gary_poster> /var/lib/juju/agents/unit-juju-gui-0/charm
[15:21] <frankban> gary_poster: /var/log/juju/
[15:22] <gary_poster> ah
[15:22] <gary_poster> cool
[15:22] <gary_poster> thanks
[15:22] <frankban> gary_poster: welcome
[15:29] <gary_poster> rick_h_, benji, the scrollbars are a worse regression than I thought
[15:29] <benji> scrollbars?
[15:29] <gary_poster> rick_h_, benji, yes, I think we may need to revrt before we release
[15:29] <benji> oh, the "regression" part was what is meant to me
[15:29] <benji> s/to/fo/
[15:29] <gary_poster> yes :-)
[15:29] <benji> s/fo/for/
[15:29]  * benji goes back to typing school.
[15:30] <benji> k, I'll not release until that is fixed
[15:31] <gary_poster> benji, rick_h_ no matter how big my browser is, whhen I go to https://ec2-54-235-226-84.compute-1.amazonaws.com/ (which is trunk) I see scroll bars until I adjust
[15:31] <gary_poster> trying on uistage as well
[15:31] <gary_poster> btw frankban qa for charm is great.  ,arking...
[15:31] <gary_poster> marking...
[15:32] <frankban> gary_poster: :-)
[15:32] <benji> https://ec2-54-235-226-84.compute-1.amazonaws.com/ has scrollbars for me in Chrome, none in Firefox
[15:33] <gary_poster> benji what about http://uistage.jujucharms.com:8080/
[15:33]  * benji looks
[15:33] <benji> FF OK
[15:34] <benji> Chrome OK too
[15:35] <gary_poster> benji me too. :-/ ok call off the dogs.  I guess we can make a release.  weird that it is specific to go env
[15:35] <benji> quite weird
[15:41] <hatch> anyone have any objection to me upgrading us to Node 0.10.1 now that the regression is fixed?
[15:42] <hatch> bcsaller: gary_poster changes have been re-proposed
[15:51] <hatch> bcsaller: created a slacktask for your comments
[15:51] <hatch> I*
[15:51] <bcsaller> hatch: thanks
[15:52] <hatch> my dogs can hear my neighbours car door close from 2 houses down but somehow they can sit right infront of my sub while my music is on
[15:52] <hatch> the force is strong with these ones
[15:52] <frankban> gary_poster: http://jujugui.wordpress.com/2013/03/28/deploying-the-gui-in-a-juju-core-environment/
[15:52] <benji> hatch: upgrading sounds fine to me, with due caution of course
[15:53] <hatch> http://starwars.com/This-Is-Madness/
[15:53] <hatch> ugh I can't believe Ahsoka Tano won over Captain Rex
[15:53] <hatch> benji: yep of course :)
[16:00] <hazmat> frankban, cool
[16:00] <hazmat> frankban, how does the gui charm know if its py or go?
[16:01] <frankban> hazmat: it checks whether or not ../agent.conf exists
[16:17] <benji> gary_poster: this bit of the release process doesn't seem right: "Check that read and execute permissions for all are present on all files
[16:17] <benji>   and directories, especially in the ``node_modules/`` directory.
[16:17] <benji> "
[16:17] <benji> the not-right part is that not all the files do have the a+x bit set
[16:18] <benji> should it be more like "all files are a+r and the files in node_modules are a+rx"?
[16:18] <benji> (I am writing a "find" command that will verify this for us in one step that I will add to the release instructions.)
[16:26] <gary_poster> hatch: no objections to Node 10.1
[16:26] <gary_poster> hatch I gave you a LGTM so will only re-review if you request.  would you like me to look at it again?
[16:27] <gary_poster> frankban, cool :-)
[16:27] <frankban> :-)
[16:28] <hatch> gary_poster: no I think the emails were delayed
[16:28] <hatch> it's been merged for a while now :)
[16:28] <gary_poster> cool hatch :-)
[16:28] <gary_poster> benji maybe so.  OTOH we can clean up that tarball now
[16:28] <gary_poster> do we need node_modules now?
[16:28] <gary_poster> I forget
[16:28] <gary_poster> but don't think so
[16:28] <benji> I have no idea.  Shall I investigte?
[16:29] <benji> or shall I make a release and a card to investigate?  <hint> <hint>
[16:29] <gary_poster> benji :-) +1
[16:30] <benji> I'll assume that the instruction that they should be executable is erronious and I will remove it.  If I am wrong, QA will tell me.
[16:30] <gary_poster> ok benji
[16:34] <hatch> bcsaller: I'm pretty sure that we can utilize the new YUI Promises stuff to avoid our multiple rendering stuff
[16:35] <benji> all these double backticks irritate me; probably the single biggest failign of reST
[16:41] <hatch> jcsackett: are you around?
[16:42] <jcsackett> hatch: for some definition thereof, sure. :-)
[16:42] <hatch> haha - just wondering if you had a sec for a guichat so I can explain the questions
[16:42] <jcsackett> hatch: sure. guichat?
[16:42] <jcsackett> e.g. hangout?
[16:42] <hatch> yup
[16:43] <hatch> i'm in
[16:43] <jcsackett> in what? is there a saved one i don't know about?
[16:43] <hatch> pmd
[16:47] <gary_poster> rogpeppe, hi.  is the "put all the info in the watcher that we need" branch already in review or near review, out of more than merely idle curiosity? :-)
[16:47] <rogpeppe> gary_poster: no, i've been on other fixes, i'm afraid
[16:48] <gary_poster> ah ok understood
[16:48] <rogpeppe> gary_poster: if benji wants to take the reins, that would be fine
[16:48] <rogpeppe> gary_poster: currently i'm delving into a couple of odd looking bugs in the AllWatcher
[16:49] <gary_poster> rogpeppe, ok it sounds like we ought to take the expose stuff then.  thank you
[16:49] <gary_poster> expsoing the attrs we need, I mean
[16:49] <rogpeppe> gary_poster: that would be great if you could, thanks.
[16:49] <gary_poster> np, thank you
[16:49] <rogpeppe> gary_poster: i think i'm better doing what i am currently
[16:50] <gary_poster> rogpeppe, that was what I heard as well :-)
[16:50] <Makyo> Nexus 10 just showed up in a box, wrapped in bubble wrap, inside another box, inside a bag, inside another bag.  V. thorough.
[16:51] <gary_poster> :-)
[16:51] <gary_poster> glad it appeared
[16:52] <Makyo> Good timing, too.  Should start getting dog ready for vet.  Won't be long.
[16:54] <hatch> Makyo: that's how my paperwork showed up from head office too
[16:54] <hatch> wrapped in about 3 recursive layers
[16:55] <hatch> :D
[16:55] <hatch> maybe it's a policy
[16:55] <hatch> lol
[16:55] <Makyo> Hah, yeah :)
[16:55] <Makyo> No US wall charger, but oh well, just USB.
[16:58] <hatch> now all we have to do is figure out how to run 120volts through a USB cable and we will have a universal power system
[16:58] <hatch> :)
[16:59] <Makyo> Still want my wireless charger.
[16:59] <Makyo> Anyway, dog to vet.  Back in a few.
[16:59] <hatch> cya
[16:59] <gary_poster> bye
[17:00] <hatch> :lbox: command not found
[17:00] <hatch> wth
[17:00] <hatch> heh
[17:18] <hatch> gary_poster: yep it needs to be changed in the charm too - but that's another branch
[17:18] <hatch> :)
[17:18] <gary_poster> cool hatch
[17:21] <rogpeppe> gary_poster: you might be relieved to hear that the first bug wasn't actually a bug in the allWatcher itself, but in the testing infrastructure around it.
[17:21] <gary_poster> :-) cool rogpeppe 
[17:21] <teknico> rogpeppe, have a look sometime? https://codereview.appspot.com/8094045
[17:21] <rogpeppe> gary_poster: i'm still not sure how to fix it though :-)
[17:21] <gary_poster> rogpeppe, lol, I have confidence
[17:22] <rogpeppe> teknico: looking (makes light relief!)
[17:23] <rogpeppe> gary_poster: the problem is that we create the allWatcher immediately the mongo State is created, but then the test stuff sets the admin password, and that then denies access to the currently-running allWatcher...
[17:23] <gary_poster> heh
[17:24] <rogpeppe> gary_poster: it was one of those "what the frick is happening?" bugs
[17:24] <gary_poster> yeah, I can imagine
[17:27] <benji> I see these errors in Firefox:
[17:27] <benji> Timestamp: 03/28/2013 12:24:13 PM
[17:27] <benji> Error: not well-formed
[17:27] <benji> Source File: http://jujucharms.com/search/json?search_text=series%3Aprecise%20owner%3Acharmers
[17:27] <benji> Line: 1, Column: 1
[17:27] <benji> Source Code:
[17:27] <benji> {
[17:27] <benji> it doesn't seem to affect the apps performance, but it is still disquieting
[17:29] <rick_h_> benji: hmm, the json from there passes json linting
[17:31] <rick_h_> benji: maybe the response isn't sending a content-type back and FF wants to try html on it or something?
[17:32] <hatch> rick_h_ the events stuff was moved to an attr on purpose to avoid cross instance issues
[17:32] <hatch> as prototype properties are shared cross instance
[17:33] <rick_h_> hatch: but cant' it just go into the same section ATTRS lives in?
[17:33] <rick_h_> { _events: [], ATTRS }
[17:33] <rick_h_> isn't that all isntance related stuff there from Base?
[17:33] <hatch> oh you want it to be a static?
[17:34] <hatch> honestly I've never put it there
[17:34] <rick_h_> hatch: well, I just don't want to create events and such tied up to something that doesn't need it like this
[17:34] <hatch> hmm
[17:34] <rick_h_> a Base drive ATTR is a lot heavier than a private property
[17:34] <hatch> well...
[17:34] <rick_h_> 'feels wrong'
[17:34] <hatch> if we don't define the property then we can use 'this._events'
[17:34] <hatch> then it will be scoped to the instance
[17:35] <rick_h_> right, that's what I mean
[17:35] <hatch> although then we have to be VERY sure that we are never calling this._events when the context is different
[17:35] <rick_h_> _events is meant for two things, creating events and destructor cleanup
[17:35] <rick_h_> how else should it be accessed?
[17:36] <rogpeppe> teknico: reviewed
[17:36] <hatch> assume we have a callback executed under some other context and we go this._events...
[17:36] <hatch> then it will point to the wrong context and those events won't be detached
[17:36] <hatch> whereas this.get('_events') will fail
[17:36] <rick_h_> we should just get to adding an extesion for Base that adds methods addEvent, cleanEvents
[17:36] <hatch> lol
[17:36] <hatch> agreed
[17:37] <rick_h_> well, that type of scope issue is always present in any JS work being done
[17:37] <hatch> yeah but usually it doesn't come with the penalty of zombie event listeners
[17:37] <hatch> :)
[17:37] <hatch> for the record I totally agree with you
[17:38] <rick_h_> ok, is there a way to generate a unique id for an instance of Base?
[17:38] <hatch> I'm just erring on the side of caution
[17:38] <rick_h_> make events a global watcher and add all events to it. Then destructor references it on cleanup
[17:38] <rick_h_> at then we can track/check for left over events in tests/etc
[17:38] <teknico> rogpeppe, thanks, looking
[17:38] <hatch> hmm
[17:38] <hatch> now that's an interesting approach
[17:39] <rick_h_> well for this branch it's referencing both _events and .get(_events) and I don't think a ATTR is the right place for this stuff
[17:39] <rick_h_> I'd vote investigating sticking it next to ATTRS and make sure it's instance scoped, if it's not then worst case just this._events = [] in the initializer
[17:40] <rick_h_> this is a really simple bit of code and scope shouldn't be an issue
[17:42] <hatch> sure ok ok
[17:42] <jcsackett> rick_h_, hatch: does handlebars provide any helpers to easily handle pluralizing? e.g. if extra is 1 "result" if extra is > 1 "results"?
[17:42] <hatch> not that I know of
[17:42] <rick_h_> jcsackett: I find sometimes just changing the text is good. "View X more" 
[17:42] <rick_h_> no plurals needed :)
[17:43] <jcsackett> rick_h_: if you're good with that; you pointed out the wireframe's actually say "see x more results"
[17:43] <rick_h_> let UX catch us before we waste time on it
[17:43] <rick_h_> yea, so "See X more" then :)
[17:43] <rick_h_> but if it's pulled out from the method into a template we can easily change it to a functino call to do plurals if needed
[17:43] <gary_poster> hatch, bcsaller, I added docs about our Jenkins setup on the wiki page.  https://wiki.canonical.com/JujuGUICI#preview Good enough?
[17:44] <bcsaller> checking
[17:44] <jcsackett> rick_h_: you alright with it remaining "see less" then? "see fewer" feels awkward.
[17:44] <rick_h_> really? less seems to not fit my tongue but I can't figure out why. 
[17:45] <rick_h_> jcsackett: but yea, if it's just my strangeness leave it for sure
[17:45] <gary_poster> fewer is count
[17:45] <rick_h_> where's deryck when you need some english 
[17:45] <gary_poster> have no idea what you are talking about :-)
[17:45] <jcsackett> rick_h_: see gary's point. fewer is when you have a number.
[17:45] <rick_h_> gary_poster: in the search results you see XX by default with a link to "show more" and then when you show more the link is "show less"
[17:46] <jcsackett> we could do "see X fewer", but that seems uneccesary for the intent.
[17:46] <rick_h_> jcsackett: maybe that's what's strange is that it's XX more (numbery) but not on the way back
[17:46] <rick_h_> jcsackett: yea, so just ignore me
[17:46] <gary_poster> we are accustomed to "less" in vbrowser because it is viaual
[17:46] <gary_poster> visual
[17:46] <gary_poster> less information
[17:46] <gary_poster> fewer pieces of data
[17:46] <jcsackett> rick_h_: ignoring away. :-)
[17:47] <rick_h_> lol, "fewer pieces of data" though. It's not "less pieces of information" is it?
[17:47] <bcsaller> gary_poster: If the wiki is the place we save the Jenkins script we should put a note at the top of that script saying to save any changes back to the wiki. Other than that looks good :)
[17:47]  * rick_h_ goes back to english school...been too long
[17:48] <gary_poster> bcsaller, was doing that in description on jenkins.  will also put it at top of script.  Not sure if wiki is best place but it is OK and easy :-)
[17:48] <rick_h_> jcsackett: let me go play with a jsbin for a minute on the _event stuff. 
[17:48] <gary_poster> thank you for review
[17:48] <teknico> rogpeppe, re: AddRelation(endpoint0, endpoint1 string) -> (endpoints .. string), I guess I'll have to change DestroyRelation too
[17:48] <jcsackett> rick_h_: argue with jeff. i don't care, honestly, but i don't want to go back and forth between you two. :-P
[17:48] <rick_h_> jcsackett: rgr
[17:49] <hatch> gary_poster: looks good - thanks for doing that! bcsaller heh that script is a lot longer than our original lol!!!
[17:49] <rogpeppe> teknico: good call, yes please, thanks
[17:50] <rogpeppe> teknico: you could probably do it in the same CL if you wanted.
[17:50] <gary_poster> cool thanks hatch
[17:50] <teknico> rogpeppe, that's what I'm doing, yes
[17:51] <rogpeppe> gary_poster: so, my current take on the SetAdminPassword issue is that if you call SetAdminPassword, you poison all existing watchers. i *think* that's a reasonable stance, but YMMV.
[17:53] <gary_poster> rogpeppe, I think paranoia is reasonable for juju's use cases.  however the watcher seems like the wrong place to be paranoid
[17:53] <rogpeppe> gary_poster: i don't see a reasonable alternative unfortunately.
[17:53] <gary_poster> if you are going to take that stance--and I think it is a reasonable one--then it would make more sense to dump users off and require reauthentication.  
[17:54] <rogpeppe> gary_poster: they're all using the same mongo client, and that's been shut out
[17:54] <rogpeppe> gary_poster: i think that's what will happen in practice actually
[17:54] <gary_poster> rogpeppe, but only when you try to use a watcher?
[17:55] <gary_poster> rogpeppe, I also think that ideally the error message would clearly indicate what's going on and why, but that's arguably nice to have in comparison
[17:56] <rogpeppe> gary_poster: hmm, i've just realised my solution won't work. SetMongoPassword really does poison all other clients.
[17:56] <gary_poster> heh
[17:56] <rogpeppe> gary_poster: and in this case we've got two clients
[17:56] <gary_poster> juju itself being the other?
[17:57] <rogpeppe> gary_poster: the one started by the dummy environ, which starts at Bootstrap time, and is what the API server is running on. and one in the juju.Conn which the clients are using.
[17:58] <gary_poster> where dummy environ == roughly "juju itself" in the context of the tests IIUC
[17:58] <rogpeppe> gary_poster: on the first connection, the client connection sets the password (so that we can avoid sending it up plaintext in the cloudinit data)
[17:58] <rogpeppe> gary_poster: yeah
[17:59] <rogpeppe> gary_poster: and this *is* an issue for the real live environment, i now realise
[17:59] <rick_h_> hatch: so if we change _events to being set in the intializer so it's per instance does that change your LGTM for jcsackett? If so I'll cave and let the ATTR go just feels dirty, but maybe less error prone potential. 
[17:59] <teknico> rogpeppe, replied to your review, thanks. I added a few questions myself, please have another look
[17:59] <rogpeppe> teknico: will do (although i have to go *very* shortly, and won't be back until Tues, i'm afraid)
[17:59] <hatch> nope that's fine
[17:59] <rick_h_> jcsackett: ok? ^^
[18:00] <gary_poster> rogpeppe, I'm out Wed-Fri next week btw
[18:00] <rogpeppe> gary_poster: ok, good to know
[18:00] <hatch> you're right that it's more performant I was just concerned with the potential issues associated with it
[18:00] <rick_h_> hatch: understand. Yea, we need a better long term solution. 
[18:01] <teknico> rogpeppe, it's actually just *one* question :-)
[18:01] <hatch> rick_h_ when we do build this solution it should be done to be contributed back to yui
[18:01] <rick_h_> hatch: +1
[18:03] <rogpeppe> teknico: replied
[18:04] <teknico> rogpeppe, thanks, have a great weekend!
[18:04] <rogpeppe> teknico: and you!
[18:04] <teknico> I'm working tomorrow (but I'll be off on Monday) :-)
[18:06] <rogpeppe> gary_poster: actually i've realised it's *not* an issue live (the bootstrap process creates a new user) and that points me to the right solution...
[18:06] <rogpeppe> gary_poster: thanks for being a fine sounding board for my thoughts
[18:06] <gary_poster> ah, make a new user?  echo chamber, perhaps ;-) but glad I helped
[18:08] <rogpeppe> gary_poster: think of yourself as a stuffed bear :-) http://talkaboutquality.wordpress.com/2010/08/30/tell-it-to-your-teddy-bear/
[18:08] <gary_poster> lol
[18:10] <rogpeppe> am off now. happy weekends all.
[18:10] <gary_poster> hatch we don't need npm as a build dependency because node now includes it right?
[18:10] <gary_poster> bye rogpeppe !
[18:11] <hatch> gary_poster: correct - and verified locally
[18:11] <gary_poster> cool thanks
[18:11] <gary_poster> LGTM
[18:11] <hatch> which I am kind of sketched out about because they are two different applications with obviously conflicting apis
[18:13] <hatch> hmm looks like I need to create a wordpress account
[18:13] <hatch> I gota spread my beliefs to the world!
[18:14] <hatch> gary_poster: do we know what happens if trunk commits happen prior to it completing a test? does it queue them up?
[18:14] <hatch> or run the latest
[18:17] <gary_poster> hatch, queu
[18:17] <gary_poster> e
[18:18] <hatch> ok good :)
[18:18] <gary_poster> benji how goes release?
[18:19] <hatch> could I get one more review on this 4ln diff :) https://codereview.appspot.com/8105043/
[18:20] <hatch> ppllllleaaaasseee
[18:28] <hatch> gary_poster: anything in particular you would like me to tackle ?
[18:29] <gary_poster> hatch, yes.  congratulations on finishing CI.  We will improve it later as a separate task.  Meanwhile, we have a new "Story A"
[18:29] <gary_poster> I've created cards for the tasks, but I need to talk you through it.
[18:29] <hatch> sure - now?
[18:30] <gary_poster> I have a call with bac.  bac, can we postpone our call by 30 min or so?
[18:30] <gary_poster> or would now be better?
[18:30] <hatch> nope take your time
[18:30] <bac> gary_poster: either
[18:30] <hatch> I'll take a 30min lunch
[18:30] <gary_poster> hatch ok cool talk to you then
[18:30] <gary_poster> bac, joining
[18:33] <benji> gary_poster: back from lunch; I figured out the little problem I had (relating to version.js) and am in the middle of QA now
[18:41] <gary_poster> cool benji thx
[18:46] <benji> our two-factor auth setup is aweful; my phone and the server keep getting out of sync and have to be reset
[18:47] <Makyo> Hm, Ubuntu's pretty on the tablet, though a little flaky. gary_poster - if I read the email right, I should put android on this, right?
[18:47] <benji> wait!  this is staging, two factor auth doesn't work here.... <sigh>
[18:47] <gary_poster> Makyo, no
[18:48] <gary_poster> Makyo, Ubuntu touch.  Though you will probably want to flash it to get it to newest
[18:48] <gary_poster> daily
[18:48] <gary_poster> Makyo will also forward you a few emails for contact and debugging info
[18:48] <Makyo> gary_poster, thanks.  Can't open the browser on the current version :)
[18:48] <gary_poster> Makyo, heh
[18:50] <gary_poster> Makyo, to flash new version, you start in ubuntu (not bootloader, despite instructions that confused me) and do step 4 of https://wiki.ubuntu.com/Touch/Install
[18:50] <gary_poster> You'll need step 1 before that
[18:50] <gary_poster> but step 2 and 3 are unnecessary now
[18:50] <gary_poster> steps
[18:54] <gary_poster> hatch, I think the most recent Jenkins failure indicates that you broke the charm :-)
[18:55] <gary_poster> yay CI! :-)
[18:59] <jcsackett> rick_h_: sorry, was finally taking a lunch break. so, just in initializer create. this._events?
[19:00] <rick_h_> jcsackett: correct
[19:00] <gary_poster> hatch, http://pastebin.ubuntu.com/5656043/
[19:00] <gary_poster> that's from charm machine from Jenkins
[19:00] <gary_poster> I'm going to make a fresh build locally and see if I can dupe
[19:01] <hatch> awwwww mann
[19:01] <hatch> oh wait
[19:01] <hatch> no that's a grunt error
[19:01] <gary_poster> hatch, dunno, that's from benji, and it is doc only :-/
[19:01] <gary_poster> so maybe a new spurious failure?
[19:02] <hatch> hmm
[19:02] <benji> or I screwed up the docs THAT bad
[19:02] <gary_poster> :-)
[19:04] <hatch> how do you deploy the charm locally? I have always spun up ec2 instances :)
[19:04] <gary_poster> hatch, dunno, rerunning make was fine. :-/ maybe crazy virtualization issue?
[19:04] <gary_poster> never seen that one before
[19:06] <hatch> maybe if we get an install error we should dump the machine and juju logs
[19:07] <gary_poster> maybe so
[19:07] <gary_poster> ran make clean-all && make build
[19:07] <gary_poster> everything fine.
[19:07] <hatch> hmm that's odd
[19:07] <gary_poster> Going to re-run test on jenkins
[19:07] <gary_poster> seems spurious
[19:07] <gary_poster> :-(
[19:08] <gary_poster> hatch guichat?
[19:08] <hatch> sure
[19:55] <bac> gary_poster: my endpoints change introduces the new requirement that adding a service causes it to fetch the charm.  that modification is impacting lots of tests that assume the old behavior.  just giving you a heads up.
[19:55] <gary_poster> ack bac sounds ok on the face of it
[20:02] <hatch> bcsaller: do you know what grunt modules we use?
[20:02] <hatch> you were saying that we didn't upgrade because some modules needed to be updated
[20:03] <bcsaller> hatch: very little, just the spritegen stuff afaik. I cut a branch once that did more stuff with it, but with the 0.4 transition it wasn't time to change 
[20:03] <hatch> ok and it looks like spritegen (node-spritesheet) isn't a grunt module
[20:04] <hatch> `npm show node-spritesheet`
[20:04] <hatch> and it was updated march 1
[20:06] <rick_h_> hatch: when you get a second have a Y.View/events ? for you
[20:07] <hatch> sure
[20:07] <hatch> go for it
[20:08] <rick_h_> hatch: so my events: {} aren't working and I recalled that there's some lazy-ness in there. Do you recall that all you have to do is this.get('container') to activiate it?
[20:08] <rick_h_> I thought I ran into something before but brain is not recalling
[20:08] <rick_h_> obviously, doing a this.get('container') in render isn't working so assuming it was something diff
[20:09] <hatch> on showView() those events are delegated on the container
[20:09] <hatch> so if there is no container then it can't delegate on anything
[20:10] <rick_h_> ah, only on showView?
[20:10] <rick_h_> I'm using a view in a view
[20:10] <rick_h_> so there's no 'showView' to handle this 
[20:10] <hatch> are you rendering the view?
[20:10] <rick_h_> hatch: rgr
[20:11] <rick_h_> https://code.launchpad.net/~rharding/juju-gui/clean_charmview/+merge/156054 line 129 is the start of the view I'm trying to get working/writing tests for. 
[20:11] <hatch> ok one sec
[20:11] <rick_h_> line 343 is the rendering of it from the Fullscreen main view. 
[20:11] <rick_h_> hatch: cool, np
[20:13] <hatch> ok just reviewed the view source and the events are attached on view initialization XOR when the container attribute is changed
[20:14] <rick_h_> hatch: hmm, ok. That's what I thought then. /me goes back to debugging
[20:14] <hatch> does tplNode.one('.bws-view-data') return a node?
[20:16] <rick_h_> hatch: yea
[20:17] <hatch> event callbacks are supposed to be strings
[20:17] <rick_h_> hatch: doh!
[20:18] <rick_h_> I was also doing a this.set('container') before I rendered the template into the container so it didn't have any matches
[20:19] <rick_h_> hatch: there we go. Thanks!
[20:19] <rick_h_> Knew I was missing stupid
[20:19] <hatch> :D \o/
[20:26] <gary_poster> hatch what's the word on the test issue?  Making progress, or want to pair?  I can deploy trunk and see if it works for me.  You can too actually, trivially: juju deploy cs:~juju-gui/precise/juju-gui
[20:26] <hatch> I'm rolling it back to 0.8 to be sure it's an issue with the upgrade
[20:27] <hatch> I am thinking its an internal dependency failure
[20:27] <gary_poster> ok
[20:27] <hatch> like something inside the modules we require
[20:27] <gary_poster> maybe so
[20:28] <hatch> some of the deps our deps rely on haven't been touched in fo'eva!
[20:29] <hatch> as in , say they require node >0.4
[20:29] <hatch> lol
[20:44] <hatch> gary_poster: reverting back to 0.8 works just fine :/
[20:44] <hatch> so theer is some unsupported dependency somewhere in the dependency mess
[20:45] <hatch> so can I easily revert the changes?
[20:45] <hatch> or do I need to re-commit
[20:45] <gary_poster> hatch, tbh I forget.  I think the preferred way is to merge in reverse
[20:45] <gary_poster> lemme see if I can figure it out, oone sec
[20:45] <hatch> alright
[20:48] <gary_poster> hatch I think bzr merge -r38..37 will do what we want:
[20:48] <gary_poster> it changes trunk to revert your revision
[20:48] <gary_poster> which you will then commit as a new change, with a message about reverting
[20:48] <gary_poster> and push
[20:49] <gary_poster> look at bzr diff after the merge to make sure it looks like what you want
[20:50] <hatch> alright thanks
[20:50] <hatch> good news is that the CI tests all pass :)
[20:51] <gary_poster> yay! :-)
[20:51] <gary_poster> also good news is that CI actually did what it is supposed to do!
[20:51] <gary_poster> keep us from having a problem for long
[20:51] <hatch> haha yay
[20:51]  * hatch has the badge for the first person to actually breaking the build
[20:51] <hatch> lol
[20:55] <hatch> annnd done
[20:55] <hatch> i'll fire off another ci run
[20:55] <hatch> O K now to doing real work
[20:55] <gary_poster> thanks hatch :-)
[20:56]  * hatch mumble rants about node.js dependencies
[20:56] <gary_poster> hatch, maybe make a bug to represent the fact that we still have a node issue that we want to resolve at some point?
[20:56] <hatch> yep
[20:56]  * gary_poster suspects it will bother hatch until he fixes it with or without the bug :-)
[20:57] <hatch> lol yes it will
[21:11] <hatch> yay the tests are running on canonistack
[21:14] <gary_poster> yay
[21:14] <hatch> and more importantly passing :)
[21:14] <gary_poster> that too :-)
[21:16] <gary_poster> benji, I'm not going to send the email to Francesco.  I'll send it to you.  The more I dig into his the more I am skeptical that we will be able to accomplish this without Roger.  This is a big deal: I am afraid there may be some serious issues with the allwatcher.  AFAICT, the config and constraints are in their own separate docs, and I don't think they are watched by the allwatcher.  therefore, if they change, we 
[21:16] <gary_poster> won't hear about it.  hopefully I am wrong.
[21:17] <gary_poster> Anyway, for Francesco, he has a task that he can get done.  If I do send him the email, it will be "if you get the other task done, think about this one, and maybe tell us if things are not as dark as they seem to me"
[21:18] <hatch> looks like when the CI passes it just gives a link
[21:18] <hatch> :)
[21:19] <benji> gary_poster: ok
[21:29] <gary_poster> bcsaller, could you remind me what a relation's scope is in juju?  I only see "global" in improv output
[21:30] <bcsaller> gary_poster: it can also be "container" for subordinate relations
[21:30] <gary_poster> bcsaller, ah ok.  nobody has those atm so it is always global, right?
[21:30] <bcsaller> if you add puppet and a sub relation you should see it as an example
[21:31] <gary_poster> oh ok
[21:31] <gary_poster> I see
[21:31] <gary_poster> thank you
[21:31] <bcsaller> the sample env should really have a sub
[21:33] <gary_poster> bcsaller, btw notice that I added cards fro in-memory environment to story a
[21:33] <gary_poster> you might want to dig in there if you feel like it
[21:34] <bcsaller> gary_poster: ahh, nice
[21:41] <bac> guihelp: how does one deal with: extend failed, verify dependencies
[21:41] <hatch> step 1
[21:41] <hatch> verify dependencies
[21:41] <hatch> :P
[21:41] <bcsaller> ha
[21:42] <gary_poster> :-P
[21:42] <bac> step 0?
[21:42] <hatch> ok but really haha
[21:42] <hatch> that means that the object you're trying to extend doesn't exist
[21:42] <hatch> so unfortunately that's pretty much all the advice there is - you will need to track back to find out why it's undefined
[21:43] <hatch> the good news, is that it's usually a typo, or you forgot to add the module into the sandbox
[21:43] <hatch> those are the first places to check
[21:43] <hatch> the next are syntax issues
[21:43] <hatch> which would cause the instantiation of the parent to fail
[21:44] <bac> hatch: it seems to be transient, which is confusing
[21:45] <hatch> is this in tests?
[21:45] <bac> yeah
[21:45] <hatch> try commenting out every other test case so it only loads your file
[21:46] <hatch> <!-- test cases -->
[21:46] <hatch> then make sure that you have added the file into the merge-files (if required) or into the modules-debug
[21:46] <hatch> annnnd now I can't build trunk
[21:47] <bac> hatch: it isn't a new test file, so none of that is applicable.
[21:47] <hatch> oh hmm
[21:47] <hatch> is the class you're trying to extend new?
[21:50] <bac> not extending a new class.   just add some methods on a pre-existing one.
[21:50] <hatch> oh ok
[21:50] <hatch> that sounds like a syntax error
[21:50] <hatch> try linting it
[21:51] <hatch> or push the code up somewhere so I can take a peek
[21:51] <bac> that's a good idea
[21:52] <hatch> gary_poster: looks like the CI failed even after retrying with similar issues
[21:52] <hatch> maybe we should increase the attempts
[21:53] <gary_poster> hatch, oh you mean firefox?
[21:53] <gary_poster> suck.
[21:53] <hatch> oui oui
[21:54] <gary_poster> naginator worked, which is kind of nice. :-/
[21:56] <bac> dang, no syntax errors
[21:56] <gary_poster> I have no freaking idea hatch.  Yeah, do five retrys if the number of tests run < 100?
[21:56] <gary_poster> hatch, we will need to solve this, but I don't want to solve it now. 
[21:57] <gary_poster> I'll be back later.  must run
[22:39] <hatch> rick_h_ jcsackett either of you guys around?
[22:39] <rick_h_> hatch: what's up?
[22:40] <hatch> if you run describe.only('notifications' in test_notifications.js there is an extend failure
[22:40] <hatch> and the traceback points to the charm-slider.js
[22:40] <hatch> this doesn't happen when you run all the tests
[22:40] <rick_h_> hatch: hmm, that sounds like the error I brought up before where it was the slider with a 0 item set causing issues
[22:40]  * rick_h_ tries it out. 
[22:44] <rick_h_> hmmm, the 'base' in Base.create is undefined
[22:44] <rick_h_> so Y.ScrollView doesn't exist
[22:44] <hatch> das very odd ya?
[22:44] <rick_h_> yea, but we had the same issues with TabView
[22:44] <rick_h_> I wonder if it's simliar
[22:45] <rick_h_> we never did figure out wtf with TabView, just cheated on it 
[22:45] <rick_h_> maybe the modules names aren't quite right? /me checks his requires vs the dir/file names in YUI
[22:46] <rick_h_> hmm, no they seem to match up
[22:46] <hatch> yeah I stared at it for a bit and coudln't figure it out
[22:46] <hatch> unfortunately this issue is stopping bac from resolving his issues
[22:46] <hatch> so should I create a critical ticket?
[22:46] <rick_h_> yea, I mean for some reason it's not fetching the required module.
[22:46] <hatch> yeah I have no idea what's up
[22:47] <hatch> as far as I can tell all of those modules ARE available
[22:47] <rick_h_> yea, I mean this is going to be a bit hard for jcsackett to figure out. The build/dep system in here is already hard to follow
[22:47] <rick_h_> Now if you remove the rest of the tests does it still do it?
[22:48]  * rick_h_ wonders how the globalconfig is setup to fetch yui deps
[22:49] <hatch> rick_h_ looks like if I comment out every other test it all passes
[22:49] <rick_h_> yea, ok. So it's some kind of interaction. Ugh I hate this one test thing to rule them all. 
[22:50] <rick_h_> so yea, the YUI files are there in the build-debug which this is using I believe
[22:50] <rick_h_> so not an issue getting them into the build dir
[22:50] <rick_h_> and hitting the url directly works, so why is it not fetching the file...does it think it's already got it or something?
[22:51] <hatch> rick_h_ looks like test_model.js causes it to go wako
[22:51] <rick_h_> hmm, ok. That's good to know then. /me goes look into there
[22:51] <hatch> 550ln test file....boooo
[22:51] <hatch> lol
[22:52] <hatch> 390-544
[22:52] <hatch> ^^ rick_h_ if you comment that out in test_models then it works
[22:53] <rick_h_> hatch: cool, now wtf since slider has nothing to do with models lol
[22:55] <hatch> 394-415
[22:55] <rick_h_> but all that is, is just the beforeEach/afterEach
[22:56] <rick_h_> hmm, these tests aren't in a closure?
[22:56] <rick_h_> neither are the slider ones
[22:57] <hatch> that block of tests has a describe inside a YUI.use() not outside like everything else
[22:57] <hatch> I bet that has something to do with it
[22:57] <rick_h_> oh, interesting
[22:58] <hatch> and I bet charm-slider is just failing becaise it's next
[22:58] <hatch> heh
[22:58] <rick_h_> notifications is next
[22:58] <rick_h_> but yea, something like that
[22:58] <rick_h_> not sure how slider fits into it all atm. 
[22:58] <rick_h_> hatch: so are you cool then tweaking that test and see if that helps?
[22:59] <rick_h_> I've got to get ready to put the boy to bed and can hop back in an hour or so. 
[22:59] <rick_h_> if you don't get to it, I'll try to adjust that test and see if we can clean this up
[22:59] <hatch> sure thing I'll create a new branch to try and fix this and see how far I get
[22:59] <hatch> ping me when you get back if I haven't posted anything :)
[22:59] <rick_h_> ok, if you get done before I get back just shoot me an email if you need help carrying it through
[22:59] <rick_h_> hah, ok will do
[23:06] <hatch> rick_h_ just doing a quick hack job on it placing the yui inside the describe has solved the issue
[23:06] <hatch> so now to clean this code up
[23:23] <rick_h_> hatch: ok, awesome! Glad that worked out. Still wonder wtf caused it to blame slider, but fixed > * 
[23:24] <hatch> rick_h_ my guess is that it just happened to be the first module requiring a new dependency
[23:24] <hatch> but thats just a twag
[23:24] <rick_h_> hatch: yea, all good
[23:35] <rick_h_> hatch: if you get a chance before tomorrow gets crazy pushing up my branch for review https://codereview.appspot.com/8103046
[23:35] <rick_h_> thanks again for the help wtih the events. Stuck me for a bit :/
[23:35] <hatch> sure - I'm actually off tomorrow and monday but I'll stop in to goto the meeting and stuff so I'll probably do it then
[23:35] <hatch> no problem :)
[23:35] <rick_h_> hatch: ah ok. I can ask another from the team if you're afk
[23:35] <rick_h_> let me know. Thanks!
[23:38] <hatch> I need a faster machine to run these unit tests
[23:38] <rick_h_> yea, runs in 20s here (browser at least)
[23:39] <hatch> pfft
[23:39] <hatch> 40s here
[23:39] <rick_h_> :P
[23:39] <hatch> lol
[23:39] <rick_h_> 9s for test-debug
[23:39] <rick_h_> chrome must be slowing me down :)
[23:39] <hatch> lol it's all the DOM manipulations
[23:39] <rick_h_> yea
[23:40] <hatch> yeah I'm about 20s on the terminal
[23:41] <gary_poster> 14 or 15 sec for me--go desktop!
[23:41] <rick_h_> yea, I've been debating a desktop this year
[23:42] <hatch> haha
[23:42] <rick_h_> I've been laptop only so long, but with all this vm/lxc/etc going on I'm itching for something I can actually run an environment on nicely
[23:42] <hatch> you two should stick around a bit so I can merge this fix into trunk tonight
[23:42] <hatch> it's proposing right now
[23:43] <rick_h_> hatch: I'll be around. Waiting for australians to show up adding more cards to the board bwuhahaha
[23:43] <hatch> lol
[23:43] <hatch> how many ausies on your team?
[23:43] <rick_h_> though hmm, if everyone is off friday wonder if he is. This is his friday
[23:43] <rick_h_> hatch: just the one design guy on loaner :)
[23:45] <hatch> ahhh haha gotcha
[23:45] <hatch> ok patch has been proposed - QA please :D
[23:46] <rick_h_> linky?
[23:46] <hatch> oops https://codereview.appspot.com/8099047/
[23:46] <rick_h_> it's almost 8pm, don't make me wait for my email to update itself and sync :P
[23:47] <hatch> haha mine is almost instant
[23:47] <hatch> I use postbox for osx
[23:47] <hatch> it's a stellar email client
[23:47] <rick_h_> I have a server pull gmail and work into into a single mailbox, filter it, and then I pull from taht
[23:47] <hatch> ahh
[23:47] <rick_h_> so it takes 4-5min to get to my local mutt install
[23:48] <rick_h_> but one mailbox is nice
[23:48] <hatch> gary_poster: if you are still around could you review that branch please :)
[23:48] <hatch> bac: this branch will fix the issue you were having
[23:49] <gary_poster> ok, but trying to run awaya as fast a spossible ;-)
[23:49] <gary_poster> good catch hatch.  LGTM
[23:50] <hatch> haha thanks!
[23:50] <hatch> have a good night
[23:50] <gary_poster> u 2
[23:51] <rick_h_> hatch: qa'd with the notifications.only() and all happy. Thanks again for running that down. 
[23:51] <rick_h_> and proving jcsackett and I didn't do it :)
[23:51] <hatch> haha np :D
[23:52] <hatch> now I'm going to go sit on the couch and watch some TV :) I'll do your review in the am before the call
[23:53] <rick_h_> hatch: ty much kind sir. Have a good night
[23:53] <hatch> you too!
[23:58] <rick_h_droid> jcsackett what if the number of results in the container is exactly the limit? what does the text for expander do?