[go-nuts] Passing string to a c-struct member of type void*

[Nicholas Yue]

Hi,

  I have the following struct in C
==
struct DataStruct
{
const char *name;
const void *data;
int type;
int arraylength;
size_t count;
int flags;
};
==

  I am trying to pass a string/(char *) to data. What is the correct 
approach ? I believe the other parameters are being passed successfully

My attempt

==
var params [2]C.struct_DataStruct
params[0].name = C.CString("type")
// cstr := C.CString("apistream")
// params[0].data = unsafe.Pointer()
params[0]._type = C.int(0)
params[0].arraylength = C.int(0)
params[0].flags = C.int(0)
==

Cheers

-- 
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/f70be5ec-e1dd-44b3-a9a8-40ad39afc398n%40googlegroups.com.

[go-nuts] Re: Go 1.16 Release Candidate 1 is released

[Nikolay Dubina]

This is great! Thank you!

On Thursday, January 28, 2021 at 11:27:49 PM UTC+8 Alex Rakoczy wrote:

> Hello gophers,
>
> We have just released go1.16rc1, a release candidate version of Go 1.16.
> It is cut from release-branch.go1.16 at the revision tagged go1.16rc1.
>
> Please try your production load tests and unit tests with the new version.
> Your help testing these pre-release versions is invaluable.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.16rc1
> is by using the go command:
> $ go get golang.org/dl/go1.16rc1
> $ go1.16rc1 download
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.16rc1
>
> To find out what has changed in Go 1.16, read the draft release notes:
> https://tip.golang.org/doc/go1.16
>
> Cheers,
> The Go Team
>

-- 
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/f9f74c2a-cd27-4371-9f0f-b1f653a71cean%40googlegroups.com.

[go-nuts] Delve v1.6.0 is released

[Derek Parker]

Hello Gophers,

Announcing the Delve v1.6.0 release! Thanks to everyone who contributed to 
this release!

Notable changes:

* Go 1.16 support
* Apple M1 support
* Syntax highlighting for code blocks (in terminal)
* Bug fixes, performance improvements and more!

Check out the full CHANGELOG here 
.

-- 
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/fb909311-a7f0-4cf2-8503-8856a7ea38c8n%40googlegroups.com.

Re: [go-nuts] Re: Virtual time for testing

[Christian Worm Mortensen]

Hi Amnon,

Thank you for your suggestion. I have taken a look at the package but it
does not seem to really work. It seems to rely on runtime.Gosched() to
suspend the current go routine until all other go routines are blocked.
That is, it relies on  runtime.Gosched() to provide functionality similar
to what I wanted  with the fictional runtime.registerDeadlockCallback
function.

However, runtime.Gosched() is not documented to do that. Also, I confirmed
with a test that it also does not do that in practice. Here is what I did
for anyone interested. I ran this program based on the example from
https://github.com/facebookarchive/clock:

package main

import (
  "fmt"
  "runtime"
  "time"

  "github.com/facebookarchive/clock"
)

func main() {
  mock := clock.NewMock()
  count := 0

  // Kick off a timer to increment every 1 mock second.
  go func() {
ticker := mock.Ticker(1 * time.Second)
for {
  <-ticker.C
  count++

  // New code inserted by me to use CPU:
  j := rand.Int()
  for i := 1; i < 1000; i++ {
j++
  }
  fmt.Printf("Value: %v\n", j)
}
  }()
  runtime.Gosched()

  // Move the clock forward 10 second.
  mock.Add(10 * time.Second)

  // This prints 10.
  fmt.Println(count)
}

Now, with my modification the program no longer prints 10. For me it
printed:

Value: 999
Value: 999
Value: 999
4

Best,

Christian

On Thu, Jan 28, 2021 at 10:34 PM Amnon  wrote:

> Try something like
> github.com/facebookgo/clock
>
>
> On Thursday, 28 January 2021 at 21:15:50 UTC Christian Worm Mortensen
> wrote:
>
>> Hi!
>>
>> Suppose I want to unit test this function:
>>
>> func generator() <-chan int {
>> ret := make(chan int)
>> go func() {
>> for i := 0; i < 10; i++ {
>> ret <- i
>> time.Sleep(time.Second)
>> }
>> }()
>> return ret
>> }
>>
>> What is a good way to do that? One way is to do it is like this:
>>
>> func testGenerator() {
>> start := time.Now()
>> g := generator()
>> for i := 0; i < 10; i++ {
>> v := <-g
>> if v != i {
>> panic("Wrong value")
>> }
>> }
>> elapsed := time.Now().Sub(start)
>> if elapsed < 9*time.Second || elapsed > 11*time.Second {
>> panic("Wrong execution time")
>> }
>> }
>>
>> However there are several issues with this:
>>
>> 1) The unit test takes a long time to run - 10 seconds.
>> 2) The unit test is fragile to fluctuations in CPU availability
>> 3) The unit test is not very accurate
>>
>> Of course this is a simple example. But what if I want to test a
>> complicated piece of code with many go routines interacting in complicated
>> ways and with long timeouts?
>>
>> In other programming languages, I have been able to implement a form of
>> virtual time which increases only when all threads are waiting for time to
>> increase. This allows functions like generator above to be tested basically
>> instantly and this has been extremely useful for me in many projects over
>> the years.
>>
>> Can I do something similar in Go? I would expect I would need to wrap
>> time.Now, time.Sleep and time.After which I will be happy to do.
>>
>> I can see that Go has a deadlock detector. If somehow it was possible to
>> have Go start a new Go routine when a deadlock was detected, I think it
>> would be pretty straight forward to implement virtual time as described. I
>> could then do something like:
>>
>> runtime.registerDeadlockCallback(func () {
>>   // Increase virtual time and by that:
>>   //  * Make one or more wrapped time.Sleep calls return or
>>   //  * Write to one or more channels returned by wrapped time.After.
>> })
>>
>> Obviously this would only be needed for test code, not production code.
>>
>> Thanks,
>>
>> Christian
>>
> --
> 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/Y9Ccen0uMcs/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/d58a4e2a-eead-4ec9-b9a9-c0a43a699e89n%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/CABTkUoakmJWkCbBkC2%3Ddu96gPN%2BGQ9ODQibQTVJXnChWBcqGPg%40mail.gmail.com.

Re: [go-nuts] calling cmd

[Jeff Mangan]

XY Problem I'll be using that in the future :-)

Yeah, I just wanted to see those stats and thought I would write a go app
to do it just for the sake of writing some go code.  It's not important.
Thanks for the info.

On Thu, Jan 28, 2021 at 2:08 PM Kurtis Rader  wrote:

> On Thu, Jan 28, 2021 at 9:29 AM Jeff Mangan  wrote:
>
>> I am trying to get the results of top (more specifically htop)  but every
>> time it prints nothing, whereas any other command (ls, pwd, etc...) returns
>> the output fine.  My objective is to get access to the process stats that
>> are returned to the screen.
>>
>
> Note that htop is screen oriented, not line oriented. That is, it uses
> terminal escape sequences to move the cursor and change the color of the
> text. Run
>
> echo q | htop > x
>
> Then look at the content of file "x".  You won't see lines of text like
> you would from the output of a command like ls. You could use Go package
> github.com/creack/pty to communicate with htop via a pseudo-tty and
> "screen scrape" its output. But that would be a really painful way to get
> information about running processes. It's hard to provide useful advice
> because it appears you've made the "XY Problem "
> mistake. Depending on what information you really want and the platform
> you're running on the answer may be as simple as running "ps waux" and
> capturing the %CPU column.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/CAHr9bga_ckmcgEeN5%3DmTdL-i2S1onMNdyFtU8V2ZQGcqy-1hdw%40mail.gmail.com.

[go-nuts] Re: Virtual time for testing

[Amnon]

Try something like 
github.com/facebookgo/clock


On Thursday, 28 January 2021 at 21:15:50 UTC Christian Worm Mortensen wrote:

> Hi!
>
> Suppose I want to unit test this function:
>
> func generator() <-chan int {
> ret := make(chan int)
> go func() {
> for i := 0; i < 10; i++ {
> ret <- i
> time.Sleep(time.Second)
> }
> }()
> return ret
> }
>
> What is a good way to do that? One way is to do it is like this:
>
> func testGenerator() {
> start := time.Now()
> g := generator()
> for i := 0; i < 10; i++ {
> v := <-g
> if v != i {
> panic("Wrong value")
> }
> }
> elapsed := time.Now().Sub(start)
> if elapsed < 9*time.Second || elapsed > 11*time.Second {
> panic("Wrong execution time")
> }
> }
>
> However there are several issues with this:
>
> 1) The unit test takes a long time to run - 10 seconds.
> 2) The unit test is fragile to fluctuations in CPU availability
> 3) The unit test is not very accurate
>
> Of course this is a simple example. But what if I want to test a 
> complicated piece of code with many go routines interacting in complicated 
> ways and with long timeouts?
>
> In other programming languages, I have been able to implement a form of 
> virtual time which increases only when all threads are waiting for time to 
> increase. This allows functions like generator above to be tested basically 
> instantly and this has been extremely useful for me in many projects over 
> the years.
>
> Can I do something similar in Go? I would expect I would need to wrap 
> time.Now, time.Sleep and time.After which I will be happy to do.
>
> I can see that Go has a deadlock detector. If somehow it was possible to 
> have Go start a new Go routine when a deadlock was detected, I think it 
> would be pretty straight forward to implement virtual time as described. I 
> could then do something like:
>
> runtime.registerDeadlockCallback(func () {
>   // Increase virtual time and by that:
>   //  * Make one or more wrapped time.Sleep calls return or 
>   //  * Write to one or more channels returned by wrapped time.After.
> })
>
> Obviously this would only be needed for test code, not production code.
>
> Thanks,
>
> Christian
>

-- 
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/d58a4e2a-eead-4ec9-b9a9-c0a43a699e89n%40googlegroups.com.

[go-nuts] Virtual time for testing

[Christian Worm Mortensen]

Hi!

Suppose I want to unit test this function:

func generator() <-chan int {
ret := make(chan int)
go func() {
for i := 0; i < 10; i++ {
ret <- i
time.Sleep(time.Second)
}
}()
return ret
}

What is a good way to do that? One way is to do it is like this:

func testGenerator() {
start := time.Now()
g := generator()
for i := 0; i < 10; i++ {
v := <-g
if v != i {
panic("Wrong value")
}
}
elapsed := time.Now().Sub(start)
if elapsed < 9*time.Second || elapsed > 11*time.Second {
panic("Wrong execution time")
}
}

However there are several issues with this:

1) The unit test takes a long time to run - 10 seconds.
2) The unit test is fragile to fluctuations in CPU availability
3) The unit test is not very accurate

Of course this is a simple example. But what if I want to test a 
complicated piece of code with many go routines interacting in complicated 
ways and with long timeouts?

In other programming languages, I have been able to implement a form of 
virtual time which increases only when all threads are waiting for time to 
increase. This allows functions like generator above to be tested basically 
instantly and this has been extremely useful for me in many projects over 
the years.

Can I do something similar in Go? I would expect I would need to wrap 
time.Now, time.Sleep and time.After which I will be happy to do.

I can see that Go has a deadlock detector. If somehow it was possible to 
have Go start a new Go routine when a deadlock was detected, I think it 
would be pretty straight forward to implement virtual time as described. I 
could then do something like:

runtime.registerDeadlockCallback(func () {
  // Increase virtual time and by that:
  //  * Make one or more wrapped time.Sleep calls return or 
  //  * Write to one or more channels returned by wrapped time.After.
})

Obviously this would only be needed for test code, not production code.

Thanks,

Christian

-- 
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/ebc81618-fd3a-4a71-bd4d-cb1a84268e93n%40googlegroups.com.

Re: [go-nuts] calling cmd

[Kurtis Rader]

On Thu, Jan 28, 2021 at 9:29 AM Jeff Mangan  wrote:

> I am trying to get the results of top (more specifically htop)  but every
> time it prints nothing, whereas any other command (ls, pwd, etc...) returns
> the output fine.  My objective is to get access to the process stats that
> are returned to the screen.
>

Note that htop is screen oriented, not line oriented. That is, it uses
terminal escape sequences to move the cursor and change the color of the
text. Run

echo q | htop > x

Then look at the content of file "x".  You won't see lines of text like you
would from the output of a command like ls. You could use Go package
github.com/creack/pty to communicate with htop via a pseudo-tty and "screen
scrape" its output. But that would be a really painful way to get
information about running processes. It's hard to provide useful advice
because it appears you've made the "XY Problem "
mistake. Depending on what information you really want and the platform
you're running on the answer may be as simple as running "ps waux" and
capturing the %CPU column.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9POoqxgftj505parnpqm2o6EVRGQm-TZ7iJYmN%2BJ_%3Dwg%40mail.gmail.com.

Re: [go-nuts] Code coverage in error cases when compared to other languages

['Thomas Bushnell BSG' via golang-nuts]

IMO:

To give these things names, you have:

func Foo(...) ..., error {
  do things here...
  err := makeASubroutineCall(...)
  if err != nil {
return ..., err
  }
  do more things
}

And we suppose that makeASubroutineCall is already will tested and you know
it returns errors correctly. What is the point of a separate test of Foo
that makes sure that it returns the errors in the same cases?

Suppose Foo had a bug, and *stopped* returning that error. Wouldn't you
want to know? Especially since in many cases, not returning that error can
cause the rest to subtly seem right (perhaps makeASubroutineCall syncs
something to disk or kicks off some secondary process)...

Someone comes along, see, and your function becomes this:

func Foo(...) ..., error {
  do things here...
  if moonIsGreenCheese() {
err := makeASubroutineCall(...)
if err == nil && someCondition {
  err = someOtherError
}
if err != nil {
  return ..., err
}
  }
  do more things
}

And then another person comes along, and now it's this:

func Foo(...) ..., error {
  do things here...
  if moonIsGreenCheese() {
err := makeASubroutineCall(...)
if err == nil && someCondition {
  err = someOtherError
}
  } else if moonIsRedCheese() {
err := makeDifferentCall(...)
if err == nil && someOtherCondition {
  err = yetAnotherError
}
  }
  if err != nil {
return ..., err
  }
  do more things
}

Do you see the bug? Wouldn't you be glad if you had a test hanging around
to catch it?

On Thu, Jan 28, 2021 at 12:22 PM Szczepan Faber  wrote:

> Good question and useful discussion!
>
> What is Go community guidance on the _value_ of unit testing the `if err
> i= nil { return err }` idiom?
>
> To make the question a little more precise, let's consider the code
> snippet in the first email in this thread. Let's assume that I already have
> coverage for Foo() function happy path. Does it make sense to increase the
> code complexity (adding mocks) in order to achieve a higher test coverage
> (covering 'return err' line)? Would that additional coverage be useful
> given that 'return err' has no complexity and Go has the compiler/linter?
>
> Full disclosure: I'm biased to avoid unit testing those idioms by default.
> However, I'm very curious what's the community guidance, any
> documents/links I can read, any reference codebases?
>
> Thank you all!
>
> On Tuesday, December 8, 2020 at 4:39:05 AM UTC-6 axel.wa...@googlemail.com
> wrote:
>
>> Hi,
>>
>> On Tue, Dec 8, 2020 at 1:19 AM 'Charles Hathaway' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm looking for a good study/quantitative measure of how well-written Go
>>> code looks compared to other languages, such as Java, when it comes to test
>>> coverage. In particular, how handling errors may reduce the percentage of
>>> code covered by tests in Go relative to other languages.
>>>
>>> For example, in this code snippet:
>>>
>>> func Foo() error {
>>>   // do some stuff that actually adds value
>>>   if err := somelib.Bar(); err != nil {
>>> // triggering the error case in Bar is hard, i.e. requires
>>> simulating network troubles
>>> // or causing a file write to fail, but we don't do anything with
>>> result besides
>>> // return it. Testing it by adding an interface or wrapper isn't
>>> worth the effort
>>> // and the only impact is really reported test coverage.
>>> return err
>>>   }
>>>   // do more stuff
>>>   return nil
>>> }
>>>
>>> In Java, you would just add 'throws SomeException' to your method
>>> declaration. The effect is that we have one line in the Go code which is
>>> not easily covered by a test, whereas Java does not report that untested
>>> case because the return path is not visible in the code.
>>>
>>> The result is that otherwise equivalent code, we will report different
>>> code coverage values, with Go being slightly lower. I'm just looking for
>>> something written on that topic that can give us a notion of how much of a
>>> difference we might expect.
>>>
>>
>> I don't think there is as much of a difference as you think.
>>
>> You seem to be considering the `throws SomeException` to not impact
>> coverage - but that's not true. It's code you add for error handling and
>> that code is not hit, unless your test actually triggers that exception -
>> just as the code you add for error handling in Go isn't hit. So if you
>> don't count `throws SomeException` as code to be covered in java, you also
>> shouldn't count `if err i= nil { return err }` as code to be covered in Go.
>> So the semantic difference really comes down to a single `throws
>> SomeException` line being able to cover *multiple* branches with the same
>> exception type. It's a difference, but it should be small in practice.
>>
>> But really, I think what this comes down to is that line-coverage - or,
>> what's actually measured and then projected down to lines,
>> "instruction-coverage" - just isn't a super 

Re: [go-nuts] What compatibility of go/ast, go/types, go/packages packages is planned, if any, when transitioning toward go2 ?

[Ian Lance Taylor]

On Thu, Jan 28, 2021 at 3:43 AM 'Carla Pfaff' via golang-nuts
 wrote:
>
> On Wednesday, 27 January 2021 at 23:28:17 UTC+1 Ian Lance Taylor wrote:
>>
>> To be clear, there is no Go 2, and there are no plans for Go 2.
>
>
> For someone who follows the mailing lists and issue comments this has been 
> known for a while, but it's easy to see where the confusion comes from, given 
> these blog posts:
>
> https://blog.golang.org/toward-go2
> https://blog.golang.org/go2-here-we-come
> https://blog.golang.org/go2-next-steps
>
> They mention backward-compatibility, but only for the initial proposals "to 
> get the ball rolling". There hasn't been a blog post titled "There are no 
> plans for Go 2" or "Go 2 is not what you think it is" so far. The current 
> policy seems to be this document:
>
> "Proposal: Go 2 transition": 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md
> "If the above process works as planned, then in an important sense there 
> never will be a Go 2."
>
> It is labeled "Proposal", but it doesn't seem to be a proposal in the usual 
> proposal process sense, and many may have missed it.

You're right, I wrote that poorly.  People use "Go 2" in various
different ways.  I should have said: there is no plan to ever break
backward compatibility with earlier versions of Go.

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/CAOyqgcXtH%3DjG%3DpK7-ADbV6cGTJ3oTyav4oK0nCpYvrgMphdQSg%40mail.gmail.com.

[go-nuts] Re: calling cmd

['Carla Pfaff' via golang-nuts]

"htop" doesn't exit (the channel read blocks until exit), and it uses ANSI 
escape codes for colorful output. You'd be better served by "top -b -n 1" 
(Linux) or  "top -l1" (macOS).

-- 
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/14196080-4cc4-41ae-bbee-87a198b7fc8cn%40googlegroups.com.

Re: [go-nuts] calling cmd

[Ian Lance Taylor]

On Thu, Jan 28, 2021 at 9:29 AM Jeff Mangan  wrote:
>
> I am trying to get the results of top (more specifically htop)  but every 
> time it prints nothing, whereas any other command (ls, pwd, etc...) returns 
> the output fine.  My objective is to get access to the process stats that are 
> returned to the screen.
>
> Here is the latest example which displays nothing:

Please post code as plain text or as a link to the Go playground.
Colorized text on a black background is difficult to read for many
people, but everyone who uses e-mail can see plain text.  Thanks.

I'm not familiar with the htop program.  What happens if you run "htop
> out.txt"?  What winds up in out.txt?

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/CAOyqgcUD-jJ--8Y6B3Wt2xK-%3DitmRQ%2BeJKD%3DjWVeNe-u1Ky1iA%40mail.gmail.com.

[go-nuts] calling cmd

[Jeff Mangan]

I am trying to get the results of top (more specifically htop)  but every
time it prints nothing, whereas any other command (ls, pwd, etc...) returns
the output fine.  My objective is to get access to the process stats that
are returned to the screen.

Here is the latest example which displays nothing:


package main

import (
   "fmt"

   "github.com/go-cmd/cmd"
)

func main() {
   // Create Cmd, buffered output
   envCmd := cmd.NewCmd("htop")

   // Run and wait for Cmd to return Status
   status := <-envCmd.Start()

   // Print each line of STDOUT from Cmd
   for _, line := range status.Stdout {
  fmt.Println(line)
   }
}

-- 
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/CAHr9bgaiOL%3DcZy2rgVv4F2y1CUpE1ovRRmuS1gDD1WwipNoswQ%40mail.gmail.com.

Re: [go-nuts] Code coverage in error cases when compared to other languages

[Szczepan Faber]

Good question and useful discussion!

What is Go community guidance on the _value_ of unit testing the `if err i= 
nil { return err }` idiom?

To make the question a little more precise, let's consider the code snippet 
in the first email in this thread. Let's assume that I already have 
coverage for Foo() function happy path. Does it make sense to increase the 
code complexity (adding mocks) in order to achieve a higher test coverage 
(covering 'return err' line)? Would that additional coverage be useful 
given that 'return err' has no complexity and Go has the compiler/linter?

Full disclosure: I'm biased to avoid unit testing those idioms by default. 
However, I'm very curious what's the community guidance, any 
documents/links I can read, any reference codebases?

Thank you all!

On Tuesday, December 8, 2020 at 4:39:05 AM UTC-6 axel.wa...@googlemail.com 
wrote:

> Hi,
>
> On Tue, Dec 8, 2020 at 1:19 AM 'Charles Hathaway' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Hi all,
>>
>> I'm looking for a good study/quantitative measure of how well-written Go 
>> code looks compared to other languages, such as Java, when it comes to test 
>> coverage. In particular, how handling errors may reduce the percentage of 
>> code covered by tests in Go relative to other languages.
>>
>> For example, in this code snippet:
>>
>> func Foo() error {
>>   // do some stuff that actually adds value
>>   if err := somelib.Bar(); err != nil {
>> // triggering the error case in Bar is hard, i.e. requires simulating 
>> network troubles
>> // or causing a file write to fail, but we don't do anything with 
>> result besides
>> // return it. Testing it by adding an interface or wrapper isn't 
>> worth the effort
>> // and the only impact is really reported test coverage.
>> return err
>>   }
>>   // do more stuff
>>   return nil
>> }
>>
>> In Java, you would just add 'throws SomeException' to your method 
>> declaration. The effect is that we have one line in the Go code which is 
>> not easily covered by a test, whereas Java does not report that untested 
>> case because the return path is not visible in the code.
>>
>> The result is that otherwise equivalent code, we will report different 
>> code coverage values, with Go being slightly lower. I'm just looking for 
>> something written on that topic that can give us a notion of how much of a 
>> difference we might expect.
>>
>
> I don't think there is as much of a difference as you think.
>
> You seem to be considering the `throws SomeException` to not impact 
> coverage - but that's not true. It's code you add for error handling and 
> that code is not hit, unless your test actually triggers that exception - 
> just as the code you add for error handling in Go isn't hit. So if you 
> don't count `throws SomeException` as code to be covered in java, you also 
> shouldn't count `if err i= nil { return err }` as code to be covered in Go. 
> So the semantic difference really comes down to a single `throws 
> SomeException` line being able to cover *multiple* branches with the same 
> exception type. It's a difference, but it should be small in practice.
>
> But really, I think what this comes down to is that line-coverage - or, 
> what's actually measured and then projected down to lines, 
> "instruction-coverage" - just isn't a super meaningful measure in this 
> context. More interesting would be branch- or path-coverage - and that 
> would be exactly the same in both cases. Every point where a 
> `SomeException` *could* be thrown would branch off a separate path, just as 
> every `if err != nil` in your Go code. And in both languages they are 
> covered iff you write a test-case that triggers that error condition.
>
> So… I'm sorry that I can't really provide a quantitative, meaningful 
> answer to your question. I don't know what relative difference there would 
> be in line-coverage for Go vs. Java in a case like that. But your question 
> sounds as if you would like to use line-coverage as a metric (maybe even in 
> CI *shudder*) to determine whether you tested enough. And the point I'm 
> trying to make is that I think that goal is fallacious :) If you need a 
> coverage-metric, use branch- or path-coverage, which won't have that 
> difference. But really, coverage reports are IMO most useful if inspected 
> manually, to choose where to invest further tests. As a metric, it just is 
> too unreliable.
>
> https://en.wikipedia.org/wiki/Goodhart%27s_law
>  
>
>>
>> Thanks,
>>   Charles
>>
>> -- 
>> 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/6b48ed73-1963-482e-aff0-b91f3aa6a2aen%40googlegroups.com
>>  
>> 

[go-nuts] Re: Options other than pointers, regarding code duplication

[jake...@gmail.com]

Perhaps providing some code could be helpful. That way we can better 
understand what the issues are.  Minimally the function signatures you have 
now, and the signature of common function you are calling inside them, as 
well as the definitions of any types being passes. Of course, the full code 
of before and after would be ideal, if you can share. 

On Thursday, January 28, 2021 at 8:21:30 AM UTC-5 m8il...@gmail.com wrote:

> I have three logging functions that are almost identical.
>
> If I move the identicle code into a function without pointers then there 
> is a
> noticeable speed decrease. I know this is premature optimisation as logging
> shouldn't happen frequently enough or be that large (hopefully).
>
> That said. I am left wondering aside from code generation steps and copy 
> and
> paste (current solution) if I am unaware of any options that might avoid 
> pointer
> use, such as:
>
> 1./ scoped global, like a Class might provide
>
> 2./ macro type instantiation that simply inserts the code at compile time 
> but
> without the compiler doing any computations
>
> I assume not, from perusing the spec?
>
> p.s. It's fine if the solution is pointers. Just wondering if I can avoid 
> panic
> potential.
>

-- 
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/1a15ed31-29d2-4214-926a-b53d30abb27fn%40googlegroups.com.

[go-nuts] Go 1.16 Release Candidate 1 is released

[Alex Rakoczy]

Hello gophers,

We have just released go1.16rc1, a release candidate version of Go 1.16.
It is cut from release-branch.go1.16 at the revision tagged go1.16rc1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.16rc1
is by using the go command:
$ go get golang.org/dl/go1.16rc1
$ go1.16rc1 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.16rc1

To find out what has changed in Go 1.16, read the draft release notes:
https://tip.golang.org/doc/go1.16

Cheers,
The Go Team

-- 
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%2BxaJdTVa3rg-azA9gqBne6iLM003qdr%3D1coswefYSgBGrQhNA%40mail.gmail.com.

[go-nuts] Options other than pointers, regarding code duplication

[Kevin Chadwick]

I have three logging functions that are almost identical.

If I move the identicle code into a function without pointers then there is a
noticeable speed decrease. I know this is premature optimisation as logging
shouldn't happen frequently enough or be that large (hopefully).

That said. I am left wondering aside from code generation steps and copy and
paste (current solution) if I am unaware of any options that might avoid pointer
use, such as:

1./ scoped global, like a Class might provide

2./ macro type instantiation that simply inserts the code at compile time but
without the compiler doing any computations

I assume not, from perusing the spec?

p.s. It's fine if the solution is pointers. Just wondering if I can avoid panic
potential.

-- 
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/e7cfd4a6-8264-229e-ad96-a935aaa1be3a%40gmail.com.

Re: [go-nuts] What compatibility of go/ast, go/types, go/packages packages is planned, if any, when transitioning toward go2 ?

['Carla Pfaff' via golang-nuts]

On Wednesday, 27 January 2021 at 23:28:17 UTC+1 Ian Lance Taylor wrote:

> To be clear, there is no Go 2, and there are no plans for Go 2. 
>

For someone who follows the mailing lists and issue comments this has been 
known for a while, but it's easy to see where the confusion comes from, 
given these blog posts:

https://blog.golang.org/toward-go2
https://blog.golang.org/go2-here-we-come
https://blog.golang.org/go2-next-steps

They mention backward-compatibility, but only for the initial proposals "to 
get the ball rolling". There hasn't been a blog post titled "There are no 
plans for Go 2" or "Go 2 is not what you think it is" so far. The current 
policy seems to be this document:

"Proposal: Go 2 transition": 
https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md
"If the above process works as planned, then in an important sense there 
never will be a Go 2."

It is labeled "Proposal", but it doesn't seem to be a proposal in the usual 
proposal process sense, and many may have missed it.
 

-- 
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/2b24821f-bf51-4723-b358-73c2c20e19d6n%40googlegroups.com.

[go-nuts] Re: What's the status/roadmap of geo/s2 library?

[Markus Heukelom]

I think your question is answered by s2/geo github  page itself 
(https://github.com/golang/geo):

"

*In Progress* Files that have some work done, but are probably not complete 
enough for general use in production code.

   - CellIndex - A queryable index of CellIDs.

etc



On Tuesday, January 26, 2021 at 7:23:09 PM UTC+1 Piotr Wieczorek wrote:

> Hi,
> I love golang seo s2 library, but one thing that's a bit annoying to me is 
> the fact that documentation (type/method comments) often refer to 
> functionality that's not implemented.
> For example, there is the CellIndex type, documentation of which suggests 
> using method IntersectingLabels or ClosestCellQuery none of which seem to 
> be implemented.
> In fact, I don't know if the CellIndex can be queried at all, as there are 
> no Query types that reference it.
> I was trying to find any open issues or a roadmap that could tell me if 
> someone is working on finishing this functionality, but I could find none.
> I could try to take stab at implementing it (although I don't think, I'm 
> smart enough or have enough domain knowledge), but maybe someone's already 
> working on it.
>
> I'd love if someone could share this information. :)
>
> Best,
> Piotr
>

-- 
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/1acfee6f-dc6e-43f5-93e9-bb962e57c989n%40googlegroups.com.