[00:00] gary_poster: no, not that I'm aware of. Looknig at the CI thing now. Looked it over since it was failing most of the day. [00:01] understood rick_h_. Yeah, we got a single success after the other problem before we dipped back down into the red. :-) and :-/ [00:06] rick_h_, passes locally on IE 10 but same failure on CI :-( [00:06] gary_poster: hmm, the video shows it passing [00:06] gary_poster: I've not poked at the CI really, but went to the saucelabs results and trying to figure out 'what' failed. some timeout, but the video shows all tests run/passed [00:07] rick_h_, I wonder if it is simply a timeout thing, now that we have so many tests. Leme see if I can remember how to increase that [00:07] gary_poster: k [00:10] rick_h_, that is the timeout error. I'll double the tmeout, from 90 sec to 180 sec, and we'll see how it goes. [00:12] gary_poster: ok cool. Yea noticing that I used to be able to run the tsets in some 30s of seconds and these days it's a chunk more than that [00:13] gary_poster: thanks for poking at that. [00:13] :-) sure [00:14] http://uistage.jujucharms.com:8080/bws/sidebar/ click on the service view of a charm :) [00:15] looking nice! You mean, just click on a charm? [00:15] no, the environment, "view" so that the browser hides away [00:15] oh! [00:16] nice rick_h_ ! :-) looks good [00:16] ok, running away until tomorrow. Thanks again. CI is good. Let's do more of that. :) [00:17] :-) I agree rick_h_ . ttyl, & have a good night [02:21] gary_poster: yeah he did mention not wanting an RTE however using just the core functionality of one will give you all of the user input stuff that you need. Then you only have to deal with parsing out the html [02:54] I switched to feedly tonight - really nice looking and pretty good UI, I wish it had a search feature though for searching through my feeds [12:13] gary_poster: yesterday how did you eventually get firebug to show you the console? [12:17] yes bac [12:17] oh [12:17] bac I reset the options and then I turned on the console tab [12:18] then it worked in the source tab [12:18] gary_poster: nm. it is behaving very oddly. the first time i had one newly styled UI. i've since reloaded the page and now have the old firebug UI. [12:18] cool [12:18] jcsackett: if you get a sec can you second the huw reviews. Pretty small ones but three of them. https://codereview.appspot.com/8972043/ (8653049|8973043) [12:27] gary_poster: https://bugs.launchpad.net/juju-gui/+bug/1110832 can be closed as fix released right? [12:27] <_mup_> Bug #1110832: Charm browser story needs in-browser environment [12:28] yes rick_h_ thanks [12:29] I need to go through bugs [12:29] not my favorite activity [12:29] gary_poster: I'm with you. Just trying to keep up with the UX folks myself [12:29] +1 thanks [12:30] gary_poster: I'm looking at this change to get rid of 'dummy' on the header. I don't see that as something in the GUI. Is that coming from juju itself? [12:31] yes rick_h_ . The "dummy" comes from improv. Other environments report other data--for instance, "Environment on ec2" [12:32] gary_poster: ah, the same improv in the gui tree? [12:32] gary_poster: e.g. if I can get it changed there it might just work? [12:33] ok, yea seeing it in the rapi-rollup thing. [12:34] rick_h_, the in-memory juju reports "demonstration," improv (from rapi-rollup) reports "dummy" [12:34] gary_poster: oh, so that'll be changing soon then when it goes to the in memory one? [12:34] rick_h_, but I thnk they just want the whole cloud-icon-plus-environment-on-X thing gone [12:34] remind me of that bug number [12:34] ? [12:34] gary_poster: #1172734 [12:34] <_mup_> Bug #1172734: Environment on Dummy [12:35] gary_poster: yea, this is just a blocker for UX so it's the 'smallest change' without doing the whole header [12:35] I had hoped it'd be a drive by in a small branch of tiny fixes :) [12:35] s/dummy/demo or something but stepped on something bigger [12:36] I see rick_h_ . If they just want "dummy" to go then yeah, that is probably already done. Start the GUI locally with staging: true in your config. I'll do as well. You should see "Environment on demonstration" [12:36] gary_poster: cool, thanks. [12:38] rick_h_, " Environment on demonstration" [12:38] that nay not be ideal still [12:38] may [12:38] gary_poster: cool, works for me. marking the bug as fix committed, but not released since staging shows the old atm. [12:39] rick_h_, ok, though....1 sec... [12:39] gary_poster: well, in our call they took offense to the word 'dummy' on the site [12:39] rick_h_, fix released: https://91.189.92.38/ [12:40] rick_h_, that's the prodstack site [12:40] ah ok very cool then [12:50] bac, did hatch steer you towards another RTE? not convinced by that from the outside [12:51] gary_poster: we're going to explore using the YUI EditorBase [12:52] gary_poster: he thinks it is lightweight enough that having lots of them on a page won't be a problem [12:52] bac, that does not produce raw text but html, so you are going down the road of what you and I had prototyped: nasty heuristics to convert html to text. I hope I'm wrong, but I don't think I am. :-) [12:53] gary_poster: understood [13:14] lol, well removing the /bws/ and making the browser always show only broke 167 tests. lol [13:15] heh [13:15] hopefully that's easier than it sounds [13:15] yea, I'm guessing a giant cascade [13:15] but was fun to go "let'r rip!" [13:16] :-) [13:35] luca____: hangout? [13:35] rick_h_: I'm in a meeting for the next hour or so [13:35] luca____: ok cool [13:35] bac another question is whether http://www.jacklmoore.com/autosize/ can look like a single line when you start. :-/ [13:36] rick_h_: our visual designer is working to tight deadlines today to get everything out to you guys asap :) [13:36] luca____: cool, have a couple of questions for you guys when you get a sec [13:37] rick_h_: ok, I'll let you know when were out [13:43] rogpeppe1, is it possible to remove a subordinate relation in juju core? was not possible in pyjuju, and IIRC the reason was that proper behavior was unclear and/or difficult to implement. [13:43] gary_poster: i haven't tried. perhaps :-) [13:44] rogpeppe1, :-) k [13:55] * gary_poster switches off to try raring on the desktop. back soon, hopefully... === gary_poster is now known as gary_poster|away [14:03] I have a very odd test failure that I'd like some help on.....test_app.js 'should be able to route objects to internal URLs' [14:04] in that test it tries to get a url of a charm....but I can't see where the charm data is populated [14:12] down to 1 failing test woot [14:13] right on [14:13] my failing tests are so confusing [14:14] add that to the console not working [14:14] can anyone tell me how to turn the console logs on during the tests? [14:15] I get the loader logs but nothing inside of a test or the application [14:15] well that's not entirely true....console logs in 'before' work [14:20] ahah found it...wow that has to be the most irritating thing [14:20] hatch, Set a breakpoint and check the value of console? [14:20] Oh, excellent. [14:20] that's not very efficient when you're in a fn that's called a number of times [14:21] know what I mean? [14:21] I just meant in one test to investigate is all. [14:21] hatch: I've been known to "window.one = true"... if(window.one) { debugger } on some occassions [14:22] just to add hacks to hacks :) [14:23] do two hacks make a right? [14:23] make for not clicking 'play' 50 times to get to the one iteration you care about :) [14:23] ^that [14:23] say...to drop a debugger in the afterEach when there are 50 tests in the suite. You could comment them all out, but hook a var in your test to window and all set [14:24] oh fyi if you set 'consoleEnabled' to true in the config of an app instance then it will log properly [14:24] * hatch contemplates deleting the console clobbering code ;) [14:25] Alright. I mean, if console.log isn't working in any test because it's being turned off, iterations shouldn't matter :) [14:26] Glad you found it, though. [14:27] now I'm so confused as to why these tests are failing... [14:34] ohh now I see why they are failing [14:34] because the test is wrong now [14:35] hatch: ping me when you've got some time [14:36] well I'm at a good stopping point, wana chat? [14:36] rick_h_: are you free? [14:37] luca____: sure thing [14:37] rick_h_: https://plus.google.com/hangouts/_/59f6e27697d7873463bc542eb1fd68f2d79b98c4?authuser=1&hl=en [14:37] luca____: https://plus.google.com/hangouts/_/8afa3721f4844e71152262d259b9f7ed6c5b76d7?authuser=0&hl=en [14:37] lol [14:37] luca____: omw === gary_poster|away is now known as gary_poster [14:43] hey gary_poster hows raring? [14:44] hatch, mostly good. graphics driver is working on desktop now. need to get webcam working... [14:45] hatch: sure [14:45] to guichat [14:46] or not [14:46] https://plus.google.com/hangouts/_/cd713a9d85f41b965a8d3f0ab9189dc8a2fce870?authuser=0&hl=en [14:46] ^bac [14:46] hatch: i saw you there briefly. now it is just gary and he's non-repsonsive [14:46] * bac joins other [14:52] jujugui please update kanban. hopefully I can join in 8 :-P [14:59] jujugui call in 1 [14:59] sigh thanks. maybe from other machine... [15:07] rick_h_: query: we sent you the assets yesterday and saw that they weren't implemented, are they ok? [15:08] luca____: yea, they're in review. Should land in next hr [15:09] rick_h_: fantastic! just checking in case we needed to re-supply [15:30] rick_h_: tagging all "nice to have" improvement as: Charmbrowser Enhancement in launchpad. Is that ok? [15:42] luca____: rgr [15:43] rick_h_: hey [15:44] luca____: yep, otp but what's up? [15:47] rick_h_: nm! Just realised what was going on :) [15:57] rick_h_: are you free for a very quick call? [15:57] luca____: give me 10? [15:57] rick_h_: sure, let me know when [15:57] luca____: k [16:03] luca____: I'm avail [16:03] rick_h_: sweet [16:04] rick_h_: https://plus.google.com/hangouts/_/cca38ee039e87fba24828491149b9f7f76e17f54?authuser=1&hl=en [16:16] luca____: so the video, assets, and search results styling from huw are on uistage [16:16] http://uistage.jujucharms.com:8080/bws/fullscreen/search/?text=hadoop [16:17] and http://uistage.jujucharms.com:8080/bws/fullscreen for instance [16:29] Makyo: hatch bcsaller can a pair of you guys look over this sometime? https://codereview.appspot.com/8977043 to bring the browser into the default view. QA it, break it as hard as you can :) [16:29] this almost seems too easy of a branch after all the fight to get this far. [16:30] rick_h_: I'll look at it soon [16:30] bcsaller: thanks [16:30] I'm going to duck and look for food. [16:31] note that removing the old stuff is a second follow up branch [16:38] rick_h_: ahh, ok, I was commenting on that [16:38] bcsaller: yea, didn't want to cross the streams and I like all-delete branches [16:44] * gary_poster restarting... === gary_poster is now known as gary_poster|away [16:49] bcsaller: can you tell me where the charm data is being populated in this test http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/test/test_app.js#L125 [16:49] it's failing in my branch and for all purposes I can't find why it would ever pass... [16:50] hatch: in beforeEach it calls injectData which simulates a delta with charm info in it (at a glance) [16:51] there is charm info there? I only see services with charm attributes [16:53] hatch: I think it then pulls that out of band [16:53] its like when the server tells you on the inital connect whats in the environment [16:54] sure but nothing is saying 'hey create a charm instance' [16:55] unless it was happening as an obscure side effect [16:55] which I suppose is possible [16:55] I did remove a ton of the endpoint.js code [16:55] so it may have been passing by accident heh [16:58] nice looking chrome devtools theme http://devthemez.com/themes/zero-dark-matrix [17:01] bcsaller: ahh it was happening by a side effect in code I removed in endpoints.js [17:01] which only matters in the tests and not in the real application [17:02] bcsaller: thanks for the review. I'll s/nop/noop :) [17:02] rick_h_: thanks === gary_poster|away is now known as gary_poster [17:08] Hey, anyone available to try guichat to see if everything is working for me now? [17:15] gary_poster: sure [17:15] rick_h_, already handled thank you [17:15] :-) [17:15] oh heh, nvm [17:15] much appreciated though [17:27] hatch: have you reworked endpoints::handleServiceEvent recently (or currently). I'm seeing an error there where db.charms.add fails because the id already exists. I think there is a real race wrt the env.get_service call above and it shows up with the sandbox. [17:27] Uncaught TypeError: Cannot call method 'load' of undefined [17:28] bcsaller: it's been entirely reworked in the current branch [17:28] no race condition possible anymore [17:28] :) [17:28] I'd like to show you the diff but I don't think bzr can diff from 'parent' [17:29] ok, its killing my testing now, but I won't do my own fix [17:29] hatch: bzr diff -r ancestor:../trunk or similar [17:29] well my trunk branch is updated [17:30] so I need to diff from whatever revision it was branched at.... [17:30] whatever that is [17:30] hm. we don't seem to build in raring... [17:30] no? [17:30] gary_poster: I'm on raring and its working for me [17:31] bcsaller, yeah? hung here after a make clean-all && make: [17:31] npm WARN engine cryptiles@0.1.3: wanted: {"node":"0.8.x"} (current: {"node":"v0.10.5","npm":"1.2.18"}) [17:31] hmm, maybe I didn't do it from clean [17:32] mm, I may need to redo the installation instructions [17:32] I mean, do them on raring [17:33] gary_poster: no other error messages? [17:33] I saw some warnings in the npm output, but it works fine and will put up the devel server [17:33] that's just a warning, I get those all the time [17:33] bcsaller, nothing else, but then I did a clean-all again and it pointed out I didn't have ImageMagick. Trying that and all other bits and bobs [17:37] made it past that part... [17:40] rick_h_, manage.jujucharms.com does not work ATM with gui, right? [17:41] gary_poster: right, not all of it does [17:41] staging does work ok now though [17:41] http://staging.jujucharms.com/ [17:41] bcsaller: clearly the lbox knows how to properly diff so I'll have to look into that to figure out how it does it [17:41] rick_h_, cool. looking at your branch. I suggest switching app/config-prod.json to staging for now [17:42] gary_poster: ok [17:42] rick_h_, also, before this lands, we will need to either set up working defaults for those values in the app, or update the charm to provide them. Otherwise trunk will fall over in charm. Also important for prodstack [17:43] rick_h_, one more piece of feedback: would be great if we could have loading circle (same, but possibly scaled down, to the one we have when loading the GUI) in the charm browser when it is just loading [17:44] Since UX guys are gone I'd suggest adding and then verifying with them [17:44] gary_poster: yes, we've got the indicator widget that needs to be applied liberally along with some caching to prevent reloading the interesting/etc [17:44] gary_poster: it's part of that that work [17:44] cool [17:45] rick_h_, I search for juju-gui (in prod but with the staging site set in config) and got an error initially [17:45] Failed to load charm details [17:45] Charm API error if type: no_such_charm [17:45] gary_poster: yes, I'm looking at that right now actually. [17:45] ok cool [17:46] gary_poster: there's a corner/multi route case I'm seeing in qa'ing some more where /fullscreen also matches the new /*id [17:46] so it hits twice and does the right thing but also tries to load a charm called /fullscreen [17:46] ah :-/ yeah. another argument for that to be in its namespace. Kinda serious. [17:46] Other solutions available too of course [17:47] yea, I've already defined the list of possible 'viewmodes' and they can't match the start of an id, which is a release name so working on stripping it out before figuring out state [17:47] rick_h_, k [17:48] gary_poster: where are 'set a default'? [17:48] for the config? [17:48] * rick_h_ didn't realize there was something outside of config- [17:48] rick_h: I have noticed an issue in our tests - we need a way to turn off subapps [17:49] rick_h_, that would just be in your own initialization. putting it in charm would be better. can do that [17:49] hatch: heh, that's what I had to noop to work around [17:49] gary_poster: ah ok [17:49] oh lol [17:49] so tests pass with it, but required a little hack [17:49] but it's why I blew up 160+ tests at first pass [17:51] rick_h_, when will the juju definition of an official charm (which is supposed to make ~juju-gui the official charm) match the charm browser's (which shows the ~charmers branch as the official charm)? This will become pretty important because, for instance, the ~charmers charm will not work with this branch (and there may be other incompatibilities) [17:51] gary_poster: I don't know. I know abentley and sinzui worked on a temp state, but don't know when the final resolution will come. [17:52] rick_h_, ack thanks. abentley, do you know? This could become a blocker [17:53] rick_h_, are we going to mark official charms with a badge or other indication before release? [17:53] gary_poster: No, I don't know. Why might it be a blocker? [17:54] gary_poster: we're trying to. It's on the UX work to try to fit in next week. [17:54] abentley, because from a user perspective, it will encourage people to use old charms. In the concrete case of the GUI, it will encourage people to use old charms that will be broken [17:54] rick_h_, ack cool [17:55] gary_poster: AIUI, promulgated charms not owned by charmers are very uncommon. [17:56] rick_h_, when browser is minimized I see it a bit hanging off to the left. Is that to spec? [17:57] gary_poster: yes [17:57] gary_poster: they want a hint that 'there's something there' [17:57] gary_poster: And can't we work around it by getting a ~charmers branch in place? [17:58] rick_h_, cool. might be nice if it were clickable with same effect as clicking button. rick_h_, that's my qa feedback for the branch. have not looked at code. from qa perspective, I'm ok with this landing when (1) that bug you are looking at is fixed (it happens a lot), and (2) the charm can deploy this branch. Yellow can help with #2. [17:59] gary_poster: ok, adding a test for #1 right now and will have that pushed up shortly and will look around for a second code review [17:59] gary_poster: thanks for qa'ing [17:59] Once those are addressed, I'd like to see a follow on branch fix the right hand charm panel. could be from yellow. The spinner also seems like a high priority [18:00] hi hatch [18:01] gary_poster: if yellow could help with removing the old charm panel that would help free me up to work on things like the spinner/caching. [18:01] abentley, promulgated charms not owned by charmers uncommon: probably. OTOH, they are the ones that are being maintained most diligently in the view of ~charmers (so diligently that the ~charmers are willing to step aside) so they are presumably fairly important to some people [18:01] gary_poster: I've got providers and search filters in front of it atm [18:03] bac: hey, I'm just finishing my lunch [18:03] few mins [18:04] abentley, get ~charmers to replace it: fine, but then identifying those charms and coordinating with people needs to be part of the project plan [18:04] gary_poster: No one disagrees about whether this should be fixed, but I don't think it's appropriate to start calling it a blocker today, with less than a week to go. [18:05] gary_poster: fix for the extra loading of an invalid charm pushed up. [18:06] gary_poster: going to add a card then to the yellow board for removing the sidebar browser [18:06] thx on call [18:09] bac: ok ready? [18:09] hatch: sure [18:10] guichat is open [18:13] Makyo: any chance I can bribe a review on https://codereview.appspot.com/8977043 from you? Updates per gary's notes included [18:13] rick_h_, Sure, it's lunch, good time to switch gears. [18:13] bcsaller: ^^ had to add a couple of calls to fix the qa issue if you want to second look it. [18:13] Makyo: ty kind sir :) [18:41] rick_h_, looking good from QA, assuming the 'charm API error of type: no_such_charm' is something else :) [18:44] rick_h_, read up, I see (been buried in go, sorry!) [18:45] Just was getting a lot of resource not found on URLs like http://staging.jujucharms.com/api/0/charm//search/precise/puppet-3 [18:45] Makyo: what's the url right now? [18:45] Makyo: maybe I missed a case. looking. search...hmm. [18:46] http://localhost:8888/sidebar/search/precise/puppet-3/?text=puppet [18:46] Makyo: sec, let me try one thing. [18:48] Makyo: yea, give me a few. I missed search when I got sidebar/fullscreen/etc [18:49] rick_h_, no worries, will keep poking around. [18:52] Makyo: cool, got it. Just need to add another test case for it. [18:53] Makyo: pushed up the code fix if you want to pull/dbl check. I'll get the test case added here [18:58] sandbox is very broken [18:59] jujugui ^^^ big problem [18:59] :( [18:59] ? [18:59] whats the issue? [18:59] example: (1) search for mysql. (2) add mysql. (3) search for wordpress. mysql disappears [19:00] another example: [19:00] (1) search for mysql (2) add mysql (3) open charm panel. still stuck on mysql page [19:00] no way to escape except searching [19:01] gary_poster: if a link is triggered outside of the viewContainer it won't delegate to navigate, if it reloads the url it will clear the sandbox, that is my guess [19:01] gary_poster, are you breaking on errors? I'm getting a problem in load. [19:01] Makyo, no, will look. [19:02] there is the race in the charm load I was talking to hatch about before as well [19:02] but he said his branch reworks that [19:02] we need to do some serious qa of that stuff then [19:03] Makyo console shows no errors for me when I load env [19:03] ah! [19:03] I see [19:03] When you deploy, endpoints.js:147 [19:03] endpoints.js is broken [19:03] yup [19:04] I don't get that from the new stuff, which is good :o) [19:04] From rick_h_ 's branch, I mean [19:04] Makyo, you mean hatch's new branch? Is that up for review? [19:04] oh [19:05] looking [19:06] is this something that my last branch broke? [19:06] may be [19:07] shall bac and I stop this so I can investigate? [19:08] yes, please, hatch. [19:08] benji, how is your branch going? [19:08] Makyo: code review and branch updated with fix + test cases for search [19:08] BigRedButton.depress() [19:08] exactly [19:08] rick_h_, cool, thanks [19:08] lol [19:09] gary_poster: I'm having trouble verifying that it is helping real charm deployment speed. [19:09] ok pulling trunk and building [19:10] and this is only using sandbox? [19:10] it works fine in rapi? [19:10] hatch sandbox is where we saw it [19:12] Uncaught TypeError: Cannot call method 'load' of undefined [19:12] yes [19:12] on second call [19:12] first one works [19:13] ok it's trying to add the same charm again [19:13] that's what bcsaller was talking about before [19:14] I think [19:14] that you said your charm fixed [19:14] checking on rapi [19:14] but still not clear why it would fail second time through [19:14] it's because you can't add two of the same id's [19:14] no [19:15] line before is [19:15] charm = db.charms.getById(charm_id) [19:15] then the env call which I think pulls the charm as a side-effect, no? [19:15] and then the add fails [19:15] and maybe we see that because the sandbox is very fast [19:15] I'll try this on my local promise branch on sandbox [19:17] bcsaller, forwarded you an email about the fact that we are supposed to use an image on your branch [19:17] I don;t think you have the image [19:17] jujugui - this works as expected on my branch [19:17] oops, autocomplete fail [19:17] and I can't get to the image on linux, oddly enough [19:17] bcsaller: I think that this is indeed a race condition [19:17] trying on os x [19:17] because it's impossible to do a race condition in my branch and it doesn't break [19:18] gary_poster: I don't think I do, but I render the help from a template, easy to modify [19:18] cool [19:18] gary_poster: so bench the textarea stuff and get my branch landed? :) [19:19] hatch, assuming it fixes everything else, yes [19:19] hatch, otherwise, bench them both and fix trunk [19:20] what was issue #2? [19:20] here is my branch - feel free to check it out and try https://code.launchpad.net/~hatch/juju-gui/load-srv-db [19:21] hatch, documented above [19:21] example: (1) search for mysql. (2) add mysql. (3) search for wordpress. mysql disappears [19:21] another example: [19:21] (1) search for mysql (2) add mysql (3) open charm panel. still stuck on mysql page [19:21] no way to escape except searching [19:21] ok trying [19:21] bcsaller, just sent you images. [19:22] gary_poster: thanks [19:23] neither of those bugs show on my branch in sandbox [19:23] trying rapi [19:24] yeah fixed in my branch [19:24] ok hatch how far are you from landing? would pairing help? [19:25] I'd feel comfortable landing after getting the 3 failing tests fixed then I can do a followup to add additional tests [19:25] probably an hour? [19:26] pairing probably wouldn't help as it's just fixing these tests to add the charm data first before trying to get it [19:26] 'just' heh [19:27] * hatch goes dark to fix tests [19:36] Makyo: I'm headnig off for a bit. Will be back tonight if you find anything else. Thanks again! [19:36] ok rick_h_ we need to add the change to the charm for your branch. benji this should not conflict with you because we are adding [19:36] rick_h_, QA is LGTM, will have the code done before you get back. [19:36] something to the template, and a new option [19:37] gary_poster: "add the change to the charm"? [19:37] gary_poster: oh right, the juju gui charm [19:37] sorry, charm is kind of loaded these days [19:37] rick_h_, as I said, your branch will break the charm unless we add the option [19:37] yeah understood [19:38] benji, I'm sorry I'm having family issues I need to address immediately as well. I need to ask you to stop work on your branch. [19:38] gary_poster: added a card to the board for that [19:38] thanks rick_h_ [19:38] benji, new task is small but important [19:39] I think that the promises are causing the tests to fail [19:40] benji, card is "Add default value for charmworldURL to the charm" [19:40] ugh this sucks [19:40] because I think the promises are throwing which is causing the test to complete [19:41] basically the promises are never resolving or erroring which is.....impossible? [19:42] benji, task is to add charmworldURL to template [19:42] for config.js [19:42] make it configurable [19:42] in charm [19:42] default should be the default in config-debug.js in juju-gui [19:42] charmworldURL: 'http://staging.jujucharms.com/' [19:43] because manage is not working, even though it should be the default :-( [19:48] ok maybe pairing won't be such a bad idea... [19:49] maybe someone else can lend a hand as to a way around this promise issue [19:49] https://npmjs.org/package/mocha-as-promised [19:51] http://stackoverflow.com/questions/15058847/unit-testing-promise-a-rsvp-js-promises [19:52] hatch: can't you just call done() in callback and done(err) in the error back? [19:52] hatch: when I worked with it that was working well enough [19:53] I don't think that applies here....guichat? [19:53] hatch: sure [19:57] hatch, bcsaller, I'd like to pair with hatch to let bcsaller finish his task. That also needs to be done ASAP. Let me know when it makes sense to switch. [19:58] gary_poster: I'm a little blocked on testing because of this as well, its currently failing in this same spot [19:58] I see :-( [19:58] other than that it basically works [19:58] bcsaller, revert hatch's previous branch locally? [19:59] gary_poster: you can join the chat if you want [20:59] I have updated cards to clarify priority [21:00] benji, you EoD yeah? [21:01] I'm just about done with the branch, verifying that it actually works by deploying the charm. Trying to figure out where it hides the generated config file now. [21:02] benji awesome, thank you. I suggest trying it out with rick_h_ 's branch, since that's the one that I'm worried about. [21:02] Finding [21:02] gary_poster: if you want to pair real quick to hand-off, that would be fine [21:02] ok benji guichat [21:03] * Makyo dgwalks quick [21:17] gary_poster: benji let me know if there's anything I can do to help. [21:17] ack thanks rick_h_ [21:18] gary_poster: I can't think of any workaround beyond a timeout for that first test....at least without added an 'else' which fires an event [21:18] not sure which is worse :) [21:18] hatch that's what I thought too [21:18] I am leaning towards prefering a timeout [21:18] +1 sadly [21:23] 0 failures [21:23] great hatch. [21:23] gary_poster: would you prefer I land this branch with passing tests and then a followup with additional tests? or hold off until the additional tests are done? [21:23] hatch, what are the additional tests you have in mind [21:24] I'd like to make unit tests to test the charm, service, db changes individuallt [21:24] these tests test them indirectly [21:24] so we can be assured it works with this [21:24] but more tests would be easier to debug later [21:25] hatch ok. land as is then follow up. thanks. also make a card for CI selenium tests of sandbox please [21:26] will do! [21:27] thank you [21:42] jujugui - would love a couple reviews plz https://codereview.appspot.com/8839050/ [21:43] rick_h_, update: I have benji's charm branch starting up with your ~rharding/juju-gui/browser-default branch. Hopefully will work. If so, can get one review and land [21:43] (I already reviewed it :-) ) [21:43] hatch on it [21:44] gary_poster: if you have the time it would be great to get a QA as well [21:44] ok hatch [21:45] ooh, the db has to know the env? That's understandable but I don't like it. :-/ [21:45] yeah I don't much like it either - I'm open for alternatives :) [21:45] to* [21:46] pass env to getFullCharm and getFullService? [21:47] I thought of that, but I wanted the db to be a source of information - so if I have to pass it in then it's no longer the source [21:47] it requires external stuff to work [21:48] gary_poster: cool on the charm. [21:48] it's not a source, but a repo I would argue [21:48] the source is juju [21:48] the environment [21:48] that's why we have to pass a source to charm.load [21:49] hmmmmm [21:49] I agree that it is a "hmmm" argument :-) but not crazy either [21:49] I accept your alternative view and substitute my own for it [21:50] yeah feel free to comment that and I'll change it [21:51] :-) k [21:51] are there any instances in the app where we don't have env but still want service/charm I wonder [21:51] hatch that would be a great counter argument :-) [21:51] hatch: that's coming soon [21:51] https://bugs.launchpad.net/juju-gui/+bug/1173274 the argument today came up of browser sans environment [21:51] <_mup_> Bug #1173274: "Connecting to environment" spinner should not block charm browser [21:52] different, rick_h_ [21:52] gary_poster: ah nvm then [21:52] thsi is code env, not visual env [21:53] gary_poster: ah, looking now. Thought this was replacing the model/charm.load() stuff [21:54] rick_h_, it is...maybe I misunderstand your point? [21:54] gary_poster: hmm, don't see in the MP the change on model/charm? just charmlist? [21:55] crap start-error in charm [21:55] * gary_poster was really hoping to relax :-( [21:55] gary_poster: well, can wait until monday. I've got enough other bits that aren't directly tied to this to do [21:55] rick_h_, not sure I agree :-/ [21:56] providers/caching/etc. [21:56] we need to have a decent set of code up for IS to review [21:56] working [21:56] gary_poster: true, but if we're shooting for thurs would hope tues would work for that? [21:56] never felt so on the tail end of timezones before this project [21:56] rick_h_, no. this schedule makes me mad. don't scratch the wound. :-) [21:57] gary_poster: k, then no relaxing for you :) [21:57] :-) [21:57] anything I can help with for this? [21:57] hatch: guichat for a sec? I'd like to understand this [21:57] sure [21:57] I feel like there's a connection in the future [21:58] ohhhh so lonelllly [22:03] rick_h_, what is your schedule. you in guichat [22:04] gary_poster: yea, in there now