[go-nuts] Better dependency management in go

Hi All, I create a github issue to suggest a proposal for making go dependency managment better. As people there suggested that this group is probably the best place to discuss this, I am posting the exact same post here: Even after the introduction of Go modules, the dependency management is

[go-nuts] how to use replace directives in go.mod in dev but not prod

I put this question on the golang issue tracker on github: https://github.com/golang/go/issues/41546 I am sure it's been answered before but hard to search for..anyone know what the right approach is? I like how node.js / NPM solve it using symlinks personally. -- You received this message

[go-nuts] Requesting bug review for https://github.com/golang/go/issues/41536

If anyone has time please sanity check my Go issue report https://github.com/golang/go/issues/41536 I think its a bug but if not I'll delete it. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] Evaluation order of return

Why does the compiler change evaluation order of return when adding a new field to a struct? I didn't check the compiler output, I only guess it somehow changes the order. play package main import ( "fmt" ) type Number interface { Value() int } type

[go-nuts] [generics] Typo for type with type argument

Hello golang-nuts, I have found a small typo in the current draft for generics. In the section "Function argument type inference" ( https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#function-argument-type-inference), there is a function NewPair: func

Re: [go-nuts] Evaluation order of return

On Mon, Sep 21, 2020 at 9:34 AM 'Axel Wagner' via golang-nuts wrote: > > The evaluation order is defined here: > https://golang.org/ref/spec#Order_of_evaluation > The important part is that the order of evaluation in a return statement is > only defined for function calls, method calls and

Re: [go-nuts] Re: What books/tutorail/resources/blog for newcomer to golang?

Also i can recommend this book: https://go101.org/article/101.html On Wed, Sep 16, 2020 at 1:15 PM Vladimir Varankin wrote: > Hey! > > My peaks, that helped me a lot, back when I started with Go (depending on > what's your prefered way to learn and how fast do you have to learn it, > some might

Re: [go-nuts] Evaluation order of return

The evaluation order is defined here: https://golang.org/ref/spec#Order_of_evaluation The important part is that the order of evaluation in a return statement is only defined for function calls, method calls and communication statements, but not in relation to other operations. So, in return

Re: [go-nuts] [generics] Typo for type with type argument

On Mon, Sep 21, 2020 at 9:08 AM Christian Persson wrote: > > I have found a small typo in the current draft for generics. In the section > "Function argument type inference" >

[go-nuts] Find n-th root of a big number

i can't find get n-th root in document of go big package so i decided to do it myself using newton's method. i found a solution at https://www.geeksforgeeks.org/n-th-root-number/ and start to implement in go. but my code only work fine for base 2. other base result gone too far from correct.

[go-nuts] mytex.RWLock recursive read lock

https://golang.org/pkg/sync/#RWMutex Holds that this prohibits recursive read locks but why would it? I understand that deadlocks can happen in case write locks are held in between the read locks but why can't a goroutine issue several RLock calls? It does actually work in the playground.

Re: [go-nuts] mytex.RWLock recursive read lock

(Note, FWIW, that in particular no write locks need to be *held*. It's enough for Lock to be *called*, it doesn't have to have returned yet) On Mon, Sep 21, 2020 at 12:29 PM Axel Wagner wrote: > I feel like the docs are pretty precise in what they say and why. > > a blocked Lock call excludes

Re: [go-nuts] ERRORLEVEL issue. Screenshots detected.

Dnia 2020-09-20, o godz. 23:51:19 Walter Weinmann napisał(a): > [image: Screenshot 2020-09-21 084403.png] > [image: Screenshot 2020-09-21 084604.png] > [image: Screenshot 2020-09-21 084819.png] Please DO NOT post screenshots of text to this list. @ Tamás Gulácsi, @ Brian Candler, @ Kurtis

Re: [go-nuts] mytex.RWLock recursive read lock

Yes that's the canonical deadlock but doesn't the docs say "In particular, this prohibits recursive read locking" which it doesn't unless you mix reads and writes. I get that it's not advisable but it's not prohibited either or there would be a panic or something. On Mon, 21 Sep 2020, 12:30

Re: [go-nuts] Re: [Feature Request] x/mobile: support for gamepad/joystick/controller events

On Fri, Sep 18, 2020 at 6:02 AM Ben Lubar wrote: > I'd appreciate feedback on the potential future existence of gamepad input > support in x/mobile x/mobile is not a very active project. Sorry. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group.

Re: [go-nuts] ERRORLEVEL issue

Are you making an explicit call to panic(), or is it a crash from inside some cgo? If you are calling panic() is it from somewhere unusual like a signal handler? I tried a small cgo program to fault and it still exited with code 1 (under macOS anyway) - incidentally the word "panic" doesn't

Re: [go-nuts] mytex.RWLock recursive read lock

It only says that's excluded *if* you can have a concurrent Lock call. On Mon, Sep 21, 2020 at 12:48 PM Henrik Johansson wrote: > Yes that's the canonical deadlock but doesn't the docs say > > "In particular, this prohibits recursive read locking" > > which it doesn't unless you mix reads and

Re: [go-nuts] ERRORLEVEL issue

This simple version is working - it seems to be a more specific issue. On Monday, 21 September 2020 at 09:37:57 UTC+2 b.ca...@pobox.com wrote: > On Monday, 21 September 2020 07:51:19 UTC+1, Walter Weinmann wrote: >> >> Same problem with os.Exit(1). >> >> > Are you saying that if you run this

Re: [go-nuts] mytex.RWLock recursive read lock

I feel like the docs are pretty precise in what they say and why. a blocked Lock call excludes new readers from acquiring the lock. This means, the following could happen: Goroutine 1 calls RLock, acquires a Read-Lock Goroutine 2 calls Lock, blocking Goroutine 1 calls RLock again, blocking (as

Re: [go-nuts] ERRORLEVEL issue

My code is here: [image: Screenshot 2020-09-21 084403.png] My script is here: [image: Screenshot 2020-09-21 084604.png] Logfile: [image: Screenshot 2020-09-21 084819.png] Same problem with os.Exit(1). What am I doing wrong? On Monday, 21 September 2020 at 05:38:11 UTC+2 Kurtis Rader wrote:

Re: [go-nuts] ERRORLEVEL issue

I'm not - sec_go is a directory: [image: Screenshot 2020-09-21 091724.png] This looks as expected ? On Mon, 21 Sep 2020 at 09:15, Tamás Gulácsi wrote: > You're building src_go.exe (-o of go build), and running orabench.exe. > > > walter@gmail.com a következőt írta (2020. szeptember 21.,

Re: [go-nuts] ERRORLEVEL issue

On Monday, 21 September 2020 07:51:19 UTC+1, Walter Weinmann wrote: > > Same problem with os.Exit(1). > > Are you saying that if you run this program: package main import "os" func main() { os.Exit(1) } you see the %ERRORLEVEL% is 0? Under Linux, calling os.Exit(1) also prints the message

Re: [go-nuts] ERRORLEVEL issue

You're building src_go.exe (-o of go build), and running orabench.exe. walter@gmail.com a következőt írta (2020. szeptember 21., hétfő, 8:51:19 UTC+2): > My code is here: > > [image: Screenshot 2020-09-21 084403.png] > > My script is here: > > > [image: Screenshot 2020-09-21 084604.png] >

Re: [go-nuts] mytex.RWLock recursive read lock

A lot can be argued ;) Ambiguous docs however aren't generally good in any way. This came up as a consequence of real code being changed by a new very skilled developer and there was quite a bit discussion that could have been avoided with clearer docs. We have sorted the issue I mostly wanted

Re: [go-nuts] mytex.RWLock recursive read lock

To elaborate a bit: You are correct in that there is a slight syntactic ambiguity whether "this prohibits" refers to the entire sentence ("if another goroutine might call Lock, then a second RLock might not be acquired"), or only to the second half. I would argue the rest of the section makes it

Re: [go-nuts] mytex.RWLock recursive read lock

On Mon, Sep 21, 2020 at 2:06 PM Henrik Johansson wrote: > Ambiguous docs however aren't generally good in any way. This came up as a > consequence of real code being changed by a new very skilled developer and > there was quite a bit discussion that could have been avoided with clearer > docs. >

Re: [go-nuts] mytex.RWLock recursive read lock

> Is this simply a recommendation or should the docs be updated to clarify what > this means? perhaps the latter, although that question only seems to come up once every two or so years. here's a good link: https://groups.google.com/d/msg/golang-nuts/XqW1qcuZgKg/Ui3nQkeLV80J the entire

Re: [go-nuts] mytex.RWLock recursive read lock

FTR, I still don't think the docs *are* ambiguous. The authoritative part is If a goroutine holds a RWMutex for reading and another goroutine might call > Lock, no goroutine should expect to be able to acquire a read lock until > the initial read lock is released. The rest is just additional