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

['Axel Wagner' via golang-nuts]

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
positives, where code gets moved around in a refactoring, appears in the
diff because of a `go fmt` re-indent (e.g. in a struct or var/const block)
or even when it wasn't changed at all, the heuristic just chose the one way
to chunk the changes that included the relevant line.
Like, I'm sure we all saw plenty of occasions where a commit we reviewed
wasn't diff'ed in the way we expected.

Best,

Axel

On Fri, Nov 20, 2020 at 5:45 AM Hunter Herman 
wrote:

> 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.
>
> It’s like a soft deletion.
>
> I would personally love for go to be able to start removing apis in this
> way.
>
> --
> 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/A88E356C-7849-4223-B67D-CA2F348708B6%40gmail.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/CAEkBMfG4q2khyV7KMJMx4K%3DUqhrxm-wudQ8v%3DDHXLgyHGkYoBg%40mail.gmail.com.

[go-nuts] Block deprecated methods in git diffs

[Hunter Herman]

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. 

It’s like a soft deletion. 

I would personally love for go to be able to start removing apis in this way. 

-- 
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/A88E356C-7849-4223-B67D-CA2F348708B6%40gmail.com.

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

['Dan Kortschak' via golang-nuts]

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, the module golang.org/x/tools/gopls
> is defined in the gopls subdirectory of the repository with root path
> golang.org/x/tools. The version v0.4.0 of that module must have the
> tag named gopls/v0.4.0 in that repository.


On Thu, 2020-11-19 at 19:28 -0800, Victor Denisov wrote:
> Interesting. Thanks, I'll give it a try.
> 


-- 
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/79bc923dbe22db64eca54e2445c97049825d109e.camel%40kortschak.io.

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

[Victor Denisov]

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 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 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 the
> > go.mod of my application that uses this library I can't do it because
> > go build complains that ref v1.2.3 is not found.
> >
> > The line that I specify in my go.mod looks as follows:
> > github.com/username/reponame/path/from/root v1.2.3
> >
> > However when I don't specify anything in the go.mod of my
> > application, go build successfully finds the module however it uses
> > absolute version reference in go.mod
> > github.com/username/reponame/path/from/root v0.0.0-date-commitid
> >
> > Can someone comment on this topic? I'm trying to understand whether
> > it's ok to have go.mod not in the root directory. Is this behavior
> > intentional or just a coincidence.
> >
> > Thanks in advance,
> > Victor.
> >
> > --
> > 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/65736f44-901b-435a-990f-7f6ee9dde588n%40googlegroups.com
> > .
>
>
> --
> 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/7Z6U5aKxaJI/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/3c1c0d314bc2bd519a06035d940ae4c8ba5ab8c1.camel%40kortschak.io
> .
>

-- 
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/CAOtw9WjXCXSMc2svUueWUZHTR2MFWnQ-Win9wBMgFhb_RfA2Nw%40mail.gmail.com.

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

['Dan Kortschak' via golang-nuts]

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 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 the
> go.mod of my application that uses this library I can't do it because
> go build complains that ref v1.2.3 is not found.
> 
> The line that I specify in my go.mod looks as follows:
> github.com/username/reponame/path/from/root v1.2.3
> 
> However when I don't specify anything in the go.mod of my
> application, go build successfully finds the module however it uses
> absolute version reference in go.mod
> github.com/username/reponame/path/from/root v0.0.0-date-commitid
> 
> Can someone comment on this topic? I'm trying to understand whether
> it's ok to have go.mod not in the root directory. Is this behavior
> intentional or just a coincidence.
> 
> Thanks in advance,
> Victor.
> 
> -- 
> 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/65736f44-901b-435a-990f-7f6ee9dde588n%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/3c1c0d314bc2bd519a06035d940ae4c8ba5ab8c1.camel%40kortschak.io.

[go-nuts] Go modules in gihub repos

[Victor Denisov]

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 the go.mod of 
my application that uses this library I can't do it because go build 
complains that ref v1.2.3 is not found.

The line that I specify in my go.mod looks as follows:
github.com/username/reponame/path/from/root v1.2.3

However when I don't specify anything in the go.mod of my application, go 
build successfully finds the module however it uses absolute version 
reference in go.mod
github.com/username/reponame/path/from/root v0.0.0-date-commitid

Can someone comment on this topic? I'm trying to understand whether it's ok 
to have go.mod not in the root directory. Is this behavior intentional or 
just a coincidence.

Thanks in advance,
Victor.

-- 
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/65736f44-901b-435a-990f-7f6ee9dde588n%40googlegroups.com.

Re: [go-nuts] Ballooning Executable Sizes

['Keith Randall' via golang-nuts]

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 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 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 versions amount to 172 insertions and 210 
> deletions. No module has changed version. No binary data is embedded in 
> either version. The only additional import is to a file within the project 
> and which is imported from many other places.
> >> 
> >> I can live with the new file size if that's the way it has to be, but 
> it's one heck of leap in size for a seemingly simple change.
> >> 
> >> I've isolated the change and uploaded to a new repository for easy 
> comparison. I would be very appreciative if someone could help me 
> understand what is happening.
> >> 
> >> https://github.com/JetSetIlly/Gopher2600-filesize-test
> > 
> > 
> > What version of Go are you using?
> > 
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXkgaP5xDR_2vbVTQ1YHbcjhQdYH0KvM9adwacQJwhz8g%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/86b9fccd-68e4-4ab1-ba33-2539669b5f63n%40googlegroups.com.

Re: [go-nuts] Ballooning Executable Sizes

[Robert Engels]

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 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 versions amount to 172 insertions and 210 
>> deletions. No module has changed version. No binary data is embedded in 
>> either version. The only additional import is to a file within the project 
>> and which is imported from many other places.
>> 
>> I can live with the new file size if that's the way it has to be, but it's 
>> one heck of leap in size for a seemingly simple change.
>> 
>> I've isolated the change and uploaded to a new repository for easy 
>> comparison. I would be very appreciative if someone could help me understand 
>> what is happening.
>> 
>> https://github.com/JetSetIlly/Gopher2600-filesize-test
> 
> 
> What version of Go are you using?
> 
> 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/CAOyqgcXkgaP5xDR_2vbVTQ1YHbcjhQdYH0KvM9adwacQJwhz8g%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/77DA3E3E-44D4-409F-BAC2-BFC6BDA9020F%40ix.netcom.com.

Re: [go-nuts] Ballooning Executable Sizes

[Ian Lance Taylor]

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 significantly larger in one case than the other.
>
>
> The changes between the two versions amount to 172 insertions and 210 
> deletions. No module has changed version. No binary data is embedded in 
> either version. The only additional import is to a file within the project 
> and which is imported from many other places.
>
> I can live with the new file size if that's the way it has to be, but it's 
> one heck of leap in size for a seemingly simple change.
>
> I've isolated the change and uploaded to a new repository for easy 
> comparison. I would be very appreciative if someone could help me understand 
> what is happening.
>
> https://github.com/JetSetIlly/Gopher2600-filesize-test


What version of Go are you using?

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/CAOyqgcXkgaP5xDR_2vbVTQ1YHbcjhQdYH0KvM9adwacQJwhz8g%40mail.gmail.com.

Re: [go-nuts] Ballooning Executable Sizes

[Rob Pike]

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 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 versions amount to 172 insertions and 210
> deletions. No module has changed version. No binary data is embedded in
> either version. The only additional import is to a file within the project
> and which is imported from many other places.
>
> I can live with the new file size if that's the way it has to be, but it's
> one heck of leap in size for a seemingly simple change.
>
> I've isolated the change and uploaded to a new repository for easy
> comparison. I would be very appreciative if someone could help me
> understand what is happening.
>
> https://github.com/JetSetIlly/Gopher2600-filesize-test
>
>
> Regards
>
> Stephen Illingworth
>
> --
> 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/9006c660-bd92-4293-87fc-fab8af1aca26n%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/CAOXNBZRvfpmTpu0Te6yMHqLiN8gXGMdy_6r5wOo6h0apdSd9nw%40mail.gmail.com.

[go-nuts] Ballooning Executable Sizes

[stephen.t....@gmail.com]

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 versions amount to 172 insertions and 210 
deletions. No module has changed version. No binary data is embedded in 
either version. The only additional import is to a file within the project 
and which is imported from many other places.

I can live with the new file size if that's the way it has to be, but it's 
one heck of leap in size for a seemingly simple change.

I've isolated the change and uploaded to a new repository for easy 
comparison. I would be very appreciative if someone could help me 
understand what is happening.

https://github.com/JetSetIlly/Gopher2600-filesize-test


Regards

Stephen Illingworth

-- 
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/9006c660-bd92-4293-87fc-fab8af1aca26n%40googlegroups.com.

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

[ben...@gmail.com]

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, September 17, 2015 at 2:16:06 PM UTC+12 Th3x0d3r wrote:

> What I'm trying to do is:
>
> out, err := exec.Command("echo","%PROCESSOR_ARCHITECTURE%").Output()
>
> but same result:
>
> *exec: "echo": executable file not found in %PATH%*
>
>

-- 
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/c8873199-57e1-47b0-9b2b-7c9c49af8288n%40googlegroups.com.

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

['Than McIntosh' via golang-nuts]

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  wrote:

> 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 gollvm and llvm-goc
> successfully.
>
> But something confuse me that is i can not import external package while
> using llvm-goc to dump llvm ir.
>
> For example, i've tried dump the code below to llvm-ir,
>
> ===
> *package main*
>
> *import (*
> *"fmt"*
> *"test/testg"*
> *)*
>
> *func add(x, y int) int {*
> *return x + y*
> *}*
>
>
> *func main() {*
> *var c = testg.Color{}*
> *a := 5000*
> *//b := 4*
> *fmt.Println(add(a, c.C))*
> *}*
> ===
> But llvm-goc returns errors:
>
> ===
> *./main.go:5:15: error: import file 'test/testg' not found*
> *./main.go:14:24: error: expected ';' or '}' or newline*
> *./main.go:15:5: error: expected declaration*
> *./main.go:17:5: error: expected declaration*
> *./main.go:18:1: error: expected declaration*
> *./main.go:14:13: error: reference to undefined name 'testg'*
> ===
>
> I wonder whether the llvm-goc can use external packages? Or is there
> anyway to dump llvm-ir from go source file ?
>
> --
> 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/5ae30fb1-1461-4b40-bfb9-6845a40dd31an%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/CA%2BUr55E5SnvsijKBWpwM%3Do2yVCwDbfeR_8yg3AnTQZGc8Q_QSw%40mail.gmail.com.

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

[jw jiang]

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 gollvm and llvm-goc 
successfully.

But something confuse me that is i can not import external package while 
using llvm-goc to dump llvm ir.

For example, i've tried dump the code below to llvm-ir,

===
*package main*

*import (*
*"fmt"*
*"test/testg"*
*)*

*func add(x, y int) int {*
*return x + y*
*}*


*func main() {*
*var c = testg.Color{}*
*a := 5000*
*//b := 4*
*fmt.Println(add(a, c.C))*
*}*
===
But llvm-goc returns errors:

===
*./main.go:5:15: error: import file 'test/testg' not found*
*./main.go:14:24: error: expected ';' or '}' or newline*
*./main.go:15:5: error: expected declaration*
*./main.go:17:5: error: expected declaration*
*./main.go:18:1: error: expected declaration*
*./main.go:14:13: error: reference to undefined name 'testg'*
===

I wonder whether the llvm-goc can use external packages? Or is there anyway 
to dump llvm-ir from go source file ?

-- 
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/5ae30fb1-1461-4b40-bfb9-6845a40dd31an%40googlegroups.com.

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

[Space A.]

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, 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:
>>
>> [info][timestamp] [filename:line_number] message k1=v1 k2=v2 ...
>>
>> It shows the correct file name(need to pop out a few call stacks) and 
>> line number in a customizable format, not as key-value pair for each line 
>> which is just too verbose to have the extra "time=" "file=".
>>
>> Please let me know the one you actually use.
>>
>>
>> Thanks!
>> Chris
>> -
>> https://github.com/chrislusf/seaweedfs
>>
>

-- 
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/0050ca29-a406-4d30-b375-b5d3dd871dban%40googlegroups.com.

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

[Denis Cheremisov]

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:
>
> [info][timestamp] [filename:line_number] message k1=v1 k2=v2 ...
>
> It shows the correct file name(need to pop out a few call stacks) and line 
> number in a customizable format, not as key-value pair for each line which 
> is just too verbose to have the extra "time=" "file=".
>
> Please let me know the one you actually use.
>
>
> Thanks!
> Chris
> -
> https://github.com/chrislusf/seaweedfs
>

-- 
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/5cff0a88-bcb5-4f5b-bc8f-8ca3e838ff19n%40googlegroups.com.