=== kadams54 is now known as kadams54-away
[20:58] <thumper> storage_test.go:147:
[20:58] <thumper>     c.Assert(info, jc.DeepEquals, expect)
[20:58] <thumper> ... obtained state.FilesystemAttachmentInfo = state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true}
[20:58] <thumper> ... expected state.FilesystemAttachmentInfo = state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true}
[20:58] <thumper> ... mismatch at .ReadOnly: unequal; obtained true; expected true
[20:58] <thumper> WTH?
[21:22] <fwereade> menn0, offhand, why does envStateCollection reject bson.M queries?
[21:23]  * menn0 has to look at the code
[21:24] <thumper> fwereade: did you see that error above?
[21:24] <fwereade> menn0, I think it's just a "nobody uses bsom.M queries" unless you know different
[21:24] <fwereade> thumper, huh
[21:24] <fwereade> thumper, that's ...interesting :/
[21:24] <thumper> yeah...
[21:24] <menn0> fwereade: I /think/ it was that they weren't being used so YAGNI
[21:25] <fwereade> menn0, cool
[21:25] <menn0> fwereade: there's no technical reason they couldn't be supported
[21:25] <fwereade> menn0, yeah, I've already written it :)
[21:25] <menn0> fwereade: map based queries are slightly finicky/dangerous anyway
[21:25] <menn0> fwereade: b/c of field ordering
[21:25] <fwereade> menn0, just thought I'd better check there wasn't a good reason
[21:26] <fwereade> menn0, hmm, can it subtly change complex queries?
[21:27] <menn0> fwereade: more that a query might not used a query if the field order in the query doesn't match
[21:27] <fwereade> menn0, I've tended to use bson.D out of habit, but .Ms are often that tiny bit cleaner to write so I've started using them a bit
[21:27] <menn0> fwereade: might not use an INDEX
[21:27] <fwereade> menn0, ahhhhh
[21:27] <menn0> sorry... haven't had my second coffee
[21:28] <menn0> I agree .M's are much nicer to write and read
[21:28] <menn0> you just have to be a little more careful
[21:28] <fwereade> menn0, anyway, I did not know that, can you point me to an example/doc/something?
[21:29] <fwereade> menn0, apart from anythinng else this likely means I've been writing my .Ds in a dumb order, because I don;t know what a good one is
[21:30] <menn0> fwereade: sorry, ignore what I said about indexes
[21:30] <menn0> fwereade: i'm being dumb
[21:30] <menn0> fwereade: i'm was misremembering this: http://devblog.me/wtf-mongo (first section)
[21:30] <menn0> fwereade: .M's are only really a problem if you're trying to exactly match a embedded document
[21:31] <menn0> fwereade: which we rarely/never do
[21:31] <fwereade> menn0, ah, ok, cool
[21:31] <menn0> fwereade: so using .M's is almost always fine
[21:31] <fwereade> menn0, I suppose I also don't know how it handles repeated names, so a conversion from D to M could be fun if they were significant
[21:32] <menn0> fwereade: do we do that?
[21:33] <fwereade> menn0, not as far as I'm aware, but I do the opposite in the M-handling because it seemed most conveniennt (and should be safe ;))
[21:33] <menn0> fwereade: yep, sure
[21:33]  * menn0 slinks away to make another coffee
[21:34] <fwereade> menn0, waigani, thumper: by the way I have a question on http://reviews.vapour.ws/r/2078/ that you might collectively know the answer to
[21:36] <fwereade> namely how exactly should cleanupsC interact with env destruction?
[21:36] <menn0> fwereade: cleanupsC was removed at runtime? that rings a slight bell, and also sounds like a terrible idea
[21:36] <fwereade> menn0, it was pretty clearly accidental
[21:37] <fwereade> menn0, foo := multiEnvCollections; foo.Remove(cleaupsC)
[21:37] <fwereade> menn0, can't even remember if it was in code or in test
[21:37] <menn0> fwereade: that does ring a bell
[21:37] <fwereade> menn0, either way I raged momentarily and moved on ;)
[21:37]  * menn0 checks for that code
[21:38] <fwereade> menn0, it's somewhere in the red in that review, I'm pretty sure
[21:38] <menn0> fwereade: found it. it's in a test.
[21:39] <menn0> fwereade: oh... and in implementation
[21:39] <fwereade> ha :(
[21:39] <menn0> there was a func which returned a copy of the multiEnvCollections but without cleanupsC
[21:40] <menn0> / newEnvAliveColls returns a copy of multiEnvCollections minus cleanupsC.
[21:40] <menn0> / This set is used to check if a txn needs to assert that there is a live
[21:40] <menn0> / environment be inserting docs.
[21:40] <menn0> func newEnvAliveColls() set.Strings {
[21:40] <menn0> 	e := set.NewStrings(multiEnvCollections.Values()...)
[21:40] <menn0> 	e.Remove(cleanupsC)
[21:40] <menn0> 	return e
[21:40] <menn0> }
[21:40] <fwereade> that's the one
[21:40] <fwereade> d} and move on, deal with the fallout later :)
[21:41] <menn0> it was used to decided whether or not to the assertion for env aliveness should be added to a txn.Op
[21:41] <fwereade> oh wait that one's ok
[21:41] <menn0> for cleanupsC it shouldn't I guess
[21:41] <fwereade> yeah I have a similarly vague understanding of maybe why we might want to do that sometimes but I'm very vague
[21:42] <fwereade> I think it's ok to insert into cleanups when an env is dyinng
[21:42] <fwereade> menn0, but I don't see why we should preserve cleanups when we nuke env docs
[21:42] <fwereade> menn0, that was either happening or I briefly hallucinated it was happening
[21:43]  * fwereade is if nothing else a reliable narrator </straight-face?
[21:43] <menn0> fwereade: it seems like what you've done with ignoreInsertRestrictions covers that previous case
[21:44] <menn0> fwereade: (although I would consider calling it something like allowInsertWhenEnvNotAlive)
[21:45] <menn0> fwereade: i'm not sure about this either. I haven't done much with cleanups. waigani, cherylj and thumper probably know more than me.
[21:45] <menn0> fwereade: where do you see code that preserves cleanups when an env is nuked?
[21:53]  * thumper was reading scroll back
[21:53] <thumper> I'm not fully caught up yet
[21:53] <waigani> menn0, fwereade: cleanupsC is part of the muliEnvCollections set - so it gets removed along with the others - as the last step of destroying an environment
[21:54] <thumper> school hols, and the girls are wanting to play with my new star realms deck
[21:54] <thumper> a little time teaching them the rules may mean many hours of freedom
[21:54] <waigani> haha
[21:58] <fwereade> thumper, nice :)
[22:01] <fwereade> thumper, menn0: it's quite possible all I saw was that it wasn't immediately certain whether the removal code in the test would run before or after any other tests that might depend on its presence or otherwise
[22:41] <thumper> wallyworld: we should chat when you have a minute or two
[22:41] <wallyworld> thumper: sure, give me 5?
[22:41] <thumper> ack
[22:51] <wallyworld> thumper: 1:1?
[22:52] <thumper> yep, there shortly, just writing something
[23:48] <waigani> thumper: your bool problem, is the struct being written to/read from mongo?
[23:49] <waigani> thumper: from the mgo docs: "Bools are converted to numeric types as 1 or 0 - Numeric types are converted to bools as true if not 0 or false otherwise"
[23:49] <waigani> thumper: maybe ppc stores the bools in a weird way
[23:53] <waigani> fwereade: ping