There is still no way to do this in a supported manner.
We may at some future time freeze ABIInternal and call it ABI1, at which
point you could use that. But we have no plans or schedule for that at the
moment.
On Sunday, July 2, 2023 at 10:44:20 PM UTC-7 opennota wrote:
> Ok Google, so one
have your program provide profiles, then use the profiler to grab a profile
after 1,2,3,4,5 days, and see where the cpu time is going.
Precis:
go tool pprof -http : :1234
and open a web browser at http://127.0.0.1:/debug/pprof
See https://pkg.go.dev/runtime/pprof for deatils
The bare
Hi Henry,
For clarity, my comments were not intended to call out any lack of
motivation — which you keyed on — but instead focus on the fact no silver
bullet is likely to exist that addresses error handling without new
language features, and that many Go developers want error handling
Yeah, I've already edited the test so my build would succeed. Adding the
optional closing quote did the trick. I'll open an issue. Thanks for the
advice!
On Monday, July 3, 2023 at 3:40:20 AM UTC-6 Steven Hartland wrote:
> Looks like a bug, I suspect because you have a space in the path the
Looks like a bug, I suspect because you have a space in the path the path
was quoted breaking the regexp as it's not expecting the final quote.
Try editing the regexp to:
^time=\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}(Z|[+-]\d{2}:\d{2})
level=INFO source=.*logger_test.go:\d{3}"? msg=msg2$
On
I don't think it has anything to do with motivation, Mike. The problem I
see is that there is no good enough solution that offers a substantial
benefit over the current approach. Many error handling proposals involve
rearranging the code with a few line savings, and sometimes at the cost of
