[00:00] hatch: We've had the anchor div conversation so many times... [00:00] huwshimi when it makes sense yes [00:00] but in this case, it doesn't :) [00:01] hatch: Why not? This is a navigation item... [00:01] what's the case here? Is it going to viewNavigate? [00:01] because pjax is such a bucket full of issues since we don't use it [00:01] rick_h_ it probably will end up doing something along those lines [00:02] huwshimi: hatch actually, these tokens shouldn't nagivate on their own. THey should fire events that the machine view panel dispatches [00:02] this is part of why I like dumb widgets, it helps break down the questions of too-intelligent UI components [00:02] rick_h_: They currently do fire an event [00:02] huwshimi if you REALLY don't want to switch then you need to change all the event handlers to use e.halt() [00:02] because we need to basically stop anything and everything that makes them anchors else they will break the app in weird and fun ways [00:03] huwshimi: ok, yea. If it makes sense to appear clickable, I'm fine as long as there's a direct test that the event does not propogate [00:03] we've been bit by it before [00:03] oh...except the pointer....that's the only related thing that needs to stay [00:03] so...many...times [00:03] I'd rather not have them at all [00:03] hatch: alt text? I guess you can alt text anything [00:03] I kept thinking there was something else [00:03] oh, tab/selectable [00:03] hatch: And make it tab-able. [00:03] it breaks that UI badly [00:04] tab select is never going to work with the app anyways [00:04] I'm not 100% sure how much we NEED it here though as it's not really a form and I'm not sure how you'd select into the space to expect a good tab experience [00:04] we'd need to somehow maintain a tabindex order across all "widgets" [00:04] I've thought about it [00:04] it's possible [00:05] maybe for V5 :P [00:05] hatch: huwshimi I'd vote implementers choice noting the need for explicit stop test if the implementer chooses to go on with [00:05] hatch: lol [00:05] ok ok I'll settle for a test checking to make sure the event does not bubble outside of it's container [00:05] sound acceptable huwshimi ? [00:06] * hatch says that like he has some kind of authority in the matter [00:06] lol [00:06] hatch: well I'm saying 'vote' [00:06] we can make it a friday card, we've been down the road before and we've done both in the code base. [00:06] I don't know either is 'wrong' but we've been bit and need safety checks [00:07] nope, actually huwshimi is correct in using it imho, but we don't use pjax....but we have pjax....so it's just a bug trap heh [00:07] maybe one of these days the yui guys will split router up so we can use only the parts we want [00:07] it's been on the books for a long time though [00:07] yea, and our app is a bit unique [00:07] it's not your standard CRUD app [00:08] we probably could do pjax with this new state stuff [00:08] create our own mold wheeee [00:08] haha [00:08] yea, if we could start over we could do things a bit diff for sure [00:09] 2.0.0 total greenfield? [00:09] lol [00:09] lol [00:09] oh the lines of rewritten code [00:09] isn't the rule 'never rewrite' though? [00:09] honestly though once we get this state stuff done, the only real 'legacy' stuff is the double dispatch [00:09] I know I've fought that rule on my bookmark app a few times [00:10] hatch: yea, and mocha and the awful test setup [00:10] lol....that doesn't exist [00:10] next up...combo loader :P [00:10] haha [00:10] let's set our sights on the really hard fun changes :P [00:10] * hatch waits for design to add fullscreen back in [00:10] lol [00:11] I think the new state stuff will make it easier to do when they do though lol [00:12] * hatch turns off code brain [00:12] I think urls are making me bitter [00:12] hatch: all good, almost through [00:12] yeah maybe watching tv tonight I'll finish the tests [00:12] the code is all done and about 1/2 of the tests === arosales_ is now known as arosales [11:02] mmorning [11:04] hi rick_h_ [11:16] rick_h_: quickstart 1.3.1 is out, Robie should work on that today [11:17] frankban: awesome, thanks for the quick turn around on that. PPA-land here we come! :) [11:17] :-) [11:17] frankban: I've got maas and OSX support for quickstart on the list of topics/work items for the next cycle [11:17] frankban: let me know if there's anything else we should look at trying to do. I can't recall anything off the top of my head [11:20] rick_h_: we have some "nice to have" fixes, i.e.: bug 1292167, bug 1302382, bug 1255635 and bug 1287876 [11:20] <_mup_> Bug #1292167: apt-http-proxy needs to be documented

[11:20] <_mup_> Bug #1302382: Support lxc-clone in local provider [11:20] <_mup_> Bug #1255635: Allow passing constraints to juju [11:20] <_mup_> Bug #1287876: support optional extra config for bundle deployments [11:21] but maas and osx are more high priority [11:21] frankban: cool, some some maintenance time would be cool [11:21] but as far as bullet features for the planning it looks like those two [11:22] rick_h_: for maas, we'd need an infrastructure where to test it. for osx, I think we'll need some brew hacking [11:22] frankban: yep, I started a conversation with someone from server yesterday about maas [11:22] frankban: it sounds like it works in a vm world [11:22] frankban: and he's going to send me some notes on some hardware suggestions [11:22] cool [11:23] frankban: I was thinking of getting 3 or 4 intel nucs to setup a GUI test lab [11:23] rick_h_: so, my understanding is that "maas support" for quickstart means "supporting the creation of maas entries in the envs.yaml", and not "support deploying maas", right? [11:23] frankban: http://marcoceppi.com/2012/05/juju-maas-virtualbox/ [11:24] rick_h_: frankban I really need to amend that post [11:24] frankban: its: 1) support it as a configurable provider 2) support deploying the gui to it 3) support deploying bundles [11:24] marcoceppi: cool, yea we're going to be trying to cut our teeth on maas so looking into the beginner stuff atm [11:25] rick_h_: that's not the way to go [11:25] marcoceppi: heh ok good to know [11:25] rick_h_: virt-manager + maas is way better experience [11:25] I've got a blog post written up about it [11:25] rick_h_: ok, so you already have a maas, and quickstart allows you to configure a juju environment on your maas provider, bootstrap juju, deploy the GUI and bundles [11:25] but not finished [11:26] frankban: yep, that's the goal anyway. I've got a note to 'investigate what's required to implement' [11:26] frankban: and maas does have an api so there might be a stretch goal or two when we get in there. [11:26] frankban: we might need to do things like use the api to make sure you've got unallocated nodes or the like [11:27] since you can't bring up new machines you don't have/etc [11:29] rick_h_: I see, so we need at least one node for bootstrap node + GUI and a machine for each unit in the bundle (assuming they are not co-located,in which case we would need to also parse the bundle) [11:29] marcoceppi: sounds great, looking forward to reading that article [11:30] frankban: that's my understanding of maas at the moment. It's a very vague understanding though I'll admit :) [11:53] * frankban lunches [14:03] rick_h_: re local icons in service blocks. This might require some changes on the guiserver in order to handle the case the local charm does not include an icon.svg, right? [14:04] rick_h_: in that case, a 404 is returned and the block would display a broken image I guess [14:09] frankban: I thought we could have hte files in the charm model [14:09] frankban: and only request it form the guiserver if we already know the charm has one [14:10] rick_h_: where in the code files are currently populated? [14:11] frankban: looking [14:11] frankban: for the stuff we get from charmworld there's a files attr from the apio [14:11] frankban: if we don't fill that during our unzip of the local charm we can add it? hatch do you recall when you worked on the unzip stuff around charms? [14:13] rick_h_: I am not sure we unzip the files when uploading local charms, and even in that case, we need to handle local charms deployed from outside the GUI, or after a refresh [14:13] frankban: true [14:14] frankban: ok, well in the case that the guiserver can't find a charm icon, it can redirect to manange. It's got solid urls for the default and the category icons [14:14] hate to duplicate that, but worst case it can 302 to the right url [14:14] does the guiserver know the charm's config for the charmworld url? [14:14] the root hostname and all that? [14:15] looking [14:15] rick_h_: the charm passes the charmworld url to the gui server, yes [14:17] frankban: ok, so the default icon is always /static/img/charm_160.svg [14:17] frankban: and we've got category one's as well, but not sure if we have that data [14:18] as that's going to be metadata.yaml info for the charm in question [14:18] frankban: what do you think of just "if no icon found, 302 to charmworld's default"? [14:18] rick_h_: we can start by just redirecting to the default icon [14:18] yeah [14:19] frankban: oh, doesn't the api send the file list? [14:19] rick_h_: so, if 404 on the gui server, just redirect to charmworldURL://static/img/charm_160.svg [14:19] rick_h_: yes [14:19] frankban: I recall we had a / that would give us the list of files? [14:19] it does [14:19] rick_h_: yes [14:19] so we can popualte the file list on reaload/etc...but it's not automatic/delta/etc so it's an extra call already [14:20] rick_h_: yes, it's an HTTPS call, not a WebSocket one [14:20] sorry, thinking this through...had in my head we'd have the same files: [somelist] on models like we do from charmworld [14:20] rick_h_: so, it's not in the delta [14:20] rick_h_: yes, we have that list returned as JSON by a GET call to /charms/?url=charmURL [14:20] hmm, ok well let's do this for now due to the demo urgency, but I'd like to revisit and see if perhaps we should try to do something with that data on local charms [14:21] sorry I missed the ding.... [14:21] rick_h_: we'll need that data for the README [14:21] maybe there's some way (annotations?) or something we can shoe-horn this into place to be better long term [14:21] frankban: right, but the readme loads async anyway so it's not as big a deal [14:22] it's not as painful to get a spinny wheel and get 'no readme found' [14:22] ok I don't understand the question [14:22] rick_h_: exactly, the icon is instead just a source reference, a path to a file somewhere [14:22] frankban: ok, I'm adding a card in the backlog to revisit the files list some more, but for demo we can just hard code 302 to charmworld from the gui's config [14:23] in case they run a local charmworld instance or something for offline-ness [14:23] hatch: all good, frankban got me straight. There were bigger issues than I had in my head at the moment [14:23] oh ok cool [14:23] * rick_h_ puffs some more air up in that head to make more room [14:23] haha [14:23] last night I got wifi working on ubuntu, and they fixed the shutdown bug [14:24] woot [14:24] now the only real 'deal breaker' is that it burns through the battery in about 1.5h [14:24] lol [14:24] on idle, osx 7, ubuntu 1.5 [14:24] something isn't quiiiiite right there [14:24] lol [14:28] * bac is back. survived first encounter with PR health care system. [14:29] bac: whoa, hope all is well [14:31] is it cheap there or still way overpriced? [14:32] seems about the same as US. but they don't want to mess with our insurance, even though they are listed in the BCBS network. [14:33] I saw a really interesting show which outlined why the US healthcare is so expensive vs others even taking govt subsidies out of the equation. It came down to each office being it's own instead of negotiating in a large group to purchase things [14:33] SHUT UP! WE HAVE THE BEST HEALTHCARE SYSTEM IN THE WORLD, MAYBE THE UNIVERSE. [14:33] i know, i heard it on tv [14:34] lol [14:34] don't mind those pesky "outcome" metrics. [14:35] if it makes you feel any better ours spend $27M to learn how to do lean....and then they claimed that it woudln't work.... [14:35] *facedesk* [14:36] no that wasn't extreme enough [14:36] *facefloor* [14:38] rick_h_: that ES book must've been something in the original Polish. the English translation is a head-scratcher at times. but, everyone says it is the best available, so i'm happy to have it. [14:39] heh [14:39] bac: hah [14:39] i guess "editor" is not a job description at those pulp houses [14:40] yea, I mean it at least got my head around ES better [14:40] rick_h_: did you send away for the free code samples? [14:40] but yea, sometimes tough to read [14:40] bac: no, the book had enough in the book for me to figure out commands to run to help debug stuff [14:40] cool [14:50] jujugui call in 10 kanban please [15:00] kadams54 call === hatch__ is now known as hatch [15:00] Yup [15:10] rick_h_: so, i have it on good authority you know of a magical flag that allows me to view icons in the GUI that dont come from the charm store [15:10] lazyPower: ssssh I'm not telling anyone [15:10] oh [15:10] so [15:10] lazyPower: it doens't work atm [15:10] lol [15:10] and we're working on local charms getting icons right now for high priority stuff that should be done be Wed [15:10] i have it on good authority this flag doesn't exist, and i will poke at you for additional details of said non-functioning freature [15:11] ;) [15:11] lazyPower: I started the feature, but it doesn't work and have not had a chance to follow up the feature as it's been a slack time thing and I don't know what slack is [15:11] lazyPower: but it's something we want to do, and one day will do, and until they jorge can throw rocks at me [15:12] local charms will work this week though [15:12] I understand the feeling all to well my friend. I'll resync after release, its got a good application during the review process [15:12] xdg-open and dragging it over the canvas doesn't really give a good overview of how it looks [15:12] lazyPower: well, if it's a local after this week you can just drag a zip of it over in a live env :) [15:12] and we're getting some really *gnarly* icons... complete with neon color schemes. its like an 80's dance party in the queue. [15:13] which you need for review anyway I assume? [15:13] i do the repository flag + local: prefix. No zipping here [15:14] lazyPower: well, we can change that :) [15:38] jujugui: trying to build charm-tools i'm seeing pip die with SSL errors trying to fetch bzr from launchpad. i suspect it is due to the re-keying, fallout from the OpenSSL problem. just a fyi in case you see similar. [15:38] bac: rgr thanks for the heads up [15:38] rick_h_ ok updated [15:48] kadams54 I'm going to hop on getting huw's branch landed [16:10] hmmm rick_h_ how do you pull down someone elses branch and then update the PR? [16:10] I tried my usual method but no luck... [16:10] do you need to clone their repo? [16:11] lazyPower there has been an update to http://askubuntu.com/questions/445025/cannot-deploy-local-charms-after-juju-upgrade I think it's a bug that he is experiencing...it should work... [16:13] Makyo in Ubuntu my laptop sounds like your system76, 1000000% fan speed lol [16:13] hatch: Error: storm not found in charm store [16:13] Yikes :) [16:13] interesting - i cant charm get it [16:13] lazyPower he is deploying a local charm... [16:14] needs more info, di dhe write it? did he branch maarten ecctors charm? whats his repository layout look like? [16:14] i've deployed from local repo using 1.18.x for the last 2 days without issue - so i'm pondering on vectors of failure [16:15] ahh, well the error message seems to show that he is using an old version of juju....if he actually is using that command [16:15] so it is confusing [16:16] theres a series mismatch on that too [16:16] does precise now download the saucy package? [16:16] hatch, got a second for a hangout? [16:16] Makyo you bet, link? [16:16] One se [16:16] c [16:17] G+ is slooooow [16:17] oo 19 forks of the juju-gui [16:17] a couple I dont' recognize... [16:18] hatch, https://plus.google.com/hangouts/_/7ecpj2bofe2256ukgemgsuge24?hl=en [16:25] crap CI hung again [16:27] jujugui does anyone know how to update someone elses PR? [16:27] hatch: take it over [16:27] git qa-pr, change it, push to your origin [16:28] oh push it to my origin [16:28] ok cool [16:29] hmm there was some way to update the actual PR [16:29] now I have to create a new PR....which is fine I suppose [16:29] I know you've done it before....just don't know how haha [16:32] ok new pr created [16:33] rick_h_ I know you're busy but if you could try and squeeze some time to look at my branch so I can move onto the next step that would be awesome......(whatever the next step is...) [16:34] wil to hatch [16:34] next step is statecontroller dispatcher stuff [16:36] oh ok, new card.. [16:36] hatch: yea, more of the old card work, tag unsched [16:48] ugh CI!!!!! [16:49] hatch: did it hang? [16:49] hatch: off my call if you want to chat still [16:49] twice now, the first time was a sauce labs hang, the second time was ERADDRINUSE [16:49] hatch: ah, I've got ot kill it then sec [16:49] oh...ok it's running the next tests now [16:49] it's supposed to kill it but seems not to [16:49] sure we can chat about this state controller, I've got a few ideas [16:50] hatch: k, linky [16:50] https://plus.google.com/hangouts/_/7ecpitdd3kur5rdfi9bkaqgbms?hl=en [17:16] jujugui going afk for food stuffs biab [17:19] hatch: confirmed its a bug in 1.18 [17:19] todaso [17:20] lazyPower ever seen trailer park boys? [17:21] only bubbles vs the bible salesman [17:21] lol [17:22] ahhh such a good series [17:36] hatch: https://bugs.launchpad.net/juju-core/+bug/1303880 [17:36] <_mup_> Bug #1303880: After upgrade to 1.18, can not deploy local charms [17:37] ouch that's a doozie [17:45] hatch: workaround is to add series to the deployment [17:45] juju deploy --repository=$SOMEPATH local:precise/mysql for example [17:46] ahhh - woops I totally missed that in his command [17:46] I always use the series....I didn't know it was optional heh [17:48] I should answer the question and steal the points [17:48] mohohahaha [17:50] lazyPower: isn't that related to the work on the charm store and prep for charms declaring series? [17:50] e.g. not really a 1.18 thing but a charm store thing (is that pulled out yet?P [17:50] ) [17:53] rick_h_: http://askubuntu.com/questions/445025/cannot-deploy-local-charms-after-juju-upgrade/445101#445101 [17:53] <_mup_> Bug #445101: package openoffice.org-filter-binfilter (not installed) failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 [17:53] _mup_: you have failed me for the last time *forcechoke* [17:53] lazyPower: gotcha cool [18:00] rick_h_: yeah it doesn't appear to be. A mistaken landing of the new CS code - should be an easy fix. That or a doc update to clear up the ambiguous url bits. I assume that behavior is coming back, but i dont really know. [18:01] lazyPower: yea, there was supposed to be some default logic in teh store to handle it I think. Maybe a bug in that, or the updated store didn't get deployed to prod yet [18:01] lazyPower: it'd be something to talk to casey about [18:01] Right. Marco and sinzui and natefinch are on it. I dont want to dogpile him :) [18:01] yep all good [18:02] I was just responding to the idea of 'big bug in 1.18' as I kind of thuoght it was almost expected behaviour, but I'm not up on the latest/greatest of what made 1.18 and what did not [18:04] rick_h_ I copied the state object wholesale [18:04] hatch: yea, noticed [18:04] so it's all the same code as before which I'll remove/replace as needed [18:04] sorry, I dived in to review everything in green and started to go "this isn't right" [18:05] hatch: all good, I'm to the good parts now [18:05] sounds good [18:20] hatch: looks like one big miss in the branch atm. I'll keep going but I'm not repeating it for each instance. Let me know if we need to chat on it [18:20] hatch: or if the comment makes sense [18:20] hmm ok checking [18:24] hatch: aside from that looks great! [18:24] <3 the tests [18:32] rick_h_ comments replied [18:32] hatch: looking [18:40] hatch: it seems I thought our conversation went off a different way. [18:40] hatch: call? [18:41] hatch: I fear that this is going to break once we do chamge objects as a change to sectionA will have to know to touch section B. You'll end up rendering both which I thought we agreed not to do [18:42] sure [18:42] sec ill make a link [18:42] https://plus.google.com/hangouts/_/7acpim020konevo66n5lf10fqs?hl=en [18:49] * Makyo ducks out to appointment, will propose shortly after. [18:52] #1 peeve: spending time debugging a one character typo [18:52] destory != destroy [19:12] haha yeah that does suck [19:12] *caugh*typescript*caugh* [20:22] rick_h_ still around? [20:22] hatch: yep [20:22] call in 10 [20:22] what's up? [20:22] https://gist.github.com/hatched/10185566 [20:23] ooh, purdy [20:23] <3 [20:23] happy with it? [20:23] excellent, I'll finish it up [20:23] yup [20:23] much better [20:23] thx [20:23] cool, thank you for the clean up, much nicer to read imo [20:24] yeah - I think I like this api design too, it could also be _addToSection('a', 'charmbrowser', this._parseCharmUrl()) but I think the explicit vars is nice [20:24] yep [20:25] wish js had real named params [20:25] but oh well [20:25] this works [20:25] and works well [20:25] so all good [20:29] jujugui heading out to take a sunshine break. Will be back in a bit. [20:29] kadams54: have fun [20:29] Solar powered coding [20:29] woot [20:30] haha [20:30] it's still way to dirty/dusty out for outsideness here [20:30] in a week or so I -may- be able to start washing things [20:30] I want to hire a street cleaner to come by [20:30] it's a mess out [20:31] yeah - we live pretty close to a high traffic road so the salt/grime settles in the snow and when it all melts then it leaves a gross film over everything [21:09] 3PM, it's mewzaq time! [21:23] hmm lots of edge cases being exposed now [21:30] jujugui do we have a method somewhere for building a nested object? leaving values which currently exist alone? [21:31] ex) var a = { b: {g:{}}}; someMethod('a.b.c.d'); ? [21:54] in case anyone is wondering Y.namespace.call(rootObject, 'path.to.create'); works like a charm [21:54] and those darn urls are finished [21:54] landing that branch finally! [22:13] That's cool, hatch. A little magical, maybe, but neat. [22:14] Makyo yeah the key is right here http://yuilibrary.com/yui/docs/api/files/yui_js_yui.js.html#l1375 [22:14] Awesome [22:15] While I'm at it, I have the inspector stuff working as we discussed, but have been puzzling over tests for a bit. [22:15] There don't seem to be many tests for _deployCallbackHandler, so I'm starting from scratch. [22:16] hmm darn [22:16] Or, well, any. [22:17] But I'll get it proposed tonight with at least the test for what I've written. [22:17] I think that's an artifact of the move to inspectors. [22:17] i.e. the rest of the functionality is tested in a more functional/less unit type of testing [22:18] The problems of testing async code, I guess. [22:18] ahh - I think that's old code too [22:18] man we really need a better test suite heh [22:18] Yeah. The file is new, so blame is off, but it's obviously been moved from other locations, since it's some of the original notification code. [22:19] maybe for xmas 2014 we'll be able to give ourselves a new test suite haha [22:19] ahh yeah [22:19] this looks amazing [22:19] https://www.indiegogo.com/projects/healbe-gobe-the-only-way-to-automatically-measure-calorie-intake [22:19] if it's real/works..... [22:20] Rock on! [22:20] I'm super tempted to pick one up.... [22:21] A friend of mine is all jaded about the quantified self movement. [22:21] yeah? I think it's so darn cool [22:21] He works at Mozilla, but used to work at Linden Labs on Secondlife, so he's jaded about quite a bit. [22:21] I want to be able to query all my vitals in a db lol [22:21] rofl [22:21] He was recently railing on http://www.factmag.com/2014/03/28/lightwave-wristband-tells-djs-if-the-crowd-are-having-a-good-time-and-is-a-stupid-stupid-idea/ [22:22] I never did understand secondlife [22:22] lol! [22:23] they could use that to see how much E is being sold....lol! [22:23] It's such a bitter article :D [22:23] (warning: contains strong Electric Daisy Carnival vibes): [22:23] haha [22:25] Not quite sure what to make of Fact. I found http://www.factmag.com/2014/04/07/stream-eric-holms-astonishing-new-subtext-album-andoya/ through it, which is ridiculous, and somehow also awesome. [22:25] * Makyo anyway, back to work. [22:26] liiiistening [22:26] If you're into ambient, the albums linked to early on are also great. [22:26] Sort of...Stars Of The Lid does drums. [22:26] annnnd nope! [22:26] Hahaha [22:27] maybe if I was just chillin out, but I don't do that often [22:27] No, you don't :) [22:28] rick_h_ also my horizontal two finger scroll works in Ubuntu....(you mentioned you had issues with that) so maybe you should do a update/upgrade and it may work now [23:04] Morning [23:22] morning huwshimi [23:22] your branch has been landed [23:22] we weren't sure where you left off last night [23:25] hatch: Ah, great, thanks :) [23:26] make sure you update the board so we know which card we can't take in the morning :)