[00:06] hatch: no, it was what I was going to start but IE bugs come first [00:07] fishing done? [00:10] hatch: yes...why yes it does [00:10] catch anything? [00:10] hatch: no, it was not a good trip [00:10] oh...? [00:11] lost my pole/reel into the lake... /me isn't proud [00:17] haha darn I hate it when that happens [00:18] new rod/reel, just over a week old. Not feeling the love of today [00:54] rick_h: last year 2 of my buddies went out fishing in a canoe with all brand new gear - an hour later they returned soaked....they tipped the canoe and lost everything [00:55] doh [00:55] counting cell phones and glasses it was probably a $3000 tip [00:55] haha [00:55] ouch [00:57] yup that was an expensive weekend! [01:22] Good news, everyone. [01:22] Makyo: I like good news [01:23] The viewBox attr on SVGs fixes both FF and IE10 [01:23] Makyo: sweet! [01:23] rick_h, Going to correct the default icons first, then we can figure out a story for charm/icon.svg [01:36] Makyo: I think the api server can patch them on ingest [01:37] bcsaller: yea, it completely can. Just needs to be added [01:37] bcsaller: and should get it added to the demo/template provided in the docs perhaps [01:38] bcsaller, yeah, that's what I was thinking. Gary was concerned about that as a solution over requesting charm authors to do it themselves. [01:39] charm authors no more known what they SVG editors save as does than... well... I bet they don't know [01:39] Hah, fair. [01:39] right [01:39] Where's the template, rick_h ? The attribute would change based on the final width/height values, curious how those are specified. [01:39] we'll never have it 'fixed' if we rely 100% on charm authors [01:40] Makyo: sec, in the juju docs. Looking. [01:40] Makyo: https://juju.ubuntu.com/docs/authors-charm-icon.html [01:40] I like that the title is "None" :P [01:40] heh [01:41] but the template is at https://juju.ubuntu.com/docs/media/icon.svg I bet jcastro or marcoceppi can update that if we need. [01:42] rick_h, Alright. From the looks of it, authors may be editing the width/height in Inkscape, as well. I may prowl around through there and see if there's an option in Inkscape itself for viewBox. [01:42] hatch: I submitted without the extra tests but poked at the env and db. Would like to chat about how those 'work' tomorrow if you've got time [01:42] Makyo: cool [01:42] thanks for looking into it. [01:43] hatch: e.g. getting a charm from the db doesn't have the config values in it that I could tell. And there wasn't an idea of fetching the charm from the env I could see either [01:46] rick_h, Okay, found it. Hopefully it's this easy! [03:20] rick_h: yeah remind me when I get in and I'll fill ya in [03:20] unless you're around now [03:20] Makyo: thanks :D [03:27] hatch: around now but past my bed time. I'll hit you up tomorrow [07:11] rick_h: what did I do? === schwuk_away is now known as schwuk [12:15] heh, well it's closer I guess. Friend was trying to convince me FF was faster than chrome now. Except test suite 37s in chrome and 56s in FF [12:15] it used to be twice as much though, so getting better [13:19] abentley, benji, sinzui: in a fit of OCD i reorganized the task list on our google doc from yesterday. i also made cards for my tasks in kanban. might be nice to add the ones you've been assigned too. i'll make cards for the unassigned ones. [13:19] thanks; oh, yeah, I need to add a card for mine too [13:19] thank you bac [13:20] lol, love fits of OCD [13:20] or CDO as jeff bailey calls it. everything should be alphabetized. [13:23] yay! I have defeated IE! Where is my victory parade? [13:24] sinzui: if you understand #10 on the list could you re-write it to make sense? it is currently gibberish to me. [13:26] jujugui: can someone else with ie10 ready confirm that bug 1112783 appears to be fixed? i have tried to reproduce and it works for me. if it works for someone else i'll mark it resolved. [13:26] <_mup_> Bug #1112783: 'destroy service' never returns from confirmation dialog [13:27] jcsackett: sec, will in just a min [13:27] rick_h: thanks. [13:30] bac: ack [13:30] jujugui IE QA/review please https://codereview.appspot.com/12871046 [13:30] rick_h: looking [13:31] bac, I cannot edit it [13:31] jcsackett: cannot reproduce [13:31] jcsackett: it's from Feb so not surprised we've fixed something between now and then [13:31] rick_h: huzzah! [13:32] rick_h: move the card to releasable, or just delete it? [13:33] sinzui: your gmail id had edit permission. now your canonical does too [13:33] jcsackett: I'd just delete. [13:33] jcsackett: and mark the bug as invalid. If it's releaseable then we'd do fix-released I'd think [13:34] rick_h: i would say it's fix-released; it wasn't invalid, we just fixed it at some point. but i'll delete the card. [13:34] jcsackett: k [13:34] jcsackett: then keep the card and get bi-weekly bug credit :) [13:35] :-P [13:36] Makyo: i see you assigned to the card for bug 1207035, but assigned in LP to 1207036; are you working on both? [13:36] <_mup_> Bug #1207035: Some charm icons are improperly sized in IE10 [13:36] oops, mup didn't pick up the second one. bug 1207036. [13:36] <_mup_> Bug #1207036: Service SVG icon in inspector is stretched vertically [13:38] jcsackett: he thinks he's got a fix for both with one change [13:38] jcsackett: so those should be good coming soon [13:38] though might need a charmworld branch as well. [13:39] bac: Could you please give me edit rights on Charmworld URLs and Pages notes? [13:40] abentley: your gmail identity has them. i think it automatically granted to all identities in the original chat. [13:40] abentley: you want me to add your canonical? [13:41] bac: Yes, please. [13:42] abentley: try now [13:43] bac: Looks good. [13:43] abentley: cool. just got smart and opened to all canonical [13:44] jcsackett: can you qa https://codereview.appspot.com/12871046 for me in your fresh IE setup please? [13:48] rick_h: sure. [13:53] rick_h: have you seen this happen on IE10 before? happened after i hit the search bar in fullscreen. http://d.pr/i/PpyH [13:54] jcsackett: looking [13:54] jcsackett: oh...interesting...not seen that one [13:54] rick_h: i'm checking if that happens in trunk. can't imagine it's related to your branch. [13:54] jcsackett: so it does it every time? [13:55] ah, I can dupe it. In fullscreen, missed tghat part [13:55] rick_h: it does it in trunk, so it's not your branch. [13:56] jcsackett: yea, I bet it's the autocomplete widget which is on comingsoon, but not jujucharms. Will need to file that as a new one [13:56] ugh [13:56] also, in IE10 if i just load jujugui and click the "browse" button i'm not going to fullscreen. [13:56] morning [13:56] rick_h: can you reproduce that? [13:56] * jcsackett hopes its something weird locally. [13:56] jcsackett: no, it changes modes for me [13:56] huzzah! [13:57] morning, hatch. [13:57] jcsackett: ok, will file the AC bug and add a card for that [13:57] rick_h: ok. [13:58] i'll update your MP with my QA ok. [13:58] brb [14:00] rick_h: got any notions of why AC pushes down the rest of the screen? i'm free to pursue the bug, but would like pointers if you've got 'em. [14:01] jcsackett: thanks for the search link then [14:01] jcsackett: errr, the notion that it's used in search as well [14:01] jcsackett: so basically going to be something in the css of the autocomplete that's not being position absolute I guess. [14:02] jcsackett: I'd just start going through the .aclist* classes and nodes and seeing if they can be tweaked [14:02] rick_h: ok. [14:03] rick_h: i'm actually less free than i thought--hatch emailed me a bug last night i need to look into as it appears to be browsercharm fallout. [14:03] probably simple though, so i should be able to get to AC soon. [14:03] jcsackett: rgr [14:06] hatch: i saw your email and the bug, but i can't reproduce. [14:07] sinzui, incidentally that rack charm store issue is caused by a bug in the charm itself [14:07] hazmat, great. [14:07] hazmat, details [14:07] or update the bug [14:08] sinzui, i replyd via email, its going to take a few for lp to publish [14:08] thanks [14:08] jcsackett: hmm I just did http://comingsoon.jujucharms.com/:flags:/serviceInspector/ dd mediawiki, click 'destroy service' click 'confirm', see error in console [14:13] hatch: i missed destroy was available before deploying. [14:15] :) [14:18] hatch: btw, it's "Jon" not "John". :-P [14:18] yeah....well..... [14:19] yeah I got nothin [14:19] oops :) [14:21] jcsackett: I always thought jc was short for Jesus Christ :-P [14:22] only in my most meglomaniacal moments. [14:22] I have slain the mighty IE! All bow before my...oh wait...my bad [14:22] * jcsackett laughs [14:22] or that his last name was Penney [14:23] yes, because none of these are jokes i have heard a thousand times. :-P [14:23] or Chasez [14:23] have you heard THAT one? [14:23] i have not. well played. [14:23] only half credit though, as it's just a variation on a theme. :-P [14:24] lol true true [14:26] hatch: fix up for that bug https://codereview.appspot.com/12795046 [14:26] can you review? [14:26] on it [14:27] jujugui: i suppose even though it's one line, i need one other reviewer.:-P ^ [14:27] there are two now [14:27] jcsackett: already done, but figured you'd trivial it [14:28] rick_h: i usually eschew trivial when the fix is for actual breakage. [14:28] and thanks for the review. [14:28] np [14:30] rick_h: when did you want to go over the db stuff [14:30] hatch: after the standup call ok? [14:30] yep no problem [14:32] abentley, jc is short for our lord and savour John Cleese. [14:33] ok, *that* one is new. [14:39] jcsackett: oh crud it's a little late now but we should have added a test for that bug [14:40] * hatch hasn't had his coffee yet [14:43] sinzui: chat? [14:43] jcsackett: I can add that test [14:44] hatch: ok, i'm pursuing a css issue with AC in IE10. if you've not gotten around to the test before i'm done with that, i can pick it up then. [14:44] I'll start on it now, I need a break from this constraints stuff [14:45] abentley, in 15? I am in meetings [14:45] sinzui: sure. [15:10] sinzui: How's it going? [15:11] abentley, all clear. we can talk [15:12] sinzui: hangout at https://plus.google.com/hangouts/_/666d51fb65e7f2ce7442c104ad381044fefac89a?hl=en-GB [15:15] Hi juju-gui people. Question about the canvas in gui. (well, two) [15:16] Shoot, marcoceppi [15:16] One, is it worth filing a bug to disable right-click context menu from the browser on the gui? We had 21 users who were operating under the assumption that in order to bring up the menus they needed to right click (they also though that the long click was right click only) and were getting frustrated by having the browser menu pop up when using right click [15:17] after showing them it was all Mouse 1 they got it, so I'm just doing due diligence as I said I'd bring it up with you guys [15:17] marcoceppi, jujugui, I say file it, and then we can triage it during calls. From my point of view, it makes enough sense, at least on the canvas. [15:17] thanks [15:18] yeah that's a tough one from past experience [15:18] if you're going to disable it, it needs to have a custom one [15:18] else I've found people get equally frustrated hah [15:18] * hatch included [15:18] why would people right-click on the web? /me never would have even thought of thatr [15:18] lol [15:18] if that's what the users expect, we could also actually make right click bring up the menu [15:18] benji: right [15:18] the second question is more of a bug, but I wanted a sanity check on it. Currently I can't highlight text when drilling down in to the unit view (ie, click on service, click on unit, try to select IP address to copy), is this a known issue? Expected behavior? If not I'll also file a bug [15:19] Makyo: hmm, maybe we can deploy flag something like that? /me doesn't want to lose 'right-click - inspect element' even in the canvas [15:19] rick_h: maybe enable a "developer" mode which doesn't override right click? [15:19] Any event I'll create a bug for you guys to track it [15:20] marcoceppi: I think the selection was disabled, checking [15:20] the inspector mode will change that [15:20] rick_h, agreed. [15:20] marcoceppi: just to confirm this is in the new inspector? [15:20] hatch: I've just been deploying cs:precise/juju-gui [15:20] So whatever that constitues [15:20] the old unit/service view it sounds like [15:21] but do you add /:flags:/serviceInspector to the url? [15:21] hatch, marcoceppi - no, drilling down is old behavior. [15:21] If there's a new inspector coming I'll just let them know that new cool shit is coming and to just dealwithit.gif [15:22] hatch, yeah, stuff under feature flags wouldn't be used in these contexts, I don't think [15:22] marcoceppi: fyi on comingsoon.jujucharms.com I can't repro your select issue [15:22] but yes big changes coming down the pipe soon :) [15:22] * marcoceppi peeks [15:22] I like the slider [15:23] hatch: ah, yeah selecting text works. Thanks! [15:23] We had about 25 people using the GUI for the first time, all really overwhelmingly good feedback outside of the above questions! [15:24] oh that's so awesome to hear :) [15:24] marcoceppi: good to hear [15:24] I saw them using it more than they were the cli ;) [15:24] Excellent :) [15:24] haha perfect ;) [15:44] rick_h: i think i have a fix up for the AC thing. care to review? https://codereview.appspot.com/12760045/ [15:44] jcsackett: sure thing, doing the lbox dance with mine right now. Will pull/check it out when it's done [15:44] and swap you reviews :) [15:45] jcsackett: oh, can you see if that fixes the home bug I filed as well then? Seems it might be related. #1212695 [15:45] <_mup_> Bug #1212695: home link moves during search in ie10 [15:46] jcsackett: maybe not, nvn [15:46] rick_h: i'll look. [15:46] but yeah. [15:49] rick_h: nvm on my MP. [15:49] in looking at yours i've realized mine introduces a new horror. [15:50] (your bug, not your MP) [15:50] goddamn IE requiring absolute positioning... [15:50] jujugui guichat in 10 kanban now [15:51] jcsackett: ugh, yea I was afraid of that. [15:51] jujugui couple of reviews please, not IE specific. Happens in all browsers. https://codereview.appspot.com/12997043 but the bug was noted in IE [15:51] rick_h: looking. [15:51] rick_h, on it. [15:54] thanks guys [15:55] jujugui looking for 2 very quick reviews on https://codereview.appspot.com/12998043/ as well [15:58] hatch, on it [15:58] thanks [15:58] think its already got two :) [15:58] jujugui guichat in 2 [15:59] bcsaller, hatch Well...bonus! [15:59] everyone likes more tests [16:00] \o/ [16:00] jujugui guichat on now [16:28] ok. i'm going to get lunch. IE10 has temporarily dispirited me. [16:29] jcsackett: hah, don't let it beat you down! [16:42] are constraints supposed to be 'dumb' right now? Or are we supposed to be pulling the options from juju? [16:46] no idea [16:59] I love lines that are 80 characters long [16:59] such - a -rebel [16:59] down with him! [17:01] ugh I can't wait until we switch to sass and have sourcemaps for our css [17:07] Quick question about charm deployments - Juju client run on node that has internet access and on isolated internal LAN, Juju boostrap node on isolated LAN/no internet access, Juju-GUI node on isolated LAN/no internet access. Q1: Does Juju client pull charms from the charm store and push to Juju bootstrap node? Q2: Is Juju-GUI node useless without an internet connection to pull pickable charms from? [17:08] lovea: the final point is true. The Gui needs access to https://manage.jujucharms.com to show the list of available charms to pick from. [17:08] icons and data are pulled from that data endpoint [17:09] rick_h: ok, thought so [17:12] hatch: Makyo do you guys know how a 'deploy' goes down? Does the gui send the charm over to the bootstrap node? Or do we just tell it to fetch it? [17:12] rick_h, we just tell it to fetch it. [17:12] just fetch it [17:12] Makyo: cool, thanks. What I assumed. [17:12] lovea: so does that answer the other part then? [17:13] Forgive my ignorance but would the theory be that, given an internet enabled Juju-GUI node, I could wire up my charms to meet my specific deployment needs as a "model", export the "model", use the Juju client to actually implement the "model" in my isolated environment. [17:13] rick_h, lovea GUI will work as a monitoring tool behind the firewall, would still show the environment, but charm-store would be empty. [17:14] lovea, yes. You can use the GUI and then export (or even just write down) your environment to be deployed elsewhere. [17:15] lovea, There is a section on "Deploying behind a firewall" at https://jujucharms.com/fullscreen/search/precise/juju-gui-74/?series=precise&text=juju-gui&type=approved#bws-readme [17:15] or are we saying that Juju bootstrap node also needs to be internet enabled because it gets fetch instructions from Juju client? [17:15] Makyo: ok I'll read up on this. Many thanks [17:15] lovea, the bootstrap node would only need internet if deploying charms from the charmstore (eg: "cs:precise/mysql"). Using the CLI, one can deploy local charms, however. [17:16] rick_h, Makyo: Thans for te clarifications [17:17] Cheers. [17:21] quit [17:24] abentley: the bundle API tweak branch is up for review if you have a moment (after lunch): https://code.launchpad.net/~benji/charmworld/update-bundle-api/+merge/180384 [17:24] benji: Okay. [17:31] rick_h: what was the trick you used to get templates auto generating again? [17:31] hatch: there was a typo in the dir name in the config of places to look? [17:31] ahh right [17:32] manually I'd do rm build-shared/juju-ui/templates.js && make build-shared/juju-ui/templates.js [17:32] yeah that's it, I'll try that [17:43] benji: I have an important call in 15 and I need to do some prep. Is it cool if I delay your review by an hour or so? [17:43] benji: I have some thoughts, but haven't gotten everything done. [17:44] abentley: sure [17:46] bcsaller: this collective event stuff has gota be fixed lol [17:48] does IE have any sort of dev tools? [17:48] F12 [17:48] jcsackett: yea, in the options is "developer tools" [17:48] they are 'sort of dev tools' [17:48] (right side gear) [17:48] F12 opens it [17:48] yea, I noticed 'debugger;' didn't do me any good :( [17:49] and the element selector only half works [17:49] nope you have to click 'start debugging' [17:49] the element selector works only if you hit 'refresh' in the devtools first [17:49] rick_h: i do not have a developer tools option in my gear menu. f12 worked though. [17:50] jcsackett: they actually market it as "The F12 Developer Tools" :D [17:50] jcsackett: oh, ok then [17:50] * jcsackett continues to loathe IE. [17:51] carry on [17:51] they say the IE11 ones are actually real devtools [17:51] * hatch is hoping [17:51] I used to have to support IE7+ [17:51] * jcsackett is hoping to never need IE11 tools, b/c he's hoping to never to IE work again. [17:51] AND the 'simulator' in IE10 doesn't even come close to simulating IE8,9 properly [17:51] sorry :) [17:52] rick_h: got a bit to chat? my current approach is so error prone i think i need to step back and maybe hear other ideas. [17:52] the 9 one did a good job with 8 [17:52] jcsackett: sure thing [17:52] rick_h: guichat is open. [17:53] rick_h: also lemme know when you want to chat about the db stuff [17:57] Hm. Good news, bad news. [17:57] Good news: ingest now adds viewBox to icons. It works in FF and IE. [17:58] Bad news: it only MOSTLY works in IE. [17:58] This wouldn't be easy >:/ [17:58] what's mostly? :) [17:59] It fixes the icons in the service blocks, but not in the browser (which might be because they're not styled with a size - investigating), and not in the inspector (for potentially the same reason) [18:00] ARG!!!! I can't propose my branch until I upgrade jshint so I can tell it about globals...... [18:00] Makyo: ahh ok, well good luck :) [18:00] What globals? [18:00] this._unitSpinner = new Spinner({ [18:01] Oh, and Spinner isn't provided by YUI or anything? I mean, that's how we get d3. [18:01] I should be able to do /* global Spinner */ [18:02] I think d3 is defined by the namespace methods [18:02] so it's not actually a global [18:02] we dont jslint the html so that's why this hasn't come up before [18:02] :/ [18:03] Nah, not that I can see. It's just used immediately in app/topology/topology.js [18:03] Oh well, though. [18:04] We've used the spinner before in JS, though. It hasn't come up yet? [18:04] hmm you're right [18:04] nope the spinner is only ever used in index.html [18:04] and in my new code [18:05] ohh wait [18:05] I was grepping crappy [18:05] and app/widgets/overlay-indicator.js [18:05] guess I'll have to make this spinner in the index.html as well [18:05] :/ [18:06] I am curious as to how d3 is being defined there [18:06] in topology.js [18:06] as in why the linter isn't going wako [18:07] What is Y.spinner.getSpinner()? [18:08] I guess I could refactor that to be a generator [18:08] It's already there, that's what I'm saying. [18:08] but even there it's not blowing up... [18:08] I'm sure you'll figure it out. We're all counting on you., [18:09] lol [18:09] /rage [18:09] So why won't Y.spinner.getSpinner() work in your case? [18:10] it's mergingness of it's options will not work for some of the options i need [18:10] Can't you provide an options object? [18:10] so I can fix that....but I'm not sure if that's the right place [18:10] I'm not sure what you mean by mergingness, so... [18:11] it merges it's defaults with the config that I need [18:11] so I'll either need to specify more options resetting them to other defautls [18:11] or patch the file [18:11] script* [18:12] jcsackett: http://paste.mitechie.com/show/1002/ [18:12] Patching sounds notsogood. Is there an issue with specifying all the options you need? [18:13] well nothing beyond I have to go find out what the defaults are [18:14] when the issue at hand is really the tools [18:15] That's fair, and perhaps working with upstream is required, but working with tools is kinda what we do. [18:15] hatch: reuse the existing spinner. What's wrong with it? [18:15] it doesn't fit in an input box and isn't blue :) [18:15] hatch: can't you just use an animated gif for the little in field spinner you need? [18:15] well, wtf is 'blue' a thing? Spinner is standardized. [18:16] and we can adjust the size in the widget if we need I believe [18:16] ah, nvm. We use the same animated gif, not js spinner. We had a bug for that at some point [18:16] bcsaller: only if you have one :) [18:17] hatch: http://www.ajaxload.info/ ;) [18:17] lol [18:17] hatch: why are we spinning a single input box? [18:17] indicator to let the user know units are being spun up [18:17] link to the UX mockup? [18:18] v11 [18:18] oh it's on the dropbox one [18:18] I don't have the link on this machine [18:18] in google drive if you search inspector and pull the v11 hit though its there [18:18] yea, loading/looking [18:19] it's ok I have updated the linter already [18:19] there is only 2145 errors! [18:19] the little blue refresh-looking thing? [18:20] oh that was only 33% of the files heh [18:20] I think it needs some config options [18:20] rick_h: yes [18:20] hatch: well where's the assets for it then :P [18:20] why are you complaining about Spinner when you can't use that anyway [18:20] * rick_h is confused [18:21] This sounds like a less than ideal path, and also counter to what we've done in the past of two-step implement-and-then-style branches. [18:22] so drop the spinner? [18:22] yea, until you have the assets to implement it imo [18:22] Or implement A Spinner, and style it later. [18:23] yea, I guess I'd do it textual with a "replace with gif when available" [18:23] it is implemented heh [18:24] Eh, nevermind, I'm out. Gotta eat, then propose the charmworld stuff. [18:27] bcsaller: I'm going to grab the asset from there I guess :) [18:30] interesting the old jshint accepted our json files, the new one does not [18:31] looks like it doesn't accept the old config file [18:34] yeah it'll take a bit to reconstruct this config [19:10] bcsaller: it appears that the databinding system doesn't like to have multiple fields bound to the same value [19:12] ohh wait nm [19:13] wait nope it's definitely broken [19:14] it only ever calls the update method once regardless of how many fields are bound [19:16] the 'target' gets overridden by the last element with the binding set to it [19:16] jujugui charmworld branch for viewbox on icons (default and ingested) https://codereview.appspot.com/13001044 [19:17] Makyo: I assume you're looking for a review. I'll take a look. [19:17] looks good to me but I'm not really qualified :) [19:17] Makyo: i'll look [19:17] benji, bac Yes, thanks. [19:20] Makyo: have you run 'make lint'? [19:21] bac, not yet, had assumed .lbox.check did that, will do it now. [19:22] Makyo: hey you could add that to .lbox.check if you wanted. but, the charmworlders are not generally using lbox. [19:23] bac, Oh, okay, maybe I'll do that. [19:27] Makyo: actuallly, charmworld is using tarmac to land, triggered by the merge proposal on LP. so using lbox is actually problematic. [19:28] bac, Only once the MP is marked approved, though, right? [19:28] Makyo: i'll go vote approved on LP. you'll then need to set a commit message and mark the whole thing Approved when you're ready to land. [19:28] bac, so propose shouldn't affect it, just don't submit? [19:29] bac, okay. Only done this once before :/ [19:29] Makyo: votes need to be recorded over there too. btw, charmworld is only requiring one review [19:29] Oh, okay. [19:30] Makyo: for now, it may make sense to change .lbox.check to be only run /bin/false [19:32] benji, single/double quotes: the processing instruction is generated by ElementTree with single quotes, but attributes are generated with double quotes. I could switch to single quotes and escape the internal ones, but I figured this was cleaner. [19:33] Makyo: that makes sense; maybe it's worth commenting [19:34] benji, Alright. As for the logs issue, I was under the impression that we should be adding the attribute on ingest, since we can as long as we have width/height (it's just 0 0 every time). Should I log it anyway, or die, or..? [19:36] Makyo: ah, so we just need the attributes, even if they are 0? If so, a warning (or info, or nothing) seems fine. I would add a comment about why we're doing what we're doing though. [19:37] benji, I can check for 0 as well, since that would be a malformed SVG. Logging and commenting sound fine too. [19:39] well, you can use lbox for inline code reviews if you want, but landing has to be done through LP [19:40] Alright. [19:57] sinzui: I just landed versioned charm-ids. [19:58] sinzui: Or rather, deployed them to staging. [19:58] \o/ [20:14] awesome! [20:17] bcsaller: I'm going to work around this now but I'd like your input whenever you have some spare time https://bugs.launchpad.net/juju-gui/+bug/1212813 [20:17] <_mup_> Bug #1212813: databinding only allows a single field to be bound to an attribute [20:43] abentley, benji: do either of you have time to review my unsexy branch that adds the concept of API3 https://code.launchpad.net/~sinzui/charmworld/add-api-3/+merge/180426 [20:44] sinzui: Sure. [20:54] sinzui: For the test_health changes, it looks like thge test cases are almost identical. Have you considered using two TestCases and just overriding the check_api call? [20:54] abentley, I can do that. [20:55] sinzui: The indentation at 173-174 looks odd to me. I'd expect it to line up with the opening paren, or else for it to be indented once. [20:56] sinzui: check_api3 isn't used yet, right? [20:56] abentley, nasty pep8 check wanted the if continuation separated from the lines executed [20:57] abentley, check_api3 is used by the /heartbeat view [20:57] Its check though uses the same rules as API2 [20:57] almost the same rules [20:58] all the checks have a common control structure [20:58] sinzui: How does check_api3 get referenced by /heartbeat? [20:58] sinzui: nm, found it. [20:59] line 244 [21:00] sinzui: r=me. [21:00] abentley, thanks. I'll refactor the tests before landing [21:16] Good news everybody. [21:16] hatch: having looked at it I don't see why that would be true (it used to be when we used a map for _bindings, but now its an array) [21:17] I was actually insane when I said things didn't work on Chrome. Thinks work fine :) [21:17] s/chrome/IE10 [21:17] Makyo: yay for insanity! [21:17] "things are actually alright" is the best kind of insanity. [21:17] I think that's insanity after the medication [21:17] Hah! I reverted my config change before I checked the icons last time. [21:18] It looks like the branch approved earlier fixes most icon issues. [21:18] Minus the one in the inspector, but that appears to be styled wrong. [21:36] jujugui need one quick review for trivial: https://codereview.appspot.com/12828045/ [21:37] Makyo: lgtm [21:37] hatch, thanks. [21:40] * hatch is furious - sent my wifes HTC One in for repairs because the screen is separating and they just called saying that the repair depo says it's physical damage and that it'll be $250 [21:42] but of course I can't talk to anyone about this bs until tomorrow [21:43] good thing I took pictures of the device before it was shipped [21:59] * Makyo finally dogwalks [22:10] bcsaller: hmm not sure - I've been fighting getting the tests to pass again so I haven't looked into it much but I know that the 'update' method was only called with a single value (the last one) so we'll just have to look at that sometime in the future [22:12] hatch: I'll try adding a test for it to what I'm doing now. Does your branch already include the change to sum up the changeKeys between updateDOM intervals, because this would look like that as well I think [22:14] bcsaller: here is my branch https://code.launchpad.net/~hatch/juju-gui/scale-up-ui [22:14] a....plethora of tests fail now hah [22:14] if plethora was 7 [22:14] well...7 is when it stops [22:14] there is probably a lot more [22:34] arg I broke the databinding [22:44] bcsaller: have a minute to take a look at my databinding code? [22:44] I'm sure I'm missing something obvious [22:44] hatch: what part do you want me to look at? [22:44] http://bazaar.launchpad.net/~hatch/juju-gui/scale-up-ui/view/head:/app/views/databinding.js#L194 [22:44] for some reason this causes the conflict code to apply the conflict style to the wrong element [22:45] which element....I'm not sure....possibly the mirror one? [22:45] bcsaller: if I comment out 194-204 it works as expected [22:46] hatch: I think you put the key collapse code in the wrong place though, I saw this living in modelChangeHandler (dealing only with keys) and cleared in updateDOM. By dealing only with keys at that layer we can select all bindings that match those keys in deltaFromChange [22:46] does that make sense? [22:48] you try and remove dup bindings, but this is the binding, not the change, we just want all the bindings matching a key at this point [22:48] (or a set of keys) [22:48] if you'd like I can take a stab at it [22:49] hmm maybe I've been staring at this too long because I was under the impression that I was aggregating the deltas using this technique [22:50] deltasFromChange is only the delta in the keyspace of the model, not the change events [22:50] you are close though [22:51] ok I am totally missunderstanding what's happening here then - maybe if you wouldn't mind fixing it so I can see what I'm missing [22:52] * hatch slides a pint of beer across the table [22:52] how about now? [22:52] :) [22:52] hatch: happy to, I'll write it now and you can merge when I have it ready [22:52] virtual beer... [22:52] awwwwsuuuummmm [22:52] next sprint - real beer [23:04] Morning [23:04] hey huwshimi how are you doing? [23:04] hatch: Good thanks, yourself? [23:06] could be better :) [23:08] hatch: Are you sick? [23:08] nah, just stupid things happening today [23:08] oh [23:08] HTC repair depo not wanting to fix my wifes One set me off [23:11] huwshimi: so hows that IE stuff coming? [23:12] hatch: so I *think* this should fix it, but I didn't generate a full test for the multiple key case as getting the timing right on that would delay you actually testing it. lp:~bcsaller/juju-gui/databinding-safeupdate [23:13] bcsaller: ok looking thanks [23:13] hatch: if that doesn't help I'll keep at it with you [23:15] bcsaller: ok I gota merge this in manually so it'll take a second [23:15] hatch: if you didn't change databindings.js for anything else take that version [23:16] yeah I added the prev value stuff [23:16] hatch: Our animating input fields are being a pain. We need to set the inputs in the inspector to a flexible width as the size of the scrollbars varies between browsers. [23:18] router issue, might lose wifi here [23:19] ok merged...trying [23:21] bcsaller: awesome, fixed [23:21] sweet [23:21] thanks a ton [23:22] now to figure out the difference [23:22] I think I saw it though [23:22] yeah, I was going to ask [23:22] ahhhh now I see now I see [23:22] this just accumulates keys until updateDOM is called [23:22] you only deal with the keys not the datasets [23:22] yeah [23:23] keeps it simple [23:23] I'm not entirely clear why my technique broke it though [23:23] clearly it was wrong...but I don't know why.... [23:23] you thought delta in deltaFromChange means ws delta changes or something [23:23] we are selecting the binding objects for model change keys here [23:23] so a set of keys becomes a set of bindings [23:24] not change events [23:24] ohh that's why it was pointing to the incorrect element [23:24] ok got it now [23:24] the delta is vs the keyspace of the model in this case. I'm open to renaming it so this doesn't happen to another dev [23:25] bindingsFromModelChange or somesuch [23:26] yeah it's not bad idea....now I"m going to tackle the remaining failures :) [23:26] thanks again! [23:27] ohh my prevValue code doesn't support pojo's [23:30] huwshimi: did you need a hand or need to bounce any ideas off anyone for that? [23:31] hatch: It's ok I just need to modify the scrolling code which is all fairly hardcoded to be more flexible [23:31] scrolling/animating [23:34] ahh ok, I think there was a scrolling change landed today [23:34] so you might want to merge trunk [23:36] hatch: Ah right, thanks