[00:02] Making 1000 units is fun and easy in the in-memory GUI :-) [00:03] Now I have 5000! [00:03] It's big [00:03] haha [00:03] * hatch waits for it to crash [00:03] :-) I was wondering about that. [00:03] I'll try 10000 [00:04] still ok [00:04] really big boxes [00:04] lol [00:05] I have a chromium browser process using 825.5 M. Maybe that's it? I'll make 30000... [00:06] hahahaha [00:07] no, it was the one using 400M, 556M now [00:07] and that's a double database [00:08] one for in-memory juju, one for the GUI side [00:10] that's pretty good [00:10] 46000 units total [00:10] lol - I would be worried that the ws would be very bogged down trying to communicate that many changes [00:11] yeah [00:11] that's the bigger concern I think [00:11] well and the svg rendering [00:11] nah [00:12] we're talking units not services [00:12] I only have four services [00:12] ohh ok [00:12] the biggest use case we've heard of is about 14 services [00:12] and we expect to nolonger support > 30 [00:12] s/nolonger/not/ [00:13] woah ...did you just edit that line? [00:13] hatch how can I get your LGTM. You want me to push, even with the merge, and point out what I changed? [00:13] * hatch just entered the danger zone I think [00:13] oh no I'll just add it [00:13] hatch, that's your irc client. It probably honors the vi style substitutions [00:14] I said s/nolonger/not/ [00:14] and it did what I asked :-) [00:14] hahaha wow [00:14] but over the wire it is still as I sent it [00:14] I thought I was going bonkers [00:14] originally [00:15] well, no guarantees for not going bonkers :-) [00:15] haha so true [02:53] chome devtools remote debugging is so cool [03:02] hatch: agreed [03:02] I need to set it up actually though still. [03:05] I messed around trying to solve these android bugs for a while this afternoon - found what caused it to fail in about 1min after setting that up [03:05] haha [03:05] no idea how to fix it yet [03:05] but found the root cause :) [03:05] lol, well knowing wtf is broken is half the battle :) [03:06] I'm too tired to think straight but we should look at https://bugs.launchpad.net/juju-gui/+bug/1158613 first thing in the morning [03:06] <_mup_> Bug #1158613: timestamp handling is not TZ aware < https://launchpad.net/bugs/1158613 > [03:06] poor huw in australia can't land a branch due to a bad test around timezone conversion lol [03:06] ugh I spent months working on timezone aware date stuff and swore i'd never do it again [03:06] apparently I didn't swear loud enough [03:06] lol [03:06] lol, then you never saw this ... [03:10] * hatch has been waiting impatiently for the reveil [03:10] reveal even [03:10] reveal? [03:10] I was waiting for you to link to something [03:11] :) [03:11] the bug above? [03:11] no some library that solved timezone issues in javascript [03:11] oh no, just the bug comes about due to his browser/timezone saying the date is the 10th, but the test thinks it should be the 9th [03:11] so he can never pass the tests [03:11] and thus lbox denies him [03:12] oh right - because the test doesn't specify timezone [03:12] right [03:12] so when it's not past bedtime I'll look I guess at what the code does vs the test does and see what needs to get updated [03:13] just find it funny the poor guy can't land a branch because of his TZ [03:13] or put it up for code review even [03:13] lol see timezones-the-devil [03:13] http://i10.photobucket.com/albums/a121/Elvislover01/Elvislover03/TheWaterboy.jpg [08:59] morning fwereade__, thanks for your review [08:59] frankban, heyhey [08:59] frankban, helpful I hope? [09:00] fwereade__: absolutely [09:01] fwereade__: re "you'll need to be able to map from entity name back to collection/_id", can I assume coll/_id == entityName.split('-') and then coll += 's'? [09:01] fwereade__: do we have that kind of convention? [09:02] frankban, hmm, I'm not sure we do [09:02] frankban, we *might* [09:03] frankban, but it is not something I have thought about consciously [09:03] fwereade__: it seems fragile, except if there is a strong convention in that sense [09:03] frankban, indeed [09:04] frankban, probably best to make it explicit [09:06] fwereade__: are you thinking about two functions, probably living in state, e.g. makeEntityName(id, coll string) string and parseEntityName(name string) (string string error)? [09:09] fwereade__: and maybe a map that maps collection names to entityName prefixes [09:10] frankban, I think you only need the second function for now [09:11] frankban, but, yeah, it probably deserves to be a top-level (but unexported) function in state [09:12] fwereade__: ok. so that function will explicitly use a map[entityname-prefix]coll-name, right? [09:17] frankban, implement it as it pleases you to do, I just care that it's in one place and explicit of purpose [09:17] fwereade__: cool, thanks === bcsaller_ is now known as bcsaller [13:45] bcsaller, I'm ready to talk any time. I have my vpn up and am staring mutely at the most recent failure [13:45] but no rush at all :-) [13:45] gary_poster: thats a good place to start :) I can join the chat in a second [13:47] cool [13:47] gary_poster: in chat when you're ready [14:02] good morning [14:03] hatch: morning, comments for you in the review. Let me know if anything doesn't make sense. :) [14:03] okee [14:06] rick_h_ thanks - what I meant about that check in the setter was if somehow it gets passed in "@#$%" it will still pass your check and then output NaN [14:06] so the only thing it pretects from is empty strings [14:06] protects [14:06] and undefined I guess [14:07] hatch: ah gotcha. I mean these are coming from a known source. I don't know it's worth going crazy on it. I guess I can run through Y.Lang.isString || Number ? [14:08] well I would just dump the check all together - like you said, it's coming from a known source, and if it's ok if it has NaN/undefined as a value then it really doesn't matter [14:08] hatch: cool [14:10] hehe Url vs URL - that one has also always bugged me, I can't decide which one I like better - jcsackett [14:10] :) [14:10] I prefer lower because it starts to look too constant-y for my tastes, but it's a preference thing. Don't want to get hung up on it [14:11] rick_h_: yeah, it's not a big deal. my english major side jumped out and said "that's an acronym!". feel free to ignore the english major side. :-P [14:12] yay no more writeonce [14:14] rick_h_ I didn't know about the linter causing issues on named methods like that [14:14] thats...lame [14:15] hatch: yea, I guess I can move the callbacks into methods on the class but seemed...unnecessary [14:16] yeah I'm going to say that I THINK the preferred way is to specify a string for the fn name in the class to promote lazy loading the attributes [14:16] but I'm not sure the specifics on that right now [14:17] I mean, it doesn't apply at all in this situation [14:17] :) [14:21] gary_poster: wrt https://bugs.launchpad.net/juju-gui/+bug/1158613 would you prefer we build the string that it's supposed to look like in the test? [14:21] <_mup_> Bug #1158613: timestamp handling is not TZ aware < https://launchpad.net/bugs/1158613 > [14:22] hatch, yes [14:22] make sense to you, hatch? [14:23] yep that makes the most sense if we want to display the date in their local timezone [14:24] cool [14:30] jujugui call now? [14:30] yup === benji___ is now known as benji === matsubara_ is now known as matsubara [15:05] rogpeppe, any idea about these test errors in trunk? http://pastebin.ubuntu.com/5637181/ [15:07] teknico: something to do with the recent stuff around version.Current, i think. you're running quantal, presumably? [15:07] rogpeppe, yep [15:13] teknico: looks like it's been broken not that long ago. there's no test image data for quantal 386 [15:14] teknico: this should be fixed very soon. [15:14] rogpeppe, great, thanks [15:34] frankban: can you provide a reference in juju-core where your errors.New trick is used and checked? [15:40] bac: my code changed so I didn't use that technique directly. however a quick search for errors.New gave me this example: ErrSilent in cmd/cmd.go [15:41] gary_poster: you asked me to teach you how to do remote debugging - https://developers.google.com/chrome-developer-tools/docs/remote-debugging this does a better job than I caould :D [15:42] could* damn I can't talk today [15:42] hatch, ok awesome thanks :-) [15:42] if you run into issues then maybe I can help debug but as far as a step by step guide goes it's pretty awesome [15:48] frankban: sorry, but my internet dropped out after i sent you that request. if you posted something could you post it again? [15:48] bac: my code changed so I didn't use that technique directly. however a quick search for errors.New gave me this example: ErrSilent in cmd/cmd.go [15:59] thanks frankban [16:16] gary_poster what date format are we using? ISO 8601? [16:16] YYYY-DD-MM [16:17] er [16:17] typically yyyy-mm-dd hatch [16:17] YYYY-MM-DD [16:17] y [16:26] anyone looking for a break to do a small review? https://codereview.appspot.com/7722045/ [16:28] hatch: looking [16:28] thanks [16:36] one more?? bueller....bueller? [16:42] looking hatch [16:45] why thank you === deryck is now known as deryck[lunch] [16:49] wrt to the jenkins tests we should ideally execute juju with verbose options and stdout/stderr captured so we have a bit more context than cmd failed [16:49] oh believe me [16:49] we've tried [16:49] ;) [16:50] jenkins is all like 'debug output? - NO!' [16:50] jenkins isn't the issue .. [16:50] its the way shelltoolbox is being used along with the cli args to juju [16:51] jenkins is clearly capturing the traceback from shelltoolbox.. but the underlying output isn't being sent back [16:51] ohh [16:51] hatch: here is a diff that will remove the irritating message from the end of the gjslint output: http://paste.ubuntu.com/5637488/ [16:52] benji: awesome :) [16:52] (it also makes the file name line number messages nicer, I (and others I assume) have tools that interpret file locations like those) [16:52] it's a bit of a hack, but it should be good enough [16:52] added a card for capturing useful output on testing [16:55] oh great [16:58] benji, thank you :-) [16:58] hatch LGTM with changes [16:59] * gary_poster goes to eat something before calls [16:59] thanks [17:29] bcsaller: do you have some time today to give me a runthrough of how the d3 and yui events are set up? [17:30] hatch: yeah, wanna say in 10 minutes in chat? [17:30] sounds good to me [17:30] I can't even get the popup to display by simulating the click right on the service because it's being prevented somewhere so a guide would REALLy help :D === matsubara is now known as matsubara-lunch [17:41] hatch: sounds like you have a call with gary now [17:42] yup sorry :) [18:06] I'm at 1.5kloc diff and only a third done. This branch is getting out of hand. [18:06] lol === deryck[lunch] is now known as deryck [18:07] bcsaller: ok all done, meet in guichat? [18:08] hatch: heading there now [18:18] bac: ping [18:19] hi rogpeppe [18:19] bac: just looking at the GetEndpoints proposal [18:19] me too === matsubara-lunch is now known as matsubara [18:19] bac: i'm just wondering why it's not just ServiceCharmInfo [18:20] bac: returning the same thing that CharmInfo does for each service [18:20] * bac looks at CharmInfo [18:20] bac: essentially it looks like you're reconstructing almost all of the information within the charm metadata [18:22] rogpeppe: it is a subset and we want the ability to get for all services at once, rather than having to make multiple calls [18:22] bac: in fact... i'm wondering if something that simply returned the charm url for each requested service might be better. [18:22] bac: then you can call CharmInfo for each unique url found [18:22] rogpeppe: also, i read my task to be to implement the same functionality hazmat had made available in pyjuju [18:23] bac: i'm concerned that there's considerable overlapping of functionality here without much gain that i can see [18:24] this is the get_service method? [18:25] hazmat: get_endpoints [18:25] bac: if we had a ServiceInfo call that returned a []struct{Name string; CharmURL string; other possible service info}, then i think that would be useful and then CharmInfo remains the definitive place to find endpoint info [18:27] hazmat: perhaps you have a different perspective on why get_endpoints is useful though? [18:27] gary_poster: is my branch going to have massive conflicts with your in-memory environment branch? [18:28] rogpeppe, it was an optimization, to prevent the gui having to fetch every charm's info separately, instead just getting interface prov/requires by svc [18:28] in a single call [18:28] otherwise you end up with the gui having to do N + N round trips (get service info, get charm info) [18:28] hazmat: if we have many services sharing the same charm, it might be a false optimisation :-) [18:29] hazmat: i don't think so. if we allowed ServiceInfo to return many services, then i think only 2 round trips are required. [18:29] benji don't know but mine landed [18:29] rogpeppe, that's not that common in general re many svcs using the same charm. possible though [18:29] hazmat: there's no problem with launching N API calls concurrently [18:30] gary_poster: oh, cool; in that case I've already merged it and didn't feel much pain :) [18:30] great [18:30] hazmat: although i suppose the js client interface might not have allowed for that possibility [18:30] rogpeppe, its not a question of feasibility but of latency till the info can be processed. [18:30] rogpeppe, it does [18:30] all commands are async to the gui [18:31] but i don't think there is a notion of launch N and wait till N has completed .. ie group deferred/promise [18:31] hazmat: it wouldn't be hard to do [18:31] hazmat: i'm not sure that two round trips is too bad, is it? [18:32] rogpeppe, you'll have to be a bit more explicit [18:32] rogpeppe, you saying a ServiceInfos method returning list of service infos and a CharmInfos method returning list of charm infos for a given set of charm urls? [18:33] hazmat: yes to the former, no to the latter [18:33] this info feeds into a gui endpoint solver which determines what the valid relations are for the env to allow for drag/drop relations with appropriate ui (disable invalid targest, etc) [18:34] hazmat: the former because it's good to be able to ask for all services. the latter because we don't want to enumerate all charms, and sending N CharmInfo calls at once should not be a problem. [18:35] rogpeppe, why the distinction? [18:35] ie what's wrong with CharmInfos([list-of-charm-urls]) [18:35] hazmat: why bother? [18:35] but thats okay with ServiceInfos returning a list? [18:36] hazmat: we need some way of finding out all the current services [18:36] hazmat: but i don't think we need a way to find out all charms in the State. [18:36] rogpeppe, it was parameterized.. not all in the state.. all in use by current services [18:37] but paramterized so the gui can just fetch those it doesn't hvae info for [18:37] the notion also grows more murky as you consider things like upgrades [18:37] you need the service watch to inform on charm changes [18:37] hazmat: yes, it will (and actually does currently) [18:37] cool [18:38] hazmat: that's why i see CharmInfo as more important than GetEndpoints [18:38] hazmat: it seems right that the GUI (as well as the state) keeps a notion of what charms it currently has information about [18:38] hazmat: and invokes CharmInfo for any it doesn't [18:39] that's seems okay.. bac the client side implementation can basically keep the same interface and internally fetch for what it doesn't have, invoking callback when complete. [18:40] hazmat: in fact, that's another reason why GetEndpoints isn't that useful - the AllWatcher will tell us about all current services [18:40] that's not its purpose.. [18:41] hazmat: isn't that how the GUI finds out about everything to start with? [18:41] its purpose is to determine the endpoints when the allwatcher fires and the service set changes [18:41] rogpeppe, yes the gui uses the delta stream to populate. i was referencing the method being discussed.. get_endpoints [18:42] rogpeppe, hazmat: so, in juju-core GetEndpoints is thrown away. do we then need new APIs to provide the required information or do those exist already? [18:42] hazmat: yes, so the service set changes - we see the new charm urls and fetch information for them, which gives us the endpoints associated with the services, no? [18:42] bac: i *think* you already have all you need [18:42] rogpeppe, yes, that's fine the gui client side go implementation can implement this ontop of the primitives [18:42] namely CharmInfo(charm_url) [18:43] hazmat: yup [18:44] bac, so effectively on get_endpoints in the go env impl client side.. you'll call CharmInfo(charm_url) for any services known that don't have charm info fetched, and then flatten that metadata back into provides:[interfaces], requires:[interfaces] [18:44] and then invoke the callback for the result, that should satisfy the interface for the valid endpoint solver. [18:44] bac: sorry to push back on this (and your implementation was fine!) but i do think that GetEndpoints isn't necessary, and i'd like to keep overall the surface area small if possible. [18:45] hazmat: what is the equivalent of get_endpoints() [no services specified]? where will i get the list of services we're interested in? [18:45] bac, if none are spec'd its whatever are known to the gui [18:45] rogpeppe: makes sense. wish we'd talked before the work was done [18:46] hazmat: yeah, ok [18:46] bac, ic the env impl doesn't have a client db handle to determine that? is that the concern? [18:46] hazmat: don't know yet. not that familiar with it and will have to look [18:47] bac: yes, sorry. perhaps we should have a meeting about upcoming proposed API additions, so we can find issues like this earlier [18:47] bac you can walk up the parent tree of event targets... although explicit component lookup would be nicer. [18:48] bac: i'm really sorry; i know how frustrating it is! [18:48] bac, I guess this is where you write the JS version and then we steal it for the in-browser-memory Python version too. [18:48] * rogpeppe has got to weekend time [18:48] g'night all [18:48] bye rogpeppe [18:58] have a great weekend all [19:01] Makyo: you mentioned yesterday that you implemented the two finger touch - mind pointing me to where that's done? [19:02] I'm slowly making progress on this :) [19:02] hatch, D3 implements that. Just a sec. [19:03] oh alright [19:03] https://github.com/mbostock/d3/blob/master/src/behavior/drag.js [19:07] thanks [19:13] OOOoo [19:13] * hatch takes one step closer to a solution [19:21] ok I found the problem [19:21] unfortunately a sollution won't be ideal [19:27] ok it looks like chrome android doesn't convert the touchstart to a click like firefox does - AND touchstart doesn't bubble on svg elements either [19:27] so it's kind of like a double edged sword [19:27] I swear, firefox is a piece of crap [19:28] firefox is doing it properly ;) [19:28] THIS time [19:28] lol [19:29] I was speaking apropos of my recent experiences. [19:30] ahh - time for "works best in ..." images again [19:30] haha [19:30] Boo Yeah! [19:30] got er fixed...it's ugly as sin though so I'll have to figure a better way haha [19:58] bcsaller: is there a way I can go from the svg .service element and get the object instance associated with it? [19:58] essentially I need to manually build the 'box' param in serviceClick [19:59] hatch: chat? [19:59] sure [20:03] * bac -> early dog walk. bbiab. [20:23] ok going to take lunch [21:11] bak [21:20] sooo anyone have any big plans for the weekend? [21:28] stop being sick, & actually sleep through the night [21:29] pfft a full nights sleep is WAY overrated [21:43] so close to getting this to work [21:49] MOHOHOHAHAHAHAHA [21:50] * hatch yells at chome android "AND STAY DOWN!" [21:56] bcsaller: you kickin around still? [22:17] jcsackett: is this branch ready for review? [23:07] hatch how does 0.0.0.0 fail on your machine? [23:08] localhost points to the 'localhost' that I need not to 0.0.0.0 [23:08] right so local host reeves to 127.0.0.1 right? [23:09] nope, totally different internal ip [23:09] and 0.0.0.0 will bind to all network addresses and work on 127.0.0.1 [23:09] hmm and 0.0.0.0 doesn't bind to this address? [23:10] lemme see [23:11] nope [23:12] actually I'm not even sure what it's binding to [23:12] I should look into that [23:12] ugh what have you got set up :p [23:12] I used to be a contractor - who knows what kind of setup I have screwed up here lol [23:13] generally you use the 0s trick to bond both local and external addresses so you can test from remote machines like IE in vm oe windows machine. [23:14] so jcsackett 's change was probably done to run tests from another machine. but it shouldn't break local host. [23:14] ahh I gotcha - yeah see I have localhost pointing to a specific local ip [23:15] so if that gets changed to a real ip then it breaks [23:16] hmm so normally changing local host can cause issues. surprised you've got it changed up. [23:17] but yea. it's intentional but usually not an issue so not done with any intent to change how things work. [23:17] yeah I figured it was committed by accident that's why I commented [23:17] well and that it'll break the first time i use it haha [23:17] but i should look into what's going on with 0.0.0.0 [23:18] very handy trick to know [23:20] I was once working on three different apache/php based projects at once [23:20] just imagine the headache setting THAT up [23:20] ugh [23:21] heh used to do php so I understand [23:21] the best part about not doing php - is not having to deal with apache for that stuff [23:22] being able to create your own server at whatever port you want is a huge plus [23:24] so just so I get this right, you're saying that 0.0.0.0 should be pointing to any of the ip's that the machine thinks it has [23:25] so 0.0.0.0 should be pointing to 127.0.0.1 [23:27] yeah I definitely broke something somewhere [23:27] well you know what that means....time for a new computer....obviously!