Tim Watson
Tim Watson
Maybe I'm missing something, but I don't get what exceptions you're talking about in https://github.com/simonmar/distributed-process/commit/ad2d328d33bf92102f8d694886f2f44a12c68e3a Simon. Are you talking about the `kill p "BANG"` calls? Because that's an asynchronous primitive...
Hmn, that's annoying. Don't you want to stash the result somehow and/or split the test cases up into separate functions anyway - which makes using `assertBool` or some such easier...
Tracing would probably be an option...
I guess I see your point, but my general feeling is that spewing to stderr is a poor man's substitute for proper logging, which is what the tracing facility provides....
I'm not entirely sure about that. Tracing produces a tonne of info, perhaps we want to selectively trace things instead. Let me ponder for a day or two and suggest...
I think what we're getting into here is that murky territory that is in between tracing and logging. There is a very lightweight framework for logging in place, so maybe...
Ah no, that code (SystemLog.hs) is in distributed-process-extras. We could migrate it, since the only things in its library that it depends on are a couple of type classes afaikt
Personally I think this should be an _option_ rather than the default behaviour.
I think part of the rationale for this is provided the same behaviour as Erlang/OTP. In that case, the `unmonitor` call flushes (or there's a flushing variant, I forget which...
Yes @facundominguez that's right, and I agree we should offer a variant rather than changing the current behaviour.