Re: [go-nuts] Tests skipping
On Monday, 23 March 2020 06:37:45 UTC, Shane H wrote: > > The output of the go test is > TestQuoteDate (skipping) // or words to that effect > > Could you copy-paste the exact, verbatim output of the test run when it does this? With a few lines either side for context? -- 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/5b799ba4-6e90-413e-bb42-6eeb37e2fb33%40googlegroups.com.
Re: [go-nuts] Re: Mem-Leak in Go method
Yes. You have a leak in your Go code. It shows you the object types that are
taking up all of the space. There is no root analysis available in Go. Read the
paper I linked to.
> On Mar 23, 2020, at 9:12 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> I used something like the following to generate a memprof for 100 minutes
>
> func main() {
> flag.Parse()
> if *cpuprofile != "" {
> f, err := os.Create(*cpuprofile)
> if err != nil {
> fmt.Println("could not create CPU profile: ", err)
> }
> defer f.Close() // error handling omitted for example
> if err := pprof.StartCPUProfile(f); err != nil {
> fmt.Print("could not start CPU profile: ", err)
> }
> defer pprof.StopCPUProfile()
> }
> timeout := time.After(100 * time.Minute)
> A_chan := make(chan bool)
> B_chan := make(chan bool)
> go util.A(A_chan)
> go util.B(B_chan)
> (..Rest of the code..)
>
> for {
> select {
> case <-A_chan:
> continue
> case <-B_chan:
> continue
> case <-timeout:
> break
> }
> break
> }
>
> if *memprofile != "" {
> count = count + 1
> fmt.Println("Generating Mem Profile:")
> fmt.Print(count)
> f, err := os.Create(*memprofile)
> if err != nil {
> fmt.Println("could not create memory profile: ", err)
> }
> defer f.Close() // error handling omitted for example
> runtime.GC()// get up-to-date statistics
> if err := pprof.WriteHeapProfile(f); err != nil {
> fmt.Println("could not write memory profile: ", err)
> }
>
> }
> }
>
> /Desktop/memprof:go tool pprof --alloc_space main mem3.prof
> Fetched 1 source profiles out of 2
> File: main
> Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
> Type: alloc_space
> Time: Mar 22, 2020 at 7:02pm (IST)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top
> Showing nodes accounting for 17818.11MB, 87.65% of 20329.62MB total
> <<<
> Dropped 445 nodes (cum <= 101.65MB)
> Showing top 10 nodes out of 58
> flat flat% sum%cum cum%
> 11999.09MB 59.02% 59.02% 19800.37MB 97.40% home/nsaboo/project/aws.Events
> 1675.69MB 8.24% 67.27% 1911.69MB 9.40%
> home/nsaboo/project/utils.Unflatten
> 627.21MB 3.09% 70.35% 1475.10MB 7.26% encoding/json.mapEncoder.encode
> 626.76MB 3.08% 73.43% 626.76MB 3.08% encoding/json.(*Decoder).refill
> 611.95MB 3.01% 76.44% 4557.69MB 22.42% home/nsaboo/project/lib.format
> 569.97MB 2.80% 79.25% 569.97MB 2.80% os.(*File).WriteString
> 558.95MB 2.75% 82.00% 2034.05MB 10.01% encoding/json.Marshal
> 447.51MB 2.20% 84.20% 447.51MB 2.20% reflect.copyVal
> 356.10MB 1.75% 85.95% 432.28MB 2.13% compress/flate.NewWriter
> 344.88MB 1.70% 87.65% 590.38MB 2.90% reflect.Value.MapKeys
>
> 1)Is this the correct way of getting a memory profile?
>
> 2)I ran the service for 100 minutes on a machine with 8GB memory. How am I
> seeing memory accounting for around 17GB?
>
> 3)I understand 'flat' means memory occupied within that method, but how come
> it shot up more than the available memory? Hence, asking if the above process
> is the correct way of gathering the memory profile.
>
> Thanks,
> Nitish
>
>> On Fri, Mar 13, 2020 at 6:22 PM Michael Jones
>> wrote:
>> hi. get the time at the start, check the elapsed time in your infinite loop,
>> and trigger the write/exit after a minute, 10 minutes, 100 minutes, ...
>>
>>> On Fri, Mar 13, 2020 at 5:45 AM Nitish Saboo
>>> wrote:
>>> Hi Michael,
>>>
>>> Thanks for your response.
>>>
>>> That code looks wrong. I see the end but not the start. Look here and copy
>>> carefully:
>>>
>>> >>Since I did not want cpu profiling I omitted the start of the code and
>>> >>just added memory profiling part.
>>>
>>> Call at end, on way out.
>>>
>>> >>Oh yes, I missed that.I have to call memory profiling code at the end on
>>> >>the way out.But the thing is that it runs as a service in infinite for
>>> >>loop.
>>>
>>> func main() {
>>> flag.Parse()
>>> if *cpuprofile != "" {
>>> f, err := os.Create(*cpuprofile)
>>> if err != nil {
>>> fmt.Println("could not create CPU profile: ", err)
>>> }
>>> defer f.Close() // error handling omitted for example
>>> if err := pprof.StartCPUProfile(f); err != nil {
>>> fmt.Print("could not start CPU profile: ", err)
>>> }
>>> defer pprof.StopCPUProfile()
>>> }
>>>
>>> A_chan := make(chan bool)
>>> B_chan := make(chan bool)
>>> go util.A(A_chan)
>>> go util.B(B_chan)
>>> (..Rest of the code..)
>>>
>>> for {
>>> select {
>>> case <-A_chan:
>>> continue
>>> case <-B_chan:
>>> continue
>>>
>>> }
>>> }
>>>
>>> }
>>>
>>> What would be the correct way to add the memprofile code changes, since it
>>> is running in an infinite for loop ?
>>>
>>> Also, as shared by others above, there are no promises about how soon the
>>> dead allocations go away, The speed gets faster and faster version to
>>> version, and is impressive indeed now, so old versions are not the best to
>>> use, ubt even so, if the allocation feels small to th GC the urgency to
>>> free it will be low. You need to loop
Re: [go-nuts] Tests skipping
I noticed that the `t.Run` call in the sample code provided is `t,Run`
instead (note the comma). I'm not sure how that compiles, but it might be
worth checking on that.
On Mon, Mar 23, 2020 at 3:16 PM Ian Lance Taylor wrote:
> On Sun, Mar 22, 2020 at 11:38 PM Shane H wrote:
> >
> > On Monday, March 23, 2020 at 2:49:46 PM UTC+11, Ian Lance Taylor wrote:
> >>
> >> On Sun, Mar 22, 2020 at 7:10 PM Shane H wrote:
> >> >
> >> > I'm a lot confused by the behaviour of some tests I have at the
> moment, they're skipping.. when there's no skip or timeout or... anything
> that I can see
> >> >
> >> > I know this is going to be difficult because I don't have code I can
> paste to show what's happening
> >> >
> >> > I'm using go1.13.9, but this behaviour was also happening with
> go1.13.7
> >> >
> >> > I have tests run from a script with
> >> > go test ./... -v -count=1 // Note count=1 was added to try and stop
> the behaviour
> >> >
> >> > The tests that I am interested are table tests run inside
> >> > for _, testCase := range tt {
> >> > testCase := testCase
> >> > t,Run(testCase.name, func(t *testing.T) {
> >> > res, err := http.DefaultClientDo(testCase.before(t))
> >> > require.NoError(t, err)
> >> > defer res.Body.Close()
> >> > testCase.check(t, res)
> >> > }
> >> > }
> >> >
> >> > When I set two of the tests to time.Sleep(time.Millisecond * 1000)
> the tests should fail
> >> >
> >> > Sometimes they do, but sometimes they instead Skip, or even report
> that they were run, passed, with an updated time (they shouldn't pass)
> >> >
> >> > Can someone point me in the direction of some helpful (perhaps)
> documentation if that's what I need to read?
> >>
> >> What do you mean when you say that the tests are skipped? What is the
> >> output of your "go test" command?
> >>
> >> Can you show us a small complete test case that demonstrates the
> problem?
> >>
> >> Ian
> >
> >
> > I wish I could (provide a test case), but it only happens on my branch.
> >
> > The output of the go test is
> > TestQuoteDate (skipping) // or words to that effect
> >
> > I'm thinking that it /has/ to be user error, but I cannot see what I'm
> doing that's causing the problem (except making the test sleep so I can
> make the API I am interacting with trigger a bug I am trying to track down)
>
> Based on what you've said so far, I really don't see any way that this
> could be a problem in the Go tools.
>
> 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/CAOyqgcUPfHZHsvhNdiKX%3DKafV0jy2nmaOcu2s3c0YKxvaNxw1g%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/CANGiwgYu5%3DFEHe2-MowGV%2BaNb%3D2FZg7hJDTzJ8%3DLtdmGOhrJMw%40mail.gmail.com.
Re: [go-nuts] Tests skipping
On Sun, Mar 22, 2020 at 11:38 PM Shane H wrote:
>
> On Monday, March 23, 2020 at 2:49:46 PM UTC+11, Ian Lance Taylor wrote:
>>
>> On Sun, Mar 22, 2020 at 7:10 PM Shane H wrote:
>> >
>> > I'm a lot confused by the behaviour of some tests I have at the moment,
>> > they're skipping.. when there's no skip or timeout or... anything that I
>> > can see
>> >
>> > I know this is going to be difficult because I don't have code I can paste
>> > to show what's happening
>> >
>> > I'm using go1.13.9, but this behaviour was also happening with go1.13.7
>> >
>> > I have tests run from a script with
>> > go test ./... -v -count=1 // Note count=1 was added to try and stop the
>> > behaviour
>> >
>> > The tests that I am interested are table tests run inside
>> > for _, testCase := range tt {
>> > testCase := testCase
>> > t,Run(testCase.name, func(t *testing.T) {
>> > res, err := http.DefaultClientDo(testCase.before(t))
>> > require.NoError(t, err)
>> > defer res.Body.Close()
>> > testCase.check(t, res)
>> > }
>> > }
>> >
>> > When I set two of the tests to time.Sleep(time.Millisecond * 1000) the
>> > tests should fail
>> >
>> > Sometimes they do, but sometimes they instead Skip, or even report that
>> > they were run, passed, with an updated time (they shouldn't pass)
>> >
>> > Can someone point me in the direction of some helpful (perhaps)
>> > documentation if that's what I need to read?
>>
>> What do you mean when you say that the tests are skipped? What is the
>> output of your "go test" command?
>>
>> Can you show us a small complete test case that demonstrates the problem?
>>
>> Ian
>
>
> I wish I could (provide a test case), but it only happens on my branch.
>
> The output of the go test is
> TestQuoteDate (skipping) // or words to that effect
>
> I'm thinking that it /has/ to be user error, but I cannot see what I'm doing
> that's causing the problem (except making the test sleep so I can make the
> API I am interacting with trigger a bug I am trying to track down)
Based on what you've said so far, I really don't see any way that this
could be a problem in the Go tools.
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/CAOyqgcUPfHZHsvhNdiKX%3DKafV0jy2nmaOcu2s3c0YKxvaNxw1g%40mail.gmail.com.
[go-nuts] Re: go tip: random high CPU usage on VirtualBox
> On 15 Mar 2020, at 07.02, Ian Lance Taylor wrote: > > On Sat, Mar 14, 2020 at 1:56 AM Mhd Shulhan wrote: >> >> Pada tanggal Sab, 14 Mar 2020 06.15, Ian Lance Taylor >> menulis: >>> >>> On Fri, Mar 13, 2020 at 1:05 AM Mhd Shulhan wrote: > On 12 Mar 2020, at 13.13, Mhd Shulhan wrote: > > >> My question is any one have idea how to debug this so I can provide more >> detailed report? >> >> Thank you in advance. > > So, I try to debug with gdb 9.1. Here is the sample of stack when the > CPU got high, > > ... > [New LWP 1885] > [New LWP 1886] > [New LWP 1887] > [New LWP 1888] > [New LWP 1889] > ^C > Thread 1 "XYZ" received signal SIGINT, Interrupt. > runtime.futex () at /Users/XXX/share/go/src/runtime/sys_linux_amd64.s:568 > 568 /Users/X/share/go/src/runtime/sys_linux_amd64.s: No such file or > directory. > (gdb) where > #0 runtime.futex () at > /Users/XXX/share/go/src/runtime/sys_linux_amd64.s:568 > #1 0x00431666 in runtime.futexsleep (addr=0xd6a3e8 > , val=0, ns=-1) at > /Users/XXX/share/go/src/runtime/os_linux.go:44 > #2 0x0040bd9f in runtime.notesleep (n=0xd6a3e8 ) > at /Users/XXX/share/go/src/runtime/lock_futex.go:151 > #3 0x0043b858 in runtime.stoplockedm () at > /Users/XXX/share/go/src/runtime/proc.go:1972 > #4 0x0043d4c6 in runtime.schedule () at > /Users/XXX/share/go/src/runtime/proc.go:2455 > #5 0x0043d89d in runtime.park_m (gp=0xc000166c00) at > /Users/XXX/share/go/src/runtime/proc.go:2691 > #6 0x004651fb in runtime.mcall () at > /Users/XXX/share/go/src/runtime/asm_amd64.s:318 > #7 0x00465114 in runtime.rt0_go () at > /Users/XXX/share/go/src/runtime/asm_amd64.s:220 > #8 0x in ?? () > ... > > Rebuild with `-gcflags=all="-N -l"` and running it again result in the > same stack trace. > > > Looking at git blame for each files does not shown any new commit > introduced since after Go 1.14. Maybe others can look. > > The next thing I will do is bissecting and rebuild and report again. According to my bisection, the following commit cause it, 14:18 ~/src/go (af1f3b0082...)|BISECTING tokenomy 0 % git bisect good 98858c438016bbafd161b502a148558987aa44d5 is the first bad commit commit 98858c438016bbafd161b502a148558987aa44d5 Author: Ian Lance Taylor Date: Tue Feb 25 20:23:15 2020 -0800 runtime: don't panic on racy use of timers If we see a racy use of timers, as in concurrent calls to Timer.Reset, do the operations in an unpredictable order, rather than crashing. Fixes #37400 Change-Id: Idbac295df2dfd551b6d762909d5040fc532c1b34 Reviewed-on: https://go-review.googlesource.com/c/go/+/221077 Run-TryBot: Ian Lance Taylor TryBot-Result: Gobot Gobot Reviewed-by: Michael Knyszek src/runtime/time.go | 216 -- src/time/time_test.go | 40 ++ 2 files changed, 92 insertions(+), 164 deletions(-) Link to CL: https://go-review.googlesource.com/c/go/+/221077 If anyone have any idea the minimal test code to test it on my VM, I will test it. >>> >>> That seems like a fairly unlikely culprit for significantly increased >>> CPU usage. Can you double check? >> >> >> Thanks for the response Ian. >> >> I am actually run the bisect twice. >> >> I have also test by reverting that commit on top of latest tip and rebuild >> and redeploy, the result is the random CPU spike doesn't happened anymore. >> >> The weird thing is between all 5 services not all of them suddenly consume >> high CPU, sometimes only one service, sometimes two of them but not three, >> four, or five at the same time. >> >> I will give it one more bisect next Monday. >> >>> >>> If you are sure that is the CL, please open a bug report at >>> https://golang.org/issue. Anything you can give us to recreate the >>> problem ourselves would be very helpful. Thanks. Someone has created the issue [1] before I finish the bisection and looking for more information. I add some information in the issue, I hope that help. [1] https://github.com/golang/go/issues/38023 -- 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/4F10C9ED-1BA4-493C-9739-194C4C377ABE%40gmail.com.
[go-nuts] How to deal with 'Expect:100-continue'
I want to return "too large body" response whenever a request's body is
larger than setting.
However, when the request has "Expect" header, the connection may be reset
if the requestbody is not read to end.
Then, I added check function. The function check 'Content-Length' and
return error response if the length is larger than setting.
if !checkExpect(request.Header) { // check if "Expect" header exists
// do nothing...( this block is to take C1 coverage )
} else {
return NewError("body is too large")
}
buf := bytes.NewBuffer([]byte{})
_, err := io.CopyN(buf, request.Body, setting + 1)
if err == nil {
return NewError("body is too large")
} else if err == io.EOF {
// do nothing...( this block is to take C1 coverage )
} else {
return NewError("failed to read")
}
But, if 'Content-Length' is camouflaged and smaller than real bodysize,
this code read body and connection may be reset.
In addition, if the request has "Transfer-Encoding" header,
request.ContentLength is -1.
Why the connection is reset when the requestbody is not read to end?
When "Content-Length" header is camoflauged or negative value, How should I
keep the connection?
--
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/5982d5ed-3ce4-4a26-b84a-6a5d2094c45d%40googlegroups.com.
[go-nuts] Re: Docker Server access Failed
I will try thank you On Sunday, March 22, 2020 at 6:28:07 PM UTC+5, Ali Hassan wrote: > > Please help me this is my repo where I'm working docker-golang . May be > some problem my server access failed on my browser > > https://github.com/ali2210/DockerTest > -- 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/d2d82cce-61ee-4c4a-8afb-eb5e00a1452b%40googlegroups.com.
Re: [go-nuts] Re: Mem-Leak in Go method
Hi,
I used something like the following to generate a memprof for 100 minutes
func main() {
flag.Parse()
if *cpuprofile != "" {
f, err := os.Create(*cpuprofile)
if err != nil {
fmt.Println("could not create CPU profile: ", err)
}
defer f.Close() // error handling omitted for example
if err := pprof.StartCPUProfile(f); err != nil {
fmt.Print("could not start CPU profile: ", err)
}
defer pprof.StopCPUProfile()
}
timeout := time.After(100 * time.Minute)
A_chan := make(chan bool)
B_chan := make(chan bool)
go util.A(A_chan)
go util.B(B_chan)
(..Rest of the code..)
for {
select {
case <-A_chan:
continue
case <-B_chan:
continue
case <-timeout:
break
}
break
}
if *memprofile != "" {
count = count + 1
fmt.Println("Generating Mem Profile:")
fmt.Print(count)
f, err := os.Create(*memprofile)
if err != nil {
fmt.Println("could not create memory profile: ", err)
}
defer f.Close() // error handling omitted for example
runtime.GC()// get up-to-date statistics
if err := pprof.WriteHeapProfile(f); err != nil {
fmt.Println("could not write memory profile: ", err)
}
}
}
/Desktop/memprof:go tool pprof --alloc_space main mem3.prof
Fetched 1 source profiles out of 2
File: main
Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
Type: alloc_space
Time: Mar 22, 2020 at 7:02pm (IST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 17818.11MB, 87.65% of 20329.62MB total
<<<
Dropped 445 nodes (cum <= 101.65MB)
Showing top 10 nodes out of 58
flat flat% sum%cum cum%
11999.09MB 59.02% 59.02% 19800.37MB 97.40% home/nsaboo/project/aws.Events
1675.69MB 8.24% 67.27% 1911.69MB 9.40%
home/nsaboo/project/utils.Unflatten
627.21MB 3.09% 70.35% 1475.10MB 7.26% encoding/json.mapEncoder.encode
626.76MB 3.08% 73.43% 626.76MB 3.08% encoding/json.(*Decoder).refill
611.95MB 3.01% 76.44% 4557.69MB 22.42% home/nsaboo/project/lib.format
569.97MB 2.80% 79.25% 569.97MB 2.80% os.(*File).WriteString
558.95MB 2.75% 82.00% 2034.05MB 10.01% encoding/json.Marshal
447.51MB 2.20% 84.20% 447.51MB 2.20% reflect.copyVal
356.10MB 1.75% 85.95% 432.28MB 2.13% compress/flate.NewWriter
344.88MB 1.70% 87.65% 590.38MB 2.90% reflect.Value.MapKeys
1)Is this the correct way of getting a memory profile?
2)I ran the service for 100 minutes on a machine with 8GB memory. How am I
seeing memory accounting for around 17GB?
3)I understand 'flat' means memory occupied within that method, but how
come it shot up more than the available memory? Hence, asking if the above
process is the correct way of gathering the memory profile.
Thanks,
Nitish
On Fri, Mar 13, 2020 at 6:22 PM Michael Jones
wrote:
> hi. get the time at the start, check the elapsed time in your infinite
> loop, and trigger the write/exit after a minute, 10 minutes, 100 minutes,
> ...
>
> On Fri, Mar 13, 2020 at 5:45 AM Nitish Saboo
> wrote:
>
>> Hi Michael,
>>
>> Thanks for your response.
>>
>> That code looks wrong. I see the end but not the start. Look here and
>> copy carefully:
>>
>> >>Since I did not want cpu profiling I omitted the start of the code and
>> just added memory profiling part.
>>
>> Call at end, on way out.
>>
>> >>Oh yes, I missed that.I have to call memory profiling code at the end
>> on the way out.But the thing is that it runs as a service in infinite for
>> loop.
>>
>> func main() {
>> flag.Parse()
>> if *cpuprofile != "" {
>> f, err := os.Create(*cpuprofile)
>> if err != nil {
>> fmt.Println("could not create CPU profile: ", err)
>> }
>> defer f.Close() // error handling omitted for example
>> if err := pprof.StartCPUProfile(f); err != nil {
>> fmt.Print("could not start CPU profile: ", err)
>> }
>> defer pprof.StopCPUProfile()
>> }
>>
>> A_chan := make(chan bool)
>> B_chan := make(chan bool)
>> go util.A(A_chan)
>> go util.B(B_chan)
>> (..Rest of the code..)
>>
>> for {
>> select {
>> case <-A_chan:
>> continue
>> case <-B_chan:
>> continue
>>
>> }
>> }
>>
>> }
>>
>> What would be the correct way to add the memprofile code changes, since
>> it is running in an infinite for loop ?
>>
>> Also, as shared by others above, there are no promises about how soon the
>> dead allocations go away, The speed gets faster and faster version to
>> version, and is impressive indeed now, so old versions are not the best to
>> use, ubt even so, if the allocation feels small to th GC the urgency to
>> free it will be low. You need to loop in allocating and see if the memory
>> grows and grows.
>>
>> >> Yes, got it.I will try using the latest version of Go and check the
>> behavior.
>>
>> Thanks,
>> Nitish
>>
>> On Fri, Mar 13, 2020 at 6:20 AM Michael Jones
>> wrote:
>>
>>> That code looks wrong. I see the end but not the start. Look here and
>>> copy carefully:
>>> https://golang.org/pkg/runtime/pprof/
>>>
>>> Call at end, on way out.
>>>
>>> Also, as shared by others above, there are no promises about how soon
>>> the dead allocations go away, The
Re: [go-nuts] If in doubt prefer to wrap errors with %v, not %w?
On Mon, Mar 23, 2020 at 10:28 AM Adrian Ratnapala < adrian.ratnap...@gmail.com> wrote: > I think this is the classic dynamic vs. static typing trade-off. I don't fully agree here - I think it's perfectly possible to have all of the flexibility and all of the static type-checking. I'm having trouble putting it into words exactly, but I think both Java's subtype based checked exceptions and Haskell's HM type inference are approaches to achieve that. Of course, both have their own downsides, so you can't fully escape the tradeoff. But personally, I still kind of feel that it would've been possible to add variance to `func()` and `interface` type constructors and get a pretty decent way to solve these problems with static type checking. But it's not actually trivial, so I won't complain about it :) So to turn this discussion into something actionable: should this > advice be added into the documentation? And if so, where (in package > fmt or errors)? > I don't think there is broad concensus on this in the community. At least that was my impression whenever I talked about it with people at conferences and meetups. Even worse, I don't even think there is a phrasing of this advice that is both sufficiently broad to be applicable and sufficiently specific to be agreeable *to myself*. Like, there is a reason I chose to mention examples, instead of coming up with a rule. To me, at least, API design is hard and kind of an art form. I sort of scoff at sage advice about it, because as far as I can tell, all of it has exceptions and sometimes it feels that it has more exceptions than regular cases :) Without consensus, I don't think there will be more "official" advice than what you've already mentioned in your original message :) And even that is pretty clear: > There is no single answer to this question; it depends on the context in which the new error is created. Lots of programers will assume that because %w is new, then it must be > the Go team's recommended "best practice". I think I was unconciously > thinking that until I read the blog post. > > > > -- > Adrian Ratnapala > -- 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/CAEkBMfHb8E5SJEKd%2B529PnQGLFDOsGAV%2B_-KnWxU%3DxoyazeQVw%40mail.gmail.com.
Re: [go-nuts] libgo is more fast that grouting.
The best approach is not to feed the troll. Let's all just abandon this thread now. -- 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/6490cb1e-abd0-4ff5-90e9-5273362fce55%40googlegroups.com.
Re: [go-nuts] libgo is more fast that grouting.
You are really toxic man. You are much more toxic than me. If you don't like Go, why do you write your feces here? Why do you like to be THE TROLL? Do you like attention so much so you are ready to be ridiculous for it? It looks so strange to me. воскресенье, 22 марта 2020 г., 13:42:16 UTC+3 пользователь Benjamin написал: > I just read an article about Oracle sued Google for Java. Surely go programming language will be abandoned soon. > Google cannot make any popular production except search engine. Google only make prototype and toy production. > I think that’s bc they think they are scientists or researchers, they do not think they engineers. > Android is widely used, But android is bought from other companies. > Only engineers can produce well designed production. Scientists or. researchers worked like students. > On Mar 22, 2020, at 16:21, Benjamin > wrote: > WOW，only children from poor families do programming work. -- 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/c1384c98-f6e5-4a65-886e-3cfd053ee876%40googlegroups.com.
Re: [go-nuts] If in doubt prefer to wrap errors with %v, not %w?
On Mon, 23 Mar 2020 at 11:22, Axel Wagner wrote: > • A function takes an io.Reader to parse the stream into some data structure > (think a json-parser). It obviously uses no other input or abstraction or > state. It makes sense to wrap the error - this allows you to provide > structured extra information (like offsets) to the user of the library and > better error messages, while maintaining your users ability to switch on what > actually went wrong. That's a good point, and I suppose it generalises. Whenever you receive an interace from client code, then you have no compiler-enforced way to predict which errors you'll get from calls to that interface; but your client might. Therefore you should either pass the error up directly or else user wrapping. (Microsoft has/had the problem that many Windows APIs let clients implement abstract classes for OS middleware to call. The MSDN page for each method would list which error codes were allowed for the method, but they had no way to enforce this, so the middleware had to try and handle all possible errors). > That latter part, BTW, is IMO a blessing and a curse. It's a blessing, > because it can reduce coupling from details in the wrapping case. ... I think this is the classic dynamic vs. static typing trade-off. Go has always been a mostly static language but happy to sprinkle in dynamic typing stategically through interfaces and reflection. By standardising on the `error` interface, Go chose error handling as one of those dynamic sprinkles. > Sorry if this message is a bit chaotic and stream-of-consciousnes-y :) I > haven't quite figured out how to talk about all of this yet :) > I guess the tl;dr is, that I tend to agree - don't just use %w without > thinking. Make a deliberate choice if you want to commit to this API detail. > And as usually in API design: If in doubt, prefer to start out with less > commitment, flexibility and surface. So to turn this discussion into something actionable: should this advice be added into the documentation? And if so, where (in package fmt or errors)? Lots of programers will assume that because %w is new, then it must be the Go team's recommended "best practice". I think I was unconciously thinking that until I read the blog post. -- Adrian Ratnapala -- 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/CAN%2BHj7gvJru-ZoLUcdcCNde3iJgK5j6aoCbipksCRMYSMznjfw%40mail.gmail.com.
Re: [go-nuts] Tests skipping
On Monday, March 23, 2020 at 2:49:46 PM UTC+11, Ian Lance Taylor wrote:
>
> On Sun, Mar 22, 2020 at 7:10 PM Shane H >
> wrote:
> >
> > I'm a lot confused by the behaviour of some tests I have at the moment,
> they're skipping.. when there's no skip or timeout or... anything that I
> can see
> >
> > I know this is going to be difficult because I don't have code I can
> paste to show what's happening
> >
> > I'm using go1.13.9, but this behaviour was also happening with go1.13.7
> >
> > I have tests run from a script with
> > go test ./... -v -count=1 // Note count=1 was added to try and stop the
> behaviour
> >
> > The tests that I am interested are table tests run inside
> > for _, testCase := range tt {
> > testCase := testCase
> > t,Run(testCase.name, func(t *testing.T) {
> > res, err := http.DefaultClientDo(testCase.before(t))
> > require.NoError(t, err)
> > defer res.Body.Close()
> > testCase.check(t, res)
> > }
> > }
> >
> > When I set two of the tests to time.Sleep(time.Millisecond * 1000) the
> tests should fail
> >
> > Sometimes they do, but sometimes they instead Skip, or even report that
> they were run, passed, with an updated time (they shouldn't pass)
> >
> > Can someone point me in the direction of some helpful (perhaps)
> documentation if that's what I need to read?
>
> What do you mean when you say that the tests are skipped? What is the
> output of your "go test" command?
>
> Can you show us a small complete test case that demonstrates the problem?
>
> Ian
>
I wish I could (provide a test case), but it only happens on my branch.
The output of the go test is
TestQuoteDate (skipping) // or words to that effect
I'm thinking that it /has/ to be user error, but I cannot see what I'm
doing that's causing the problem (except making the test sleep so I can
make the API I am interacting with trigger a bug I am trying to track down)
--
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/ba5495e5-5fc3-45f7-a36c-ba54635dc333%40googlegroups.com.
