Re: [go-nuts] Bets approach for test helper packages within same project

2023-08-07 Thread josvazg
setup or external dependencies, must be run by passing the required build tags explicitly. Jose El lunes, 7 de agosto de 2023 a las 9:38:40 UTC+2, TheDiveO escribió: > https://stackoverflow.com/a/54734212 > > On Monday, August 7, 2023 at 8:48:24 AM UTC+2 josvazg wrote: > >> Inte

Re: [go-nuts] Bets approach for test helper packages within same project

2023-08-06 Thread josvazg
ts as usual. > > On Fri, Aug 4, 2023 at 11:01 AM josvazg wrote: > > > > We are working on a project that requires some test helpers and mocks > that, ideally, should: > > > > - Helpers should be accessible by all testing code, unit tests, > integration or e

[go-nuts] Bets approach for test helper packages within same project

2023-08-04 Thread josvazg
We are working on a project that requires some test helpers and mocks that, ideally, should: - Helpers should be accessible by all testing code, unit tests, integration or e2e. - Note unit tests live along side normal code in their *_test.go files. - The rest of tests will be on a

Re: [go-nuts] Recomended GOPROXY (or not) for Open Source projects?

2021-06-28 Thread josvazg
sly be at > risk if I continued to use it. > > Put another way: if the code is OSS, but it depends on something that's > not OSS and freely available, then can the code claim to be called OSS in > the first place? > > On Saturday, 26 June 2021 at 08:34:13 UTC+1 josvazg w

Re: [go-nuts] Recomended GOPROXY (or not) for Open Source projects?

2021-06-26 Thread josvazg
o good reason. This is not as simple as just vendor on your same repo, but on the flip side makes your exported repos more trustworthy and easier to consume. Are there better ways to have the cake and eat it too? WDYT? Thanks, Jose El sábado, 26 de junio de 2021 a las 8:42:46 UTC+2, josv

Re: [go-nuts] Recomended GOPROXY (or not) for Open Source projects?

2021-06-25 Thread josvazg
4:56 UTC+2, david@gmail.com escribió: > On Fri, Jun 25, 2021 at 1:23 PM josvazg wrote: > >> When working on internal company projects, it makes sense to use a >> company wide GO Proxy assuring that all go dependency code is available and >> immutable. But when yo

[go-nuts] Recomended GOPROXY (or not) for Open Source projects?

2021-06-25 Thread josvazg
When working on internal company projects, it makes sense to use a company wide GO Proxy assuring that all go dependency code is available and immutable. But when you move to an Open Source project, you cannot longer use such private proxy. I wonder what is the best practice recommendation for

[go-nuts] Gidelines or best practices on error on error handling?

2021-01-30 Thread josvazg
Is there some idiomatic or well known way to deal with extra errors when you are already recovering from or reporting an error condition? The typical case is, you hit an error and need to release resources before returning it. But the resources themselves may fail when closing them. One (freque

Re: [go-nuts] RISCV & Golang custom-compilations ahead?

2020-09-13 Thread josvazg
ISA variants to the compiler in the go codebase, before thinking about plugins or alike. Correct? Jose El domingo, 13 de septiembre de 2020 a las 21:14:10 UTC+2, Ian Lance Taylor escribió: > On Sun, Sep 13, 2020 at 1:50 AM josvazg wrote: > > > > This is not a proposal, just a cu

[go-nuts] RISCV & Golang custom-compilations ahead?

2020-09-13 Thread josvazg
This is not a proposal, just a curiosity question to check if anyone in the Go ecosystem has already thought on this issue and have some solutions in mind. I might be late to this realization, but nowadays is pretty clear Intel monolithic ISA dominance is threatened. ARM is taking over Macs and

[go-nuts] Type parameters on another line

2020-08-01 Thread josvazg
Let me know if this or something similar was already proposed and rejected for some reason but otherwise... What if instead of trying to cram all into a single line we use a previous line before the function or type definition explaining how the type parameter aliases are to be interpreted. Lik

Re: [go-nuts] GolangRT Docs?

2017-01-26 Thread josvazg
Replying to myself. Here is a must read to understand the go runtime better and its source code: https://github.com/golang/go/blob/master/src/runtime/HACKING.md -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and s

Re: [go-nuts] GolangRT Docs?

2017-01-26 Thread josvazg
Also, any recommended entry point or guide to read the runtime source code? -- 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.

Re: [go-nuts] GolangRT Docs?

2017-01-26 Thread josvazg
Thanks a lot Ian! My mind picture of the runtime is more detailed now. I guess for more I should now read the code itself. Just one side issue. You said: " Memory allocated on the stack in function F can not be used by callees of F. After F returns, the memory is gone. " I don't quite get it.

Re: [go-nuts] GolangRT Docs?

2017-01-25 Thread josvazg
for the runtime is static. 7. GolangRT subset language not only is fuzzy and changing, it is also very limited to me generally useful for anything else. Thanks, Jose El martes, 24 de enero de 2017, 22:16:07 (UTC+1), Ian Lance Taylor escribió: > > On Tue, Jan 24, 2017

[go-nuts] GolangRT Docs?

2017-01-24 Thread josvazg
Golang runtime has been fully translated to Go for a while now. I know I could just read the source code directly but... Is there any known or recommended documentation (talk, slides, article) about the runtime Go code? I am specially interested in anything that describes the Golang runtime la

Re: [go-nuts] Re: Thread safety programatic definition for Go

2017-01-01 Thread josvazg
enero de 2017, 0:48:28 (UTC+1), Michael Jones escribió: > > Josvazg, Your notion of "globals safe" should allow init() functions as > safe writers. They are always invoked serially. > > On Sun, Jan 1, 2017 at 7:29 AM > wrote: > >> >> On Sunday, January

[go-nuts] Thread safety programatic definition for Go

2017-01-01 Thread josvazg
I am trying to come up with a detailed definition of what a thread safe Go program is (and is not). One that a (go) tool could check by analyzing the code for me. Here is what I got so far: - If there are no go statements, then the program is single threaded and thus thread safe.

Re: [go-nuts] Static race detector?

2016-09-14 Thread josvazg
to say "let me do this I know what I am doing" than run into issues without noticing. Thanks, Jose El martes, 13 de septiembre de 2016, 8:16:14 (UTC+2), Jan Mercl escribió: > > On Tue, Sep 13, 2016 at 7:53 AM josvazg > > wrote: > > > Why does Go does not have

[go-nuts] Re: Static race detector?

2016-09-13 Thread josvazg
Thanks for all links and answers! -- 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. For more options, visit https://groups

[go-nuts] Static race detector?

2016-09-12 Thread josvazg
Why does Go does not have a static race detector? What are the difficulties? (just pointing me to the right docs to read is fine) I was thinking in a naive high level way... If Rust can do it, using its ownership model, Go could have a tool checking the AST that analyzes variable scopes and che