[go-nuts] Re: testing examples printing to stdout not working for global var

It looks like you have a bug in your code. "In tests, standard output is accumulated during execution and dumped to standard output when done." "Example functions may include a concluding line comment that begins with "Output:" and is compared with the standard output of the function when the

[go-nuts] testing examples printing to stdout not working for global var

this caught me out, is it a bug? https://go.dev/play/p/atJb8dZHoqi -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To

[go-nuts] oauth2/jws creates "invalid" signatures

Does anyone know why the jws signatures created by the golang.org/x/oauth2/jws are displayed as "invalid signature" on jwt.io ? As far as I'm concerned it seems compliant with the JWS creation specs[0] but it looks like jwt.io is expecting a public key or "jwk string" as well ? Below is an

Re: [go-nuts] Error wrapping not always work??

Got it. Thanks a lot sir. On Sunday, May 1, 2022 at 2:53:29 PM UTC-4 axel.wa...@googlemail.com wrote: > To be clear: You seem to assume that `errors.Is` recursively unwraps both > errors passed to it and checks for equality along any of their pairings (or > maybe in the innermost wrapped

Re: [go-nuts] Error wrapping not always work??

To be clear: You seem to assume that `errors.Is` recursively unwraps both errors passed to it and checks for equality along any of their pairings (or maybe in the innermost wrapped error). But that's not the case. errors.Is checks if the first error wraps the second. One error wrapping another is

Re: [go-nuts] Error wrapping not always work??

On Sun, May 1, 2022 at 6:12 PM Tong Sun wrote: > > > On Sunday, May 1, 2022 at 11:17:35 AM UTC-4 axel.wa...@googlemail.com > wrote: > >> In the first case, you ask if the respective errors wrap e1. The answer >> is yes - both wrap e1. >> In the second case, you ask if one error wraps the other.

Re: [go-nuts] Error wrapping not always work??

On Sunday, May 1, 2022 at 11:17:35 AM UTC-4 axel.wa...@googlemail.com wrote: > In the first case, you ask if the respective errors wrap e1. The answer is > yes - both wrap e1. > In the second case, you ask if one error wraps the other. The answer is no > - they both wrap ErrInvalidArgument,

Re: [go-nuts] Error wrapping not always work??

In the first case, you ask if the respective errors wrap e1. The answer is yes - both wrap e1. In the second case, you ask if one error wraps the other. The answer is no - they both wrap ErrInvalidArgument, but they don't wrap each other. errors.Is doesn't check if both errors passed wrap the same

[go-nuts] Error wrapping not always work??

Please take a look at https://go.dev/play/p/Dl_IGD46bPe I have two error wrappings there, one works and one doesn't (I'm expecting both to be the "Same"). Why one works and one doesn't? thanks -- You received this message because you are subscribed to the Google Groups "golang-nuts" group.

[go-nuts] Re: A patch to avoid point-time race coincidence like Rust

On Sunday, 1 May 2022 at 11:45:28 UTC+1 Brian Candler wrote: > get rid of the global variables. Use channels instead. Share memory by > communicating; don't communicate by sharing memory. > https://www.youtube.com/watch?v=PAAkCSZUG1c=168s http://go-proverbs.github.io/ -- You received this

[go-nuts] Re: A patch to avoid point-time race coincidence like Rust

On Sunday, 1 May 2022 at 07:04:34 UTC+1 yan.z...@gmail.com wrote: > Any advice? > If the value you are trying to read and update is int32 or int64, you can use the sync.Atomic package. However, if you feel you need to do this all the time, I can't help but

Re: [go-nuts] go fails to detect a point-time race condition

On Sat, 2022-04-30 at 22:49 -0700, Zhaoxun Yan wrote: > I am sure it did not detect race immediately at least in my > project, which has similar global variable race conditions, but in a > more subtle way . > > For example, the checking of one global variable is from an > incoming message from

[go-nuts] A patch to avoid point-time race coincidence like Rust

A global variable has a plausible chance to race as one goroutine reads it while another writes it, as shown in previous post: https://groups.google.com/g/golang-nuts/c/PHw_zU6Ayfo So I am trying to enforce a lock on each global variable to avoid such accident just as Rust does on every