[00:01] <thumper> davecheney: ta
[00:49] <thumper> yay VMs
[00:49] <thumper> fired up a clone for the live tests
[00:49] <thumper> while running normal ones on another
[00:57] <thumper> davecheney: ok so some of the live tests are failing...
[00:57] <thumper> davecheney: how often do they fail for you?
[01:53] <thumper> davecheney: can you ping me when you're back plz
[02:10] <thumper> hi jam
[03:02] <thumper> hi davechen1y
[03:04]  * davechen1y blows a kiss
[04:50] <jam> hi thumper
[04:50] <jam> 6am is usually a bit early for me :)
[05:06] <bigjools> I have several maps of string to array of strings and I want something that gives me those sorted by the map keys.  How do I do it in Go?
[05:07] <davecheney> bigjools: you need to extract the keys into a []string
[05:07] <davecheney> then sort the string
[05:08] <bigjools> how do I keep the values of the keys?
[05:08] <davecheney> then using that sorted []string, use that as a key into your map
[05:08] <bigjools> what map?
[05:08] <bigjools> I have many maps
[05:08] <davecheney> bigjools: ok, i'll step back and let you explain the problem
[05:08] <davecheney> i mistook your previous sentence
[05:08] <bigjools> I should be more specific :)
[05:09] <bigjools> I have a http.Requesl
[05:09] <bigjools> argh
[05:10] <bigjools> I have a http.Request.Query()
[05:10] <bigjools> arse, hang on
[05:11] <bigjools> which returns Values
[05:11] <davecheney> bigjools: maybe launchpad.net/goamz/ec2/sign.go will be of use
[05:11] <bigjools> which is a map[string][]string
[05:11] <bigjools> we need to ultimately have a string containing "name:value,name:value" ... sorted on name
[05:12] <bigjools> this is 2 lines of Python but in Go we're struggling :/
[05:12] <davecheney> yes, Go does not provide the syntactic sugar for list comprehenions
[05:12] <davecheney> er, whatever
[05:13] <davecheney> bigjools: what happens when you have this
[05:13] <davecheney> map["something"] = []string { "foo", "bar" }
[05:14] <davecheney> what does that look like when it is encoded
[05:15] <bigjools> I like comprehenions :)
[05:17] <bigjools> davecheney: ok we have a handle on this I think, thank you
[05:20] <davecheney> bigjools: http://play.golang.org/p/9k54JbkHsG
[05:20] <davecheney> ^ a start, maybe ?
[05:22] <bigjools> davecheney: awesome, good start.  Do you know if sort is case insensitive?
[05:22] <bigjools> or can be made so
[05:22] <davecheney> that ist he default sort
[05:22] <davecheney> i'm sure it is case sensitive
[05:23] <bigjools> I forgot to say that we need to lower case the map keys in the output string
[05:23] <davecheney> bigjools: are you doing this to sign a request ?
[05:23] <bigjools> davecheney: it's part of a signing, yeah
[05:23] <bigjools> it's a rather complicated signature :/
[08:20] <rogpeppe> mornin' all
[08:21] <dimitern> rogpeppe: morning
[08:22] <rogpeppe> dimitern: hiya
[08:24] <jam> bigjools: I realzie this is late, but is this correct: http://play.golang.org/p/xtOOa3bDno
[08:24] <fwereade> rogpeppe, dimitern, jam: heyhey
[08:24] <jam> h
[08:24] <jam> hi fwereade
[08:24] <rogpeppe> fwereade: yo!
[08:24] <dimitern> fwereade: hiya
[08:24] <rogpeppe> jam: hiya
[09:41] <fwereade> just stepping out for a bite of breakfast
[11:30] <dimitern> wallyworld, mgz: standup?
[11:30] <mgz> hey
[11:35] <dimitern> jam: ping
[11:37]  * TheMue is afk, lunchtime, biab
[12:39] <rogpeppe> fwereade: any chance of a review of https://codereview.appspot.com/7815044/ ?
[12:40] <rogpeppe> fwereade: i'll be happier if you've reviewed at least one of these branches :-)
[12:40] <rogpeppe> fwereade: otherwise i feel a bit out on a limb
[12:41] <fwereade> rogpeppe, I'm just finishing up a good solid morning of hackery, I'll be on reviews very soon
[12:42] <rogpeppe> fwereade: cool, thanks
[12:42] <rogpeppe> fwereade: nice to hear BTW.
[12:42] <rogpeppe> fwereade: (the hackery that is)
[12:45] <fwereade> rogpeppe, am I right in thinking that TestBootstrapAndDeploy is still "meant to be" failing at remove-unit time?
[12:45] <rogpeppe> fwereade: yeah
[12:45] <fwereade> rogpeppe, well cool :)
[12:46] <rogpeppe> fwereade: i got some way into fixing the test, but it didn't work, and i haven't got back to it since
[12:46] <rogpeppe> fwereade: if you wanna take a look, i'll send you the branch
[12:46] <fwereade> (ie, cool, I haven't broken anything ;p)
[12:46] <rogpeppe> fwereade: i *really* want to fix that bloody live test!
[12:47] <fwereade> rogpeppe, I'll grab the branch, but I can't promise to focus on it any time soon
[12:47] <rogpeppe> fwereade: maybe you could have a look to check for obvious wrongness anyway
[12:49] <rogpeppe> fwereade:  bzr+ssh://bazaar.launchpad.net/~rogpeppe/juju-core/223-jujutest-fix-deploy-test/
[12:49] <fwereade> rogpeppe, cheers
[13:15] <jam> dimitern: yes?
[13:15] <dimitern> jam: that was before you appeared in the standup
[13:16] <jam> rogpeppe: what is "fix rpc test failure in trunk" on the Kanban board. Is that https://code.launchpad.net/~rogpeppe/juju-core/213-rpc-test-timeouts/+merge/148162?
[13:16] <jam> I'm just noticing that the review lane went red, but I don't actually know which one that is.
[13:16] <rogpeppe> jam: one mo, i'll just check
[13:16] <fwereade> jam, sorry, that was me
[13:16] <fwereade> jam, I accidentally did too much
[13:17] <fwereade> jam, I am in review mode now :)
[13:17] <jam> fwereade: yeah, I see you have 5 constraints things in the queue
[13:17] <fwereade> jam, hopefully they're reasonably clear
[13:18] <rogpeppe> jam: jeeze, i can't remember!
[13:18] <rogpeppe> jam: i'm pretty sure i fixed that ages ago
[13:19] <jam> rogpeppe: yeah, I think so, I think it just didn't get moved over9
[13:19] <jam> which is why I was checking.
[13:19] <rogpeppe> jam: and i don't *think* it was that CL
[13:19] <jam> rogpeppe: I don't see any RPC test fix CLs in https://code.launchpad.net/juju-core/+activereviews
[13:19] <mgz> rogpeppe: can't find anything else that looks like it...
[13:19] <rogpeppe> jam: note to self: write better descriptions and link 'em to the CL in question!
[13:20]  * rogpeppe wants an ls -lt on branches
[13:20] <jam> rogpeppe: certainly I just reviewed "Write API design" though maybe that landed now?
[13:20] <jam> rogpeppe: 'bzr branches' ?
[13:20] <rogpeppe> jam: -t ?
[13:21] <jam> some people have written plugins to check if branches have been merged, I could dig one of them out for you
[13:21] <jam> so it does the recursive "find all branches not merged into X"
[13:21] <jam> well, find all branches merged into X and prune them.
[13:21] <rogpeppe> jam: that is: i want to see them in time-last-modified order.
[13:21] <rogpeppe> jam: that plugin would be useful too though
[13:21] <rogpeppe> pwd
[13:26] <rogpeppe> jam: i think this was the fix: https://codereview.appspot.com/7324048/
[13:36] <rogpeppe> anyone use bzr pipes here?
[13:44] <fwereade> rogpeppe, https://codereview.appspot.com/7815044/ has a question
[13:45] <rogpeppe> fwereade: looking
[13:45] <rogpeppe> fwereade: the worst that could happen is that the entries get seen again and ignored, i think
[13:46] <fwereade> rogpeppe, what happens if we remove an entity that was apparently never there?
[13:46] <rogpeppe> fwereade: it's a noop
[13:47] <fwereade> rogpeppe, ok, cool
[13:47]  * rogpeppe checks again to be sure
[13:48] <fwereade> rogpeppe, LGTM then assuming comment there
[13:49] <rogpeppe> fwereade: thanks.
[13:50] <rogpeppe> fwereade: BTW, although it isn't a problem if we remove an entiry that's not there, how do you see that happen with respect to the getAll/watch logic?
[13:50] <rogpeppe> s/happen/happening/ ?
[13:51] <rogpeppe> fwereade: oh, i see. ignore me.
[13:51] <fwereade> rogpeppe, I have become sensitised to such constructs ;)
[13:53] <rogpeppe> fwereade: the thing that isn't so great (although i'm not quite sure how to get around it) is that while we'll doing the getAll, we're not reading from the watcher channel, so we can stall other things.
[13:54] <rogpeppe> fwereade: perhaps i should start a goroutine that reads from in and aggregates the results into a slice that's processed after getAll has completed.
[13:55] <fwereade> rogpeppe, for now that feels like a good candidate for a comment, in case we see negative consequences later, but probably not worth the work right now
[13:55] <rogpeppe> fwereade: agreed
[14:05] <rogpeppe> dimitern: have you seen this? 245-allwatcher-state-backing
[14:05] <rogpeppe> dimitern: http://pastebin.ubuntu.com/5625282/
[14:05] <dimitern> rogpeppe: looking
[14:06] <dimitern> rogpeppe: i've seen similar while fixing the uniter tests in my last CL, but all was working fine - i run the tests 10 times ok
[14:43]  * rogpeppe is off for some lunch
[14:46] <frankban> dimitern: I see that failure every time, last one using revno 1013. go1.0.2 on quantal.
[14:51] <jam>  rogpeppe: that looks a bit like the failures thumper and wallyworld saw on Raring (consistent failures)
[14:51] <jam> but I thought they landed changes to fix it.
[14:51] <jam> I wonder if it might  have regressed things on Quantal/Precise?
[14:51] <fwereade> frankban, jam, trunk is fine on precise for me
[14:52] <fwereade> frankban, just in case, would you try removing $GOPATH/pkg/linux_amd64 and testing again?
[14:54] <frankban> fwereade: trying
[14:55] <jam> fwereade: confirmed. If I just run the worker/uniter tests directly everything passes for me on precise + go1.0.3
[14:55] <jam> (P itself only has go1)
[14:56] <dimitern> trunk is fine for me as well on quantal
[14:56] <dimitern> using go1.0.3
[15:02] <frankban> fwereade: same failures. I'll try upgrading go, how to do that (gophers ppa?), and what's the version you suggest?
[15:03] <fwereade> frankban, I'm on 1.0.2 and I *thought* that was what were were using
[15:17] <dimitern> fwereade: got a minute?
[15:23] <fwereade> dimitern, sure
[15:24] <dimitern> fwereade: i merged the changes, but u.SetCharmURL and u.SetCharm(old, removed now) assume some slightly different things
[15:25] <fwereade> dimitern, oh yes?
[15:25] <dimitern> fwereade: I'm fixing the tests now, but i'd like to look at carefully it after i propose
[15:25] <fwereade> dimitern, if the change is significant it's probably worth thinking it through before we hit the tests too hard... they might actually still be right ;p
[15:26] <dimitern> fwereade: i think i can sort it out, but not sure about one assert there
[15:27] <fwereade> dimitern, cool, let me know if you need anything
[15:29] <fwereade> dimitern, if lots of tests are broken, though, I think that is most likely to point at a problem elsewhere
[15:30] <dimitern> fwereade: not a lot, just a couple for now
[15:30] <fwereade> dimitern, ah, jolly good
[15:35] <rogpeppe> fwereade: i responded to your review. (https://codereview.appspot.com/7815044) i added a comment, but resisted some of the other suggestions. YMMV.
[15:40] <dimitern> fwereade: whoohoo! all passed! proposing :)
[15:40]  * fwereade cheers
[15:50] <fwereade> frankban, no joy?
[15:53] <rogpeppe> fwereade: i don't see why you mind about the length of a test timeout failure. if anything, i think we should increase the limit elsewhere, as a heavily loaded system may easily pause for 500ms.
[15:53] <rogpeppe> fwereade: (some tests have a 5 second timeout)
[15:53] <fwereade> rogpeppe, true enough, sgtm
[15:54] <rogpeppe> fwereade: cool. i wonder if we should have the short and long pauses as constants in testing somewhere actually. or as command line params.
[15:54] <fwereade> rogpeppe, not a bad idea
[15:55] <frankban> fwereade: no :-/ tried replacing quantal own golang-* (1.0.2) with gophers ppa golang-stable (same version), still the same failures. asked Matthew to run the tests in our branch, if they pass, then I further investigate on this problem of my configuration later
[15:55] <fwereade> rogpeppe, one for our Copious Free Time ;p
[15:55] <rogpeppe> fwereade: indeed
[15:55] <fwereade> frankban, sorry to hear that
[15:56] <dimitern> fwereade: https://codereview.appspot.com/7497047
[15:59] <dimitern> fwereade: if you can take a look specifically in u.SetCharmURL changes
[16:01] <dimitern> I'm off for today
[16:01] <dimitern> good evening all
[16:23] <frankban> fwereade: Makyo encountered the same failures in trunk. after increasing the timeouts in uniter_test.go (from 5 to 20 seconds and from 50 to 200 milliseconds) the tests pass in my machine (which is, apparently, quite slow :-/ )
[16:24] <fwereade> frankban, crikey
[16:25] <fwereade> frankban, I knew those tests were slow but they must be flat-out awful for you
[16:27] <rogpeppe> fwereade: how would you feel about moving the Constraints type out of state and into its own package?
[16:28] <fwereade> rogpeppe, +1
[16:28] <fwereade> rogpeppe, it's been itching at me once r twice in every branch
[16:28] <rogpeppe> fwereade: cool
[16:28] <rogpeppe> fwereade: because it resolves an import cycle problem that benji is having
[16:28] <rogpeppe> fwereade: (api/params wants to reference Constraints, but state imports api/params)
[16:29] <fwereade> rogpeppe, all the better then :)
[16:29] <rogpeppe> fwereade: indeed
[16:29]  * rogpeppe really really hates arbitrary timeouts in tests.
[16:31] <frankban> fwereade: the full suites takes about 3:30 minutes here
[16:31] <rogpeppe> fwereade: i'm thinking launchpad.net/juju-core/constraints, but launchpad.net/juju-core/state/constraints could work too.
[16:31] <fwereade> rogpeppe, I'd prefer top-level than inside state
[16:31] <rogpeppe> fwereade: cool
[16:35] <rogpeppe> fwereade: any suggestions for another noun other than Constraints in "constraints.Constraints" ? i haven't got a good one, but thought someone might.
[16:36] <fwereade> rogpeppe, I was having wicked thoughts of constraints.T, but I don't think it'd be popular
[16:36] <rogpeppe> fwereade: yeah, i was thinking about constraints.C
[16:36] <fwereade> rogpeppe, pondering constraints.Value
[16:36] <rogpeppe> fwereade: i thought of that too
[16:37] <fwereade> rogpeppe, verbose enough to read well, no more annoyingly bulky than the existing specifier
[16:37] <rogpeppe> fwereade: +1
[16:37] <rogpeppe> fwereade: and not annoyingly stuttery
[16:37] <fwereade> rogpeppe, cool
[16:37] <fwereade> rogpeppe, yeah
[18:14] <rogpeppe> fwereade: is there any particular reason not to use constraints.Value as the constraintsDoc?
[18:15] <fwereade> rogpeppe, I am reluctant to make the db document the same type as the document I expose via the api
[18:16] <fwereade> rogpeppe, I could maybe be convinced that we can swap in a new type when we need to
[18:16] <rogpeppe> fwereade: i'm not sure it's worth the cost of the separation. we already use external types in our entity documents.
[18:16] <rogpeppe> fwereade: (and that too)
[18:28] <rogpeppe> here's the next branch in the allWatcher branches: https://codereview.appspot.com/7650048
[18:28] <rogpeppe> reviews appreciated :-)
[18:30] <rogpeppe> time to stop. g'night all.
[20:46] <thumper> fwereade: hey, you around.
[20:52] <benji> OK intrepid developers, I have a new branch up for review that adds more to the API: https://codereview.appspot.com/7600044
[21:23] <fwereade> thumper, heyhey
[21:24] <thumper> fwereade: hey
[21:24] <fwereade> thumper, I'm not sure how clear I managed to be earlier
[21:24] <thumper> fwereade: we should chat
[21:25] <thumper> gimmie five though to fix these bugs
[21:29] <fwereade> thumper, sorry about that, the whole machine went into spasm somehow
[21:34] <thumper> fwereade: hangout?
[21:35] <fwereade> thumper, sure
[21:35]  * fwereade starts one
[22:17] <fwereade> morning davecheney
[22:20] <davecheney> fwereade: howdy
[22:20] <fwereade> davecheney, how's it going?
[22:21] <davecheney> good
[22:21] <davecheney> trying to get an env running on hp cloud
[22:21] <davecheney> also have a branch nearly ready for review that increases the delay time between mgo retries from *as fast as possible* to something we control
[22:21] <fwereade> davecheney, cool -- not *too* painful I hope?
[22:22] <davecheney> as always, testing is a problem
[22:22] <fwereade> davecheney, sweet, that was annoying me again just today
[22:22] <davecheney> esp as to do the delay, i'm working around mgo's built in retry logic
[22:22] <davecheney> which i'm assuming can't be changed
[22:23] <fwereade> davecheney, I don;t recall anything that would lead me to believe otherwise
[22:23] <davecheney> things in charm testing land are positive
[22:23] <davecheney> when ec2 plays ball charm-test and graph-test work
[22:23]  * fwereade cheers
[22:23] <davecheney> but ec2 continues to be unreliable inside its own network
[22:24] <fwereade> davecheney, any indications on whether hp cloud is any better?
[22:25] <davecheney> none yet
[22:25] <davecheney> see prtv message
[22:26]  * davecheney disappears for a quick bio break
[23:55] <davecheney> thumper: can i get your $0.02NZ ob my concerns about using floats for money, https://codereview.appspot.com/7693048/
[23:55] <thumper> sure...