[00:18] morning huwshimi [00:18] rick_h__: Hi :) [02:39] huwshimi: hey [02:40] hatch: Hello! [02:42] so did you end up figuring out your issue or do u want me to take a look? [02:43] hatch: I haven't figured it out. It appears that when I attach the event it then gets triggered by the event's method that created it! [02:44] clickoutside is a complicated and resource intensive event because it is a 'fake' event [02:44] lemme pull down your code and take a look [02:45] thanks! [02:51] huwshimi: do you guys get the show 'The Dome' there? [02:51] hatch: Not that I know of [02:51] count yourself lucky, it's horrible [02:52] some tv version of a steven king book - somehow it keeps getting renewed [02:52] :) [03:10] huwshimi: quite the issue we have here heh [03:10] hatch: Yeah, fun times! [03:12] so I have a fix, but it sucks [03:12] if you wrap the clickoutside binding in a settimeout then it's ok [03:13] ohh I think I know how to fix it [03:25] ok I was wrong lol [03:26] hatch: oh :( [03:26] the problem is how the clickoutside event handler works.... [03:27] it's a synthetic event [03:31] hatch: This is only an issue because the button that triggers the open is outside the menu [03:35] (That's not something that we can change, however) [03:37] hatch: Any other ideas? [03:38] huwshimi: yeah so I'm thinking that's what will have to be done [03:38] hatch: The timeout? [03:38] the clickoutside handler is just not written properly [03:38] well that was the wrong thing [03:38] it's not written to be used as we are using it [03:39] hatch: OK, well thanks for taking a look. [03:39] huwshimi: I guess right now in the interest of getting this landed is to render the menu for each token [03:40] er [03:40] render the ... in the menu [03:40] then when it gets clicked, show the real menu [03:40] it's a big performance smack but the real fix is going to take too much time [03:40] hatch: swap out button with the real one? [03:40] the [03:40] no I mean the ... is part of the menu [03:40] widget [03:41] hatch: Oh, so just render everything all the time? [03:41] when it's clicked then show the tooltip portion of the menu [03:41] yeah I think that's going to be the only way this will work, because the clickoutside will capture everything on the various up, down, bubble event phases [03:41] it doesn't filter them to only catch one way unfortunately [03:42] :( [03:44] it can be written to work as intended [03:44] unfortunately it'll take too long and I think we'd like to get this landed heh [03:46] hatch: Oh, I have a solution. [03:46] let me push this up [03:48] hatch: https://github.com/huwshimi/juju-gui/commit/370e1510bb44d483da21d36f82e9e477d09a578f [03:49] looking [03:50] actually that 'all' could be 'one' [03:50] so I was thinking something like that, but it's touching the DOM x number of times 'just incase' [03:51] hmm [03:52] huwshimi: you know that's probably an alright idea if it uses a .one [03:53] hatch: Yeah, so this: https://github.com/huwshimi/juju-gui/commit/afd157fe01fc39488f0727335cb69b457bbb4d53 [03:53] but it's a little bandaidie [03:53] yeah [03:53] hatch: Is it better than rendering all the widgets? [03:53] much :) [03:54] like orders of magnitude haha [03:54] good work [03:55] hatch: OK, I'm going to have some lunch and then add tests. This could probably do with another review tomorrow [03:55] yep for sure I'll review it in the am [03:56] thanks for staying on this :) [03:56] hatch: Thanks for that! [03:56] np [03:56] thank you [04:07] no problem === uru-afk is now known as urulama [08:13] urulama: morning! [08:16] rogpeppe1: heya [08:17] rogpeppe1: how are we doing today, sir? [08:17] urulama: good thanks [08:17] urulama: and you? [08:19] rogpeppe1: a bit sleepy, but nothing that proper indian tea could not solve :) [08:20] urulama: :-) [08:20] rogpeppe1: could you take a look at Jay's PR, please ... https://github.com/juju/charmstore/pull/77 [08:20] urulama: i'm just looking at it already [08:44] urulama: reviewed [08:45] rogpeppe1: thanks [08:46] rogpeppe1: i've set him towards the baseURL yesterday, but it was too late in the night to actually review the code [09:13] * urulama goes make some tea [09:29] rogpeppe1: ping, when you are ready [09:29] urulama: ok, one mo [09:30] urulama: ping :-) [09:30] https://plus.google.com/hangouts/_/canonical.com/roger-uros [09:59] frankban, rogpeppe1: give me 5min please, there's a post-man at the door [10:00] urulama: ok [10:03] frankban: wonna join for a blobstore talk? [10:03] urulama: sure [10:04] urulama: link? [10:04] https://plus.google.com/hangouts/_/canonical.com/roger-uros?hceid=dXJvcy5qb3Zhbm92aWNAY2Fub25pY2FsLmNvbQ.r0oegfsr6b313oqhn3br43ltqs [10:05] oh, sorry [10:05] frankban: https://plus.google.com/hangouts/_/canonical.com/blobstore?hceid=dXJvcy5qb3Zhbm92aWNAY2Fub25pY2FsLmNvbQ.i8ktli6o0tbmsbe5qmtk62eaik [10:43] frankban, rogpeppe1: google does not like us :) [10:44] urulama: we're back in... [11:01] rogpeppe1: is it better to compare two *charm.Reference by value (e.g. *id1 == *id2) or by str repr (id1.String() == id2.Strng())? [11:02] frankban: value [11:02] rogpeppe1: cool thanks [11:04] morning [11:06] morning rick_h__ [11:06] * frankban lunches [11:15] morning rick_h [11:49] morning [11:50] morning bac [11:51] rogpeppe1, frankban: wrote minutes about blobstore. please take a look if anything is missing, lots of topics were covered :) [11:51] rick_h__: you have a minute to chat? [11:51] bac: this was funny last night. https://twitter.com/chcholman/status/501906093136969729 [11:51] urulama: sure thing [11:52] urulama: looking [11:52] rick_h__: daily standup? https://plus.google.com/hangouts/_/canonical.com/daily-standup?hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.j0rk5d371ph8331ijtf48t2uj0 [11:52] loading [11:52] rick_h__: https://plus.google.com/hangouts/_/g4sy3treomztkk367qiounpbg4a [11:53] rick_h__: so you know that person on twitter? [11:53] rick_h__: the first one was "borked", hope the second one works [11:54] urulama: trying [11:54] bac: so she's in a city nearby and we 'know' each other by knowing some of the same tech people [11:54] bac: never met [11:54] urulama: i hadn't heard of CADF before [11:55] rogpeppe1: ah, its just some standard for auditing in clouds [11:55] urulama: have you got a good overview link by any chance? [11:55] * rogpeppe1 is wary of standards [12:08] urulama, rogpeppe1, guihelp: I need two reviews for https://github.com/juju/charmstore/pull/78 . anyone? thanks [12:09] frankban: on it [12:09] thanks [12:17] frankban: will be on it after a short lunch [12:17] urulama: thank you [13:38] morning all [13:39] morning hatch [13:39] kadams54: so we also had a monstrous storm last night :) took the power out :) [13:40] yippee [13:45] http://www.quora.com/How-good-is-YUI-as-an-open-source-JavaScript-library-compared-to-current-alternatives-2014?srid=dOo&share=1 [13:45] " But now that JavaScript itself will soon have a built in module system and loader, the way forward is to embrace ES6 modules. [13:45] " [13:45] "will soon" bothers me [13:46] :( on the lack of noting the niceities of a deep event system, common api across code, etc. [13:46] but yea, it's running its course [13:47] heh there is no way we'll be able to use es6 modules/loader any time soon [13:47] maybe 1yr [13:47] maybe [13:48] My next personal project whatever that may be will not use YUI so I can try and find a good collection of modules to provide a similar functionality [13:48] so far I can't find anything that has the event stack :/ [13:48] those darn events..... [13:49] maybe I could write something [13:49] yea, I bet you still end up writing a lot more code [13:49] it's kind of sad that there's not more of a desire to modernize YUI vs deprecate [13:49] Y! is too busy buying mobile companies....lol [13:59] rick_h__: just rebooting [14:43] * rick_h__ heads back to the house [14:44] kadams54: did you end up doing the review of my branch yet? [14:44] hatch: in progress. I'm also having problems with changeState in my branch. [14:45] So I'll finish off QAing yours and then pester you with state questions ;-) [14:47] yeah sure np [14:47] changeState is really easy to understand and debug once you wrap your head around how it works [14:47] hatch: jcastro kadams54 btw is the uncommitted progress icon just the yellow triangle? The yellow triangle technically means pending... [14:50] luca: right now there is no uncommitted progress icon [14:51] there is the pending icon but that's after juju has ACK'd it and it's really pending [14:51] but there is this odd place between uncommitted and the ACK [14:51] which I have seen be up to 30s [14:51] where it's not pending or not uncommitted [14:56] jujugui call in 5 [14:56] or 4 [14:56] kanban away please [14:58] rick_h__: i get "this party is over" :( [14:59] jujgui https://plus.google.com/hangouts/_/gw35roelf4huu6vmyvyl3z6rgea?authuser=1 [14:59] hatch: I see, thanks [14:59] see if this works [15:00] I'm in the normal standup room [15:00] with ant and matt [15:00] ok, it's working now [15:00] just doens't like me [15:00] jujugui standup time! [15:00] rick_h__: https://plus.google.com/hangouts/_/canonical.com/daily-standup?hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.j0rk5d371ph8331ijtf48t2uj0 [15:00] rick_h__: try this one [15:01] bac: ^ [15:01] oops [15:01] joining [15:03] having trouble [15:10] rick_h__: are all of the cards in the ready to code of equal priority? It seems like some of these may be able to be pushed to post 1.0 [15:10] jujugui: sorry, i cannot get into the hangout [15:11] it's over [15:11] :) [15:17] hatch: miss anything good [15:17] ? [15:18] rick_h__: did some break dancing to lady had a little lam [15:18] lamb [15:20] guihelp: where is views.Templates originally defined/setup? [15:20] hatch: we can debate over them [15:20] hatch: but they all seemed 1.0 stuff when I looked monday [15:20] kadams54: it's built from the /lib/templates or something, /me pulls up a browser to look [15:21] kadams54: sorry, the things in app/templates is built into lib/templates.js as compiled handlebars [15:22] kadams54: what are you trying to do? [15:24] jujugui: bye, see you later === urulama is now known as uru-afk [15:59] * rick_h__ goes to get lunch [16:27] jujugui do we have any assets or mockups for ""handle changes from the delta stream and alert with conflicts in ecs"" ? [16:27] not that I've seen [16:27] hatch: no [16:28] I can work on the backend of it np, but I'll send something to luca about it I guess [16:29] hatch: yea, I think that card is one that breaks into smaller. we need to plan out where/how to keep the 3 results (current, ghost, delta) and how to resolve that [16:29] yep ok on it [16:44] hatch: thanks for the great qa notes on huw's branch! [16:44] :) np [16:48] jujugui it appears we can't clear config changes, because we don't retain the old ones, just a list of what has changed. Any thoughts? [16:48] Makyo: chat with hatch as I think we need it for that as well [16:48] hmm [16:48] Makyo: hatch quick chat? [16:48] yeah.....standup? [16:49] * rick_h__ will try again wheee [16:49] if it says it has ended just click refresh a couple times [16:49] went to FF [17:02] rogpeppe1: so, should we return nil, nil in a meta endpoint if, for instance, it makes sense only for charms and a bundle is passed? [17:03] rogpeppe1: IIUC, if the meta result is nill, then the result is not included in meta when include is used [17:04] frankban: yes, that's right. [17:04] * rogpeppe1 needs to stop now. wedding anniversary requires prompt stopping :) [17:04] g'night all [17:05] rogpeppe1: good night [17:06] happy anniv rogpeppe1 ! === uru-afk is now known as urulama [18:23] jcsackett: thnks for the review, I replied [19:20] kadams54: review? [19:21] hatch: yeah, still wrestling with a local env [19:21] hmm, what issues are you having? I've probably had it before haha [19:21] hatch: the behavior was funky when I ran through, so I wanted to verify and make sure it wasn't just my setup. [19:22] oh ok, what was happening? [19:23] hatch: the machine would go through OK, but the bare metal container would be left as uncommitted state. I had to force a re-render on the container token before it properly displayed the state. [19:23] oh ok that's possibly a real bug [19:23] actually probably is [19:23] hatch: So I ran through the QA instructions, deployed, confirmed, waited, then saw the machine change from uncommitted to deployed. But the container stayed as uncommitted. [19:24] the uncommitted state rendering is kind of implemented funky [19:24] the bare metal cannot be uncommitted so that's definitely a bug [19:24] As far as my local env woes… I think it's the same thing jcsackett's seen. I've run the juju set command, it seems to run successfully, then I refresh in the web browser and nothing is running anymore. [19:25] Annnnnddd now it works fine. Of course. [19:25] are you juju setting the source? [19:25] kadams54: on precise you have to use sha to set the source. [19:25] On trusty you can use branch. [19:25] it takes time to pull down and build the source [19:25] Hmm, I'm on precise, but it just worked with the branch… [19:25] and what jcsackett just said [19:26] ( which I also learnt just recently) [19:26] hatch: yeah, I gave it 10 minutes :-) [19:26] hatch, I'm not sure I'm +1 with your reply; you say it's overkill to put update id on the machine list, but that's the only place you use the method. [19:26] Seems like overkill to patch, to me. [19:27] I just figure because it's a limitation of the library and not of our code it should go to the lib [19:27] kadams54: can you write that bug in the PR and I'll look into it after lunch [19:27] I agree it's unnecessary to create our own extension, but can't you just add update I'd for the machine list? We already have one as an object, right? [19:27] hatch: Yeah, now that I've finally managed to confirm it :-) [19:28] hatch: FYI, I added the changeState code pretty much as it is in scale-up.js, for navigating to machine view… but it seems to do nothing. That is, if you're in service view when you click on the link, you'll still be in service view. [19:29] jcsackett: no LML has an internal ID map which is only updated on add and remove so you cannot update the id of a LML object and still have it functional [19:29] Aaaah. [19:29] That's the missing part of info. [19:29] kadams54: does the service view bubble the change up to the browser.js? [19:29] jcsackett: oh sorry :) [19:29] I'll add that to the PR [19:30] Ah, good question. I'll make sure it does. [19:31] kadams54: typically you will include the steps to reproduce the QA failure [19:31] even though I know how....just for good measure [19:31] ok. hatch, knowing that, I'm good. Can you add a test for the patch's added method, though? [19:31] jcsackett: I can [19:31] plz add to the PR [19:33] hatch: done. [19:33] Will do. Thanks, hatch. [19:33] thanks - I'll get on that right after lunch [19:33] I'm trying to figure out a good strategy to port the gui to Dart without rewriting :D [20:55] * rick_h__ runs away night all! [21:18] cya rick_h__ [21:18] oh that was like 25mins ago [21:18] heh [21:37] heyyyyyy hatch [21:37] wassup boi! [21:38] Wanna be a peach and proof something for me? (rough video cut, but almost done) [21:39] yeah sure [21:39] I'm just finishing up a review [21:39] https://www.youtube.com/watch?v=CEfFy6tODrQ knew I could count count on ya! ty ty [21:39] oooo you're doing a charm review? [21:42] haha no, js review [21:42] lazyPower: I'll start looking at it in about 5 [21:43] no rush :) and ooohhh yeah. i almost got excited there for a second. [21:48] lazyPower: your quiet... [21:48] can you preamp the audio? [21:48] that has been preamped [21:49] Whats your youtube volume at perchance? [21:49] i preamped it and ran it through a compressor [21:49] 100% heh [21:49] wow [21:49] and my laptop is also at 100% [21:49] really? [21:49] oi [21:49] :) maybe it's just my computer [21:49] I'm running in a vm [21:49] let me solicit additional feedback - you're on mac right? [21:50] I'm on a mac, in Ubuntu [21:50] lol [21:50] maybe my soundcard default volume is set to low :) [21:50] anyways, continuing [21:52] hatch: ty for the feedback though - if i need to up the amps on the audio i'll try to do that on teh final copy [21:52] s/amps/decibels/ [22:02] lazyPower: notes pm'd [22:04] Thanks man! Much appreciated. [22:09] anytime :) [22:10] When it's done let me know so I can spread it among my network too [22:10] anything to get the juju love out there [22:39] hatch: how does one turn the simulator off in gui? [22:39] it's massively mucking me up. [22:39] ctrl s [22:39] thank you. [22:39] "One does not simply....turn the simulator off" [22:39] * jcsackett sort of wants the simulator off by default [22:39] jcsackett: you can also set it to off in the config-debug.js file [22:39] yes, but then i have to fix that before i commit. [22:39] I've been asking for that but always get voted down [22:40] i might bring it up on friday (again) [22:40] come to the dark siiiide [22:40] * hatch hands you a pin [22:40] it is *so* annoying when you're dealing with machine creation/unit creation etc. [22:40] yop [22:40] I'll +1 your vote to banish [22:41] now and convince others behind closed doors like a good politician and make it look like a true democracy when we vote [22:41] lol [22:41] rofl [22:41] oh I crack myself up [22:53] * jcsackett laughs [23:06] Morning [23:08] morning huwshimi [23:09] lots of comments on your branch but good to land once those are taken care of (they are all tidy up things) [23:20] morning hju [23:20] mornin huwshimi [23:20] tab completion works better when you type correctly :/ [23:21] haha [23:24] :D [23:41] rick_h__: If you happen to have the time, I'd love another review of the more menu: https://github.com/juju/juju-gui/pull/498 [23:43] huwshimi: will look in a sec here. [23:44] huwshimi: thanks for making those fixes [23:44] be sure to rebase before landing :) [23:47] hatch: Thanks for the review, yeah, lots of changes in there :) [23:47] heh mine is the same, I'm going to have to have fun rebasing that one