[00:11] Whew, got it. Man, ingest is a long path! [00:12] Makyo: :) [09:10] hi dimitern: so, IIUC, rsyslog-gnutls is now required to be installed in the local machine to bootstrap a local environment, right? [09:11] frankban, hey, that's right [09:11] dimitern: and this will be a requirement for 1.18 [09:13] frankban, yes, but it seems juju-local doesn't list rsyslog-gnutls as a dependency [09:13] dimitern: asking because, if that's the case, we'll need to update quickstart as well. === rogpeppe is now known as 17SAAOELG [09:14] frankban, isn't quickstart about installing juju-local? === rogpeppe1 is now known as rogpeppe [09:15] dimitern: quickstart installs the juju stable PPA, and then apt get installs juju-core, lxc and mongodb-server [09:16] frankban, from source? [09:16] dimitern: apt-get install [09:16] frankban, ah, sorry - from the ppa [09:17] frankban, ok, so does it install juju-local package? [09:17] dimitern: no [09:17] frankban, it should [09:17] dimitern: I guess juju-local is a meta-package for juju-core, lxc and mongodb-server, correct? [09:17] frankban, http://paste.ubuntu.com/7037530/ [09:18] dimitern: cool, and you'll add rsyslog-gnutls I suppose [09:18] frankban, I pinged jamespage about it [09:20] dimitern: so effectively installing juju-local means a complete installation, also supporting cloud providers [09:20] frankban, it should be enough [09:22] dimitern: I'll investigate why we decided to install single packages instead of juju-local. If there is no valid reason, I'll change quickstart to just install juju-local from the PPA. [09:22] frankban, tyvm [09:23] dimitern: thank you! [09:30] * hazmat totally missed were quickstart went to using urwid [09:30] whe [09:30] when [09:31] frankban, there's a change in jujuclient 0.17.3 that's worth noting.. occassionally juju core will disconnect all api clients [09:32] for watches specifically, i added a default parameterized behavior that will auto reconnect them [09:34] hazmat: interesting, auto_reconnect=True [09:35] hazmat: IIRC there was a similar bug some weeks ago, is this different? [09:36] frankban, its the same bug.. roger had re-worked timeouts in the api server which is why it had got marked closed last time.. [09:36] frankban, but another manifestation of the same err, is that juju api-server goes awol occassionally [09:37] something about a failure around mongodb socket, and then it disconnects all clients [09:37] core agents auto reconnect and handle [09:37] hazmat: ack, so this will be fixed in 1.18 I suppose [09:37] frankban, unclear.. [09:38] :-/ [09:38] hazmat: are you planning an update for the jujuclient packages in the juju stable ppa? if so, we'll need to also update quickstart [09:39] hazmat: I am also thinking about the jujuclient tgz in the gui charm, perhaps we need to use the last release there too [09:43] hazmat: moreover, a mega-watcher random disconnection on 1.18 would also be a big problem for javascript clients (e.g. the GUI) [09:43] rogpeppe: ^^^ [09:45] frankban: i'm planning to look at that today [09:46] frankban: i haven't yet managed to reproduce the problem yet though [09:46] frankban, i had it pushed to trusty [09:46] frankban, i haven't really touched the stable ppa.. [09:46] * hazmat wonders if he can bribe someone to update deployer and client in there [09:46] rogpeppe: cool, thanks [09:47] rogpeppe, i've gotten about a dozen people reporting in the last two weeks.. i think canonistack environments help to reproduce ;-) [09:49] hazmat: i guess i will try to repro inside canonistack then [09:50] hazmat: could you please ping us on PPA update? unrelated: are you still living on the wrong timezone? [09:51] hazmat: re urwid, yeah, we use that for the environment management CLI [09:52] hazmat: the only downside is that it's not easy to make it work on windows, so maybe we'll need another solution when porting quickstart there [09:52] hazmat: from the bug report (lp#1284183) it's not entirely clear how platform specific the repro script is [09:52] <_mup_> Bug #1284183: jujuclient.EnvError: [09:53] frankban, toddler [09:53] frankban, if you want to push it yourself your welcome to.. your pushing quickstart there? [09:54] * frankban thinks about pyside [09:54] frankban, over pyqt? [09:54] yeah [09:54] hazmat: toddler? [09:55] frankban, baby not sleeping well [09:55] hazmat: OIC [09:57] frankban, yeah.. never been clear to me pyside was going to keep up.. its already well behind on qt 5 support afaics [09:57] frankban, the only reason i've seen people choose pyside is licensing.. [09:59] hazmat: interesting, I did not look at that ecosystem for a while [10:01] hazmat: so https://code.launchpad.net/~ahasenack/+archive/python-jujuclient and https://code.launchpad.net/~ahasenack/+archive/juju-deployer-daily , right? [10:05] hazmat: I'll take care of copying binaries over to the juju stable ppa. I plan to do that on my next quickstart slot (next week probably, maybe earlier). [10:06] frankban, awesome thanks.. i think the distro packaging is different, it fetches from pypi [10:09] hazmat: yeah I think we have the same situation with quickstart, where trusty uses pypi and our PPA builds use a launchpad recipe [12:06] yea, they've packaged the deps up from the pypi [12:07] rick_h_: when you have time, could we please have a call? [12:11] frankban: sure thing [12:12] frankban: https://plus.google.com/hangouts/_/CONVERSATION/UgxGu-UJzXYihe-SGLV4AaABAQ?hl=en&hscid=1394021535421286643&hpe=11omarnn9ff7sl&hpn=Francesco%20Banconi&hisdn=Francesco%20Banconi&hnc=0&hs=35 [12:38] rogpeppe: in the near future we might want to add the following fields to the mega-watcher MachineInfo: Life, Series, ContainerType, Jobs SupportedContainers, Constraints, ParentId and maybe also Adresses. do you see any problems with that path? [12:42] frankban: mostly seems fine [12:43] frankban: ContainerType and ParentId can be inferred from the machine id [12:44] frankban: i need a charm review if you have a moment: https://codereview.appspot.com/71230043 [12:44] rogpeppe: yeah, that's what we do now, and we can keep doing it [12:44] frankban: machine Constraints are an implementation detail and should not be exposwed [12:44] rogpeppe: so, should we use HardwareCharacteristics? [12:44] frankban: SupportedContainers may not always be set (but if it is, it is valid) [12:44] frankban: yes [12:46] rogpeppe: cool, so, what about: Life, Series, HardwareCharacteristics, SupportedContainers, SupportedContainersKnown, Jobs, Addresses [12:46] bac: sure [13:06] bac: i forgot to ping you yesterday after putting the test up. it's now up at https://code.launchpad.net/~jcsackett/charmworld/bad-average/+merge/209272 [13:06] jcsackett: cool [13:06] * bac looks [13:09] bac: done [13:09] jcsackett: nice, thanks. approved. [13:09] frankban: thanks [13:09] bac: thanks! [13:14] has anyone seen errors like this when doing a "make devel"? [13:14] npm ERR! Error: ENOENT, open '/home/benji/work/juju-gui/github/node_modules/node-spritesheet/node_modules/q-fs/test/partial.js [13:15] benji: npm -v && nodejs -v [13:15] benji: can you paste the whole block there? I've seen ENOENT stuff before. [13:15] ?? [13:15] 1.4.3 [13:15] v0.10.26 [13:15] uhm... same here [13:16] benji: you've got the sys deps, imagemagick ? [13:16] rick_h_: I did what HACKING said, other than that I have no idea [13:16] thanks for checking frankban [13:16] benji: ok, it's in hacking but asking to verify [13:17] the only thing around spriting would be base node issues and missing imagemagick library used to do the spriting [13:17] that I can think of off the top of my head with the one liner there [13:25] rick_h_: cards created [13:25] frankban: thanks [13:26] rick_h_: what's the goal of "Update machine/unit models with extra data now available"? [13:26] frankban: well, there was existing data and then there's the ability to pull data via new calls? Or maybe there's not. [13:26] frankban: so the first card was about fleshing out our models with existing data, and then updating them with what we need from the new addmachine calls [13:27] frankban: so does addmachine give us access to anything we didn't have? Or maybe it sounds like it's all the in delta and we've got that covered now? [13:28] rick_h_: so, addMachines returns something like { [13:28] err: 'only defined if a global error occurred' [13:28] machines: [ [13:28] {name: '1', err: 'a machine error occurred'}, [13:28] {name: '2/lxc/1', err: null} [13:28] // One entry for each machine/container added. [13:28] ] [13:28] } [13:28] rick_h_: so I don;t see any new info for us [13:28] frankban: ok, then we can ditch that card [13:29] frankban: gone, thanks for checking up on it. [13:29] rick_h_: cool. Fortunately we can parse the parent/container relationships from the machine names [13:30] benji: any luck? [13:31] benji: want to look at doing a screenshare/call to try to see what's up? [13:31] rick_h_: so right now we have name, agent_state, agent_state_info from the watcher + parentId parsing the name. I guess it is everything we need for machine view 1.0 [13:32] frankban: and we have the machine spec info ? [13:33] * bac afk...bbiab [13:33] rick_h_: machine spec is used to deploy units to a specific machine: this is now enabled, and IIRC units have an attribute for the machine name they belongs to [13:34] frankban: so we need the machine constraint metadata. [13:34] frankban: sharing the machine view pdf with you, should have an email [13:35] rick_h_: ok, I'll take a look after lunch [13:39] rick_h_: here are the first few lines of "make devel" and the first (of many, many) errors I get: http://paste.ubuntu.com/7038531/ [13:41] benji: check the owner of ~/tmp and ~/.npm and make sure it's you. [13:41] benji: and if you try a make clean-all and make devel again does it hit the same issue? [13:45] rick_h_: yep, me in both cases [13:47] if I remove those two directories and run "make devel" again, I get a different first error: [13:47] npm ERR! EEXIST, mkdir '/home/benji/work/juju-gui/github/node_modules/yui' [13:48] a make clean-all should remove all of those directories and start again [13:48] clear the cache that is and local copies [13:48] I don't think clean-all touches ~/.npm [13:49] but node_modules isn't in ~/.npm [13:49] /home/benji/work/juju-gui/github/node_modules/yui [13:50] 1284183 [13:50] frankban: seems reasonable, although i'm not entirely sure we need SupportedContainersKnown [13:50] frankban: s/reasonable/good/ [13:53] benji: it looks from this traceback that you had an npm install get part way and fail one time and it doesn't like to re-run. So make clean-all should remove the existing stuff and restart. [13:54] benji: the thing to see if the failing traceback on a clean first-run of the npm install if it fails again [13:54] rick_h_: I had the same thought and am running several sequentially now [13:55] maybe you just hit a network snafu on a pass and got unlucky? [13:55] I don't think so. It has never failed consistenly like this before. [13:56] I suspect either some setup setup that we forgot to document or a recent change that breaks new installs but works on old installs and we haven't noticed because we use git [13:57] benji: ok so I'm confused. Are you getting any successful runs after a make clean-all? You mentioned running sequentially now? [13:57] rogpeppe: fo you mean SupportedContainers can be null when they're not determined and a map when they are? [13:57] not sure how using git effects the npm install? [13:57] I have not had a single successful run since re-installing my OS. [13:58] benji: the only recent change was the nodejs upgrade. Several of us have gone through the hacking doc on new installs of trusty. I'll setup a fresh lxc to see if I can dupe [13:59] since we install locally, and any amount of "make cleaning" will never be enough, there can be a hysteresis that causes existing builds to continue to work while new ones break [14:00] benji: right, so an lxc test is a good sanity check. But I know I've done three trusty fresh installs and gotten it running [14:01] rick_h_: we already have support for adding machines/containers with a set of constraints. We currently don't receive HardwareCharacteristics from the meta-watcher. To be clear, we can set constraints for new machines but we cannot show hardware for existing machines. Looking at the slides, the current situation seems ok for now. [14:01] frankban: ok, good to know. There was some design around putting machine hardware characteristics in the UX but if that got pulled out even better [14:02] * rick_h_ migrates to coffee shop to run from cleaners. back in a few min [14:06] rick_h_: an idea could be to replace the 6-weighted card we removed with two 3-weighted cards to 1) update core MachineInfo and 2) reflect new info in our machine models. But I am ok if, as you mentioned, you want this work to be done later [14:07] frankban: yes [14:07] frankban: or an array [14:07] rogpeppe: +1 then, yeah I mean, a sequence in general [14:08] rogpeppe: oh, yes I used map I intended slice [14:13] frankban: yea, let's stick in in the on deck for now. We've added the existing new stuff in maint. [14:14] frankban: and if we get time we can pull them from on deck to work on this 2wk cycle if we can [14:15] rick_h_: ok sounds good [14:36] benji hey what error are you getting when trying to build the gui? [14:36] hatch: here's what I get from a fresh build http://paste.ubuntu.com/7038531/ [14:37] benji: http://paste.ubuntu.com/7038757/ works from a clean machine to running gui [14:37] benji: I created an empty trusty lxc, set that as install-gui.sh and run it and end up with a gui running [14:37] benji: this is without any bind to my home directory or anything [14:37] rick_h_: I'll try that as a script [14:38] benji: I'm running it a second time to verify on another clean lxc [14:38] I don't think this machine is dirty, I've only installed about 10 packages (other than GUI things) [14:38] benji: understood, just trying to duplicate your issues on as clean as I can get. Don't even have the ppa install command [14:38] benji does npm have access to /usr/lib ? [14:39] does it work if you run it with sudo? [14:39] hatch: I doubt it; it's not being run as root [14:40] I'm not about to run it as root [14:41] benji: ok, verified that script on a new empty lxc brings up the gui in one shot [14:41] benji: just watch the user:group in the chown [14:41] rick_h_: thanks; running it now [14:41] and <3 google wifi at starbucks. 6Mb/s downloads ftw [14:41] benji npm needs access to ~/.npm and /usr/local/lib/node_modules [14:41] rick_h_: chown? where did those come from? [14:42] benji: that's because when you first run npm install -g (global) it creates those two directories for your user owned by root [14:42] hatch: the gui's npm install doesn't install to /usr/local/lib/node_modules [14:42] benji: so to be able to use them for the make devel local deps, you have to chown them to writ ethem [14:42] benji: this is why I was asking about if ~/.npm and ~/tmp was owned by you or root. [14:42] rick_h_: is that in HACKING? [14:42] benji: yes [14:42] benji: well the chown isn't [14:42] benji ok then ~/tmp needs access too then [14:43] I had these in my hacking doc updates but SOMEBODY thought that it was too harsh :P [14:43] benji: that's why it was the first thing I asked about. If the directories already existed you're fine, only on a fresh intsall does it bring that up [14:43] hatch: no, you had it where root owned everything [14:44] or no, you chowned /usr/lib [14:44] to your local user [14:44] yeah [14:44] :) [14:44] which was not going to fly [14:44] :P [14:45] it is pretty stupid that the node/npm install doesn't fix the folder permissions for it to actually work [14:45] well it's stupid that a -g install touches your home directory at all [14:45] if I'm doing something globally nothing per user should be involved [14:45] there's a system /tmp for that [14:46] javascript jabber just put out a podcast with the npm guys. I'm tempted to listen to see if my rage at them will go down at all [14:46] or just go higher [14:47] higher [14:47] definitely higher [14:47] that's a safe bet [14:47] lol [15:01] hatch: any reason for me not to use Y.isInstanceOf to check for a charm vs a bundle model? [15:01] * hatch needs more backstory [15:02] hatch: I want to do X if charm model and Y if bundle model. I don't see a single instance of Y.Assert.isInstanceOf in our code and it makes me think I'm missing something [15:03] assert.equal(x instanceof Y.juju.models.Bundle, true) [15:03] like that? [15:03] no, it's for real code not tests [15:03] I guess I can just check object.NAME [15:03] rick_h_: hatch I'm working on the UX for upgrading a charm in the inspector in regards to this bug: https://bugs.launchpad.net/juju-gui/+bug/1252586 if we remove it from the list of quick action notifications and maybe put a "Change version" link in the header which takes you to a dedicated space within the inspector that would be ok? [15:03] <_mup_> Bug #1252586: Upgrade service is given too much real-estate [15:04] if (x instance of Y.juju.....) ? [15:04] luca__ well imho the header might be the wrong place for it [15:04] it's a very limited use action [15:05] hatch: ok, sooooo where do you think it should live? Maybe in the configuration section? [15:05] so I'd even go as far as to put it on the configuration panel [15:05] yeah [15:05] hatch: thats the only other place I could think of [15:05] I don't really want to have a new pane for it [15:06] no I agree [15:06] just taking a look one sec [15:06] should we alert users to new upgrades? [15:06] I'm thinking it should go in the configuration pane, maybe above the 'Import configuration file' button? [15:07] hmm [15:07] so populate a quick action notification for new upgrades, which disappears once they've looked at it? [15:07] luca__: hatch what about just making it something that either pops out a panel or that clears the inspector space and takes it over ? [15:07] this would look like the 'service is being destroyed' notifications? [15:07] ^ luca__ [15:08] rick_h_ I was thinking expands to push the settings down [15:08] hatch: no, a black notification like errors or running [15:08] hatch: luca__ I'm not sure a fan in the config because changing the version will change the config available [15:08] hatch: it's kind of two different things there [15:08] rick_h_: interesting [15:08] quick hangout? [15:08] sure [15:08] loading..... [15:09] https://plus.google.com/hangouts/_/7ecpjqdgivcbmgclulgpeuekf8?hl=en [15:23] hatch: rick_h_ cheers! [15:23] :) [15:24] rick_h_ ok back to your object compare issue.... [15:25] hatch: ignore me, I've got something that works for now [15:25] hah ok cool [15:50] jujugui call in 10 [15:53] jujugui small review please https://github.com/juju/juju-gui/pull/160 [15:53] rick_h_, can you ping me when the gui can show recommended bundles? [15:53] jcastro: that's the branch ^^ [15:53] jawesome [15:53] jcastro: will do, should be on comingsoon in a couple of hours. Won't be on jujucharms until next release [15:54] jujugui deploying local charms is broken on comingsoon until I land my current branch....sowwy [15:54] hatch: doh [15:54] * hatch blames the qa'ers [15:54] :P [15:54] ruh roh [15:54] what's wrong? [15:55] it's trying to create an instance which doesn't exist [15:55] simple one line fix [15:59] jujugui call in 1 [16:00] benji ping [16:00] hatch: pong [16:00] call now [16:00] ah [16:07] I waved goodbye to everyone on the hangout and then realized that I don't have a camera plugged in. [16:07] lol [16:08] we all waved back, mustbe magic [16:10] haha [16:17] rick_h_ yeah they are talking about the $ now [16:17] hatch: heh good to know [16:21] basically nodejitsu was running a single huge couchdb for the entire npm db [16:21] .... [16:21] that's why it kept crashing [16:27] yea [16:27] so the $ was so nodejitsu could afford to keep npm running [16:27] it had nothing to do with npm inc [16:28] I'm just surprised noone said 'hey maybe running a single huge instance is a bad idea' [16:28] yea, but I can't see $300K going to a couple month's bandwidth bill [16:29] well no, I'm pretty sure they raised that expecting to fund the year [16:29] then npm peaced out [16:29] lol [16:29] they didn't cover that, but that's my guess [16:30] exactly, it sure seems like they're sitting aorund with $250K sitting in their back pockets [16:30] :/ [16:30] nodejitsu is, yeah.... [16:30] not entirely sure what they should do with that [16:30] I mean, the project they were hoping to support just kinda left [16:30] lol [16:31] and I didn't know this....but issac wrote npm before he started at joyent as a personal project [16:33] rick_h_ your CI failed - in case you missed that [16:33] right [16:33] hatch: I got it, updated branch is running [16:33] make lint fml [16:33] lol [16:33] gota get into the habit of pre-lint and testing :P [16:33] I am thinking of putting it as my pre-push hook :) [16:38] *sigh* fixing tests [16:38] fixing tests is demoralizing lol [16:39] "awesome this works so great.......*32 test failures*.....son of a...." [16:51] hatch: looks like it's the theme of the day https://twitter.com/git_clone_makyo/status/441254662885212160 [16:51] lol [16:52] haha damnit [16:52] Sigh~ [16:54] I hate to ruin its excitement. It just can't help itself! EEEEEE [16:57] haha [16:59] Got the comment that it looks like a Roguelike. "It is very dark. You are likely to be eaten by an out-of-date mock." [16:59] hah [16:59] hahaha [17:12] jujugui: I have a very small documentation branch that would have prevented me wasting a day getting the GUI set up: https://github.com/juju/juju-gui/pull/161 [17:12] looking [17:12] benji: done [17:13] thanks [17:13] hatch: you missed your chance [17:14] 32 failures > 3 failures > 16 failures > 5 failures AHHHHHHHHH [17:15] come on, you know that the failure count in the tests is never worth a dran [17:15] darn [17:15] once a test fails all kinds of things fail for no good reason [17:15] one test at a time [17:16] lol [17:17] aswing-and-a-miss [17:18] I have found that running suites in the browser is way faster than running them in the console [17:18] Yes. [17:19] Don't even need to worry about .skip then [17:19] Er... .only [17:23] 2! [17:23] 102 -> 97 here. So many mocks to fix. [17:27] Makyo: what changed so bad? the charm url? [17:28] rick_h_, We get the service info back from that method in the JSON, but previously, we ignored everything except errors in that object. [17:32] rick_h_, So half of those are "expecting 3 values to unpack, only got two" and half are missing arguments in mocked methods expecting to receive that info. [17:38] Makyo: ah, gotcha [17:41] oh I love yui bugs [17:41] what did you break now? :P [17:42] for whatever reason, a view is being destroyed but it's leaving it's container in the dom [17:42] that's the way it works [17:42] isn't it? if you give it a container? [17:43] nope http://yuilibrary.com/yui/docs/api/files/app_js_view.js.html#l318 [17:43] ohhh [17:43] http://yuilibrary.com/yui/docs/api/files/app_js_view.js.html#l160 you have to pass the option to delete [17:43] waitasecond [17:43] yeah [17:43] what the farquad [17:43] if (options && (options.remove || options['delete'])) { [17:44] so it's the way it's supposed to work :) [17:44] why the heck would you ever want to leave the container in the dom? [17:44] because you often render a View into an existing container [17:44] or swap views in that container [17:44] taking the container out would be a pita [17:44] but a view renders it's own container if one isn't provided [17:44] so it should know that and remove it [17:44] it's not a widget with a boundingBox to keep [17:45] k, so maybe it should destroy ones it creates, but it doesn't [17:45] and hasn't worked that way [17:46] crazy, maybe I've always passed in a container so I never noticed it [17:46] yea, not sure. [17:46] learn something new every day [17:46] but yea, we often in tests do a makeCotnainer and then destroy that container [17:46] so it tends to get cleaned up that route [17:46] and maybe didn't notice [17:47] yeah, well good thing we had this test :) [17:47] :) [17:47] * rick_h_ pats the test on the head...good test, good [17:47] haha [17:49] frankban: would "Support ToMachineSpec in fake backend ServiceDeploy and AddServiceUnits calls" be a good card for me to take? [17:50] benji: sure, the arg is already in the real go env [17:51] benji: https://github.com/juju/juju-gui/pull/152 is the recent branch to the go env [17:51] oh, you reviewed it, heh [17:52] :) [17:53] frankban: I'm a little surprised it is marked as size 3. Are there complications I'm not seeing? [17:55] benji: well, when we scored it we didn't know there was a 'crib this branch for how it's done' in the time allocated. And that score is time to get through review and land as well. [17:55] ok [17:57] benji: as Rick said, and also I guess some time can be spent for some investigations on the real juju-core side. e.g. what happens if the specified machine/container does not exist in the env? [17:57] makes sense [18:00] 97 -> 7 :P [18:02] nice [18:02] I'm doing a final run now [18:02] planning on a few [18:02] lol [18:03] w000t 0 [18:26] Woo! OK (SKIP=1) [18:26] and there was much rejoincing [18:26] err joicing [18:26] or something [18:32] Man, I can't hold both git and bzr in my head at the same time :( [18:33] heh, welcome to the rest of us :) [18:33] every day I do something backwards [18:52] hmm [19:16] Did... did _mup_ just go out for coffee? [19:19] oo boy laggy [19:19] Makyo that was the NSA installing new logging software [19:19] lol [19:19] Rewriting _mup_ in coffeescript, brb [19:19] lol [19:20] Makyo the other day I was reading a blog post that said "Atom plugins can be written in JavaScript" lol [19:20] so I am clearly not the only person haha [19:20] lol [19:20] Pff :) [19:23] actually I saw a review on Atom which showed it and sublime side-by-side and Atom had a pretty big lag comparatively - I hope that's not indicative of webkit based apps on the desktop [19:23] It seems okay to me. [19:23] Granted I only briefly played around with it with the CS game thing. [19:23] yeah - I'm not sure one would notice if they aren't side by side [19:24] but it was probably 500ms difference [19:24] changing tabs [19:24] Which I mostly wrote in Vim because Vim had good literate CS support. [19:26] jujugui lf a review/qa on https://github.com/juju/juju-gui/pull/162 plz and thanks [19:26] rick_h_ ok on to reviewing your branch [19:26] hatch: ty [19:31] holy crud we need to index the bundle table [19:31] lol [19:31] wow that's slow [19:32] rick_h_ review done [19:36] anyone able to review my branch atm? [19:36] I'm going to continue on with it so I'd like to try and catch any issues up front :) [19:40] hatch: can in a sec [19:40] cool thanks [19:41] I think someone is DOS'ing someone in my internets [19:41] is so slow [19:41] suuuure, blame it on the DDOS [19:48] On today's Not-The-0nion: I'm glad to hear that Macaulay Culkin is in a pizza-themed Velvet Underground cover band playing percussion and kazoo. http://thepizzaunderground.bandcamp.com/ [20:04] lol wut [20:05] That's 9 minutes of my life I'll never get back. [20:05] Strange things happen when you leave people home alone. [20:05] rofl [20:42] Makyo: I know we talked about grabbing a inspector card, but if you could peek at that bug I mentioned yesterday next and walk me through that I'd appreciate it. [20:42] after all this fun, but just to setup the next up circle [20:43] rick_h_, Sure, though leave for vet in 15 or so. If it's after EOD for you, I can probably get it done if you want to hand it off. [20:43] hatch: how many views does this make? [20:43] Makyo: yea, I returned it to the ready to code yesterday to grab this one for the recommended issue [20:43] umm [20:43] I need more context [20:44] hatch: well there's two cards for "update viewlets to be views" [20:44] rick_h_, okay. That's the d3 error? [20:44] hatch: so curious if this is a good time to move the card or if we're not half way ther eyet? [20:44] Makyo: yep [20:44] damn, using my kenisis, the air keyboard, and my thinkpad keyboard I think I'm getting worse at typing on all three of them [20:46] rick_h_ oh I'm leaving it there until I finish my current branch [20:46] then I'll move it [20:46] we will be 1/2 way then [20:46] hatch: ok, put it in review then? [20:46] not yet [20:47] not till my new new branch lands [20:47] :) [20:47] hatch: or by 'current' you mean next? [20:47] yeah sorry [20:48] k cool [20:49] Alright, vet now, shouldn't be long. [20:49] have fnu Makyo [20:54] the microwave just turned on [20:54] and there goes my wifi [20:54] lol [20:55] hah [20:56] I think I'm going to go buy me a cable today too [21:00] I'm out all, night [21:00] * rick_h_ runs away [21:01] cyaz [22:23] oh boy this databinding stuff really is complicated [22:23] maybe we should move to react [22:51] rick_h_ https://bugs.launchpad.net/juju-gui/+bug/1288450 [23:04] 1000+ line diff and the only lint warning is that I forgot to doc a file [23:04] w000t [23:04] lol [23:07] hatch: k [23:07] that one should probably be critical? [23:07] make test-debug [23:07] bah [23:08] hatch: yea [23:08] well for the morning I'll have 16 test failures to fix [23:09] then the service config viewlet will be done [23:09] this one was a lot of work [23:23] jujugui charmworld reviews/QA: https://codereview.appspot.com/71070051 [23:33] hatch, https://twitter.com/horse_js/status/441355172510314496 [23:33] rofl [23:35] The one problem I ran into that I really didn't like about CS was the optional parens were irregular if you were dealing with passing the result of a function call as an argument in another function call. [23:35] but you could get around that with newlines. [23:36] And it screwed with order of operations. [23:44] oh, that is a little wako