Re: [go-nuts] Re: How to update a module's direct dependencies only

On Thu, Sep 5, 2019 at 3:28 PM Tamás Gulácsi wrote: > Ain't Go 1.13's "go get -u" does exactly this? > And the old behaviour with "go get -u all" ? > Thanks for the input but: > I cannot use 'go get -u -t -d ./...' here because that brings in the >> indirect dependency 'goB' into my go.mod. >>

[go-nuts] Re: How to update a module's direct dependencies only

Ain't Go 1.13's "go get -u" does exactly this? And the old behaviour with "go get -u all" ? https://golang.org/cmd/go/#hdr-Add_dependencies_to_current_module_and_install_them "The -u flag instructs get to update modules providing dependencies of packages named on the command line to use newer

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

On Thu, Sep 5, 2019 at 10:18 PM Jan Mercl <0xj...@gmail.com> wrote: > `go get` should do just one thing and do it well. Automagically > adjusting `go.mod` if one is found in the current directory (or in any > of its parents) when outside $GOPATH is IMO neither of that. Or it > should be enabled by

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

On Thu, Sep 5, 2019 at 8:18 PM wrote: > Running 'go get ...' inside a module can add indirect dependencies to go.mod. I'm surprised. There's probably some rationale behind `go get` having such side effects. Can anyone please shed some light on this? -- You received this message because you

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

I second Jan's request for light-shedding. It's one thing to add real indirect dependencies. I can sort of understand that. Can't think of a sensible reason for adding dependencies that are unrelated to the code in the module. On Thursday, September 5, 2019 at 2:23:11 PM UTC-4, Jan Mercl

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

On Thu, Sep 5, 2019 at 9:22 PM Jan Mercl <0xj...@gmail.com> wrote: > > > Running 'go get ...' inside a module can add indirect dependencies to > > go.mod. > > I'm surprised. There's probably some rationale behind `go get` having > such side effects. Can anyone please shed some light on this? $

[go-nuts] Seeing 'plugin built with different version' errors with Go1.11 (but not with Go1.10)

Hi, I've been using Go plugins with Go1.10, and after initial problems getting our build system to build using identical paths to avoid the dreaded 'plugin was built with a different version of package' error, it all settled down and was working well for 6 months or so. We're now trying to

[go-nuts] 'go build' over writing source code.

Hi, I downloaded go version 1.13 and tried to create new test project outside GOPATH. Following is my observation. Should I open a bug or it is expected/known behavior? *What version of Go are you using (`go version`)?* $ go version go version go1.13 linux/amd64 *Does this issue reproduce

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

> current directory is. But if the current directory happens to be > inside a module, the user inadvertently also performed (1). Thanks, Mihai. That sounds like a consistent explanation. I'm going to try creating a new junk project to see if I can reproduce the problem. Unfortunately, I'm going

Re: [go-nuts] 'go build' over writing source code.

On Thu, Sep 5, 2019 at 9:47 AM wrote: > > I downloaded go version 1.13 and tried to create new test project outside > GOPATH. Following is my observation. > Should I open a bug or it is expected/known behavior? > > What version of Go are you using (`go version`)? > $ go version > go version

[go-nuts] Line wrapping and the lack of some convention

Hi, I would liked that gofmt would handle this one also in order to avoid battles about what is the correct line wrapping in go. In Effective Go there is a section, with smaller fonts than the usual document that states: Line lengthGo has no line length limit. Don't worry about overflowing a

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

On Thu, Sep 5, 2019 at 8:51 PM Mihai Borobocea wrote: > $ go help module-get > The 'go get' command changes behavior depending on whether the > go command is running in module-aware mode or legacy GOPATH mode. > … > Get resolves and adds dependencies to the current development module > and then

[go-nuts] v1.13: Altered go.mod file in project after updating vim-go binaries

I've got an existing Go project that lives under GOPATH, i.e. ~/go/src/github.com/... I just updated to go 1.13 (from 1.12.1) and rebuilt the project without changing any sources. The build succeeded and Go created a go.mod (and go.sum) file that containing my third party dependencies (there

[go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

On Thursday, September 5, 2019 at 8:48:11 PM UTC+3, Michael Ellis wrote: > > I ran :GoUpdateBinaries. > > When I looked at git status, I saw that the go.mod and go.sum files had > changed. My go.mod now contains lines for all vim-go dependencies! > Running 'go get example.com/some/module'

[go-nuts] x/net/Listen behaviours

Hi! I'm having some confusion over the behaviour of net.Listen() and it's interactions with http.Server. Can anyone take a look at this, and let me know what I'm doing wrong? Thanks! System description - Go: go version go1.12.9 darwin/amd64 OS: macOS Mojave

[go-nuts] Questions related to mock exec.Command in unit test

Currently I am using the following code to mock the exec.Command. But there are two issues: 1. I expect the code being tested gets the expected output message (value of the variable 'msg') from STDOUT, but actually what it gets from STDOUT is always "PASS", which should be the output of the

Re: [go-nuts] Re: v1.13: Altered go.mod file in project after updating vim-go binaries

I also. We have to add additional mess to our build scripts when we get testing dependencies that are not part of our distribution to avoid contaminating the go.{mod,sum} in the repo root. This has repeatedly been a source of irritation and frustration. Dan On Thu, 2019-09-05 at 11:36 -0700,

Re: [go-nuts] Line wrapping and the lack of some convention

On Thu, Sep 5, 2019 at 10:59 AM Sotirios Mantziaris wrote: > > I would liked that gofmt would handle this one also in order to avoid battles > about what is the correct line wrapping in go. > > In Effective Go there is a section, with smaller fonts than the usual > document that states: > >

[go-nuts] Re: Expectations for errors.Is/As with error trees

Hi, On Tuesday, September 3, 2019 at 8:29:36 PM UTC-7, Abhinav Gupta wrote: > The PR we have open > implements the following behavior: > >- For errors.As, the first error in the list where errors.As succeeds >is >returned. >- For

[go-nuts] A better io.Reader.Read signature?

Dave Cheney has written (yet another) excellent blog post on Go, on the subject of API design and caller-controlled allocations: https://dave.cheney.net/2019/09/05/dont-force-allocations-on-the-callers-of-your-api In this he compares two possible signatures for the io.Reader.Read method:

Re: [go-nuts] A better io.Reader.Read signature?

Your proposed signature has a little problem and that is that when calling result, err := reader.Read(nil) the Read method doesn’t know how many bytes it should read. The incoming buffer parameter actually serves two purposes. First is to provide a place for storage. The second is to tell

Re: [go-nuts] 'go build' over writing source code.

Thanks for replying. I understood the my mistake. I executed wrong 'go mod' command. By mistake I used 'go mod init main.go'. Thank you. On Thursday, 5 September 2019 22:27:44 UTC+5:30, Ian Lance Taylor wrote: > > On Thu, Sep 5, 2019 at 9:47 AM > wrote: > > > > I downloaded go version 1.13

Re: [go-nuts] Re: [ANN] Gio: portable immediate mode GUI programs in Go for iOS/tvOS, Android, macOS, Linux, Windows

> > Hi, I wanted to try gio this week, and after a lot of work getting > kde-plasma v5.14.3 working on Wayland (Funtoo x86_64), I now have hit the > same issue here: > > https://git.sr.ht/~eliasnaur/gio/tree/master/ui/app/os_wayland.go#L1134 > > "wayland: no xdg_wm_base available" > > I'm a

Re: [go-nuts] Re: How to update a module's direct dependencies only

On Thu, Sep 5, 2019 at 4:33 AM t hepudds wrote: > To upgrade your direct dependencies to their latest release (with your > indirect dependencies using versions selected based on the requirements of > your direct dependencies), this should work in most cases: > > go get $(go list -f '{{if not

[go-nuts] Re: ticker not firing often enough in minimal mac app with run loop

I came across a similar issue when I was working with a heartbeat feature for Macs. The same code ran as expected on Linux machines. In the end, the issue was with Sleep Mode in the Mac machine. When a Mac goes to sleep, time based functions seem to pause. They resume when the machine is woken

[go-nuts] Re: ticker not firing often enough in minimal mac app with run loop

Thanks for all the replies everybody! id activity = [[NSProcessInfo processInfo] beginActivityWithOptions:NSActivityBackground reason:@"Good Reason"]; *Seems to do the trick*, and cpu usage stays at 0.01% I tried using sudo nice -1 and even -20, the cpu usage went up from 0.01 to 0.1, but I