I ended up creating an issue on this:
https://github.com/golang/go/issues/44026
On Sat, Jan 30, 2021 at 9:12 PM Christian Worm Mortensen
wrote:
> Hi Mike,
>
> Thank you for your consideration. I think you exactly got the essence of
> my question: How do I wait on all go routines to finish (or
On Sun, Jan 31, 2021 at 8:04 AM Amnon wrote:
> I really do not like code like
> defer func() {
> if cerr := f.Close(); cerr != nil && err == nil {
> err = cerr
> }
> }()
..
> If somebody later
> changes the function to return unnamed values, this defer will silently fail.
The def
If the go program compiled by a completely static compiled version of go
binary compiler will also be static automatically? To be more specific, on
Ubuntu 20.04, I've compiled the latest git master version of go compiler in
a completely static manner as shown below:
$ which go | xargs file
/hom
why mutex in runtime do not need starve mode?
--
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 deferred function literal refers to a named return variable.Changing
it to an unnamed one will cause the program to no longercompile.*
Interesting
https://play.golang.org/p/jnRn4Bv98xS
See the example on the Go Playground.
Jan, someone can explain to me why it will no longer compile
What makes you think it does not? Have you looked at Mutex.lockSlow()? I
have not really worked through the algorithm, but the comments do mention
starvation mode.
On Sunday, January 31, 2021 at 10:15:23 AM UTC-5 cuiw...@gmail.com wrote:
> why mutex in runtime do not need starve mode?
--
You
On Sun, Jan 31, 2021 at 5:24 PM Amnon wrote:
> https://play.golang.org/p/jnRn4Bv98xS
>
> See the example on the Go Playground.
>
> Jan, someone can explain to me why it will no longer compile?
That's not an example of what I wrote: "Changing it to an unnamed one
will cause the program to no long
OK.
If you take the
https://play.golang.org/p/L8z2Q_F_fi3
and change the line 18
from
func foo() (err error) {
to
func foo() error {
The code will continue to compile.
But it will stop working (i.e. the error from f.Close will not be returned
by foo).
Unfortunately this is not a contrived
On Sun, Jan 31, 2021 at 6:01 PM Amnon wrote:
> If you take the
> https://play.golang.org/p/L8z2Q_F_fi3
>
> and change the line 18
> from
> func foo() (err error) {
>
> to
> func foo() error {
>
> The code will continue to compile.
That's again the case of "making the return variable unnamed and d
in runtime/print.go gwrite, if the data is put in the gp.writebuf where
does that writebuf get flushed?
--
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-nu
Thanks to Ian's pointers I was able to get to a state where "go build"
command passes successfully. For the moment my compile/link/asm stubs
produce minimally viable outputs (which are mostly empty), but the go tool
is happy enough with the contents. Next step of plugging GopherJS logic in
should n
Thanks. I think I figured it out. Apart from the build tags that you have
mentioned, depending on the code editor, the build tool need to be
specified GOOS and GOARCH too.
And some of the old code completion tools do not support the new syscall/js
package.
In my case, using atom.io, I had to laun
mutex in sync package and runtime is different,
mutex in runtime package is
here, https://github.com/golang/go/blob/master/src/runtime/lock_futex.go#L46
i do not see there is a starving mode.
On Monday, February 1, 2021 at 12:38:08 AM UTC+8 jake...@gmail.com wrote:
> What makes you think it does
Not sure the runtime needs it - as all lock usages are known - so the users in
the runtime can ’negotiate’ fairness through other means for a particular mutex.
> On Jan 31, 2021, at 8:56 PM, xie cui wrote:
>
> mutex in sync package and runtime is different,
> mutex in runtime package is here,
The VSCode Go Plugin joining the Go project
(https://blog.golang.org/vscode-go) was certainly great news.
Is it possible that something similar might happen with the popular vim-go
plugin (https://github.com/fatih/vim-go)?
--
You received this message because you are subscribed to the Google G
I have a C library with some test-cases (using googletest) that all pass. I
created Go bindings for the C lib and converted the tests to testify format.
Some Go test fails because a return value from the C function (type float)
is different than expected. For example:
ASSERT_FLOAT_EQ(10, GetHei
On Sun, Jan 31, 2021 at 7:07 PM robert engels wrote:
>
> Not sure the runtime needs it - as all lock usages are known - so the users
> in the runtime can ’negotiate’ fairness through other means for a particular
> mutex.
Yes. The point of starvation mode in sync.Mutex is to avoid high tail
lat
On Sun, Jan 31, 2021 at 12:22 PM arthurwil...@gmail.com
wrote:
>
> in runtime/print.go gwrite, if the data is put in the gp.writebuf where does
> that writebuf get flushed?
The gp.writebuf field is only used to implement runtime.Stack. It
isn't flushed anywhere, it's just returned to the caller
On Sun, Jan 31, 2021 at 9:14 PM Robert M. Münch
wrote:
>
> I have a C library with some test-cases (using googletest) that all pass. I
> created Go bindings for the C lib and converted the tests to testify format.
>
> Some Go test fails because a return value from the C function (type float) is
On Sun, Jan 31, 2021 at 5:54 AM Hongyi Zhao wrote:
>
> If the go program compiled by a completely static compiled version of go
> binary compiler will also be static automatically? To be more specific, on
> Ubuntu 20.04, I've compiled the latest git master version of go compiler in a
> complete
Robert,
Advanced googletest Topics
Floating-Point Comparison
Comparing floating-point numbers is tricky. Due to round-off errors, it is
very unlikely that two floating-points will match exactly. Therefore,
ASSERT_EQ 's naive comparison usually doesn't work. And since
floating-points can have
On Mon, Feb 1, 2021 at 1:46 PM Ian Lance Taylor wrote:
>
> On Sun, Jan 31, 2021 at 5:54 AM Hongyi Zhao wrote:
> >
> > If the go program compiled by a completely static compiled version of go
> > binary compiler will also be static automatically? To be more specific, on
> > Ubuntu 20.04, I've co
22 matches
Mail list logo
