[go-nuts] Re: Should we stop using a global logger?

Or, what if... type FunnelContext interface { context.Context logger.Logger } type RequestHandler struct { // No context specific fields here, instance stays reusable across requests } func (RequestHandler) Handle(ctx FunnelContext) {} On Thursday, August 24, 2017 at 8:58:15 PM

[go-nuts] Should we stop using a global logger?

In Funnel [1], we've been using a global logger, based on logrus [2]. This has worked fine through the early stages of the project, but it's starting to show a few cracks. In particular, we need to ensure that a request (task) ID is present in all log messages. Solutions to this have grown to

Re: [go-nuts] Capture test output per-function

On Thursday, July 6, 2017 at 12:40:30 AM UTC-7, Jan Mercl wrote: > > On Thu, Jul 6, 2017 at 12:56 AM wrote: > > > As far as I can tell, go test captures the output per-package, and when > one test fails it dumps all the captured logs. > > It's per test, not package. > > I

[go-nuts] Capture test output per-function

In Funnel, we have a growing end-to-end test suite which has many test functions. https://github.com/ohsu-comp-bio/funnel/tree/master/tests/e2e When one test fails, Funnel's logs are dumped, and there are lots of them. Debugging tests has become difficult. As far as I can tell, go test

[go-nuts] Re: Why there is no container/set

Back to the original question, container/set seems like a great addition. It could have a nicer interface than map[T]U and a single best implementation. Can we talk about whether the owners of that package agree? On Saturday, December 3, 2011 at 1:32:02 AM UTC-8, James Chow wrote: > > I used