[01:04] <davecheney> m_3: still on for lunch today ?
[01:04] <davecheney> m_3: that is more of a statement than a question, just confirming
[01:10] <m_3> davecheney: yup
[01:12] <davecheney> m_3: just sent you an email, do you like Thai hawker food ? Luksa and the like ?
[01:16] <m_3> sounds good... I'm easy
[01:17] <davecheney> m_3: groovy
[07:21] <fwereade_> mornings :)
[07:29] <davecheney> fwereade_: howdy
[07:29] <fwereade_> davecheney, heyhey
[07:30] <davecheney> things are looking up, we can bootstrap into other regions
[07:30]  * fwereade_ cheers
[07:30] <davecheney> and I'm just about to get the local ec2 test running
[07:30] <fwereade_> davecheney, sweet
[07:30] <davecheney> gustavo was supportive of moving the Provisioner into another package
[07:30] <fwereade_> davecheney, I spent most of the night hitting everything related to testing and zookeeper with an axe
[07:30] <davecheney> so i can import it into the local tests
[07:30] <fwereade_> davecheney, yeah, I saw
[07:30] <fwereade_> davecheney, hope he is of this change too
[07:31] <davecheney> fwereade_: looking for that race, or just because it deserved it
[07:31] <fwereade_> davecheney, duplicated bits and pieces everywhere, subtly inconsistent bits and pieces
[07:31] <fwereade_> davecheney, also a single monster test suite for almost everything in state
[07:32] <fwereade_> davecheney, the collective pain passed my threshold
[07:32] <fwereade_> davecheney, and it's the sort of thing I really *don't* want to do piecemeal
[07:32] <davecheney> fwereade_: excellent work
[07:33] <fwereade_> davecheney, any ad-hoc duplications I leave lying around will, according to the law of sod, be those that someone sees and copies next time they need to take to ZK, or use a State, or whatever ;)
[07:39] <davecheney> fwereade_: did you move zkSuite into juju-core/testing ?
[07:39] <davecheney> or are you planning too ?
[07:40] <davecheney> the zkSuite i refer to comes from cmd/jujud
[07:40] <fwereade_> davecheney, I'm planning to drop it and use juju-core/testing.ZkConnSuite for initzk, and juju-core/state/testing/StateSuite for the others
[07:41] <fwereade_> davecheney, just unpicking that bit right now actually :)
[07:41] <fwereade_> davecheney, neither of those exist yet, except this this tree ofc
[07:41] <davecheney> fwereade_: excellent, I hope it gets commited soon
[07:42] <davecheney> 'cos I need that to start a zk to back the provisioner for the local ec2 tests
[07:42] <fwereade_> davecheney, me too...
[07:42] <fwereade_> davecheney, ah, cool
[07:43] <fwereade_> davecheney, I'm not sure it will actually get proposed until you've gone to bed
[07:43] <fwereade_> davecheney, that said I hope it will before eod for me
[07:44] <fwereade_> davecheney, so if you do happen to see it over the weekend, and are able to give the bits that hit your code a once-over (and hopeful LGTM), I think it would help
[07:44] <fwereade_> davecheney, it's gong to be much too big for a single person to review it effectively, even though *most* of the changes are from splitting up state_test
[07:47] <davecheney> understood
[07:47] <davecheney> review backlog ... sigh
[08:11] <fwereade_> davecheney, cmd/jujud/main_test.go
[08:11] <fwereade_> davecheney, is it intentionally not in the main package?
[08:11] <fwereade_> davecheney, I thought you changed all those to be internal?
[08:12] <davecheney> let me check, that may have been an accident
[08:12] <fwereade_> davecheney, it looks as though that test isn't actually run any more
[08:13] <davecheney> sorry, that was an accident
[08:13] <davecheney> hmm, looking further
[08:13] <davecheney> i didn't touch main_test
[08:14] <davecheney> but it should be fixed
[08:15] <fwereade_> davecheney, cool, I'll pick thoe up with the one I'm doing
[08:16] <davecheney> ok, thanks
[08:17] <davecheney> I can do it too, but it'll be depending on my other services branc
[08:18] <fwereade_> davecheney, since I'm already hitting everything to do with testing I think it fits best with what I'm doing
[08:19] <davecheney> kk
[08:19] <fwereade_> davecheney, actually, do you have a few minutes to take a preliminary look at what I've done? assuming I haven't broken anything in the latest pass, I'll propose -wip in a couple of mins
[08:20] <fwereade_> davecheney, or will I be keeping you at work inappropriately? ;)
[08:21] <davecheney> fwereade_: yeah fire it off
[08:22] <fwereade_> davecheney, https://codereview.appspot.com/6348053
[08:23] <fwereade_> davecheney, testing/zk.go, and state/testing/testing.go, are at the heart of it all
[08:24] <fwereade_> davecheney, most of the stuff in the state package can otherwise be pretty much ignored for now, it's just test-moving
[08:24] <fwereade_> davecheney, so if you take a look at those, and how they affect the jujud tests, that would probably be most directly useful
[08:25]  * davecheney looks
[08:34]  * fwereade_ passes davecheney the goggles, and hopes they do something
[08:35] <davecheney> fwereade_: looks pretty good to me
[08:35] <fwereade_> davecheney, cool, thanks for taking a look :)
[08:36] <davecheney> you could probably split this into two changes, to reduce the sticker shock
[08:36] <davecheney> but 90% of the change is one liners in a file
[08:38] <fwereade_> davecheney, yeah, maybe I should do the state_test split separately
[08:38] <fwereade_> davecheney, bah :)
[08:38] <davecheney> i don't think it's worth it, this branch will probably take a few review cycles, so it's probably not saving much
[08:39] <fwereade_> davecheney, yeah, I must admit I'm not especially enthused by the idea, but the I wouldn't be ;)
[08:40] <fwereade_> davecheney, hmm, an idea
[08:40] <fwereade_> davecheney, state_test.ConnSuite should probably not be used anywhere near as much as it is
[08:41] <fwereade_> davecheney, if I move the tests that use zkConn directly out into their own zk-substrate-specific test it would probably be a good thing
[08:41] <fwereade_> davecheney, but that's surely one for a new CL
[08:44] <davecheney> fwereade_: stepping offline for a while, gonna see what is happening in the real world
[08:44] <fwereade_> davecheney, take care, have fun
[08:44] <davecheney> fwereade_: you too
[09:31] <fwereade_> TheMue, heyhey
[09:31] <TheMue> fwereade_: Hi
[09:39] <TheMue> fwereade_: Oh, update tells me to reboot. One moment.
[09:43] <TheMue> fwereade_: So, back again, just submitted the deleted-is-now-removed-change
[09:43] <fwereade_> TheMue, cool
[09:43] <fwereade_> TheMue, I'll merge that in a mo
[09:44] <fwereade_> TheMue, I have a hideous monster of a branch in progress
[09:44] <fwereade_> TheMue, but it does remove a whole bunch of duplication across the tests that hit state and/or zookeeper so hopefully it won't be too controversial
[09:44] <fwereade_> TheMue, do you have anything else likely to land soon?
[09:44] <TheMue> fwereade_: I'm still porting the firewall, it uses multiple watchers. And now I've got a method with a callback inside a callback. :(
[09:45] <TheMue> fwereade_: No, I'll need some time.
[09:45] <fwereade_> TheMue, cool
[09:45] <fwereade_> TheMue, an internal updates channel may be helpful if I've understood what you're doing correctly
[09:46] <fwereade_> TheMue, ie the main loop selects on w.subwatcher.Changes and w.updates
[09:47] <fwereade_> TheMue, and a separate goroutine for each additional watcher sends on w.updates for the attention of the main loop
[09:48] <fwereade_> TheMue, sensible/relevant?
[09:48] <TheMue> fwereade_: Maybe an approach, yes. I'll take a look how it matches. But it SGTM.
[09:49] <fwereade_> TheMue, if by callback-inside-callback you just mean consuming the initial event from a new watcher before sending it off on its own goroutine I think that's sensible and necessary
[09:56] <TheMue> fwereade_: I've got to get deeper in the code first, understanding what happens there today.
[09:57] <fwereade_> TheMue, SGTM, give me a shout if you see anything particularly surprising, I seem to have spent a disturbing amount of time thinking about this sort of problem recently
[11:53] <Aram> hey.
[11:54] <fwereade_> Aram, heyhey
[12:29] <TheMue> fwereade_: Could you please help me getting yield right?
[12:29] <TheMue> Aram: Hi btw
[12:29] <fwereade_> TheMue, I'll do what I can :)
[12:30] <fwereade_> TheMue, what's the problem?
[12:30] <TheMue> fwereade_: I understand it as a generator returning the yielded value with each call. So far no problem.
[12:30] <fwereade_> TheMue, but @inlineCallbacks is weird?
[12:31] <TheMue> fwereade_: But when the call to the generator function has a list as argument and inside the func this list is iterated and every time a yield, what do I get?
[12:32] <TheMue> fwereade_: And those inlineCallbacks too, yes. ;)
[12:32] <fwereade_> TheMue, not sure I follow the first bit, can you point me to the code?
[12:33] <fwereade_> TheMue, the idea of inlineCallbacks is that you repeatedly yield a Deferred, and the result of that Deferred is sent back into the generator once it's fired
[12:33] <fwereade_> TheMue, basically it lets you write callback-based code and kid yourself it's not really using callbacks
[12:34] <fwereade_> TheMue, so the critical thing is not to think of inlineCallbacks-decorated methods as being generators at all
[12:35] <fwereade_> TheMue, it's a creative and useful abuse of generators but that's not really a useful perspective from which to view them IMO
[12:37] <TheMue> fwereade_: OK, thx, a first hint. And forget my first sentence, I interpreted the indent inside firewall.py wrong.
[13:07] <TheMue> So, organized my checkup at the dentist on Monday morning. *dislike*
[13:25] <fwereade_> TheMue, Aram: I have the most horrifying CL known to man, just proposed at https://codereview.appspot.com/6348053
[13:25] <Aram> oh man
[13:25] <fwereade_> TheMue, Aram: it's explained in great detail on codereview
[13:26] <fwereade_> Aram, I hope that it moves us a significant step towards substrate-independent state testing, which is why I'm pointing it out to you in particular
[13:27] <fwereade_> TheMue, because it hits a lot of tests that you yourself wrote, I would particularly appreciate your feedback
[13:28] <TheMue> fwereade_: I'm already looking.
[13:29] <TheMue> fwereade_: Btw, I often read CL here, but I've been not able to find the long version of this abbrev. Could you help me?
[13:30] <fwereade_> TheMue, ChangeList, apparently :)
[13:30] <TheMue> fwereade_: Thought so, indeed. But it seemed too simple. ;)
[13:31] <TheMue> fwereade_: I'm knowing it as a change set.
[13:32] <TheMue> fwereade_: http://en.wikipedia.org/wiki/Changeset
[13:33] <fwereade_> TheMue, indeed
[13:33] <fwereade_> TheMue, seemed easiest to just adopt the preferred local terminology :)
[13:33] <TheMue> fwereade_: Yes, only wanted to know. Maybe there's a history behind it.
[13:51] <fwereade_> TheMue, Aram: btw, if I do appear to be making unsupportable statements in the description, or to otherwise be on crack, please point it out... I'm somewhat nervous that niemeyer is going to reject it on principle, and I'd like it to be as sane as possible in all respects other than size ;)
[13:52] <TheMue> fwereade_: Normally your ideas have very good reasons.
[13:53] <fwereade_> TheMue, thank you -- but occasionally total nonsense slips out past the internal censor, and N other opinions are very helpful ;)
[13:53] <TheMue> fwereade_: *lol*
[14:19] <TheMue> ..ooOO( Note to Mr. Reade: This change is indeed a *monster*. )
[14:58] <TheMue> fwereade_: You've got a review.
[15:31] <fwereade_> TheMue, tyvm for review
[15:31] <fwereade_> TheMue, how about "conf" instead of "any"?
[15:36] <TheMue> fwereade_: I'm missing the intention of that type. The name should reflect this.
[15:37] <fwereade_> TheMue, it's for holding environ configurations, haven't noticed any other uses
[15:40] <TheMue> fwereade_: We could reuse it naming it like "dictionary", otherwise especially for this case "environConfig".
[15:41] <fwereade_> TheMue, SGTM
[15:41] <TheMue> fwereade_: But that are all minors. In general it seems to be an important change to me.
[15:42] <fwereade_> TheMue, fantastic
[15:42] <TheMue> fwereade_: And cleaning up the test tables (all in the methods or all out of them, simplification, anonymous structs) can be done later.
[15:43] <fwereade_> TheMue, yeah, I'm not sure I feel those are important enough to do until I have reason to modify them
[15:43] <fwereade_> TheMue, the big reason for this change is that I'm about to extend state.Initialize and without consistency that will be a nightmare
[15:44] <fwereade_> TheMue, the little reason is just low-level ongoing frustration as I complained about ;)
[15:45] <TheMue> fwereade_: :D