[00:44] <rick_h_> hatch: around?
[00:45] <hatch> depends....:P
[00:45] <rick_h_> heh, huw is having some npm issues today and wondered if you knew/could help him out
[00:45] <hatch> sure I can give it a try
[00:45] <hatch> I'm also making supper though :)
[00:45] <rick_h_> sec, getting him into the channel
[00:45] <rick_h_> hatch: all good
[00:47] <rick_h_> there he is
[00:47] <huwshimi> Hey
[00:47] <rick_h_> huwshimi: so as I was saying. I pulled the latest trunk, make clean-all && make && make devel without any issues here
[00:48] <rick_h_> hatch: might know more if you're still getting an error as he's hacked with the npm stuff a bit while I just cross my fingers and pray it works :)
[00:48] <huwshimi> rick_h_: I'll pull a new branch and see if that fixes anything
[00:48] <rick_h_> huwshimi: cool
[00:48] <rick_h_> hatch: and bcsaller are a bit farther back in TZ so not sure how long they're around but worth a ping if you can't get it going
[00:48] <huwshimi> rick_h_: It'll take 5-10 minutes :)
[00:49] <rick_h_> cool, well I'm on cold meds and my wife is fussing at me to get to bed. good luck!
[00:50] <hatch> :)
[00:50] <huwshimi> rick_h_: Alright, thanks. Night.
[00:50] <hatch> huwshimi: mention me when you have it all downloaded and run `make`
[00:50] <hatch> just cooking supper
[00:50] <huwshimi> hatch: OK will do, thanks
[00:56] <huwshimi> hatch: Same thing. Fresh branch of trunk. Ran make and here's the npm-debug.log http://paste.ubuntu.com/5711913/
[01:05] <hatch> ok looking
[01:06] <hatch> what do you get when you run
[01:06] <hatch> node --version
[01:06] <hatch> and npm --version
[01:07] <hatch> oh wait nm I se
[01:09] <hatch> hmm that's very odd
[01:09] <hatch> did you install npm/node with sudo?
[01:10] <huwshimi> hatch: I think I just did "sudo apt-get install nodejs"
[01:11] <huwshimi> (as per the hacking doc)
[01:11] <hatch> ahh ok I thought you were on osx
[01:12] <hatch> hmm honestly I'm not sure
[01:12] <hatch> I gota run for about an hour but I'll look into it when I get back
[01:12] <huwshimi> hatch: OK, no problems. Thanks
[01:17] <gary_poster> bcsaller, ping
[01:17] <bcsaller> gary_poster: pong
[01:17] <gary_poster> hey bcsaller, thanks.  reviewing diff.  mostly looks good so far but one concern that's either wrong or easy to fix
[01:18] <gary_poster> for allow-external-sources
[01:18] <gary_poster> we should not install extra repos
[01:18] <gary_poster> *but*
[01:18] <gary_poster> we should be able to apt-get install
[01:18] <gary_poster> In the case of IS,
[01:18] <gary_poster> they will have established the CAT repo on every juju image
[01:19] <gary_poster> and we will be able to ask them to put various packages in CAT
[01:19] <bcsaller> gary_poster: ah ha, I thought they'd use a custom image ro something
[01:19] <gary_poster> so apt get install is AOK
[01:19] <gary_poster> just nit adding extra repos
[01:19] <gary_poster> not
[01:19] <bcsaller> gary_poster: should be an easy change
[01:20] <gary_poster> cool thanks bcsaller.  the only downside from what I see you have now is that we can't predict the failure, as you do now
[01:20] <gary_poster> but so be it
[01:20] <gary_poster> reality is more important :-)
[01:20] <gary_poster> bcsaller, maybe the option name should change?
[01:21] <bcsaller> gary_poster: ideas?
[01:21] <gary_poster> allow-additional-deb-repositories is long but relatively accurate
[01:21] <bcsaller> hmm, I can do that 
[01:22] <gary_poster> thank you bcsaller. Will you do that tonight?  I was writing the email to IS but I'd like that to be right before they look at it
[01:22] <gary_poster> if you will do it tonight then I will check back later
[01:22]  * gary_poster has 773 unread emails 
[01:23]  * gary_poster usually does inbox 0
[01:23]  * gary_poster has been a bit focused on deadlines lately :-P
[01:23] <bcsaller> gary_poster: I will do it now, can you look at the second check in hooks/install though
[01:23] <gary_poster> thanks bcsaller, looking
[01:23] <bcsaller> is that a valid policy to preserve?
[01:25] <gary_poster> bcsaller, if allow-additional-deb-repositories, do not install ppa:juju/pkgs, but do install those PYTHON_DEPENDENCIES
[01:26] <gary_poster> I mean, if *not* allow-additional-deb-repositories, do not install PPA
[01:26] <bcsaller> gary_poster: I'm sorry, I mean in backend/InstallMixin
[01:26] <gary_poster> oh
[01:26] <bcsaller> I told you the wrong place :(
[01:27] <bcsaller> thats why I names the var 'sources' because I thought we wanted this type of protection in place as well 
[01:28] <bcsaller> but it might be an invalid requirement 
[01:34] <gary_poster> bcsaller, there were two uses in InstallMixin.  To try and be as clear as possible, I wrote about all three uses here: http://pastebin.ubuntu.com/5711981/
[01:34] <bcsaller> gary_poster: thank you
[01:34] <gary_poster> welcome
[01:43] <gary_poster> bcsaller, changes look very nice so far.  Trivial, but I suggest you move GuiMixin repositories to UpstartMixin, or combine those two.  Not trivial: could you review http://pastebin.ubuntu.com/5711996/ and verify that, to the best of your knowledge, these are the packages that we need in CAT, noting the sources I mention?
[01:55] <gary_poster> bcsaller, maybe paranoid, but I wonder if we should do an apt-get update in the install hook in lieu of adding more deb repos, when that flag is set.
[01:56] <bcsaller> gary_poster: I suspect you're right, add_extra would have done that 
[01:56] <gary_poster> right
[01:56] <bcsaller> gary_poster: I'
[01:56] <bcsaller> Im in the middle of a test of it now though
[01:56] <gary_poster> ok cool
[01:57] <hatch> oh huw is gone
[02:29] <gary_poster> bcsaller, I need to go.  I just sent you a proposed email to IS.  I really need to send this today.  I'll check back in about 45 minutes to see if you feel comfortable with me sending it, and if you have any corrections.  Then I'll go to bed. :-)
[03:11] <bcsaller> gary_poster: replied with the comments in email, should be good to go
[12:00] <gary_poster> hi all
[12:01] <gary_poster> frankban, hi.  am I right that we could switch the charm to apache without technical difficulties, just with a bit of annoyance?
[12:02] <frankban> gary_poster: haproxy + apache? If so, I think you are right.
[12:02] <gary_poster> frankban, yes, haproxy + apache.  Cool, thanks.  Did you see that reply from mthaddon?
[12:03] <frankban> gary_poster: yes I do, he has another concern about multiple services on the same charm (IIRC haproxy).
[12:04] <gary_poster> frankban, right, I need to talk him away from that one
[12:04] <frankban> gary_poster: +1
[12:04] <gary_poster> :-)
[12:04]  * frankban is curious about why nginx is not blessed
[12:05] <rick_h_> frankban: because it's not in main, and it has a shady history of only existing in a russia version control system 
[12:06] <rick_h_> frankban: but these days I think the last *blocker* is that it's not in main and that IS has experience with everything on apache
[12:06] <frankban> rick_h_: ack, thanks
[12:06] <frankban> gary_poster: time for a quick call in the usual place?
[12:06] <rick_h_> we hit the same change :)
[12:06] <rick_h_> and asked the same question
[12:07] <gary_poster> frankban, about to have call with mthaddon, will ping
[12:07] <frankban> gary_poster: ok thanks
[12:12] <bac> thanks for the view frankban.  teknico could you have a look at https://codereview.appspot.com/8735044/ ?
[12:22] <gary_poster> frankban, ok can call now.  going to guichat.  no rush, join when you are ready.
[12:31] <gary_poster> rogpeppe, can you think of any situation in which all of a service's units are in a stopped state, and the service is *not* being destroyed?
[12:32] <rogpeppe> gary_poster: what do you mean by "stopped state" there?
[12:32] <gary_poster> rogpeppe, the unit is in a state called "stopped"? :-)
[12:32] <gary_poster> not pending, not error...
[12:32] <gary_poster> status is stopped on a unit
[12:32] <rogpeppe> gary_poster: hmm, let me have a look
[12:34] <rogpeppe> gary_poster: it would happen if you did remove-unit on each unit of the service
[12:34] <gary_poster> rogpeppe, and at that point the service would still be "around" in database terms--you could still make relations and add units and so on?
[12:35] <rogpeppe> gary_poster: yes
[12:35] <gary_poster> rogpeppe, GUI does not allow removing the last unit of a service FWIW, and neither AFAIK does pyjuju
[12:35] <gary_poster> but that's an aside
[12:36] <rogpeppe> gary_poster: interesting. i don't really see why it shouldn't, but that's a different issue, yeah
[12:36] <gary_poster> rogpeppe one other question: is there any way of looking at a service and knowing that it is on the way to being destroyed?
[12:36] <rogpeppe> gary_poster: yes, its Life will be Dying
[12:37] <rogpeppe> gary_poster: BTW did you see this? https://codereview.appspot.com/8761045/
[12:37] <gary_poster> rogpeppe, ah, ok.  I guess we ought to expose that in the deltas then. :-P
[12:37] <rogpeppe> gary_poster: yup
[12:37] <gary_poster> rogpeppe I saw that you had it up last night, but hadn't seen you had two LGTMs.  yay!  landing soon?
[12:37] <rogpeppe> gary_poster: yup
[12:46] <gary_poster> cool thank you rogpeppe 
[13:08] <teknico> bac, looking
[13:18] <bac> teknico: sorry i didn't see your new card.
[13:18] <teknico> bac, no worries :-) thanks for the review!
[13:28] <teknico> bac, done
[13:28] <bac> thx teknico
[13:37] <frankban> rogpeppe, gary_poster: it seems that, when a service A is connected to another service, the latter being in an error state, the ServiceDestroy call removes all the unit of service A but leaves the service alive without units.
[13:37] <rogpeppe> frankban: interesting
[13:37] <rogpeppe> frankban: that might be the expected behaviour
[13:38] <rogpeppe> frankban: what happens if you resolve the error status of the other service?
[13:39] <frankban> rogpeppe: trying
[13:41] <frankban> rogpeppe: it works well, the service A is removed after the unit is resolved
[13:41] <rogpeppe> frankban: hmm. i wonder.
[13:41] <gary_poster> rogpeppe, out of curiosity, why would that be desirable behavior?
[13:42] <rogpeppe> gary_poster: i'm not sure
[13:42] <gary_poster> cool
[13:42] <rogpeppe> gary_poster: it could be that it's not possible to leave a relation without the say-so of the other service
[13:42] <rogpeppe> gary_poster: in fact, i think that's probably the reason
[13:42] <rogpeppe> gary_poster: we insist on orderly teardown
[13:43] <gary_poster> huh.  "user is in charge and doesn't want the service so let's handle it for them" seems more user-friendly on the face of it.  But I guess the GUI really should be able to communicate these stories to the user
[13:44] <gary_poster> if user presses destroy and service hangs around, at the very least we should hand hold them
[13:44] <gary_poster> A notification like "the service cannot be completely destroyed until all units are resolved"
[13:44] <rogpeppe> gary_poster: i agree. i think the other service should probably allow services to leave the relation even if it's in an error state
[13:45] <rogpeppe> frankban: could you raise an issue, and mention why it's unexpected behaviour, please
[13:45] <gary_poster> cool
[13:47] <Makyo> Is that like https://bugs.launchpad.net/juju-core/+bug/1168154 ?
[13:49] <frankban> gary_poster, rogpeppe: IIUC it seems that a service refuses to execute his hooks while it's in an error state, and this involves also the relation-broken one. So, trying to destroy a connected service actually removes the units but fails removing the service itself. This can be sane from a point of view: the problem is that destroy service calls succeed without errors, and the user does not immediately know what's g
[13:49] <frankban> oing on.
[13:49] <frankban> rogpeppe: is that correct?
[13:49] <rogpeppe> frankban: sounds right to me
[13:50] <rogpeppe> frankban: although it's not clear to me why we need to execute the relation-broken hook *before* leaving the relation
[13:50] <gary_poster> Makyo, very similar to the one frankban is talking about, yes
[13:56]  * bac kicks lp2kanban
[13:59] <hatch> mornin!
[14:00] <rick_h_> jovan2: look like the changelog changes landed on staging as well: http://uistage.jujucharms.com:8080/bws/fullscreen/precise/apache2-2
[14:02] <jovan2> Thanks rick_h_
[14:03] <gary_poster> frankban, fwiw, I made a comment on Makyo's bug that is somewhat pertinent to what you are working with.  Dunno if it is helpful for you or even interesting, but it is comment 3 of https://bugs.launchpad.net/juju-core/+bug/1168154
[14:06] <frankban> gary_poster: cool, thanks, I'll link your comment in the new bug. I am trying to dupe the problem before filing it.
[14:06] <gary_poster> cool
[14:24] <frankban> rogpeppe, gary_poster: filed bug 1169588
[14:25] <frankban> and mup is not awake: https://bugs.launchpad.net/juju-core/+bug/1169588
[14:26] <benji> I have a gui review up at https://codereview.appspot.com/8797043
[14:27] <benji> Is the kanban bot not working any more?
[14:27] <gary_poster> frankban, thank you, looks good
[14:28] <gary_poster> benji, I saw bac was kicking lp2kanban but that's all I know
[14:28]  * bac still kicking
[14:28] <benji> k
[14:34] <hatch> I thought that the kanban bot broke a long time ago
[14:41] <hatch> rick_h_: did huw get npm working? I had to leave but he was gone when I got back
[14:41] <rick_h_> hatch: I *think* so. He had a pair of branches for me to look at but mentioned 'fighting with make all day'
[14:41] <rick_h_> hatch: so no idea how it went down.
[14:42] <hatch> ahh - his error message looked a lot like permissions issues
[14:53] <gary_poster> benji LGTM
[14:53] <benji> thanks
[14:55] <gary_poster> teknico, as you are working on your card, you might be interested in a conversation Ben and I had about one of my recent branches, which is pertinent.  Trying to find...
[14:57] <gary_poster> teknico, see https://codereview.appspot.com/8680043/ .  First comment #4, in para starting with "I agonized about this comment a bit," and then comment #7
[14:57] <teknico> gary_poster, looking
[14:58] <gary_poster> thanks teknico.  In essence, I'm inviting you to reconsider what I did, if you hadn't already.
[15:01] <teknico> gary_poster, uhm, hatch and I agreed that it would be a good idea to use the nsRouter in all the navigateTo event firings (?)
[15:01] <hatch> ^ bcsaller
[15:01] <teknico> gary_poster, is that reasonable?
[15:02] <gary_poster> teknico, sure, do you see the relation to what I pointed to?  This was bcsaller's advice as well, and what I did in that branch made it possible but somewhat more annoying to construct url's to a root value
[15:02] <gary_poster> teknico, so, my point is...
[15:02] <gary_poster> as you do what you are doing, which is fine by me,
[15:03] <gary_poster> consider whether what I did makes what you are doing overly annoying
[15:03] <gary_poster> and if so
[15:03] <gary_poster> ...I dunno, figure out something better :-P
[15:03] <teknico> gary_poster, links to the root are looking like this: this.fire('navigateTo', {url: this.get('nsRouter').url({gui: '/'})});
[15:04] <teknico> gary_poster, they do not upset me :-)
[15:04] <teknico> hatch, is that ^^ right? does it represent what you told me? :-)
[15:04] <hatch> yep
[15:04] <gary_poster> teknico I don't think that will work unless you include {includeRootPaths: true}
[15:04] <hatch> untested of course
[15:05] <gary_poster> teknico see https://codereview.appspot.com/8680043/diff/10001/app/assets/javascripts/ns-routing-app-extension.js
[15:05] <hatch> oh that's interesting
[15:05] <hatch> I wonder why that's there
[15:05] <teknico> gary_poster, oh, *that*'s the flag you were mentioning in the review
[15:05] <gary_poster> teknico, yes
[15:05] <gary_poster> sorry
[15:06] <hatch> gary_poster: do you know why that's included?
[15:06] <gary_poster> hatch, why yes :-)
[15:06] <teknico> those review comments are kind of cryptic :-)
[15:07] <gary_poster> hatch, do you mean "why do we remove namespaced root paths from the underlying URL? "  Or do you mean "why do we make it possible to include namespaced root paths in a url?"
[15:07] <gary_poster> or both :-P
[15:07] <hatch> why do we need a special flag, why can't we just generate the url
[15:08] <hatch> because it's just saying 'hey we won't generate the url you ask for....unless you ask for it with a smile' :D
[15:08] <benji> is the non-drag-or-click-ability of the service boxes on the trunk a known issue?
[15:08] <gary_poster> hatch, a root url is implied in all namespaces if not given
[15:08] <gary_poster> benji no
[15:08] <gary_poster> not by me
[15:09] <gary_poster> and confiremed on uistage
[15:09] <hatch> I know what it is
[15:09] <hatch> rick_h_: the subapp browser container is covering the environment
[15:10] <hatch> thanks benji
[15:10] <gary_poster> hatch so anyway, if I say "give me a url that is /:gui:/:foo:/:bar:/" then the pretty version of that is "/"
[15:10] <rick_h_> hatch: yes, we'll rework the html in follow up. 
[15:10] <gary_poster> thanks benji & hatch.  rick_h_, you able to revert, or fix quickly?
[15:10] <rick_h_> gary_poster: oh sorry, does it cover when not in /bws?
[15:10] <hatch> gary_poster: ahhh gotcha thx
[15:10] <hatch> rick_h_: yep
[15:10] <gary_poster> rick_h_, yes http://uistage.jujucharms.com:8080/
[15:10] <rick_h_> gary_poster: yes, can fix it asap
[15:11] <gary_poster> thanks rick_h_ 
[15:11] <gary_poster> hatch, teknico, *but*...
[15:11] <gary_poster> if I am on the /:gui:/service/wordpress page
[15:11] <gary_poster> and I want the user to go to the root
[15:11] <gary_poster> then that needs to be spelled /:gui:/
[15:12] <gary_poster> because of you spell that "/" then the router's combine method will assume that you want to keep all namespaced paths that you didn't explicitly specify as they are now
[15:12] <gary_poster> So there are a few options
[15:13] <gary_poster> But did that make sense, teknico, hatch, before I talk about the possible solutions, including the one I chose, even though I was not entirely convinced by it?
[15:14] <gary_poster> s/of you spell that/if you spell that/
[15:14] <hatch> I think that this is showing a small issue in the way the urls are being generated...
[15:14] <hatch> for example...
[15:15] <teknico> gary_poster, I'm still confused, can you please tell me what the router output will now be in the second case you mentioned (spelling "/")?
[15:15] <hatch> if I"m at example.com/foo/bar/:gui:/baz/bax and I generate a url via nsRouter.url({gui: '/cars'/}) I should get a url example.com/foo/bar/:gui:/cars/
[15:15] <hatch> so following that thinking....
[15:16] <hatch> nsRouter.url({gui: '/'}) should return example.com/foo/bar/:gui:/
[15:18] <gary_poster> teknico, the router combine method will say "ok, we are currently at /:gui:/service/wordpress.  I am supposed to now go to a new url that the developer gave me, which might or might not have a value in the same namespace.  If the new url doesn't have a value in a given namespace, I will keep the current value in place.  That way, for instance, if I'm at :charmstore:/foo/bar and you tell me to go to :gui:/service/wor
[15:18] <gary_poster> dpress, we don't lose url state of the charmbrowser bit--the new url is :charmbrowser:/foo/bar/:gui:/service/wordpress.  You gave me the new url "/".  That doesn't override any namespaces at all!  I'll keep everything just as it is now."I want to keep any namespace that is not "
[15:19] <gary_poster> just as it is now
[15:19] <gary_poster> uh oh that got messed up :-/
[15:20] <hatch> gary_poster: but when you pass an object in does it not assign those rules to the specified namespace?
[15:20] <gary_poster> Actually, just lop off the last partial sentence and it's what I meant (remove "I want to keep any namespace that is not ")
[15:20] <gary_poster> hatch, in to what?
[15:21]  * gary_poster reads your comments now...
[15:21] <hatch> well we aren't passing strings into the url method
[15:21] <hatch> we are passing an object specifying the namespace as the key
[15:21] <teknico> gary_poster, ok, go ahead: what's the URL of "everything as it is now"?
[15:22] <rick_h_> gary_poster: hatch fix is through lbox, just waiting on next staging update. 
[15:23] <hatch> thanks rick_h_
[15:24] <gary_poster> teknico, If the combine method is combining any url with namespaced paths--and they are all namespaced--then a "/" path without namespace in that context...let's move to guichat in a sec
[15:24] <gary_poster> rick_h_, thank you.  trying to manually update...
[15:25] <hatch> gary_poster: mind if I join?
[15:25] <teknico> gary_poster, ok
[15:25] <gary_poster> hatch of course not, meant to include you
[15:25] <gary_poster> rick_h_, updated (http://uistage.jujucharms.com:8080/juju-ui/version.js) but still see problem.  retrying...
[15:25] <rick_h_> gary_poster: needs css update
[15:26] <gary_poster> ack
[15:26] <gary_poster> I did a make build
[15:26] <rick_h_> gary_poster: looking 
[15:26] <gary_poster> rick_h_, maybe there are more less files to watch now ?
[15:26] <rick_h_> gary_poster: yes, but they're tied into make
[15:26] <gary_poster> ok
[15:27] <rick_h_> gary_poster: but yea, I don't see the css change in the site
[15:27] <rick_h_> #subapp-browser should have a default display: none rule on it
[15:27] <gary_poster> rick_h_, http://pastebin.ubuntu.com/5713430/ shows make build output.  it combines css but shouldn't it have built css from less?
[15:28] <gary_poster> can run make clean && make...
[15:28] <gary_poster> but that would be a Makefile bug that we ought to be able to fix trivially if that is the problem
[15:28] <rick_h_> hmm, 'just worked' here with me running make devel as I fixed it in
[15:28] <gary_poster> trying make clean
[15:28] <rick_h_> maybe it's in make devel but not a diff make target space
[15:29] <gary_poster> should be part of build target...
[15:29] <gary_poster> rick_h_, make clean && make fixed it, thanks.  put a card in to investigate build css issues when you get a chance later?
[15:30] <rick_h_> gary_poster: will do
[15:30] <gary_poster> thank you
[15:30] <frankban> rogpeppe, gary_poster: I am working on adding services' life to the delta. What do you think it is better: passing the juju-core int values (0:alive, 1:dying, 2:dead) or maybe just provide what's required by the GUI, e.g. Alive bool?
[15:31] <gary_poster> I like alive bool, where dying means dead, yeah?
[15:31] <frankban> gary_poster: yes, dying is alive == false
[15:32] <gary_poster> cool, fine with alternative but sounds good to me
[15:32] <frankban> gary_poster: that's called boolean euthanasia
[15:32] <gary_poster> lol frankban 
[15:32] <hatch> lol
[15:51] <gary_poster> jujugui please update kanban board
[15:58] <rogpeppe> gary_poster: the config branch has landed BTW
[15:58] <gary_poster> jujugui call in 2
[15:58] <gary_poster> awesome thanks rogpepe
[15:58] <gary_poster> rogpeppe, 
[16:01] <gary_poster> benji ping
[16:16] <benji> g*ry: sorry I was late to the meeting, my battery alarm went off the same time as your ping so I was running around like a crazy person getting power out here
[16:16] <benji> One of my projects around the house should be external outlets every 20 feet or so.
[16:16] <hatch> benji: that's code here
[16:17] <hatch> not sure if it's 20ft but something like that
[16:17] <benji> hatch: houses built in rural Tennessee in 1938 don't quite meet modern code. ;)
[16:17] <hatch> haha
[16:18] <benji> I still have quite a bit of "knob and tube" wiring, which is frightenting.  I have so many project to do.
[16:29]  * gary_poster had to look up knob and tube wiring
[16:29] <gary_poster> cool benji :-)
[16:32] <gary_poster> benji I triage #1169625 as low based on your description.  Do  you agree?
[16:32] <benji> gary_poster: yep, it's just aesthetics
[16:33] <gary_poster> cool, will mark
[16:33] <benji> I should have marked it as such.
[16:33] <gary_poster> np
[16:37] <benji> gary_poster: is it a bug that "make devel" and "make prod" generate 404s when you directly navigate to "http://localhost:8888/:gui:/service/wordpress/config/"?
[16:37] <benji> (when tha service does indeed exist)
[16:37] <gary_poster> benji, yeah
[16:38] <benji> ok, I'll file that one then
[16:38] <gary_poster> cool thank you
[16:41] <benji> gary_poster: that one seems "normal" (as opposed to "low" or "high")
[16:41] <gary_poster> benji, mmm...let's call it high.  I need to garden bugs. :-/
[16:42] <benji> gary_poster: yeah, I meant "high" for the bug, non-annotated (normal) if it were a card
[16:42] <gary_poster> benji, OIC, yes agree
[17:01] <teknico> gary_poster, what does "TARDIS" mean in "Multi dimensional router (TARDIS)"?
[17:01] <gary_poster> teknico, Doctor Who joke from bcsaller :-)
[17:02] <gary_poster> http://en.wikipedia.org/wiki/TARDIS
[17:02] <teknico> ok, I suspected as much, just wanted to check :-)
[17:06] <hatch> if the sandbox had a sample setup it would be awesome to dev with
[17:06] <hatch> so fast
[17:10] <bcsaller> hatch: writing a simulator should be a slack card. I think the way to go is to add support for env import/export to the fakebackend 
[17:10] <hatch> slots of slacks
[17:11] <rick_h_> hatch: got a quick sec for another guichat on navigate?
[17:12] <hatch> 2 seconds
[17:13] <hatch> alright
[17:13] <hatch> see u in guichat
[17:17] <rick_h_> hatch: take 2?
[17:17] <hatch> take 2
[17:19] <gary_poster> bac benji or Makyo, Francesco is heading out for the day.  Someone needs to get his lp:~frankban/juju-core/bug-1169609-service-life branch tested and landed
[17:20] <gary_poster> He suggests this: "I'd also manually test it, bootstrap, deploy, detsroy-service, to be extra paranoid check if it works well with the GUI"
[17:21] <gary_poster> This needs to land today
[17:21] <gary_poster> In order to get it into raring
[17:21] <Makyo> I can test.
[17:22] <gary_poster> so it is of higher urgency then bug 1169239 or bug 1169350, both of which are also good.
[17:22] <gary_poster> Thank you very much Makyo 
[17:24] <frankban> Thanks a lot Makyo: the goal for that branch, and the thing to be tested above all, is that when you destroy a service you should see a serviceInfo change in the delta including Life: "dying" (where before it was "alive")
[17:25] <Makyo> frankban, alright.  Connection's being a little slow, but I'm on it.
[17:25] <frankban> thanks again, have a good evening all
[17:49] <rick_h_> https://blog.mozilla.org/labs/2013/04/introducing-towtruck/ cool for doing UX reviews and such
[17:50] <hatch> very cool
[18:04] <gary_poster> Hey Makyo I forget how it works but on http://uistage.jujucharms.com:8080/ aren't you supposed to be able to hover over the connection thing to the right of puppet and see the relations?
[18:05] <Makyo> gary_poster, yeah.
[18:05] <gary_poster> thought so.  Will file bug, thx
[18:08] <Makyo> Can't connect to websocket with core.  Frustrating.
[18:08] <Makyo> The connection to wss://blah:17070/ was interrupted while the page was loading.
[18:09] <gary_poster> Makyo, are you using the charm?
[18:09] <Makyo> gary_poster, no, local with updated config-debug.js
[18:10] <gary_poster> Makyo, oh.  did you do the cert dance on firefox?
[18:10] <Makyo> Yep.
[18:10] <gary_poster> oh ok
[18:10] <Makyo> gary_poster, ^
[18:11] <gary_poster> Makyo, I've got nothing then.  I think the charm was working.   If not, we need to raise an alarm pronto.
[18:11] <Makyo> Trying the charm next.
[18:15] <Makyo> Probably just this awful, awful connection.  Looking into it after this test.
[18:24] <rick_h_> hatch: halp! I'm missing something to get your subapp/view event to work. 
[18:25] <rick_h_> hatch: https://code.launchpad.net/~rharding/juju-gui/browser_links/+merge/159215 is the diff, the event is picked up if listened directly, but not through the addTarget. I tried making sure the event is published with the eventFacade set to true. Guessing I'm missing another step?
[18:26] <hatch> looking
[18:27] <hatch> this._editorial.addTarget(this);
[18:27] <hatch> ^ rick_h_
[18:27] <rick_h_> ah, other way around. doh
[18:28] <hatch> :)
[18:29] <rick_h_> hey, that seems to work better. Thanks :)
[18:29] <rick_h_> wooo! and a click was routed and there was much rejoicing
[18:32] <Makyo> bac, benji, gary_poster I need someone to help test this
[18:32] <Makyo> I think my net's just too flaky for the websocket anywhere but locally now.
[18:32] <benji> Makyo: what can I do for yout?
[18:33] <Makyo> I've got the charm up and running at https://ec2-54-234-250-86.compute-1.amazonaws.com/
[18:33] <Makyo> And I've got debug-log running.
[18:33] <bac> Makyo: i can help too.  i have the most stable connection in all the carribean
[18:33] <Makyo> Just need someone to deploy something like mysql and then destroy it.
[18:34] <hatch> alright
[18:34] <hatch> what's the pw?
[18:34] <Makyo> dbf1302887184d04aafb7502b40fcf51
[18:35] <hatch> wow sucks for the guy who has to type that every day
[18:35] <hatch> lol
[18:35]  * gary_poster thinks of evil things he could do with that
[18:35] <hatch> Makyo: can't log in
[18:35] <bac> i just got into Makyo's 401K
[18:35] <gary_poster> lol
[18:35] <Makyo> Hah.
[18:35] <benji> Makyo: it looks like you have all the help you need.  Let me know if there is anything I can do.
[18:36] <Makyo> YEah, hatch, it's sending EntityName rather than AuthTag.
[18:36] <Makyo> Give me just a sec.
[18:36] <Makyo> Forgot to set the source.
[18:37] <gary_poster> so "a sec" here means "about 10 minutes" :-)
[18:37] <hatch> lol
[18:37] <Makyo> hah, yeah.  About every third juju command fails for connection lost.
[18:37] <hatch> sounds like you need to switch to hotspotting your phone
[18:37] <hatch> or are you on one of those archaic providers who limits your data?
[18:38] <gary_poster> btw, hatch, it was a small thing to fix the sandbox subordinate thing.  seeing if I can figure out bug 1169668 real quick for a twofer.
[18:38] <Makyo> It gets slowed down after a while, but not capped.
[18:38] <hatch> gary_poster: ahh awesome
[18:38] <Makyo> Try logging in again
[18:38] <Makyo> Well, refresh first.
[18:38] <hatch> Makyo: ahh cool - we are unlimited but throttled after 10GB which is alright :)
[18:39] <hatch> but I can still stream netflix on throttled speeds so Iunno what they get throttled to haha
[18:39] <gary_poster> heh
[18:39] <hatch> Makyo: still can't log in
[18:40] <gary_poster> fwiw, I'd be surprised if the charm built in 3 min
[18:40] <Makyo> I'm still getting EntityName.  Was the AuthTag branch not released?
[18:40] <gary_poster> built the GUI I mean
[18:40] <Makyo> Well, whatever, I'll switch to bzr
[18:40] <gary_poster> Makyo, it was, but it takes about 8 minutes IME to get the dependencies
[18:41] <gary_poster> oh, released!
[18:41] <gary_poster> no, it wasn't
[18:41] <gary_poster> needs to be lp:juju-gui
[18:41] <Makyo> gary_poster, Yeah, I just saw hook complete. I'll switch to bzr.
[18:41] <gary_poster> cool
[18:43] <Makyo> Was thinking trunk was an alias to that, but then I saw it downloaded a tarball :)
[18:43] <gary_poster> yeah, trunk series release.  Maybe not the best name I chose.
[18:44] <gary_poster> I think the subordinate relation thing is another fallout from the safe DOM name change...
[18:46] <hatch> poop, I wish the GUI would send the relation id to the backend to remove
[18:46] <hatch> that would have been trivial to implement heh
[18:47] <gary_poster> OK, fixed the subordinate thing.  To whom it may concern (maybe Makyo knows?) why can't you remove a subordinate relation?
[18:48] <hatch> in the sanbox?
[18:48] <Makyo> gary_poster, I put it in there, but gosh that was a while ago.  Let me hunt down the branch.
[18:48] <gary_poster> hatch, the GUI doesn't let you
[18:49] <gary_poster> hatch, it is a popup
[18:50] <bac> gary_poster: s/to whom it may concern/g u i h e l p/ :)
[18:50] <hatch> gary_poster: ahh yeah even doing it through the service view throws an error
[18:50] <gary_poster> bac, heh, yeah, if Matt hadn't known I would have escalated
[18:50] <bcsaller> gary_poster: in PyJuju w/o stop hooks it doesn't work at all. With stop hooks there are still unclear semantics around the ordering and teardown of subordinates wrt their parent container 
[18:50] <Makyo> gary_poster, https://bugs.launchpad.net/juju-gui/+bug/1078776
[18:51] <hatch> ok so I don't need to implement that in the fakebackend then?
[18:51] <Makyo> hatch, Nah.
[18:51] <gary_poster> Makyo, bcsaller ah, ok, thanks!
[18:51] <hatch> ctrl+a del
[18:51] <gary_poster> hatch, sorry, didn't know :-) (and hopefully not ctrl-a!)
[18:52] <hatch> haha no, I just had it in my TDD list :)
[18:52] <Makyo> Alright, gui finished building.  hatch +whoever, refresh and try logging in again
[18:52] <hatch> alright
[18:53] <bac> gary_poster: regarding the config/setting card, now that rog is supporting it we just need to update the db in the handler, right?  the work-around of refetching should not be required iiuc
[18:53] <hatch> Makyo: ok mysql deployed...do I now wait for it to bootup?
[18:53] <Makyo> Yes please.
[18:53] <hatch> ok that means white correct?
[18:54] <Makyo> Yeah.
[18:56] <gary_poster> bac
[18:56] <gary_poster> sorry bac right
[18:56] <bac> gary_poster: yay
[18:56] <gary_poster> bac, the only thing extra is the default values, as we discussed on call
[18:56] <bac> yeppers
[18:58] <bac> gary_poster: fwiw, i spent more time than i wanted dealing with canonistack/lp2kanban.  it looks like canonistack has a problem where new machines are communicating with the keyserver-like thing on the backend that is supposed to insert a user's ssh keys.  worked with montreal to try to get it diagnosed.
[18:58] <bac> s/are / are not
[18:58] <gary_poster> bac, ah, sorry.  ok.  resolved yet or in progress?
[18:59] <hatch> Makyo: destroyed....popup happened, the mysql element destroyed, then it poped back onto the gui, with a white ring....turned to a yellow ring....then dissapeared
[18:59] <bac> gary_poster: logged in their new fancy salesforce tracker.  don't know what happens now.  the work-around is to just keep spinning up and killing machines until one lets you in
[19:00] <gary_poster> hatch, darn, I think you need to get the service after it pops back to verify that there is some new attribute--life I think--and it is set do a "DYING" state
[19:00] <gary_poster> Makyo, or you can look at logs, alternatively
[19:00] <Makyo> hatch, okay.  I did see the correct Life attribute, at least!
[19:00] <gary_poster> bac, ugh, ok
[19:01] <Makyo> {"RequestId":18,"Response":{"Deltas":[["service","remove",{"Name":"mysql","Exposed":false,"CharmURL":"cs:precise/mysql-16","Life":"dying","Constraints":{},"Config":{"binlog-format":"MIXED","dataset-size":"80%","flavor":"distro","max-connections":-1,"preferred-storage-engine":"InnoDB","query-cache-size":-1,"query-cache-type":"OFF","tuning-level":"safest"}}]]}}
[19:01] <gary_poster> Makyo, hatch, ok, that's perfect.  We need to change the behavior hatch described after frankban's branch lands
[19:01] <Makyo> Cool :)
[19:01] <Makyo> Test complete for that?
[19:02] <gary_poster> Mayo +1
[19:02] <gary_poster> Makyo +1
[19:02] <gary_poster> Mustard +1
[19:02] <Makyo> Ketchup -10000
[19:02] <gary_poster> :-)
[19:02] <Makyo> Never any ketchu.
[19:02] <Makyo> p
[19:02] <Makyo> Alright, destroying the env, and now I'm going to go reflash my router to see if that fixes this net problem.
[19:03] <Makyo> An update over the weekend is when it started.
[19:09] <hatch> yay es5 `[0, 1].each(function(index) {});`
[19:09] <hatch> :)
[19:09] <hatch> crap that's wrong lol
[19:09] <hatch> [0, 1].forEach(function(index) {});
[19:11] <hatch> it kind of looks funny
[19:16] <rick_h_> curses! back to still needed to write a state manager for the browser to be able to build the right url to navigate to
[19:17] <gary_poster> rick_h_, why?
[19:17] <gary_poster> that's definitely not our hope, AIUI
[19:17] <rick_h_> gary_poster: because of the way I pass through multiple route callables to build the UX, no one part knows wtf the current state actuall is. 
[19:18] <gary_poster> but...the current url is supposed to represent the state that you have to worry about in this regard?
[19:18] <rick_h_> the search nav widget has a button to go fullscreen. It's dumb. It just wants to say "change the current url to fullscreen" but the view that rendered it just knows "any sidebar view needs a search widget" and doesn't know about a charmID that's currently visible. Someone else knows that. 
[19:19] <rick_h_> gary_poster: right, but I'd have to store the last url and parse/update it which is what the state manager needs to do
[19:19] <gary_poster> put it in the url, rick_h_ ?  That was our intent
[19:19] <gary_poster> but rick_h_ that's what the namespaced router does for you already
[19:20] <rick_h_> gary_poster: so it will handle the namespace, but not the parts of my url that I care about. I have to know what url or object of params to give to the navigate code
[19:20] <gary_poster> it gets the url before changing, parses, updates only the bits you want to update, and then...
[19:20] <gary_poster> oh!
[19:21] <gary_poster> rick_h_, you could put state in its own namespace :-P
[19:21] <rick_h_> so for just the browser /bws/sidebar/search/precise/apache2-2?text=apache
[19:21] <gary_poster> rick_h_, fwiw in that context I was wondering about this story:
[19:21] <rick_h_> that breaks down to sidebar view mode, filled with search results, looking at the details of the precise apache2 charm
[19:22] <rick_h_> so the button that goes to fullscreen wants to do a s/sidebar/fullscreen but keep the rest and then I can hand the url to navigation code
[19:22] <gary_poster> rick_h_, maybe crazy idea, but what about making a new namespace for just the sidebar/fullscreen choice?  The fullscreen choice would be the root
[19:23] <gary_poster> so it would not be present for fullscreen urls
[19:23] <rick_h_> *thinking*
[19:23] <gary_poster> *or*
[19:23] <gary_poster> crazier idea
[19:23] <gary_poster> this gets to a user concern I had
[19:23] <gary_poster> what if you open the charm browser
[19:23] <gary_poster> look at some cool stuff
[19:24] <gary_poster> find a charm you like
[19:24] <gary_poster> minimize the charm browser for a sec to see the environment
[19:24] <gary_poster> and then open it up again
[19:24] <gary_poster> crap!
[19:24] <gary_poster> state lost!
[19:24] <rick_h_> yea, I'm working to keep that. 
[19:24] <rick_h_> minimize doesn't change the url or change the browser subapp state
[19:24] <gary_poster> welll...he said with a crazy gleam in his eye
[19:24] <rick_h_> ruh roh
[19:24] <gary_poster> :-)
[19:25] <gary_poster> if you divide out the left window expansion state
[19:25] <gary_poster> then it has three states
[19:25] <gary_poster> closed, side, full
[19:25] <gary_poster> changing that state becomes super simple
[19:25] <gary_poster> if it is in its own namespace
[19:25] <gary_poster> and meanwhile the charm info hangs around, la de da de de da
[19:26] <rick_h_> maybe my crash course in routing/namespace today hasn't full prepped me to grasp the awesomeness of the idea
[19:26] <gary_poster> (that was the sound that charm infos make when they sing)
[19:26] <rick_h_> I've got a namespace due to my subapp defining one. To create new ones I'm seeing the need to multi-subapp or something
[19:26] <rick_h_> which seems like crazy talk 
[19:27] <gary_poster> rick_h_, I dunno maybe not awesome, maybe crazy.  I was hoping that namespace/subapp were not tied together at the hip.  hatch?
[19:29] <hatch> umm lemme read the baglog
[19:29] <hatch> backlog
[19:31] <rick_h_> I like baglog
[19:31] <hatch> sounds like the issue is caused by not having the url states as variables
[19:32] <hatch> like having sidebar/fullscreen a /:viewsize/
[19:32] <rick_h_> hatch: they are, depending on which route handling function you're in :)
[19:33] <rick_h_> hatch: but yea, :viewsize is not a var.
[19:34] <rick_h_> hatch: oh hmmm...maybe something can be worked out. the var can be repeated in later routes I guess
[19:34] <rick_h_> and then the subapp can pass the req.params into the view for it to know about the current state
[19:34] <gary_poster> rick_h_, maybe this is an "everything starts to look like a nail" situation.  Just an idea.
[19:35] <hatch> rick_h_: lets guichat this
[19:35] <rick_h_> gary_poster: I'm looking. I think there's a half way point where it's not as complicated as I'm thinking it is, but maybe not as simple as on the fly namespaces
[19:35] <gary_poster> ack
[19:35] <rick_h_> hatch: sure
[19:36]  * gary_poster holds himself back from joining, 'cause he wants to get other stuff done. sounds like fun though.  lemme know what you decide :-)
[19:42] <hatch> rick_h_: you froze
[19:47] <hatch> solved....going for lunch
[19:47] <hatch> bbl
[20:07] <bac> guihelp: anyone seen something like this http://pastebin.ubuntu.com/5714170/ where subsequent juju commands have failed b/c the previous one isn't done yet?  introduced since yesterday i think.
[20:07] <gary_poster> not I
[20:13] <Makyo> Hopefully good news on net \o/
[20:13] <Makyo> bac, This is a stretch, but have you tried deleting /tools from  your s3 bucket?
[20:13] <bac> Makyo: not today
[20:13] <bac> do i need to add that to my morning routine?
[20:14] <Makyo> bac, curious if it helps. I've seen something like that, but I also saw it around a 'error: using closed connection' problem, so I had deleted the tools
[20:14] <bac> make tea, take dog out, shower, delete bucket, take dog out, delete bucket, cereal
[20:15] <gary_poster> lol
[20:15] <bac> Makyo: i got everything happy by reissuing those commands after the bootstrap was done.  so my environment is happy.  when i'm done with it i'll try what you suggest
[20:16] <bac> thanks for the idea
[20:18] <gary_poster> Hey Makyo, I feel like learning some debugging tips.  Want to see if your connection is good enough to pair? :-)
[20:19] <gary_poster> If you are busy that is fine of course
[20:19] <Makyo> gary_poster, Now's good :)
[20:19] <gary_poster> cool, Makyo guichat is free.  thank youi
[20:31] <rick_h_> note to self: _state is a registered trademark YUI doesn't like if you try to use it for your own devices
[20:33] <rick_h_> lol, _dispatch is also already owned
[20:39] <hatch> :)
[20:47] <rick_h_> hatch: going to ring again :)
[20:47] <rick_h_> meh, let me try one more thing first I guess
[20:48] <hatch> alright
[20:50] <hatch> does anyone know what I am supposed to put into the delta for removing relations?
[20:50] <hatch> ^ bcsaller gary_poster
[20:50] <hatch> I don't really understand the delta yet
[20:51] <gary_poster> hatch will look soon
[20:52] <bcsaller> hatch, gary_poster I'm checking now
[20:52] <bcsaller> I expect its very little
[20:52] <hatch> thanks - and also some time i'd like a crash course on the delta :)
[20:56] <rick_h_> ok hatch, I think I broke routing. 
[20:57] <rick_h_> hatch: I needed to have multiple routes with the * to enable hitting multiple functions to do the rendering in the subapp
[20:57] <rick_h_> hatch: but now when I try to route to a url I get 'URL has more than one reference to same namespace ' which I assume it's because with the * there's multiple possible 'routes' it could be?
[20:57] <hatch> guichat?
[20:58] <hatch> or actually, the code you have would be better
[20:58] <bcsaller> hatch: sure
[20:58] <rick_h_> hatch: let's try not to atm, at a coffee shop and don't have my head set
[20:58] <hatch> have it pushed up somewhere?
[20:58] <hatch> ahh ok
[20:58] <bcsaller> oh, that wasn't to me
[20:58] <hatch> bcsaller: well if rick_h_ doesn't want to talk to me you can :)
[20:58] <hatch> haha
[20:58] <rick_h_> hatch: https://code.launchpad.net/~rharding/juju-gui/browser_links and the link to test out with is http://127.0.0.1:8888/bws/fullscreen/precise/cassandra-1/ then click on the 'minimize' button on the right
[21:00] <hatch> is the method name router already used?
[21:00] <hatch> thought it was....
[21:00] <rick_h_> oh hmm, it works 
[21:00] <hatch> ok well no biggy, I just thought that it did
[21:00] <rick_h_> I can change it. It's used in two places in this file
[21:00] <hatch> ok back to reading
[21:01] <hatch> rick_h_: I'm curious as to why you are calling that method with call() vs just calling it directly, the scopes are the same
[21:02] <rick_h_> hatch: because I wanted to get fancy :P
[21:02] <hatch> lol
[21:02] <hatch> ok I'll check out the code now to see what's happening
[21:02] <rick_h_> _getStateUrl buids the url for the subapp to fire it's event to. 
[21:02] <bcsaller> hatch: for the relation remove it looks like it will be the standard remove clause (untested), this.changes.relation[relation.get('id')] = [relation, false];
[21:03] <rick_h_> and that urls is triggered the multple points errors
[21:03] <hatch> bcsaller: ok great thanks, that's kind of what I had assumed but wasn't sure
[21:03] <bcsaller> changes.relations
[21:03] <bac> hi gary_poster, you have a minute for a quick call re: config loading?
[21:03] <gary_poster> bac, in 5?  Matt is helping me debug
[21:04] <bac> gary_poster: sure, just ping me
[21:04] <hatch> rick_h_: I thought they were shutting that coffeeshop down?
[21:04] <rick_h_> hatch: I'm trying a new one farther away full of kids doing magic card game :(
[21:04] <rick_h_> I can't just stay in the house all day for multiple days 
[21:04] <hatch> helllz yeah
[21:05] <rick_h_> hatch: how about phone call?
[21:05] <hatch> magic cards all but went poof here
[21:05] <rick_h_> heh
[21:05]  * hatch has a few shoeboxes full
[21:05] <hatch> lol
[21:05] <rick_h_> or I can head back to the house to chat 
[21:05] <rick_h_> lol
[21:05] <hatch> one sec I am now loaded up
[21:06] <hatch> ok I can repro, now to debug
[21:09] <hatch> rick_h_: i'm not sure what I did but on refreshing I now can't make reuqests to the staging.jujucharms.com url
[21:10] <hatch> oh wait
[21:10] <hatch> i'm on sidebar
[21:10] <rick_h_> hatch: yea, ignore that
[21:10] <rick_h_> hatch: abentley moved an api enpoint to fill in the editorial data that's not updated yet
[21:10] <rick_h_> the charm deails still loads/works
[21:11] <rick_h_> http://127.0.0.1:8888/bws/fullscreen/precise/cassandra-2/ and /fullscreen/sidebar is what I'm trying to figure out
[21:11] <rick_h_> and this multi-route business comes into that change over
[21:11] <rick_h_> either page loads fine on it's own, but re-routing ot the other via the minimize button next to search throws the error
[21:12] <hatch> ok so the real issue looks to me Uncaught TypeError: Cannot read property 'parentNode' of null
[21:12] <rick_h_> ooh, wonder if it's prefix /
[21:12] <rick_h_> hatch: no, that's the double routing breaking 
[21:13] <rick_h_> hatch: pushing up a branch with debugger's right at the right points. 
[21:14] <rick_h_> hatch: one of them is right after the new url is generated in the subapp and before it fires it up to the this.navigate
[21:14] <rick_h_> hatch: that url getting up to the ns routing code is confusing it
[21:15] <rick_h_> hatch: branch update pushed, merge down again
[21:17] <rick_h_> hatch: guichat? or another chat if it's taken?
[21:17] <rick_h_> willing to try it if you can tolerate the noise :)
[21:18] <hatch> something is messed right up here
[21:18] <rick_h_> hatch: lol
[21:18] <hatch> it's being dispatched 3 times
[21:19] <rick_h_> no, both routes get dispatched two times each
[21:19] <rick_h_> only one is checking if it's already been run so one is ignored
[21:19] <rick_h_> and the other runs twice (the charmDetails)
[21:21] <gary_poster> bac come on by guichat
[21:22] <bac> gary_poster: ok, just a sec
[21:22] <rick_h_> hatch: https://plus.google.com/hangouts/_/6c81e1105b1668757643f2f3efb3d0a5ee33fa6f?authuser=0&hl=en if you want to try to chat
[21:23] <hatch> it's ok just debugging
[21:23] <rick_h_> hatch: cool
[21:24] <hatch> ok the sidebar renderer is definitely being called three times
[21:24] <hatch> but why three
[21:26] <hatch> ok i'm getting close
[21:26] <rick_h_> hmm, parse is getting the url /bws/fullscreen/precise/cassandra-2/:charmstore:/bws/sidebar/precise/cassandra-2 to parse 
[21:26] <hatch> ok I think i have it fixed
[21:27] <hatch> just give me a second to clean this up and test some more
[21:27] <rick_h_> hatch: rgr
[21:27] <rick_h_> thanks
[21:27] <hatch> can you tell me where the event handler is for the button we r pressing?
[21:28] <rick_h_> hatch: yes, in subapp/browser/views/view.js
[21:28] <rick_h_> see _bindXXXXXX
[21:28] <hatch> got it
[21:28] <rick_h_> we're binding to TOGGLE_FULLSCREEN
[21:30] <hatch> ok I have it working but it re-renders the whole application when you click that button
[21:30] <rick_h_> :(
[21:30] <rick_h_> hatch: isn't there a ev.halt() on the button handler?
[21:30] <hatch> nope
[21:30] <hatch> but that didn't help
[21:31] <rick_h_> oh no there's not doh
[21:32] <hatch> http://pastebin.ubuntu.com/5714396/
[21:32] <hatch> there is my diff to get it working but with the refresh
[21:33] <rick_h_> hatch: well I wonder if that's jut working around the issue. If it's refreshing then it's not going through the nsrouter to trigger the issue
[21:33] <rick_h_> hatch: so it's probably still there just you can't see it. 
[21:33] <rick_h_> hatch: whenI debug the parse() method in the nsrouter it's getting two urls that maps to the same thing
[21:34] <rick_h_> hatch: as I pasted above: /bws/fullscreen/precise/cassandra-2/:charmstore:/bws/sidebar/precise/cassandra-2 parses the first part correctly, but then it's got left :charmstore:, '/bws/sidebar/precise/cassandra-2' so it finds two valid url parts that overlap
[21:35] <rick_h_> hatch: because of that dupe it throws that error in line 130 of the router
[21:36] <rick_h_> honestly tempted to just say if it's already int he result to just drop it silently but guessing there's something between the subapp navigate/nsrouter parse() that needs a fix
[21:40] <hatch> closer...
[21:47] <hatch> ok fixed
[21:48]  * rick_h_ bows as I'm still trying to see what's wrong. 
[21:48] <rick_h_> that error was just a warning really, and the _dispatch list seems in good shape
[21:49] <hatch> few moments I just want to clean this up
[21:49] <rick_h_> hatch: np
[21:49] <hatch> and i'llg et you the diff
[21:50] <hatch> is sidebar to fullscreen supposed to work too?
[21:50] <hatch> or not yet
[21:50] <rick_h_> hatch: yes
[21:50] <rick_h_> that shold work both ways
[21:50] <hatch> ok so then it's not fixed
[21:50] <hatch> lol
[21:50] <rick_h_> the lick handler updates the change: {} based on the current setting
[21:50] <hatch> close though, works one way but not the other
[21:50] <rick_h_>  click handler that is
[21:51] <rick_h_> ok, maybe I've got a bug in that then. 
[21:51] <rick_h_> hmm, well actually that'd be hard. the isFullscreen is based off the class name. Maybe the old view isn't destroyed or something
[21:52] <hatch> ok fixed
[21:52] <hatch> now cleanup
[21:52] <hatch> whatever I had for lunch feels like it's trying to eat it's way out of my gut
[21:52]  * hatch punches self
[21:53] <rick_h_> get me the diff before alien jumps out of your stomach!
[21:53] <rick_h_> :P
[21:54] <hatch> haha
[21:54] <hatch> http://pastebin.ubuntu.com/5714442/
[21:56] <hatch> rick_h_: try and follow what my changes did, especially wrt the routing
[21:56] <hatch> if you don't understand I'll be more than happy to guide you through it
[21:56] <rick_h_> hatch: looking...looks like removed all the next() calls
[21:56] <rick_h_> ah, movd it 
[21:57] <rick_h_> but ...hmm that could case me to have my race conditions again as details can't run until after fullscreen or sidebar run
[21:58] <hatch> they won't that's called in your showview callback
[21:58] <hatch> so the sidebar and fullscreen will run then call renderEditorial
[21:59] <rick_h_> right, but charmDetails needs to run after fullscreen/sidebar
[21:59] <rick_h_> that's why next() is called from them once it either builds or isn't needed to run again because it's already there
[22:01] <hatch> oh I see -
[22:02] <rick_h_> but you're right that it 'works' now. I don't really get why, but ok
[22:02] <rick_h_> I can work from here. I thoght the giant url in the router/warnings about "URL has more than one reference to same namespace " was to blame but cool
[22:02] <hatch> rick to avoid those race conditions
[22:02] <hatch> remove the next in the router method
[22:03] <rick_h_> time to run, day care closes in 28min
[22:03] <hatch> and then add the ones back on lines... 165 256
[22:03] <rick_h_> I'll be back online after his bed time to tinker some more
[22:03] <hatch> it still works but should avoid the race condition you were worried about
[22:03] <rick_h_> hatch: yea, I'll mess with it and see. Thanks for looking it over!
[22:03] <hatch> no problem
[22:27] <hatch> huwshimi: hey did you get your npm issue solved?
[22:27] <huwshimi> hatch: Yes! I figured out that the ppa had somehow been disabled so I hadn't got an update. Enabled the PPA, updated and then it all worked.
[22:28] <hatch> wow that's odd
[22:28] <hatch> I was sure it was some permissions issue
[22:31] <huwshimi> I saw some reports of similar errors happening when the nodejs version was too high for the dependency, I guess in this case it was the other way around somehow.
[22:35] <rick_h_> huwshimi: can you invite me to the hsngout?
[22:35] <huwshimi> rick_h_: https://plus.google.com/hangouts/_/03b8a4d3cc2897be3e02449440076450533a80cb
[22:35] <rick_h_> huwshimi: can you have curtis invite me thriugb g+?
[22:36] <huwshimi> rick_h_: Happening
[22:46] <hatch> just FYI remove relations is finished just writing the integration tests now
[23:04] <hatch> :/ I hate it when tests only fail in phantom
[23:15] <Makyo> Did frankban's go branch land?
[23:40] <gary_poster> Makyo, you would have landed it, ugh
[23:40] <gary_poster> sorry
[23:41] <gary_poster> I did not make that clear
[23:41] <gary_poster> Makyo, any chance for you to propose?
[23:41]  * gary_poster feels stupid
[23:41] <Makyo> gary_poster, sorry :( I was dropping 30-50% of packets at the time.  I can try to propose now.
[23:41] <gary_poster> Makyo, thank you would be great.  completely my fault
[23:42] <gary_poster> any progress on that bug
[23:42] <gary_poster> stepping away
[23:43] <Makyo> gary_poster, not quite, dogs went nuts.  Will look at this evening.
[23:44] <rick_h_> hatch: is there an object == helper? I thought there was but my search fu is coming up empty