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

[Mihai Borobocea]

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 (or .Main .Indirect)}}{{.Path}}{{end}}' -m
> all)
>
Thank you for this shorter solution and its GitHub issue.
To run it on any module (including modules without dependencies and with no
.go files in the module root) this checks that the list of dependencies
isn't empty:

go list -f '{{if not (or .Main .Indirect)}}{{.Path}}{{end}}' -m all | xargs
--no-run-if-empty go get

Then my remaining question is: How to find out if one of my dependencies
has a newer major version?
Is there, or should there be, a way using the standard tools to query for
this?
I found a couple of GitHub issues about upgrading to /v2+ (like changing
the /vN import suffix automatically) once the user knows about a new major
version. But I didn't find an issue about discovering that there is a new
major version without manually checking.

Regards,
Mihai

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMXRBmgsS_qzJoT6fFd%3D%2Baag9bh%3DnXp6WrFtSY_05WDUOyxf8A%40mail.gmail.com.

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

[Tor Langballe]

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 still got the big pauses, I guess it still puts the app to sleep 
when it thinks it isn't doing anything, even if it gets more CPU when it's 
not sleeping.

tor


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c2e7d85a-dd86-4fd7-b2c8-e52d6fd5b712%40googlegroups.com.

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

[Elias Naur]

> 
> 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 newbie to Wayland -- what does this mean and what component needs 
> upgrading?
> 

I'm sorry that you had to go through all that work. If its any
consolation, there is progress on the X11 port over at
gioui.org/issue/8.

In the shorter term, I'm not sure why the xdg_wm_base is not available
in your version of Plasma. According to

https://phabricator.kde.org/D13510

and

http://blog.davidedmundson.co.uk/blog/my-month-in-kwinwayland/

"...KWin 5.14 will have support for XDG WM Base..."

the xdg_wm_base extension should be available in the version you run.

Is there a chance you might be running the Weston reference compositor?
Being a reference implementation, it lags behind on the desktop-oriented
features. For example, you need Weston 6.0 to get xdg_wm_base support.

If you can, please post a dump of running a Gio program with
WAYLAND_DEBUG=1 set. That dump should reveal whether it is really your
compositor lacking xdg_wm_base or a Gio bug.

-- elias

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BWRYG13XWSEO.J1COPIFVIIYH%40testmac.

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

[Tamás Gulácsi]

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 minor or patch releases 
when available. Continuing the previous example, 'go get -u A' will use the 
latest A with B v1.3.1 (not B v1.2.3). If B requires module C, but C does 
not provide any packages needed to build packages in A (not including 
tests), then C will not be updated."

"With no package arguments, 'go get' applies to Go package in the current 
directory, if any. In particular, 'go get -u' and 'go get -u=patch' update 
all the dependencies of that package."

2019. szeptember 5., csütörtök 1:35:58 UTC+2 időpontban mihaib...@gmail.com 
a következőt írta:
>
> Hello,
>
> I am looking for a way to regularly update my Go module's direct 
> dependencies. Without specifying indirect dependencies myself: let my 
> direct dependencies specify what they need in their own go.mod.
>
> After reading relevant documentation, I could only come up with this 
> partial workaround:
>
> go list -m -u -f '{{if and (and (not .Indirect) (not .Main)) 
> .Update}}{{.Path}}@{{.Update.Version}}{{end}}' all | xargs 
> --no-run-if-empty go get
>
> Suspecting this scenario is common and useful, I have prepared a minimal 
> concrete example below (each module is a repository under 
> github.com/MihaiB for now).
> "X → Y" means "module X depends directly on module Y".
> I have the following Go modules:
>
> goMain → goA → goB
> goMain's tests → goT
>
> All modules have published versions v1.1.0, v1.2.0 and v2.0.0 (except 
> goMain which has no version tags). All dependency arrows above (go.mod 
> entries) specify v1.1.0, so all can be updated.
>
> goMain's .go files are in a sub/dir/ to make sure the commands I type 
> inspect all packages inside the module, but this isn't mandatory: I can 
> also repeat a command in each package's directory if needed.
>
> 
> In goMain:
> $ cat go.mod 
> module github.com/MihaiB/goMain
>
> go 1.13
>
> require (
> github.com/MihaiB/goA v1.1.0
> github.com/MihaiB/goT v1.1.0
> )
> 
>
> 1) How to find out if goA or goT have a newer v1 version, and update to it?
> My 'go list … | xargs …' workaround above does this by listing the direct 
> dependencies and passing them to 'go get'.
> Would it make sense to support this functionality via a shorter command?
> I cannot use 'go get -u -t -d ./...' here because that brings in the 
> indirect dependency 'goB' into my go.mod.
>
> 2) How to find out if goA or goT have a newer major version (v2 or later)?
> I know that v2 and later have a different import path (ending in "/v2"), 
> so different major versions are different packages and they can be used 
> together in my module.
> But I would like a command which tells me if some of my direct 
> dependencies have a newer major version, otherwise I would have to check 
> each dependency by hand to find out.
>
> Mihai
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ffeefec0-dcfd-41c4-98e1-ac7e0483e480%40googlegroups.com.

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

[Mihai Borobocea]

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.
>>
> In my minimal concrete example at https://github.com/MihaiB/goMain and
described in the first message in this thread.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMXRBmj2YCXMLHYQd3T_nv2osQ-0vz_Y21JOaPoyKG8Bc%3DNgbg%40mail.gmail.com.

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

[William Ivory]

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 
switch to Go1.11, and the exact same code and Debian build rules now 
consistently produces the 'different version' error.  Is anyone aware of 
any changes between Go1.10 and Go1.11 that might explain this?

Thanks,

William

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/54fc4aa3-7eff-4c97-868f-9299ef5c76c1%40googlegroups.com.

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

[varshneyabhi]

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 with the latest release?*
yes


*What operating system and processor architecture are you using (`go env`)?*
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/abhishek/myprog/golang/bin"
GOCACHE="/home/abhishek/.cache/go-build"
GOENV="/home/abhishek/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/abhishek/myprog/golang"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct";
GOROOT="/home/abhishek/software/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/abhishek/software/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build290715438=/tmp/go-build 
-gno-record-gcc-switches"


*What did you do?*
1. Create folder testmux in non GOPATH folder.
2. Create main.go file inside testmux.
3. Execute go mod init
4. Execute go build 

code for 'main.go' is present at:
https://play.golang.org/p/nzbMB2v48ty

Other Observation
Executing same steps inside $GOPATH/src, create binary testmux. It does not 
over write main.go.

*What did you expect to see?*
On command 'go build' inside project folder binary with project folder name 
should be present.

*What did you see instead?*
Command 'go build' over writes main.go command with binary (ELF) format. 
The source code is gone now. Not recoverable.

Regards,
Abhishek Varshney

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fee40820-3d86-4ee3-8361-01371f7c997e%40googlegroups.com.

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

[Ian Lance Taylor]

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 go1.13 linux/amd64
>
> Does this issue reproduce with the latest release?
> yes
>
>
> What operating system and processor architecture are you using (`go env`)?
> $ go env
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN="/home/abhishek/myprog/golang/bin"
> GOCACHE="/home/abhishek/.cache/go-build"
> GOENV="/home/abhishek/.config/go/env"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/home/abhishek/myprog/golang"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct";
> GOROOT="/home/abhishek/software/go"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/home/abhishek/software/go/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD=""
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build290715438=/tmp/go-build 
> -gno-record-gcc-switches"
> 
>
> What did you do?
> 1. Create folder testmux in non GOPATH folder.
> 2. Create main.go file inside testmux.
> 3. Execute go mod init
> 4. Execute go build
>
> code for 'main.go' is present at:
> https://play.golang.org/p/nzbMB2v48ty
>
> Other Observation
> Executing same steps inside $GOPATH/src, create binary testmux. It does not 
> over write main.go.
>
> What did you expect to see?
> On command 'go build' inside project folder binary with project folder name 
> should be present.
>
> What did you see instead?
> Command 'go build' over writes main.go command with binary (ELF) format. The 
> source code is gone now. Not recoverable.

Where exactly did you create the folder testmux?  What were the exact
commands that you ran?  What was the exact output?

I tried to follow your direction.

> mkdir /tmp/x
> cd /tmp/x
> 
> go mod init
go: cannot determine module path for source directory /tmp/x (outside
GOPATH, module path must be specified)

Example usage:
'go mod init example.com/m' to initialize a v0 or v1 module
'go mod init example.com/m/v2' to initialize a v2 module

Run 'go help mod init' for more information.

What did you see when you ran "go mod init"?

Ian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVK7z8bJZyw1FP7MCcxWQ8oTsHCBM2D2yRbj7DqhJKbvw%40mail.gmail.com.

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

[Michael Ellis]

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 are only 
two of them).  Ok, that's nice, I thought. I added and committed go.mod and 
go.sum.

When I started editing sources (with NeoVim), I noticed that vim-go was no 
longer working, so I ran :GoUpdateBinaries.  It most succeeded with one 
complaint among the 2 dozen or so packages it updated.  It's still not 
working well in the editor, but that's not the point of this post.

I wrote some new code in one of my project files, running go vet from the 
command line several times until there were no errors.  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!  WTF? None of those repos 
have anything to do with my project code.

Has anyone else encountered this? 

FWIW, here's what the require section now looks like.  The lines I've 
bolded are the prior content.

9fans.net/go v0.0.2 // indirect
github.com/alecthomas/gometalinter v3.0.0+incompatible // indirect
github.com/alecthomas/units v0.0.0-20190717042225-c3de453c63f4 // indirect
github.com/cosiner/argv v0.0.1 // indirect
github.com/davidrjenni/reftools v0.0.0-20190827201643-0605d60846fb // 
indirect
github.com/fatih/gomodifytags v1.0.1 // indirect
github.com/fatih/motion v1.0.0 // indirect
github.com/go-delve/delve v1.3.1 // indirect
github.com/google/shlex v0.0.0-20181106134648-c34317bd91bf // indirect
github.com/josharian/impl v0.0.0-20190715203526-f0d59e96e372 // indirect
github.com/jstemmer/gotags v1.4.1 // indirect
github.com/keegancsmith/rpc v1.1.0 // indirect
github.com/kisielk/errcheck v1.2.0 // indirect
github.com/klauspost/asmfmt v1.2.0 // indirect
github.com/konsorten/go-windows-terminal-sequences v1.0.2 // indirect
github.com/koron/iferr v0.0.0-20180615142939-bb332a3b1d91 // indirect
github.com/mattn/go-colorable v0.1.2 // indirect
github.com/mattn/go-isatty v0.0.9 // indirect
github.com/mattn/go-runewidth v0.0.4 // indirect
github.com/mdempsky/gocode v0.0.0-20190203001940-7fb65232883f // indirect
github.com/peterh/liner v1.1.0 // indirect
* github.com/robfig/cron v1.2.0*
github.com/rogpeppe/godef v1.1.1 // indirect
github.com/sirupsen/logrus v1.4.2 // indirect
github.com/spf13/cobra v0.0.5 // indirect
github.com/stamblerre/gocode v0.0.0-20190327203809-810592086997 // indirect
github.com/zmb3/gogetdoc v0.0.0-20190228002656-b37376c5da6a // indirect
go.starlark.net v0.0.0-20190820173200-988906f77f65 // indirect
golang.org/x/arch v0.0.0-20190815191158-8a70ba74b3a1 // indirect
golang.org/x/crypto v0.0.0-20190829043050-9756ffdc2472 // indirect
golang.org/x/lint v0.0.0-20190409202823-959b441ac422 // indirect
* golang.org/x/net v0.0.0-20190827160401-ba9fcec4b297*
golang.org/x/sys v0.0.0-20190904154756-749cb33beabd // indirect
golang.org/x/tools v0.0.0-20190904211325-a4fdb3a8b281 // indirect
gopkg.in/alecthomas/kingpin.v3-unstable v3.0.0-20180810215634-df19058c872c 
// indirect
honnef.co/go/tools v0.0.1-2019.2.3 // indirect


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7da3b1f0-a5c4-416e-a7c2-2d5ce2b6a8ce%40googlegroups.com.

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

[Sotirios Mantziaris]

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 
punched card. If a line feels too long, wrap it and indent with an extra 
tab.

The above line leaves a lot of room for interpretation:

Assume you have something lengthy, which is also left for interpretation, 
you should wrap and ident with an extra tab:

Now I have the following outcomes:

shinyThing := New(argument1 string, argument2 string, argument3 string,
  argument4 string, argument5 string)


you have

shinyThing  := New(
  argument1 string, 
  argument2 string, 
  argument3 string,
  argument4 string, 
  argument5 string
)

and there are possibly 100 more variations out there.

I personally prefer the first one because I use as much horizontal space as 
I can (i have a limit for 120 chars per line) and I use as little as 
possible vertical space in order to not need to scroll. I optimize for 
having as much as possible in one screen.

Does anybody have a convention that is generally accepted for this?
Would this make sense to be part of gofmt?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/11db50dc-d8e2-4a75-b9a2-bf00ae7f9a89%40googlegroups.com.

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

[mihaibopublic]

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' inside a Go module (the go.mod 
file is in the current directory or a parent directory) seems to add 
example.com/some/module to go.mod as an "// indirect" dependency.
Also 'go get -u modA" will try to update modA's dependencies and add them 
also as "// indirect" dependencies to your go.mod.
More details in https://github.com/golang/go/wiki/Modules

At first glance, it seems that GoUpdateBinaries calls GoInstallBinaries 
which constructs a 'go get' command, optionally with a -u flag:
https://github.com/fatih/vim-go/blob/master/plugin/go.vim#L117
https://github.com/fatih/vim-go/blob/master/plugin/go.vim#L191

Running 'go get ...' inside a module can add indirect dependencies to 
go.mod.

Mihai

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9091117c-b39b-43aa-8ae8-7de5a6cea6e2%40googlegroups.com.

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

[Jan Mercl]

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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-WhnkL23wGLZkT-AtGeiL4b%2BzW1gNT8cBcpdY8hY89ucw%40mail.gmail.com.

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

[Michael Ellis]

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 wrote:
>
> 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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5de47c75-79ea-429c-866f-5091c5210426%40googlegroups.com.

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

[Mihai Borobocea]

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 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 builds and installs them.

If you are inside a module (there is a go.mod file in your current dir
or a parent dir) you can just type
$ go help get
But the output of this command changes depending on your current dir
(describes either module-aware or legacy GOPATH behavior).

Other resources are https://tip.golang.org/doc/go1.13#modules (with a
subsection on go get), https://github.com/golang/go/wiki/Modules and
this series of blog posts https://blog.golang.org/using-go-modules
These are what I've looked at to get a sense of modules and stop using
GOPATH now that go 1.13 is out.

I posted this related message with a minimal example of module
dependencies and thoughts/questions on how to update my module's
direct dependencies without mentioning indirect dependencies:
https://groups.google.com/forum/#!topic/golang-nuts/FrWNhWsLDVY

My impression is that Go modules and dependency management are well
thought through and the commands have well defined behavior. But it is
not a small topic/scenario, so getting a sense of how things work
takes some effort and experimentation.

Mihai

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMXRBmjATyYQqYFhP7ff7_frWwE7M55%2BxVhSXCGoT4Ss-S0Kyg%40mail.gmail.com.

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

[Jan Mercl]

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 builds and installs them.

Thanks for the pointer. I think that behavior is not a good idea. Yes,
it's convenient that when working on a module and realizing some
dependency is missing, `go get` handles updating `go.mod`. However at
the same time this breaks the workflow of possibly a big number of
people. The OP's :GoUpdateBinaries in vim-go is just one example. I
don't know how many people use `vim_go`, but the project has 10k+
stars. Developer's scripts/make files/go generate "scripts" etc, all
of that may legitimately invoke `go get` for things the module _is
not_ actually dependent on.

`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 a flag, like -um (update go.mod) or this is maybe
a job for some `go mod foo` command, not `go get`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XXYVhQaQ0wd%3D29zqDc8hK6w%2BUvOaEMDjA8_Gepux_9_Q%40mail.gmail.com.

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

[Mihai Borobocea]

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 a flag, like -um (update go.mod) or this is maybe
> a job for some `go mod foo` command, not `go get`.

A-ha, I think I understand the problem: 'go get' can be used for two
unrelated purposes:
1) to add/update dependencies in the current Go module
2) to install a program globally: 'go get golang.org/x/lint/golint'
produces ~/go/bin/golint

One normally wants to perform (2) from anywhere: like 'apt-get install
...' (or perhaps 'npm install -g ...'), it doesn't matter what the
current directory is. But if the current directory happens to be
inside a module, the user inadvertently also performed (1).

If this is the case, it seems an issue worth addressing.
However, I have only a basic understanding of go commands and modules.
I might miss important details.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMXRBmi_Gpa9_DrmDXP8NKNP7YR2xi-ZSxuRGKcdqHbidZytcQ%40mail.gmail.com.

[go-nuts] x/net/Listen behaviours

[jgrime]

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 (10.14.6)


Problem description
--

Passing a net.Listener from net.Listen() into the Serve() method of an 
http.Server does not behave how I expect ...


Test program
-

A simple server that responds to connections by echoing info regarding the 
URL by which it was contacted (see below):

package main

import (
"context"
"flag"
"fmt"
"log"
"net"
"net/http"
"os"
"os/signal"
"strconv"
"syscall"
"time"
)

// Print information about the local machine's network interfaces
func printNetworkInterfaces() {
ifaces, err := net.Interfaces()
if err != nil { panic("net.Interfaces()") }

if len(ifaces)<1 {
log.Println("No network interfaces found.")
return
}

hostname, _ := os.Hostname()
log.Println( "Network interfaces for " + hostname )

for _, iface := range ifaces {
addrs, err := iface.Addrs()
if err != nil { panic("iface.Addrs()") }
if len(addrs) < 1 { continue }
log.Println("-",iface.Name,iface.HardwareAddr)
for _, addr := range addrs {
switch v := addr.(type) {
case *net.IPNet:
str := fmt.Sprintf("IPNet: IP=%s, mask=%s, network=%s, string=%s", v.IP, 
v.Mask, v.Network(), v.String())
log.Println(" ", str)
case *net.IPAddr:
str := fmt.Sprintf("IPAddr: IP=%s, zone=%s, network=%s, string=%s", v.IP, 
v.Zone, v.Network(), v.String())
log.Println(" ", str)
default:
log.Println("")
}
}
}
}

// Just write the incoming url back to the sender
func echoHandler(w http.ResponseWriter, r *http.Request) {
txt := fmt.Sprintf("Echo: (%s)",r.URL.Path)
w.Write( []byte(txt+"\n") )
log.Println(txt)
}

var (
listener_ = flag.Int("listener", 0, "Use an explicit net.Listener.")
port_ = flag.Int("port", 0, "Set the port to listen on (0 = any free 
port?).")
timeout_  = flag.Int("wait", 0, "Timout (in seconds) before server killed 
(0 = no timout).")
)

func main() {

onShutdown := func(what string, cleanup func()) {
log.Println( fmt.Sprintf("- Shutting down %s ...",what) )
cleanup()
log.Println( fmt.Sprintf("  %s shut down.",what) )
}

flag.Parse()

useListener := *listener_
port := *port_
timeout := *timeout_

// Let's see what interfaces are present on the local machine

printNetworkInterfaces()

// Simple server for incoming connections.

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) 
{echoHandler(w,r)});

var listener net.Listener = nil
addrString := fmt.Sprintf(":%d",port)

// Using an explicit Listener provides more control over the specifics,
// e.g. tcp4/6 and letting the system select a currently free port.

if useListener>0 {
log.Println("Using net.Listener")

listener, err := net.Listen("tcp4", addrString) // :0 -> use any free port
if err != nil { log.Fatalln(err) }

defer onShutdown("listener", func() {listener.Close()} )

addrString = listener.Addr().String()
host, portStr, err := net.SplitHostPort(addrString) // as port may have 
been assigned by system
if err != nil { log.Fatalln(err) }

log.Println( fmt.Sprintf("Listener Addr string: %s (host: %s, port: 
%s)",addrString,host,portStr) )

port, err = strconv.Atoi(portStr)
if err != nil { log.Fatalln(err) }

addrString = fmt.Sprintf(":%d",port) // as port may have been assigned by 
the system
}

server := http.Server { Addr: addrString }

// Run web server in a separate goroutine so it doesn't block our progress

go func(server *http.Server, listener net.Listener) {

var err error

if listener == nil {
err = server.ListenAndServe()
} else {
err = server.Serve(listener)
}

switch err {
case nil:
case http.ErrServerClosed:
log.Println("Caught ErrServerClosed")
default:
panic(err)
}
}(&server, listener)

defer onShutdown("server", func() {server.Shutdown(context.Background())} )

log.Println("Port:", port)
log.Println("Address:", addrString)

// User interrupt channel

sig := make(chan os.Signal, 1)
signal.Notify(sig, os.Interrupt, syscall.SIGTERM)

// Timeout channel, if needed

tc := make(<-chan time.Time);
if timeout > 0 {
tc = time.After(time.Second * time.Duration(timeout))
}

// Wait on user interrupt or timeout

select {
case <-sig: // user interrupt
case <-tc: // timeout
}

// Cleanup

log.Println("Shutting down.")
}

According to the Go docs :

For TCP networks, if the host in the address parameter is empty or a 
literal unspecified IP address, Listen listens on all available unicast and 
anycast IP addresses of the local system. To only use IPv4, use network 
"tcp4".

It also says "See func Dial for a description of the network and address 
parameters", from which :

Known networks are "tcp", "tcp4" (IPv4-only), "tcp6" (IPv6-only), "udp", 
"udp4" (IPv4-only), "udp6" (IPv6-only), "ip", "ip4" (IPv4-only), "ip6" 
(IPv6-only), "unix", "unixgram" and "unix

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

[Michael Ellis]

> 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 to be traveling for the next 2 days and won't have
time to try it until Sunday.  For the time being I've simply done a git
checkout to retrieve the prior go.mod and go.sum.




On Thu, Sep 5, 2019 at 3:53 PM Mihai Borobocea 
wrote:

> 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 a flag, like -um (update go.mod) or this is maybe
> > a job for some `go mod foo` command, not `go get`.
>
> A-ha, I think I understand the problem: 'go get' can be used for two
> unrelated purposes:
> 1) to add/update dependencies in the current Go module
> 2) to install a program globally: 'go get golang.org/x/lint/golint'
> produces ~/go/bin/golint
>
> One normally wants to perform (2) from anywhere: like 'apt-get install
> ...' (or perhaps 'npm install -g ...'), it doesn't matter what the
> current directory is. But if the current directory happens to be
> inside a module, the user inadvertently also performed (1).
>
> If this is the case, it seems an issue worth addressing.
> However, I have only a basic understanding of go commands and modules.
> I might miss important details.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/-vUHGd5zlPI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMXRBmi_Gpa9_DrmDXP8NKNP7YR2xi-ZSxuRGKcdqHbidZytcQ%40mail.gmail.com
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK6kDbYFGF4JVqJKZL1XzWw3MEzM7t5O_BLY2a6jStwJh%2BtZDQ%40mail.gmail.com.

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

[Tom Payne]

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:
  func (r *Reader) Read(buf []byte) (int, error)
  func (r *Reader) Read() ([]byte, error)
and makes a very good case for why the first, albeit trickier to use, is 
the better API. The post also sets up a false dichotomy/straw man argument, 
comparing only two signatures when there are other alternatives too.

What about the following API:
  func (r *Reader) Read(buf []byte) (result []byte, err error)
If the buf argument is non-nil then buf is used to store the result, 
len(result) == the int returned by the actual Read(buf []byte) (int, error) 
method.
If the buf argument is nil then a new []byte is created and returned, i.e. 
the allocation is done by Read and the method is as easy to use as Read() 
([]byte, error).
The semantics of the error return remain the same (i.e. Read might return 
both some bytes read and an error), but that is orthogonal to the memory 
allocation.
An example of this pattern is here 
.

Given that slices are small and cheap to copy (a pointer to the data, a 
length, and a capacity) what are the downsides to using
  func (r *Reader) Read(buf []byte) (result []byte, err error)
as a method?

I am not suggesting that we change io.Reader (that would break 
everything!), just looking for input into good Go API design.

This would be a comment on Dave's fantastic blog, but the blog does not 
have comment functionality, so I'm asking here, and I know that Dave lurks 
here too.

Cheers,
Tom

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8ffb9828-c6e2-47de-bca1-ef6988f081e8%40googlegroups.com.

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

[Ian Lance Taylor]

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:
>
> Line lengthGo has no line length limit. Don't worry about overflowing a 
> punched card. If a line feels too long, wrap it and indent with an extra tab.
>
> The above line leaves a lot of room for interpretation:
>
> Assume you have something lengthy, which is also left for interpretation, you 
> should wrap and ident with an extra tab:
>
> Now I have the following outcomes:
>
> shinyThing := New(argument1 string, argument2 string, argument3 string,
>   argument4 string, argument5 string)
>
>
> you have
>
> shinyThing  := New(
>   argument1 string,
>   argument2 string,
>   argument3 string,
>   argument4 string,
>   argument5 string
> )
>
> and there are possibly 100 more variations out there.
>
> I personally prefer the first one because I use as much horizontal space as I 
> can (i have a limit for 120 chars per line) and I use as little as possible 
> vertical space in order to not need to scroll. I optimize for having as much 
> as possible in one screen.
>
> Does anybody have a convention that is generally accepted for this?

There is some discussion at
https://golang.org/wiki/CodeReviewComments#line-length .

> Would this make sense to be part of gofmt?

I don't think so, because good line breaks require semantic knowledge
that gofmt doesn't have.

Ian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWg-B79pLpmc-AjVh6z98fFNiFZv%2B8UwpKQNiCrH4Bi4Q%40mail.gmail.com.

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

[Michal Strba]

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 how many bytes should be
read.

If you want to read all the bytes from a reader, you can use
https://golang.org/pkg/io/ioutil/#ReadAll

If you want to read N bytes into a freshly allocated buffer, you can make a
helper function:

func ReadNBytes(r io.Reader, n int) (result []byte, err error) {
result = make([]byte, n)
n, err := r.Read(result)
return result[:n], err
}

On Fri, 6 Sep 2019 at 00:48 Tom Payne  wrote:

> 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:
>   func (r *Reader) Read(buf []byte) (int, error)
>   func (r *Reader) Read() ([]byte, error)
> and makes a very good case for why the first, albeit trickier to use, is
> the better API. The post also sets up a false dichotomy/straw man argument,
> comparing only two signatures when there are other alternatives too.
>
> What about the following API:
>   func (r *Reader) Read(buf []byte) (result []byte, err error)
> If the buf argument is non-nil then buf is used to store the result,
> len(result) == the int returned by the actual Read(buf []byte) (int, error)
> method.
> If the buf argument is nil then a new []byte is created and returned, i.e.
> the allocation is done by Read and the method is as easy to use as Read()
> ([]byte, error).
> The semantics of the error return remain the same (i.e. Read might return
> both some bytes read and an error), but that is orthogonal to the memory
> allocation.
> An example of this pattern is here
> .
>
> Given that slices are small and cheap to copy (a pointer to the data, a
> length, and a capacity) what are the downsides to using
>   func (r *Reader) Read(buf []byte) (result []byte, err error)
> as a method?
>
> I am not suggesting that we change io.Reader (that would break
> everything!), just looking for input into good Go API design.
>
> This would be a comment on Dave's fantastic blog, but the blog does not
> have comment functionality, so I'm asking here, and I know that Dave lurks
> here too.
>
> Cheers,
> Tom
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8ffb9828-c6e2-47de-bca1-ef6988f081e8%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAO6k0uvEZgHm9ppQ8sA1K-M8fA2WENf0tJG1KyTov7PXAt6GcQ%40mail.gmail.com.

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

[Mitchell Hashimoto]

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 errors.Is, all errors are checked until one matches, in which 
>case we
>succeed. If none of the errors matched, we fail. 
>
> This means that if you have multiple os.PathErrors, you can use errors.As
> to extract the first of those, and you can use errors.Is to match for
> equality against any of those.
>
> What we’d like to ask the community and the Go Developers is whether this
> behavior is what you would expect from a combined error tree like this.
>

At HashiCorp, we have our own lib go-multierror 
 and we were recently 
discussing the same thing. So thank you for opening this thread and 
appealing to the broader Go community.

We came to the same conclusions as you did, to the exact behavior. It seems 
the most reasonable to me given the current interface definitions.

So I just want to say I agree, and would love to hear from anyone else how 
they feel. 

Best,
Mitchell
 

> Thanks.
>
> Abhinav
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4af1fe63-bdc6-484b-a05f-49667f89f86d%40googlegroups.com.

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

[Dan Kortschak]

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, Michael Ellis wrote:
> 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 wrote:
> > 
> > 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 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e9296ff0af9019370cbfc96cc9d68541959868a6.camel%40kortschak.io.

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

[Benjamin]

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 golang unit test result.
2. When the exit code of "TestHelperCommand" is non-zero, then I expect the 
function which calls fakeExecCommand should get an error response, but it 
doesn't. What do I miss?

// fakeExecCommand is used to replace the real command in unit test
func fakeExecCommand(executable string, args ...string) *exec.Cmd {
newArgs := []string{"-test.run=TestHelperCommand", "--", executable}
newArgs = append(newArgs, args...)

cmd := exec.Command(os.Args[0], newArgs...)
cmd.Env = []string{
"USE_HELPER_COMMAND=1",
fmt.Sprintf("STDOUT=%s", msg),
fmt.Sprintf("EXIT_STATUS=%d", exitCode),
}

return cmd
}

func TestHelperCommand(t *testing.T) {
if os.Getenv("USE_HELPER_COMMAND") != "1" {
return
}

stdOutMsg := os.Getenv("STDOUT")
if len(stdOutMsg) > 0 {
fmt.Fprintf(os.Stdout, stdOutMsg)
}

stdErrMsg := os.Getenv("STDERR")
if len(stdErrMsg) > 0 {
fmt.Fprintf(os.Stderr, stdErrMsg)
}

exitCode, _ := strconv.Atoi(os.Getenv("EXIT_STATUS"))
os.Exit(exitCode)
}在此输入代码...

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a2849d6b-852b-4d8d-9f10-269722a4b514%40googlegroups.com.

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

[Abhishek Varshney]

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 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 with the latest release? 
> > yes 
> > 
> > 
> > What operating system and processor architecture are you using (`go 
> env`)? 
> > $ go env 
> > GO111MODULE="" 
> > GOARCH="amd64" 
> > GOBIN="/home/abhishek/myprog/golang/bin" 
> > GOCACHE="/home/abhishek/.cache/go-build" 
> > GOENV="/home/abhishek/.config/go/env" 
> > GOEXE="" 
> > GOFLAGS="" 
> > GOHOSTARCH="amd64" 
> > GOHOSTOS="linux" 
> > GONOPROXY="" 
> > GONOSUMDB="" 
> > GOOS="linux" 
> > GOPATH="/home/abhishek/myprog/golang" 
> > GOPRIVATE="" 
> > GOPROXY="https://proxy.golang.org,direct"; 
> > GOROOT="/home/abhishek/software/go" 
> > GOSUMDB="sum.golang.org" 
> > GOTMPDIR="" 
> > GOTOOLDIR="/home/abhishek/software/go/pkg/tool/linux_amd64" 
> > GCCGO="gccgo" 
> > AR="ar" 
> > CC="gcc" 
> > CXX="g++" 
> > CGO_ENABLED="1" 
> > GOMOD="" 
> > CGO_CFLAGS="-g -O2" 
> > CGO_CPPFLAGS="" 
> > CGO_CXXFLAGS="-g -O2" 
> > CGO_FFLAGS="-g -O2" 
> > CGO_LDFLAGS="-g -O2" 
> > PKG_CONFIG="pkg-config" 
> > GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build290715438=/tmp/go-build 
> -gno-record-gcc-switches" 
> >  
> > 
> > What did you do? 
> > 1. Create folder testmux in non GOPATH folder. 
> > 2. Create main.go file inside testmux. 
> > 3. Execute go mod init 
> > 4. Execute go build 
> > 
> > code for 'main.go' is present at: 
> > https://play.golang.org/p/nzbMB2v48ty 
> > 
> > Other Observation 
> > Executing same steps inside $GOPATH/src, create binary testmux. It does 
> not over write main.go. 
> > 
> > What did you expect to see? 
> > On command 'go build' inside project folder binary with project folder 
> name should be present. 
> > 
> > What did you see instead? 
> > Command 'go build' over writes main.go command with binary (ELF) format. 
> The source code is gone now. Not recoverable. 
>
> Where exactly did you create the folder testmux?  What were the exact 
> commands that you ran?  What was the exact output? 
>
> I tried to follow your direction. 
>
> > mkdir /tmp/x 
> > cd /tmp/x 
> >  
> > go mod init 
> go: cannot determine module path for source directory /tmp/x (outside 
> GOPATH, module path must be specified) 
>
> Example usage: 
> 'go mod init example.com/m' to initialize a v0 or v1 module 
> 'go mod init example.com/m/v2' to initialize a v2 module 
>
> Run 'go help mod init' for more information. 
>
> What did you see when you ran "go mod init"? 
>
> Ian 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3ceb7e04-ff85-42ed-a0ba-7a9541bc289d%40googlegroups.com.

[go-nuts] THANKS GO TEAM FOR GOLANG'S NEW VERSION.

[jfrankogramos]

THIS IS NOT ABOUT MISTAKES IS ABOUT THANKS TO ALL PEOPLE THAT MAKE GOLANG A 
FANTASTIC CHOISE IN THE LANDSCAPE OF PROGRAMMING LANGUAGES.
I'M A NOVATE WITH GOLANG BUT I HOPE TO CAN HELP SOME DAY AND AGAIN THANKS A 
LOT. AND GREETINGS FROM GUATEMALA

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/62a44b24-136c-47d9-b3fc-74febd1144e1%40googlegroups.com.