[00:55] ubuntu@ip-10-4-114-16:~$ pgrep jujud -lf [00:55] 5074 /var/lib/juju/tools/juju-0.0.0-precise-amd64/jujud provisioning --zookeeper-servers localhost:2181 --log-file /var/log/juju/provision-agent.log --debug [00:55] 5077 /var/lib/juju/tools/juju-0.0.0-precise-amd64/jujud machine --zookeeper-servers localhost:2181 --machine-id 0 --log-file /var/log/juju/machine-agent.log --debug [05:55] davecheney: mornin' [05:55] rogpeppe: hows' tricks ? [05:56] davecheney: good thanks. finally got around to painting the kitchen last weekend... two years after we did the rest of it! [05:56] davecheney: still needs another coat, but getting there [05:56] rogpeppe: yup, you'd think as an adult painting would be simple [05:56] turns out it's really bloody hard [05:57] davecheney: i've had an idea about the watchers which i'd like to run past you [05:57] btw, I think ec2/config_test.go might be broken [05:57] as in, doesn't test anything [05:57] davecheney: hmm, how so? [05:57] trying to write a _failing_ test case for https://bugs.launchpad.net/juju-core/+bug/1025128 [05:58] { [05:58] "admin-secret: 81a1e7429e6847c4941fda7591246594\n" + baseConfig, [05:58] func(cfg *providerConfig) {}, [05:58] this should fail right ? [05:58] "", [05:58] }, [05:59] rogpeppe: did you read my mid afternoon status, we have a machine agent running on machine/0 now [06:00] * rogpeppe has a look [06:00] davecheney: oh, no i didn't - i've got a branch almost done which runs the MA. that's cool though, it's not much code. [06:01] rogpeppe: dagnabbit, we're all over each others toes [06:01] davecheney: i know, it's as things start to close in [06:01] i'm kinda hanging in the wind until deploy secrets is comitted [06:02] davecheney: that'll be soon, i hope, if one or other of the config branches gets in [06:02] * davecheney nods [06:02] davecheney: did you have a look at this BTW? https://codereview.appspot.com/6343107/ [06:03] rogpeppe: i had a brief look, SGTM [06:03] but i'm really only intersted in getting secrets deployed [06:03] davecheney: it's part and parcel [06:03] config has had _so_ many polishes, it must ground down to a nub now [06:04] davecheney: it's surprisingly subtle [06:04] rogpeppe: that suggests that its serving many masters [06:04] davecheney: i found that when trying to hack on william's code [06:04] subtle the way state.Info is subtle [06:04] davecheney: it was trying to be two things at once [06:05] davecheney: i don't thing state.Info is subtle [06:05] think [06:05] davecheney: there was lots of code doing not very much [06:06] davecheney: you're right, config tests are fucked [06:07] rogpeppe: should I raise a bug [06:07] i fixed 1025128, but it's hard to test when the test harness is rooted [06:07] davecheney: i just changed one of the existing error messages and the test still passed... [06:08] rogpeppe: indeed o_O [06:08] davecheney: go test -gocheck.f TestConfig [06:08] davecheney: runs no tests [06:08] oops [06:08] bwahaha [06:08] hwo did that happen ? [06:08] davecheney: ha! [06:08] davecheney: i see [06:09] davecheney: someone at some point (maybe me!) changed (configSuite) to (s *configSuite) [06:09] bzr blame ? [06:09] davecheney: i dare not [06:10] care to unfuk ? [06:10] davecheney: gimme 30s [06:11] davecheney: ha! not so fast - loads of tests fail... [06:12] shit [06:13] rogpeppe: maybe log a bug [06:13] i'll do it [06:13] davecheney: looks like william might've done it... [06:13] fwereade_: ahem [06:13] so easy to do [06:13] rogpeppe: sohuld thre be two bugs then ? on against gocheck to avoid this kind of thing ? [06:14] davecheney: arguably. it should probably give an error if it finds tests on the value type when it's been given a pointer [06:15] rogpeppe: i think this should be raised as a bug [06:15] davecheney: yeah [06:15] rogpeppe: i'll do it [06:16] davecheney: can i run my watcher idea past you? [06:16] rogpeppe: https://bugs.launchpad.net/juju-core/+bug/1025138 [06:16] ^ can you put some debug in this issue [06:16] then i'll log one against gocheck to make sure we can't screw ourselves again [06:16] rogpeppe: sure, tell me about your watcher [06:18] davecheney: i'm concerned by how hard it is to write multiplexers. this was some code i suggested to frank for the firewall code: http://paste.ubuntu.com/1089462/ [06:18] davecheney: the code inside loop() there should really only be three lines of code. [06:19] davecheney: and i think the problem is to do with the way we stop watchers [06:19] rogpeppe: one idea i had was to pass into the watcher a channel to receive changes [06:19] davecheney: each watcher has its own Stop function. [06:19] this is unusual, but might make a mux style watcher simpler [06:19] davecheney: i think a nicer alternative is to pass a stop channel into the watcher [06:20] davecheney: then the watcher closes its channel when done [06:20] rogpeppe: but you can't select on a closed channel, right ? [06:20] davecheney: that way you've got a *single* stop channel for all watchers you're muxing [06:20] davecheney: 'course you can [06:20] davecheney: (select on read) [06:20] * davecheney remains unsure [06:20] davecheney: and only a single channel to read from each watcher [06:21] davecheney: i *think* it could simplify things considerably [06:21] * davecheney goes to play with play.g.o for a second [06:23] rogpeppe: indeed, this will work, http://play.golang.org/p/G15bEHpZkP [06:23] davecheney: absolutely. it's the way closed chans are meant to be used [06:24] nice [06:24] davecheney: having a single stop channel means that a muxer can "delegate" its stop request to those things it's watching [06:24] rogpeppe: if you pass it in as <- chan, then you know you are the only one who can close it [06:24] davecheney: then every watcher would provider a Wait (sp?) method which would read messages from the watcher chan until EOF, then return the watcher's error [06:24] davecheney: exactly [06:25] davecheney: i *think* this means most watchers can dispense with tomb [06:25] rogpeppe: certainly for those watchers where we don't need any sort of error value from, yes [06:25] davecheney: no, errors are easy too [06:26] davecheney: most watchers are single-goroutine [06:26] davecheney: it's easy for them to get an error from the watcher they're reading from and put it in an instance variable [06:26] davecheney: the only way for a client to get the error is to call Wait. [06:27] davecheney: and when that returns, we're guaranteed that the error is in a known state [06:30] davecheney: errors are crucial, because all watchers need to be able to return an error [06:30] * davecheney nods [06:32] shit, i've just buggered cobzr [06:33] rm -rf ../../.bzr/cobzr ? [06:34] davecheney: nope, edit .bzr/branch/location [06:34] davecheney: that's a really bad suggestion BTW! [06:34] davecheney: it would erase all my branches [06:34] rogpeppe: I did the above by mistake once, once [06:35] davecheney: oops [06:35] davecheney: in this case it wasn't so bad. i did branch -m ec2-fix-configsuite' [06:35] ' [06:35] (note the linefeed) [06:35] davecheney: it doesn't like it! [06:35] davecheney: at least, it "works" [06:36] davecheney: then you can't do anything [06:36] davecheney: i'll raise a bug! that's what i'll do... [06:37] davecheney: ha. can't do that. [06:57] davecheney: i did one watcher: https://codereview.appspot.com/6373048 [06:59] davecheney: the important bit is the change on lines 162-167 [06:59] davecheney: we don't have to select on output any more [06:59] davecheney: which makes muxers much easier (and we will have lots of them in the firewall and unit agent) [07:22] rogpeppe: holy shit, a closed channel always fires !?? [07:22] davecheney: absolutely! [07:22] davecheney: have you not read the spec? [07:22] davecheney: they're *really* useful [07:22] rogpeppe: not for a while [07:23] davecheney: it's the only way to use a chan to broadcast [07:24] davecheney: it's always been like that. except in the early days you'd get a panic if you read more than N times N =~ 20. [07:24] rogpeppe: i can't find a reference to it in the spec [07:25] but a closed channel looks like it always behaves like it has a value of the zero value and false [07:25] davecheney: http://golang.org/ref/spec#Close [07:25] I guess you're talking about this bit "zero value for the channel's type without blocking" [07:26] it doesn't specifically mention it's use in select {} but whatever [07:26] as you say, a very useful property [07:26] davecheney: yeah [07:26] to both [07:27] the fact it's level triggered is very useful [07:27] although, it's not really acting as a default case [07:27] davecheney: thanks to fwereade_'s refactoring, the state/wacher.go changes are pretty minimal, it seems [07:27] davecheney: what do you mean by that? [07:28] that is, receiving from a closed channel will be chosen pseudorandomly from the set of ready channels [07:28] davecheney: yeah [07:28] davecheney: which is fine, i think. [07:28] yup [07:28] davecheney: you might have two closed channels, of course [07:28] combined with nil'ing the channel, it's very powerful [07:28] davecheney: definitely [07:28] anyway, time for a break, and some dinner [07:29] davecheney: both of those things weren't in Limbo, and i really appreciate them [07:29] davecheney: enjoy! [07:29] davecheney: 't'was good to catch you [07:29] later lads, if I don't see you again tonight, we'll talk at le standup! [07:29] davecheney: aye [08:04] morning [08:09] TheMue, heyhey [08:09] rogpeppe, also heyhey :) [08:09] fwereade_: yo! [08:10] fwereade_: i've had a minor revelation about the watchers [08:10] TheMue: yay! [08:10] rogpeppe, oh yes? [08:10] fwereade_: i was thinking about this code, which i suggested to TheMue as part of the firewall code: http://paste.ubuntu.com/1089462/ [08:10] rogpeppe, is this to do with the which-ready-channel-you-receive-from-is-random thing? [08:11] rogpeppe, that has had me a little suspicious lately, easy to miss [08:11] fwereade_: that was a side shoot [08:11] fwereade_: or... maybe i don't know what you're referring to there [08:11] fwereade_: i thought that the code above was way more complex than it should be [08:12] rogpeppe, I shouldn't worry about it for now, I'm just developing a sl. twitchy feeling that we may not have fully analysed some of the watchers, I'll figure it out properly myself :) [08:12] fwereade_: this potential change makes them easier to analyse, i think [08:12] fwereade_: the idea is that actually most watchers layer on top of other watchers [08:12] rogpeppe, anyway, sorry derail [08:13] rogpeppe, yes, this is very true [08:13] * TheMue listens [08:13] fwereade_: and so the fact that each watcher has its own Stop method makes things hard [08:13] rogpeppe, ok... [08:13] fwereade_: we can do better, i think, if we *pass in* a stop channel [08:14] fwereade_: and use the EOF status of the watch channel as an indication that the watcher has completed [08:14] rogpeppe: Hmm, an idea: why don't we build the watchers so that, when creating an instance, we don't pass behaviors based on interfaces. They are called on changes and errors. [08:14] rogpeppe, hmm, this has crossed my mind in individual cases [08:14] rogpeppe: Everything else is handled internally. [08:14] TheMue: i'm not sure i understand that [08:15] rogpeppe: Wait a moment, I'll write a paste as outline. [08:15] fwereade_: here's an example of what i mean: https://codereview.appspot.com/6373048/diff/1/state/watcher/watcher.go [08:15] rogpeppe, the trouble is that pass-a-stopper is a nice thing internally, but as a consumer of our APIs I would much rather get an object I can Stop() myself [08:15] fwereade_: yes, that's the down side [08:15] fwereade_: *but* [08:15] fwereade_: it makes everything else simpler [08:17] fwereade_: particularly in the muxing case, which we're going to be doing a *lot* in the firewall and unit agent code [08:18] fwereade_: that code i pasted earlier turns into something like this: http://paste.ubuntu.com/1094518/ [08:18] fwereade_: i.e. exactly what it *should* look like [08:19] rogpeppe, hmm, yes, I agree it's useful in those cases [08:19] * fwereade_ is fretting that it's not necessarily everything we need [08:19] fwereade_: how do you mean? [08:19] rogpeppe, eg in one of the things I have up for review [08:19] rogpeppe, relationUnitsWatcher I think [08:20] rogpeppe, I found that stop chans weren't quite enough for my single-thing-watcher goroutines [08:20] rogpeppe, and I convinced myself that I needed a whole separate tomb for every goroutine [08:21] fwereade_: i don't *think* you do [08:21] rogpeppe, maybe I should have been keeping references to the subwatchers around directly, that would probably be enough [08:22] rogpeppe, the specific issue was "make sure this goroutine is not going to send anything else on the updates channel" [08:22] fwereade_: ah! [08:22] rogpeppe, ie, make sure I can't get a changed event after a deleted event [08:22] fwereade_: but that's the important thing about this change! [08:22] fwereade_: we don't care any more! [08:22] rogpeppe: http://paste.ubuntu.com/1094521/ is very, very quick. The important idea should be that you don't bother with different channels and tombs. The watcher does this and calls the methods of the passed behavior. [08:22] fwereade_: because the way we wait for a watcher to complete is by reading all events from the channel. [08:23] rogpeppe: It's used in Erlang/OTP very much. Services provide the backend, behaviors concentrate on business logic. [08:23] fwereade_: have a look at that watcher code i posted above [08:23] rogpeppe, I do like that, but I'm still not sure it helps my case [08:24] rogpeppe, this is me waiting until I'm sure that one specific goroutine is no longer going to be sending on a shared channel [08:24] TheMue: i'm not sure i understand the motivation, or the context. [08:24] fwereade_: why do you need to do that? [08:24] TheMue: is this a suggestion for state/watcher.go ? [08:25] rogpeppe, to ensure that I will not get any embarrassing changed events after I've sent a departed event for a particular relation units [08:25] TheMue: it looks quite similar to what fwereade_'s done in that file already [08:26] fwereade_: because you've got two watchers watching different aspects of the same thing? [08:26] rogpeppe: Inside one watcher, yes. But take a look at your paste above. We still build new watchers upon, with own tombs, with multiply channels and all that stuff. [08:27] rogpeppe, assume that I got a change immediately followed by a delete, and my main goroutine is processing the delete while the child goroutine is processing the change [08:27] rogpeppe: My intention is to simplify that. [08:27] TheMue: i'd have to see a more complete example to understand what you're suggesting. [08:28] rogpeppe, unless I wait for the child to actually die, I can't be sure which of the channels it's selecting on will be selected [08:28] fwereade_: isn't the problem there that you've got two things operating on the same state? [08:28] rogpeppe, ie when the scheduler gets around to it next, Dying is closed but updates is also unblocked [08:28] fwereade_: which channels is it selecting on? [08:29] rogpeppe, I have two different things operating on two different pieces of state that are in the same system [08:29] rogpeppe, waiting to receive from a stop chan (which might be a tomb.Dying()), or send on an updates chan for the attention of the main goroutine [08:30] fwereade_: with this change, you would not do that [08:30] fwereade_: you'd just send on the updates chan unconditionally [08:31] rogpeppe, right, so how do I avoid getting change events on the updates chan as soon as I want to stop receiving them? [08:31] fwereade_: you don't. [08:31] fwereade_: but i don't see why that's a problem. [08:31] rogpeppe, at the time I stop, the child goroutine may already be waiting to send [08:31] fwereade_: that's fine. [08:31] rogpeppe, I want to be damn sure it will not do so [08:32] fwereade_: at the receiving side, you have to ignore the subsequent event(s) [08:32] rogpeppe, because a relationUnitsWatcher that sends crap like unit-0-0 deleted followed by unit-0-0 changed is just crackful [08:32] fwereade_: but that shouldn't be hard [08:32] rogpeppe, when N goroutines are sending on the shared update channel? [08:33] rogpeppe, I keep more state lying around to know which events I should filter out f the updates stream? [08:33] fwereade_: yeah, it's not a difficult problem, i think. you maintain some state per goroutine on the receiver side. [08:33] fwereade_: each even coming from the shared update channel will identify its goroutine [08:33] rogpeppe, hmm, doesn't really feel like a win to me, but I could perhaps be convinced [08:33] fwereade_: so the state can be there trivially [08:34] s/each even/each event/ [08:34] fwereade_: i *think* it's a much easier structure to reason about [08:35] rogpeppe, it's just a feeling that the watchers which keep state around are harder to reason about [08:35] rogpeppe, it could well still be a net win; makes most things easier and some harder [08:36] fwereade_: at least this state is simple local state, no concurrent interactions with it [08:36] fwereade_: in this case, i think it's as simple as "x.ignore = true"; [..] if x.ignore { continue} [08:37] fwereade_: but i may well misunderstand your problem [08:37] rogpeppe, well, it's multiple goroutines, so I'd need to invert it and store the ones I *do* care about in a map [08:37] rogpeppe, I agree not very complex [08:38] rogpeppe, I'm not arguing it's an insupportable burden [08:38] fwereade_: i don't think so... each goroutine stores info about itself [08:38] fwereade_: and sends that info on the watch channel. [08:38] fwereade_: so when an event arrives, you get the info too, which you can manipulate as local state. [08:39] rogpeppe, but the critical info always comes in on the main goroutine, not the child, I don't think the child should be storing that state [08:39] rogpeppe, I am not opposed to exploring this idea further [08:39] fwereade_: cool [08:39] moin everyone. [08:39] Hi Aram [08:39] Aram: yo [08:39] ! [08:39] rogpeppe, just pointing out a use case which I think is legitimate and not the best fit [08:39] Aram, heyhey [08:39] fwereade_: i'll be interested to have a look at the CL [08:40] rogpeppe, I have a stack of them, bit insomniac this w/e [08:40] fwereade_: i had this idea sitting in my head all weekend, but couldn't get anywhere near a computer... [08:40] rogpeppe, TheMue: in fact I think https://codereview.appspot.com/6408045/ is basically a trivial [08:40] rogpeppe, TheMue: but one with a surprisingly significant effect [08:41] rogpeppe, TheMue: so I would appreciate both your opinions [08:41] rogpeppe, TheMue: it's independent of https://codereview.appspot.com/6405044/ which is a prereq for https://codereview.appspot.com/6402048/ [08:42] rogpeppe, the first one of those 2 is the use case I was talking about [08:42] rogpeppe, the second one ties together a bunch of stuff in a way that I find pleasing [08:43] rogpeppe, and gets us a RelationUnit type that is aware of the existence/settings of other RelationUnits in other agents [08:43] fwereade_: rogpeppe: TheMue: I have to take at least half a day off... I've stayed too much in the sun and I have a fever and an excruciating headache. [08:43] Aram, np, look after yourself :) [08:43] fwereade_: 6408045 is because yaml doesn't marshal deterministically? [08:43] rogpeppe, yeah :/ [08:43] woke up and drank 2 liters of water. [08:43] Aram: ok, sorry about that [08:43] fwereade_: although i'm jealous of your sun [08:43] fwereade_: it's been 13 degrees here for weeks [08:44] rogpeppe, it was swapping dict field order about 1 time in 10 in normal use [08:44] fwereade_: i've got the central heating on [08:44] fwereade_: ah, makes sense [08:44] rogpeppe, the test case hits it 100 times and it sometimes switches rendering order >50 times [08:44] fwereade_: LGTM [08:44] rogpeppe, that was a fun midnight bug-hunt though [08:44] rogpeppe, cool [08:44] fwereade_: good catch! [08:45] TheMue, if I could get one from you too I'll merge it straight in [08:45] rogpeppe, cheers :) [08:45] fwereade_: although... [08:45] rogpeppe, go on [08:45] fwereade_: why did it cause anything to fail? [08:46] fwereade_: i'd've thought the tests should be resilient to config nodes changing-but-not-changing [08:46] rogpeppe, AIUI ConfigNode is meant to *not* change-without-changing [08:46] rogpeppe, a while ago niemeyer said he would consider that behaviour to be a bug [08:47] rogpeppe, and it is an assumption I was depending on in the tests [08:47] fwereade_: nonetheless, the watchers *should* be resilient to it, no? [08:47] fwereade_: ah [08:47] rogpeppe, no, IMO the system should assume this useful property of ConfigNode [08:47] rogpeppe, this case specifically [08:47] fwereade_: ok [08:48] rogpeppe, relation unit writes private-address to its settings node on creation [08:48] rogpeppe, the private address *might* have changed if the UA was restarted and is rejoining an existing one [08:48] fwereade_: i suppose contentWatcher copes with updates-without-changes at too low a level [08:48] rogpeppe, or it might not, or the node might not exist at all [08:48] rogpeppe, IMO the nice thing to do is just to always set private-address on join [08:49] rogpeppe, and let the lower level filter out the changes-that-don't-chnage [08:49] rogpeppe, with the bug, a particular node's version can change under the hod and send me an unepected event [08:50] "relation unit writes private-address to its settings node on creation" [08:50] rogpeppe, not even an unexpected event, actually [08:50] i don't understand that [08:50] rogpeppe, just an unexpected version [08:50] rogpeppe, ok, every unit participating in a relation has its own settings and presence nodes [08:50] fwereade_: Looks good [08:50] fwereade_: what's a "relation unit" and what's the private address we're talking about here? [08:50] rogpeppe, existence of the presence node implies validity of the settings [08:51] fwereade_: ok [08:51] rogpeppe, one thing we guarantee is that if you're in a relation with some other units, you will have access to their private-address setting [08:51] rogpeppe, so that you can do whatever magic youpersonally require to get your charm talking to the other side of the relation [08:51] fwereade_: ah, i didn't know that [08:51] rogpeppe, make sense roughly? [08:52] fwereade_: yup [08:52] rogpeppe, I'm not saying there isn't a better way to do it, but the python seems to work pretty well like that :) [08:53] fwereade_: i guess i'm surprised that the config node watcher doesn't filter out occasions when the content has changed but the attrs haven't [08:53] fwereade_: but i'm happy with your fix [08:53] fwereade_: it seems very plausible [08:53] rogpeppe, feels like a lot more hassle to do it at output time when we already have all the info available at input time, as it were [08:53] fwereade_: yeah [08:54] rogpeppe, and then we get more predictable behaviour at a lower level and can build higher-level stuff with more confidence [08:54] fwereade_: definitely. [08:54] fwereade_: thanks for the explanation [08:55] rogpeppe, need to take a longish break, cath was away for the weekend and I need to JIT some housekeeping which got sacrificed to coding while laura was asleep ;) [08:55] fwereade_: :-) [08:55] fwereade_: when you're back i should have a watcher CL for your perusal [08:55] rogpeppe, cool [08:56] rogpeppe, TheMue: I'll just merge the ConfigNode change before I break [08:56] fwereade_: and i'll add some tests to that config proposal. i *hope* that gustavo likes it. [08:56] rogpeppe, that's always the worry [08:56] rogpeppe, I wish I had a better niemeyer sim [08:57] fwereade_: mine's still training the neural net. [08:57] fwereade_: it's pretty erratic [08:57] rogpeppe, indeed, I find it actually gets worse with time because it functions accurately for weeks and then, suddenly, *total* failure [08:58] fwereade_: wildly non-linear solution space [08:58] rogpeppe, indeed :) [09:00] rogpeppe, TheMue: thanks, submitted [09:08] fwereade_: Cheers [09:21] Oh, revision 300, nice number. [09:51] davecheney: Heya [09:51] TheMue: howdy [09:51] i'll leave the firewaller to you [09:53] davecheney: Thx *bow* [10:01] davecheney, heyhey [10:03] 'sup ! [10:14] * TheMue thankfully bought the Ubuntu fleece jacket in Oakland. It's pretty cold today here. [10:49] * fwereade_ is exhausted by the mere prospect of the 10-minute walk in blazing sunshine to collect laura from nursery [10:49] bbs [11:00] niemeiyer: any comment ? https://www.youtube.com/watch?v=32DD4DF7Qpo [11:11] davecheney, TheMue, fwereade_: request for comment: https://codereview.appspot.com/6373048/ [11:14] davecheney: lol [11:15] * davecheney reads [11:56] fwereade_: i'm not sure that passing a tomb around would be a good idea [11:56] rogpeppe, yeah, it feels too bulky [11:57] rogpeppe, potentially [11:57] fwereade_: a tomb has a single idea of an error [11:57] rogpeppe, ah, sorry, what's the problem there? [11:57] fwereade_: my main inspiration for the CL was my realisation that there's a fundamenal asymmetry using channels [11:57] fwereade_: channels fan in but they don't fan out [11:57] rogpeppe, yeah [11:58] fwereade_: which leads me to think that stopping your sources is more appropriate as a broadcast. [11:58] fwereade_: then each source tells you when it has responded and completed. [11:58] rogpeppe, fwereade_: What's still somehow too complex for me is the chaining of goroutines. We do goroutine(baseWatcher) -> goroutine(somehowSpezializedWatcher) -> goroutine(neededWatcher) [11:59] fwereade_: and when we've got a channel coming from that source, EOF on the channel seems the Right Way. [11:59] rogpeppe, sure, that's what we do anyway, right? [11:59] TheMue: chaining of goroutines is the Go Way. [11:59] TheMue, yeah, the chaining of goroutines makes me happy [11:59] fwereade_: yes, but the stopping is still one-to-one. [11:59] TheMue, so long s they're sanely written they make very nice building blocks IMO [11:59] rogpeppe, fwereade_: I would like to already tell the first one what I want to do and only think about the business logic. [12:00] TheMue: i'm not sure what you mean by "the business logic" [12:00] TheMue, IMO the good thing is that you *can* as long as you enforce communication by channels [12:00] fwereade_: But we have so much overhead around it, each time with new tombs. [12:00] rogpeppe, the domain logic if you prefer [12:00] TheMue: my proposal does away with most of the tombs [12:00] TheMue, is this overhead serious? [12:00] rogpeppe: The stuff that I want to be done, sorry for the wording. [12:01] rogpeppe, yeah, that's what makes me uncomfortable, I find the tombs *really* helpful [12:01] fwereade_: IMHO it can be done more simple using interfaces. [12:01] fwereade_: a tomb is overkill much of the time [12:01] fwereade_: did you look at the watcher implementations in the CL? [12:01] rogpeppe, if "knowing when you've stopped" is overkill, then yes [12:01] fwereade_: they don't use a tomb, and the code is no more complex IMHO [12:02] fwereade_: when you've only got one goroutine, there's no difficulty knowing when you've stopped :-) [12:02] fwereade_: you return... [12:03] TheMue: the fundamental problem we're trying to solve here is that there are things changing all over the system, and we need to respond to them in a coherent way [12:03] s/to them/to the changes/ [12:04] TheMue: channel multiplexing can work really nicely here, but it's a right pain if you have to select every time you want to send or receive on a channel. [12:04] rogpeppe: How does your CL helps regarding this point. [12:05] rogpeppe: OK, get's more clear. [12:05] TheMue: you see the two pieces of code at the start of the CL description? [12:05] TheMue: that's the simplification that this CL buys you [12:05] rogpeppe: That's why I started with using range. [12:05] TheMue: *exactly*! [12:05]