=== Makyo is now known as Makyo|out === BradCrittenden is now known as bac [12:52] hi teknico, frankban [12:53] teknico: does "go env |grep GOPATH" actually show your GOPATH as in the juju-core README? i've set mine but it isn't being shown. [13:01] teknico: nm. 'go env' doesn't show it but my GOPATH is being used [13:49] bcsaller_, hatch, Makyo|out I think we are ready for the (probably relatively short) Landscape kickoff call I mentioned Monday. Let's plan to do it before the daily call when Makyo|out joins--probably no later than 1:11 from now (1500 UTC) [13:49] gary_poster: sounds good [13:49] thx [13:51] sounds like a plan [13:58] oo those designs are sexy [14:05] * hazmat tries out the gui in opera for kicks [14:06] sadness [14:07] yeah? what breaks? [14:08] bac, yes, same conclusions [14:09] hatch, js error on initial connect, quite a few style errors [14:09] teknico: thx [14:09] hatch, basically a blank page [14:09] we have a helpful page intro page saying use chrome... [14:10] hazmat: oh haha, with my limited Opera experience usually they do things 'to the book' meaning that if anything is done even a little off spec it breaks :) [14:11] hatch, yeah... makes them a nice validation tool.. here's the js traceback. http://pastebin.ubuntu.com/1643873/ [14:12] css errors http://pastebin.ubuntu.com/1643884/ [14:13] was curious cause they just announced they'll be moving to webkit and chromium as a base [14:15] gary_poster: I did not realize yesterday that you were telling me that I had not followed the flow chart. I did not realize that there were to be two messages. [14:16] To clarify/verify: there are to be *two* loading messages: one that says that the application is loading and after that one that says that we are connecting to the environment. [14:17] benji, yes. as I said, sympathetic to what you did. If we can do the second message, though, potentially compelling. [14:18] I can do anything given enough time and money. ;) [14:18] hazmat: oh yeah I forgot that it throws errors for unknown prefixed properties heh [14:19] benji, right. timebox it to two hours, let's say? [14:19] k [14:19] And I'll money-box it so I spend no more than $100,000,000. Just like normal. [14:20] benji :-P [14:20] but if it's incomplete at $100M then you can requisition more to get it completed....just like the government :P [14:24] :) [14:25] it's snowing....1" so far! [14:35] bac, teknico: https://code.launchpad.net/~jtv/juju-core/no-go-env/+merge/142280 [14:37] frankban: nice. too bad it stalled. [14:38] does anyone have emacs config for our current style guide handy? [14:38] frankban, nice, thanks [14:39] hazmat: i have an incomplete emacs config. it sometimes formats in ways that cause the linter to complain. [14:40] frankban, teknico: i added a comment to jtv's MP asking him to please land. we'll see. [14:41] bac, that would help .. feel like i'm fighting emacs more than coding atm [14:41] cool bac, thanks [14:41] * hazmat wonders if its time to give sublime a shot [14:42] I'm really irritated with the dev of sublime so although I use it I probably won't be upgrading [14:43] hazmat, hey, please don't kill it yet, I still need it! ;-) [14:43] hatch, why the irritation, if I may? [14:44] hatch, because of charge for upgrade? better than promising free like tmxt2 and loosing motivation [14:45] teknico: well around the middle of last year he basically drops off the earth - doesn't respond to any requests about the editor or updates. Then just recently comes out with a new version out of the blue and for people who 'recently' bought, he is charging a fee which makes it more expensive than if they had waited a week [14:45] I don't have any issue paying to upgrade - but his actions make it clear that the community isn't important [14:46] hazmat: re gojuju workflow: how do you update trunk after cobzr has been used (i.e. after lightweight checkouts has been created)? "bzr switch master && bzr pull lp:juju-core (--remember)" from the juju-core dir? bzr pull from .cobzr/master and the update? [14:47] hazmat: http://paste.ubuntu.com/1644110/ -- like i said it is hacky and not complete. improvements welcome. [14:47] frankban, go get juju-core/package/... [14:47] frankban, the triple dot syntax is update recursive deps [14:48] frankban, oh.. i haven't been using cobzr.. i'd ask on juju-dev [14:48] hazmat: ok thanks [14:48] hatch, I usually prefer using FLOSS tools, also to avoid these kinds of issues, but in this case the tradeoff seems reasonable, and the pricing terms described in his announcement seem reasonable overall [14:49] http://www.sublimetext.com/blog/articles/sublime-text-3-beta [14:49] bac, thanks! [14:49] rogpeppe, ^ frankban's question re cobzr [14:49] teknico: the pricing is an inconvenience - I'm mostly irritated at his handling of this new version [14:50] as far as disappearing, yes, anything that depends on just one person is somewhat worrying, FLOSS or not [14:50] when someone pays you for a product they expect support - and not responding to comments for 6months is not very good service [14:50] that's also true [14:50] good point, noted [14:50] frankban: i think switching to master and doing a pull as you stated is correct. [14:51] so with all that said :) It's a very very good product which has me torn on the upgrade ;) [14:52] hum... Sublime Text now uses Python 3.3 for plugins, wonder if I have to update my little plugin... [14:55] Makyo|out: when you return - the 'renderedHandler' in topology/service.js doesn't appear to have any effect on the application - maybe it's an artifact of an older version? [14:55] frankban, that's a plus in my book :-) [14:59] teknico: yes, but it can break my workflow! http://xkcd.com/1172/ [14:59] frankban: lol [15:01] xkcd comics are funny because they are true :P [15:07] gary_poster: integration chat starting soon? [15:08] I was wondering the same thing === bcsaller_ is now known as bcsaller [15:09] bcsaller, hatch waiting on Makyo|out [15:12] if you set the charm layout - resize the window - refresh - the charm layout stays the same even if the new window is too small [15:12] known bug? [15:13] hatch, new and intermittent. If I keep readjusting it sometimes works. :-/ [15:14] hatch you filing or shall I? [15:14] I already have it open :) [15:14] cool thanks :-) [15:16] hatch btw you can land bug 1123291 yeah? [15:16] <_mup_> Bug #1123291: Update HACKING readme with missing details < https://launchpad.net/bugs/1123291 > [15:16] There you are _mup_! [15:17] sure let me just review the responses to make sure I got everything [15:17] hatch, bcsaller if Makyo|out is not around at call, let's just talk amongst ourselves after the daily call about it, and I can fill him in with the gist later [15:19] sure [15:20] maybe his window install didn't go so well [15:20] :) [15:21] gary_poster: in the hangout [15:23] do we subscribe to the generic op events in the gui? or just use the op callbacks? === Makyo|out is now known as Makyo [15:27] hazmat, bcsaller and I have a very limited idea of what you are talking about, but we think the answer is callbacks if we understood you :-) [15:28] jujugui call in 2 [15:30] benji goodspud call now [15:31] hmm, insuficient beepage [15:42] hazmat: you want to start another hangout? [15:42] teknico_, frankban: do the juju-core tests pass for you? [15:42] hatch, come baaaaack [15:42] bcsaller, sure [15:42] heh [15:43] bcsaller, old juju-gui ;-) ? tinyurl.com/juju-ui [15:43] bac, I'm having problems with them right now, actually === teknico_ is now known as teknico [15:43] teknico_: me too. and if i follow the instructions for speed up to run 'go test -i ...' it fails miserably and full of lies. [15:44] bac, that too, glad it's not just me, fwiw :-) [15:44] yes, quite a comfort [15:45] bac, teknico I suggest pinging Roger (r o g p e p p e) but I won't do it for you because I'm not as far along as you all :-) [15:46] gary_poster: ok [15:46] rogpeppe, ^^ any ideas? [15:46] teknico: looking [15:46] teknico: (just off a meeting) [15:46] would pastebin help? [15:48] hatch, saw your note about IE10 self-signed experience. would love to hear more, yes [15:48] sorry that was in relation to the url state [15:48] oh ok [15:48] darn :-) [15:49] yeah sorry - I have absolutely 0 experience with self-signed cert with IE10 :) [15:49] rogpeppe, bac, here's my scrollback, fwiw: http://pastebin.ubuntu.com/1644452/ [15:50] teknico: are you running tests in trunk? [15:51] teknico: because if you are, i'm afraid i broke the tests last night. :-/ i'm about to propose a branch that fixes it. [15:51] rogpeppe, the output of "cobzr branch" is "* master", if that's what you mean [15:51] rogpeppe, oh, that's good to know, thanks [15:52] teknico: what's the most recent revno on your branch? [15:52] rogpeppe, 885 [15:53] rogpeppe: i'm at 887 and seeing the same failed tests [15:55] bac, teknico: i've just merged a branch that at least means the test failures don't time out [15:55] jujugui: i've created a google doc for tips/issues for us getting started with go. unresolved ones can be fixes or bugs but i thought we could share experiences now. please edit if you have stuff to add. https://docs.google.com/a/canonical.com/document/d/1OEOzDu9lh4ko8oSgl_tjQlk98x_rgtiiSSJYBRopic8/edit?usp=sharing [15:55] teknico: the rpc package will still fail its tests under Go 1.0.2, but the fix is coming soon [15:56] bac, thanks [15:56] rogpeppe: if i run 'go test' it complains that some packages need to be updated and i should run 'go test -i' but when i do i get: [15:56] go test -i launchpad.net/juju-core/... [15:56] can't load package: package launchpad.net/juju-core: no Go source files in /home/bac/work/src/launchpad.net/juju-core [15:56] rogpeppe, thanks, trying [15:56] rogpeppe, should we be running weekly? [15:56] cool thanks bac. [15:56] we need new stuff from rog [15:56] bac: that functionality only works with more recent versions of Go i'm afriad [15:56] rogpeppe, is that fix 1.0.3 or 1.1? [15:56] hazmat: which fix? [15:57] * bac lunches [15:57] the rpc fix? trying to understand if we should be running weekly instead of stable [15:57] hazmat: no. the rpc problem is because i was relying on 1.1-specific behaviour in json unmarshalling. i'm fixing it so it no longer does. [15:58] ack [15:58] hazmat: with a severe note-to-self to remind me to *always* run all tests against 1.1 *and* 1.0.2 before submitting :-) [15:58] hazmat, if those are Go version numbers, my installed packaged are 1.0.2-2 [15:58] rogpeppe, sounds like a job for continous integration tool [15:59] hazmat: agreed. people have been working on that, but it's not there yet. [16:13] ok all changes to the HACKING document have been completed - now since i have already run `lbox propose -cr` do I need to do anything different this time to resubmit for review? [16:13] bcsaller, re use db, how good is the gui currently about lots of updates? ie. should i still be batching. [16:14] hatch Same command again. [16:14] is it common that I need to add 'make clean' ? [16:14] hazmat: if we need to debounce the update that would be a simple change, for now I wouldn't worry about batching in the place you're dealing with it [16:15] I'll add make clean to the `submit for review` steps [16:15] hatch, You shouldn't need too, since none of the made files are under rc. [16:17] rogpeppe, uhm, running "go test -gocheck.vv" in juju-core/state is still timing out like before on revno 888 [16:18] teknico: hmm, this is what i see: http://paste.ubuntu.com/1644622/ [16:18] rogpeppe, oh, I think I know what it is [16:19] rogpeppe, hazm4t mentioned that MongoDb 32 bit does not support SSL [16:19] teknico: ah yes. if you ran go test ./... -gocheck.vv, you'd probably see a message [16:19] teknico: you'll need to download the built version [16:19] hmm I'm a little confused by the `bzr log` command - I just 'committed' but that commit isn't showing up in `bzr log -r-5..` [16:20] is there a flag I'm missing? [16:20] teknico: ah, 32 bit [16:20] rogpeppe, do you mean from http://juju-dist.s3.amazonaws.com/ ? No 32 bit versions there [16:20] teknico: you'll need to compile it [16:20] teknico: there's a charm to do that. [16:21] teknico: unfortunately... [16:21] teknico: there's a bit of a chicken/egg situation here [16:21] indeed :-) [16:22] teknico: if your machine has suitable horsepower, you could compile mongo on it [16:22] ahh `bzr log -l5` [16:22] rogpeppe, am I the very first unlucky fellow developing Juju on a 32 bit environment? sounds weird [16:23] teknico: the recipe is in juju-core/cmd/builddb/precise/builddb/hooks/install [16:23] teknico: noone has got around to generating a 32 bit exe, yeah. sorry about that. [16:24] rogpeppe, ok, next machine will get a fresh new 64 bit install :-) [16:24] hatch, bzr alias ll="log --line -l10" is helpful [16:24] hatch, then bzr ll [16:24] rogpeppe, ok, it seems doable [16:25] rogpeppe, does it have to be 2.2.0, or would 2.2.3 be preferable? [16:25] Makyo: pfft and yesterday I read a doc which said bzr had sane defaults and that's one reason it's better than git...lol [16:25] teknico: i think you should probably go with the exact same version [16:25] rogpeppe, I will (yay for patch versions :-P ) [16:25] hatch, yeah, I found it helpful to just not really compare them, though apparently cobzr changes that some. [16:26] teknico: you might want to spin up an ec2 instance to do the compilation - it's pretty intensive and takes some hours. [16:27] rogpeppe, wow, ok, thanks for the hint [16:27] teknico: and once you've got the executable, it'd be great if you could sling a copy over to dave.cheney who can make it available in the public ec2 bucket [16:27] Makyo: ok back to getClientRect() - 1) load app 2) d-click charm 3) click juju to return 4) labels should be broken ? [16:28] rogpeppe, that sounds useful too :-) I will [16:29] hatch, load app in Chrome and FF, click to view a service in chrome, create a relation to that service in FF, make sure there are no NaN errors in chrome's console, then click back to environment and make sure the labels look okay. [16:29] if mongo were written in Go, compiling it would probably be less resource-intensive :-) [16:29] hatch Or just two separate tabs, I guess. [16:29] hatch, just that Chrome's console is a little better. [16:33] yeah looks ok here I'll try a few different aproaches just to be sure [16:33] is it possible that this code was legacy? [16:33] was something upgraded or changed that could have made this legacy? [16:38] hatch: as a historical point, the whole environment view recently went through a fairly massive refactoring [16:38] alright :) [16:38] I just didn't want to remove this code if there was absolutely no possibility that it was fixed hah [16:39] hatch, yeah, that's what I had mentioned on the call. Used to get NaN problems in the svg. [16:39] yeah heh - ok I'll remove this code [16:39] yay for dead code removal! [16:45] hatch, Makyo, bcsaller are you all available for call now by chance? [16:46] gary_poster, yes. [16:46] yep [16:46] gary_poster: yeah [16:46] in the board room? [16:46] :) [16:46] cool guys, let's go to jujugui [16:47] it is unfortunate that the name of our hangout is the same as the interrupt-everyone-on-the-team-with-a-notification string [16:47] agreed [17:20] bac benji you happen to be around and not lunching? [17:20] gary_poster: yep [17:20] gary_poster: yep [17:20] cool [17:21] frankban, teknico you around and available? [17:21] just finishing up my merge; it was a mess with lbox and a prereq branch [17:21] gary_poster, yep [17:21] gary_poster: yes [17:21] cool, benji, bac, teknico frankban to the bat-cave! (juju gui) [17:24] will `bzr add editedfile.js; bzr commit -m "msg" ` commit only the added file? I have some edited files in this branch but I only want to commit one of them [17:24] * hatch is trying to apply git workflow to bzr again ;) [17:27] hatch, bzr commit editedfile.js -m "msg" [17:27] hatch: no, "bzr commit" will commit all outstanding changes [17:27] what he said [17:27] eggcelent [17:28] More like svn in that respect. [17:28] Window guys are here, out for a sec. [17:35] jujugui - any objections to me removing the file assets/javascripts/svg-layouts.js ? the module in it is no longer needed and is being removed [17:36] hatch: I can't answer that without verifying usage [17:37] I suppose - so there aren't any rules about removing files as long as it doesn't break anything? :) [17:37] hatch, It's used twice in trunk, both in topology/service.js [17:38] yep - it's now used never in anything ;) [17:38] hatch, Once is the area you removed, but what about the other? [17:38] the other area would break if it returned null [17:38] ex) null.width [17:38] so I reverted it to the 'original' method [17:40] I'll commit the code shortly for review [17:40] hatch, we can do functional testing on it. [17:42] juju trunk should be fixed now [17:43] teknico, bac: ^ [17:43] rogpeppe: thx [17:43] rogpeppe, thanks [17:45] unfortunately fixing it has meant that i'm not going to be proposing the watcher branch today [17:46] 100g yogurt containers are just too smal...they need a big-boy version.....300g! [17:46] * hatch just keeping the discussion on-topic [17:59] hatch: you need horizontal scaling [17:59] but there is so much waste with the setup and teardown then [18:00] this is clearly a task for scale up not out ;) [18:01] Makyo: http://bazaar.launchpad.net/~hatch/juju-gui/1123426-getClientRect/revision/382 [18:12] hatch, gave you a small extra review too :-P [18:13] lol damn - this is the last time I write documentation on something I know nothing about haha [18:13] famous last words :-) [18:13] lol [18:15] gary_poster: would you like me to split the shell command at 80 char as well? [18:16] hatch, only if it is still copy/pastable [18:16] ok I'll leave it then [18:17] so I understand these lboc propose messages https://gist.github.com/hatched/a99739e29af40314ab74 [18:18] is the error on ln #2 and ln #57 normal? [18:18] that's the full output of the `lbox propose -cr` [18:20] I'm just updating the undocumented file right now [18:20] hatch, http://pastebin.ubuntu.com/1645341/ on make devel [18:22] hmm [18:22] bin/mergefiles (which calls lib/mergefiles.js, I think) is still looking for that file. [18:23] yep sorry I missed the -a flag on my `ack` command [18:23] I'll do another once over [18:23] just to be sure [18:34] could someone take a peek at this `lbox propose -v -cr` https://gist.github.com/hatched/a99739e29af40314ab74 it's failing on 'branch check' [18:37] hatch, lbox runs .lbox.check script in the branch root to verify the branch is clean/good [18:37] hatch, it's failing on the linter. You can run make lint to get the output, or make prep to have the beautifier try and fix it for you. Looks like it's because renderedHandler is undocumented, but not in the list. [18:37] can be run manually to verify [18:38] Makyo: are the entries in undocumented done by hand? [18:38] hazmat: ok thanks [18:38] hatch, make undocumented, I think [18:40] ahh yes - the undocumented undocumented option [18:40] ;) [18:41] hatch, I think it's more desirable to add documentation than add to the undocumented list. make help though, will list targets, and instruct you toward the Makefile for other phony targets. [18:44] Victory! [18:45] I swear I'll get this workflow figured out [18:49] gary_poster: wrt HACKING -> do I now only need to commit and then `lbox submit` ? or do I need to push as well? [18:49] lbox will push for you. [18:50] cool [18:55] benji: You created a task called "Extend Y.Node with svg support" - it actually already has it it just doesn't pass the methods through so you need to do node.getDOMElement().{svgmethod} [18:55] benji, just noticed we login multiple times on the gui.. [18:56] two separate login requests right next to each other fwiw [19:01] hazmat: hmm, I don't remember anything about svg; do you have a URL? [19:01] svg? [19:01] re. login; hmm, that sounds like a but [19:01] just watching the improv script api calls [19:02] s/but/bug/ [19:02] yeah.. filing one [19:02] what benji, svg is to hatch [19:02] ah [19:02] s/what// [19:02] hatch, benji, re: getting text from an SVG node? [19:02] https://canonical.leankit.com/Boards/View/102529849#/102902647 [19:03] gary_poster: anything in particular you would like me to work on for the afternoon? I was thinking 1075656 would give me a really good idea of how the system works (although take longer than a day) [19:04] after installing bigjool's mongo PPA i have success! http://paste.ubuntu.com/1645668/ [19:05] cool [19:05] awesome bac. [19:05] bug 1075656 [19:05] <_mup_> Bug #1075656: Charm panel should be YUI composite view, not closure

< https://launchpad.net/bugs/1075656 > [19:05] hatch, yeah not good for today [19:05] ohh mup is a bot [19:06] :) [19:06] hatch, re: svg elements: not sure that stands anymore. We've (mostly) switched from the prior method to d3's classed method, but you can search for anything requiring utils.toggleSVGClass or whatever it was. [19:06] yeah :-) [19:06] Also, can use d3 to get text of svg nodes rather than node.getDOMNode().firstChild.blah in tests. [19:07] hatch maybe easy and new stuff is bug 1123562. Alternatively, choose something fast and IE [19:07] <_mup_> Bug #1123562: selenium tests fail in firefox because of browser warning < https://launchpad.net/bugs/1123562 > [19:07] ok that's good to know, I'm definitely going to be reading up on d3 over the next few days [19:09] gary_poster: sure I can look into that one - although would not using a 'testing config' make more sense ? I am not keen on the idea of having code sitting in the app that's only used for testing being shipped to the client [19:11] open to different solutions. that's another one, and can think of others. quick call in juju gui? [19:11] you bet [19:33] bac: where is this document about getting a go juju dev environment set up? I've look through my email but I don't see anything. [19:34] benji: it is in the google drive 'juju gui' folder. direct link: https://docs.google.com/a/canonical.com/document/d/1OEOzDu9lh4ko8oSgl_tjQlk98x_rgtiiSSJYBRopic8/edit [19:35] bac: thanks! [19:35] benji: i didn't send an email...just pasted here. [19:38] hazmat: go test complains that some packages aren't independently installed and thus slow things down. but installing with 'go test -i' as suggested doesn't work. 'go get' doesn't work either. list here: http://paste.ubuntu.com/1645904/ thoughts on how to properly get them installed? [19:39] actually i should ask over at #juju-dev unless you know right off the top of your head [19:46] bac, separately go get -u launchpad.net/goose && go get -u launchpad.net/goamz [19:51] thanks hazmat. this worked: go get -u launchpad.net/goamz/... && go get -u launchpad.net/goose/... [19:55] cool [21:10] jujugui - any chance I can get some reviews of https://codereview.appspot.com/7306104/ so I can merge it before the end of day [21:11] hatch, taking a look [21:11] I'm doing one too [21:11] thanks [21:17] hatch "land as is" from me. nice job [21:17] thank yaz [21:18] and its off! [21:20] when closing tickets is `lbox submit` mean "Fixed Release" or "Fixed Committed" ? [21:21] hatch, its fixed release .. but you need to pass the bug in to lbox [21:22] i think [21:22] oh.. that's only propose [21:22] ok so I manually change them? [21:23] hatch, it might do it if the branch is already linked to the bug not sure.. we have a secondary system (lp2kanban) that's trying to sync things back and forth as well [21:23] but otoh, it might need manual intervention.. try and find out i guess. [21:24] ok next bug I work on I'll see what happens, some of these have been closed for a while and they haven't been automatically closed [21:33] hatch, change bugs to fix committed until we release. thank you for cleaning those up though [21:35] cool and that getClientRect one gives me a lot of points [21:35] w00t w00t [21:35] * hatch marks all of his tickets secure [21:37] oh karma !== fire point value [22:00] oops looks like the net went down [22:02] signing off. bye all === hatch_ is now known as hatch [22:03] gary_poster, hmm. ran into an issue on the memory environment.. [22:03] raw yaml configs.. [22:08] hatch, nice!, first commit :-) [22:09] 2nd :) [22:09] well the first was just some css [22:09] :) [22:15] hazmat, ah! we can't send yaml to the env from charm deploy unless we go back to those bad js yaml libs? We could simply disable that functionality. It's small, especially for playground [22:15] * gary_poster not really here. disappearing again :-) [22:17] gary_poster, yeah.. i'm just tossing error for now on that case. cheers [22:45] Makyo: it works w/o the queue I think :-/ [22:49] bcsaller, so it might've just been the async stuff? [22:50] bcsaller, re using db directly, we're not subscribing directly to model events anywhere are we? else there's some strangeness possible because model event will fire before op callback gets invoked. [22:50] Makyo: it looks like it was an issue of timing [22:50] hazmat: we're not yet (with the exception of notifications), I'd like to but its still bound around the db.update event [22:56] 16GB macmini ram kit - awesome, I won't have to worry about my VM's crashing haha http://eshop.macsales.com/item/Other%20World%20Computing/1333DDR3S16P/ [23:04] USians - Monday's a holiday, correct? [23:06] Feb 18th is [23:06] :) [23:07] hatch, yeah, just making sure it applies. [23:08] monday is a holiday here [23:08] no idea what for [23:13] Makyo: just saw your comments on the tickets [23:13] that's actually exactly why it's being moved into there [23:13] the search box [23:14] hatch, Oh, so the tickets are for the redesign issues? [23:14] and then the splitting the charm panels are to allow for the design changes [23:14] yeah - the view code needs to be slightly refactored to make it easier to accomplish those changes [23:15] hatch, Alright. Keep in mind that other squads may be working on that portion of the project. [23:15] gary and I went over it this afternoon so I'm sure he can bring you up to speed on it tomorrow [23:15] oh yeah for sure [23:15] hatch, Alright, it just wasn't clear from the tickets. [23:15] yeah sorry I kind of made the tickets for myself ;) [23:18] hatch, and autocomplete? I suppose we can do that with charmstore charms, since then we'll have a list outside, but otherwise, charms are loaded lazily. [23:18] so essentially how I envision that working is after load we'll request a list of all the available charms and display them in the search list [23:19] then there will be an input box which will filter the result list based on the users input [23:19] if the # of charms gets too large then we can easily switch it later to poll a server instead of a local dataset [23:20] hatch, that's fair, but I think we should check next time we're all around where that fits in with current work, given that that would require either an update to core (of which there are a few now), or from a different source, such as the charm store. [23:20] oh yeah for sure - I think I marked that was as low priority [23:20] which ticket? [23:21] https://bugs.launchpad.net/juju-gui/+bug/1124583 [23:21] <_mup_> Bug #1124583: Charm list should be an autocomplete result list < https://launchpad.net/bugs/1124583 > [23:21] yep low [23:21] hmm.. yeah. it was originally an auto complete list.. way back when.. [23:22] hazmat, Was there just a cs list to consume? [23:23] Makyo, no it was an auto complete yui datasource hooked up directly to the charm store api [23:23] hazmat, Ah, cool. [23:23] ahh - see I was thinking of using it as a filter not for polling [23:24] I've used it with a table with about 500 records before and it was very fast [23:24] but there comes a point where the overhead of the initial load is too much [23:25] here is an example http://yuilibrary.com/yui/docs/autocomplete/ac-filter.html [23:25] hatch, revision 19 app/views/search.js [23:26] hatch, btw qbzr is a really nice gui on all the bzr commands, recommended. [23:26] hmm I'll have to look into this qbzr [23:27] ahh I see how you did that [23:27] have a good one.. i'm out for the day [23:27] you too cya! [23:28] hazmat, ciao