Re: [go-nuts] Block deprecated methods in git diffs

Hi, I think this would best be prototyped as a third party project. One potentially deal-breaking issue I see with this approach is that diffs aren't precise (or rather, what they precisely are doesn't align well with what humans expect). I'd imagine that you'd come up with tons of false

[go-nuts] Block deprecated methods in git diffs

Go can’t break backwards compatibility, but we all know there are apis and features we wished were removed. What if go vet was extended to check if deprecated apis were used in the current git diff? Go can’t delete apis, but by extending go vet it can push back hard against their usage.

Re: [go-nuts] Go modules in gihub repos

Reference: https://golang.org/ref/mod#vcs-version > If a module is defined in a subdirectory within the repository, that > is, the module subdirectory portion of the module path is not empty, > then each tag name must be prefixed with the module subdirectory, > followed by a slash. For example,

Re: [go-nuts] Go modules in gihub repos

Interesting. Thanks, I'll give it a try. On Thu, Nov 19, 2020 at 7:08 PM 'Dan Kortschak' via golang-nuts < golang-nuts@googlegroups.com> wrote: > You should tag the version with the path to the module root: for > example path/from/root/v1.2.3 > > On Thu, 2020-11-19 at 18:58 -0800, Victor Denisov

Re: [go-nuts] Go modules in gihub repos

You should tag the version with the path to the module root: for example path/from/root/v1.2.3 On Thu, 2020-11-19 at 18:58 -0800, Victor Denisov wrote: > Hi, > > I've recently encountered an interesting behavior of go modules. > I have a library in a repository on github. The go.mod file for

[go-nuts] Go modules in gihub repos

Hi, I've recently encountered an interesting behavior of go modules. I have a library in a repository on github. The go.mod file for this library is not in the root directory of the repo. I create a signed tag in the repo, say v1.2.3. However when I try referring the full path to the module in

Re: [go-nuts] Ballooning Executable Sizes

This was traced down to passing very large (multi-MB) types by value. TL;DR, don't do that. See the issue for more details. On Thursday, November 19, 2020 at 12:59:32 PM UTC-8 ren...@ix.netcom.com wrote: > Based on the OP it is occurring with 1.13,14,15 > > > On Nov 19, 2020, at 2:19 PM, Ian

Re: [go-nuts] Ballooning Executable Sizes

Based on the OP it is occurring with 1.13,14,15 > On Nov 19, 2020, at 2:19 PM, Ian Lance Taylor wrote: > > On Thu, Nov 19, 2020 at 11:34 AM stephen.t@gmail.com > wrote: >> >> I have a reasonably sized project that produces executables that have >> ballooned in size between two

Re: [go-nuts] Ballooning Executable Sizes

On Thu, Nov 19, 2020 at 11:34 AM stephen.t@gmail.com wrote: > > I have a reasonably sized project that produces executables that have > ballooned in size between two relatively simple commits. > > I've tested with three compiler versions and in each case the executable size > is

Re: [go-nuts] Ballooning Executable Sizes

Filed https://github.com/golang/go/issues/42729 On Fri, Nov 20, 2020 at 6:34 AM stephen.t@gmail.com < stephen.t.illingwo...@gmail.com> wrote: > Hello, > > I have a reasonably sized project that produces executables that have > ballooned in size between two relatively simple commits. > > I've

[go-nuts] Ballooning Executable Sizes

Hello, I have a reasonably sized project that produces executables that have ballooned in size between two relatively simple commits. I've tested with three compiler versions and in each case the executable size is significantly larger in one case than the other. The changes between the two

[go-nuts] Re: exec: "date": executable file not found in %PATH%

If you do want to find the processor architecture, instead of shelling out, can you use runtime.GOARCH? See https://golang.org/pkg/runtime/#pkg-constants -- it has a value like "amd64", similar to PROCESSOR_ARCHITECTURE on Windows. It also works on different platforms/OSes. On Thursday,

Re: [go-nuts] Does it support using external package in gollvm?

Can you please post the exact commands you're using? The recipe in https://go.googlesource.com/gollvm#seetheir is meant to give you an idea as to how to do this, but without seeing exactly what you typed it's hard to tell what the problem s. Thanks. On Thu, Nov 19, 2020 at 8:57 AM jw jiang

[go-nuts] Does it support using external package in gollvm?

i've read some papers said that he changed the go source file to llvm ir using llgo. but i found that llgo is not maintained . So i search and find gollvm in https://go.googlesource.com/gollvm#seetheir. i follow its instruction steps and build the

[go-nuts] Re: Any recommendation for structured logging library in Golang?

If you want to go for structured and layered logging in JSON, consider https://github.com/francoispqt/onelog четверг, 19 ноября 2020 г. в 12:14:21 UTC+3, Denis Cheremisov: > Zerolog does the trick, need a bit of setup though for what you want > > среда, 18 ноября 2020 г. в 07:21:48 UTC+3,

[go-nuts] Re: Any recommendation for structured logging library in Golang?

Zerolog does the trick, need a bit of setup though for what you want среда, 18 ноября 2020 г. в 07:21:48 UTC+3, ChrisLu: > I am considering moving from glog to structured logging. I tried logrus, > go-kit, uber/zap, but could not find one good fit. In short, this is the > desired format: > >