Re: [go-nuts] flag: bug with shared values?

[Michael Jones]

> 2. if other gophers has ideas of workaround?


Use distinct values, but never access them directly.

Write setter/getter functions that do the value sharing as you prefer and
return the desired result.

On Fri, Sep 18, 2020 at 11:30 AM Ian Lance Taylor  wrote:

> On Fri, Sep 18, 2020 at 12:50 AM Manfred Touron  wrote:
> >
> > 1. if I need to open an issue or not on the go repo, if the fix is not
> about code, it can be about doc maybe?
>
> Documentation fixes are always welcome.  You can open an issue or just
> send a change.
>
> > 2. if other gophers has ideas of workaround?
>
> I don't understand why it is important for these two different flags
> to share the same variable.
>
> 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/CAOyqgcU9cMZnf4PaozoBEa4kL7DJgK1PDmnkibDmQ%2BLhbgm%3DJw%40mail.gmail.com
> .
>


-- 

*Michael T. jonesmichael.jo...@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/CALoEmQwNNNfMuNQxKHbD3Lo%3Db85Sn8HrNd3YK%3DqMiZGNq8wuMw%40mail.gmail.com.

Re: [go-nuts] flag: bug with shared values?

[Ian Lance Taylor]

On Fri, Sep 18, 2020 at 12:50 AM Manfred Touron  wrote:
>
> 1. if I need to open an issue or not on the go repo, if the fix is not about 
> code, it can be about doc maybe?

Documentation fixes are always welcome.  You can open an issue or just
send a change.

> 2. if other gophers has ideas of workaround?

I don't understand why it is important for these two different flags
to share the same variable.

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/CAOyqgcU9cMZnf4PaozoBEa4kL7DJgK1PDmnkibDmQ%2BLhbgm%3DJw%40mail.gmail.com.

Re: [go-nuts] Cloud the current generic draft constraint a type parameter must be exactly some types

[tapi...@gmail.com]

If sum types are supported can they can be used as general parameter types,
then it is possible to declare overloaded functions/methods demoed in the 
end of this article 
.
 

This might be good for some scenarios.

On Friday, September 18, 2020 at 1:31:10 PM UTC-4 Ian Lance Taylor wrote:

> On Fri, Sep 18, 2020 at 10:07 AM tapi...@gmail.com  
> wrote:
> >
> > instead of sharing the same underlying types with some types?
>
> In the current design draft, the answer is yes, but only for
> non-predeclared defined types.
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
>
> 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/d7a14e4b-51e4-491d-a86b-ac1928c30642n%40googlegroups.com.

Re: [go-nuts] Why does interface type carries pointer to basic types but not values itself?

[Ian Lance Taylor]

On Fri, Sep 18, 2020 at 10:31 AM Никифор Серяков  wrote:
>
> Lets imagine this code.
>
> ```go
> var i int
>
> func main() {
> i = 3
>
> F(i)
> }
>
> var q interface{}
>
> //go:noinline
> func F(a interface{}) {
> q = a
> }
> ```
>
> then run `go tool compile -S ~/a.go`
>
> Skipping all not related, in main function we'll see
>
> ```
> 0x001d 00029 (/home/nik/a.go:6) MOVQ $3, "".i(SB)
> 0x0028 00040 (/home/nik/a.go:8) MOVQ $3, (SP)
> 0x0030 00048 (/home/nik/a.go:8) PCDATA $1, $0
> 0x0030 00048 (/home/nik/a.go:8) CALL runtime.convT64(SB)
> 0x0035 00053 (/home/nik/a.go:8) LEAQ type.int(SB), AX
> 0x003c 00060 (/home/nik/a.go:8) MOVQ AX, (SP)
> 0x0040 00064 (/home/nik/a.go:8) CALL "".F(SB)
> ```
>
> Where `runtime.convT64` is 
> https://github.com/golang/go/blob/master/src/runtime/iface.go#L364,
> which allocates (except some small optimization) new `*int` variable instead 
> of just copying value itself.
>
> So for interface declared (here 
> https://github.com/golang/go/blob/master/src/runtime/runtime2.go#L208) as
> ```go
> type eface struct {
> _type *_type
> data  unsafe.Pointer
> }
> ```
>
> `int` to `interface{}` conversion looks like
> ```go
> v := new(int)
> *v = value
> return eface{
> _type: &type.int,
> data: unsafe.Pointer(&v),
> }
> ```
> instead of
> ```go
> return eface{
> _type: &type.int,
> data: unsafe.Pointer(value),
> }
> ```
>
> I have some guess, that it is connected with garbage collection and 
> requirement to know in advance if some piece of memory is pointer or not. But 
> isn't it worth it to add some `if` in gc and do not make such allocations, 
> reducing gc pressure?

Interface values used to work more or less as you describe.  As you
guessed, it was changed to support a more efficient concurent garbage
collector.  The garbage collector has to know whether a value is a
pointer or not.  With the implementation the gc compiler uses today,
both fields of an interface value are always pointers.  If the second
word in an interface is sometimes a pointer and sometimes not, then
the garbage collector has to look at the first word to decide.  And
that is a race condition for a concurrent garbage collector.  It might
be possible to handle it, but it would significantly complicate the
write barrier.

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/CAOyqgcWO%2BuzVj9qR0O9%3Drz_VuvymPjw2JD8AJ-45vTQ-4RE%3DqQ%40mail.gmail.com.

Re: [go-nuts] Cloud the current generic draft constraint a type parameter must be exactly some types

[Ian Lance Taylor]

On Fri, Sep 18, 2020 at 10:07 AM tapi...@gmail.com  wrote:
>
> instead of sharing the same underlying types with some types?

In the current design draft, the answer is yes, but only for
non-predeclared defined types.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types

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/CAOyqgcUsDVKtTV70LVqRy2kjZZUGt0x%2BbyLGSZteeqxXP76O%3Dg%40mail.gmail.com.

[go-nuts] Why does interface type carries pointer to basic types but not values itself?

[Никифор Серяков]

Lets imagine this code.

```go
var i int

func main() {
i = 3

F(i)
}

var q interface{}

//go:noinline
func F(a interface{}) {
q = a
}
```

then run `go tool compile -S ~/a.go`

Skipping all not related, in main function we'll see

```
0x001d 00029 (/home/nik/a.go:6) MOVQ $3, "".i(SB)
0x0028 00040 (/home/nik/a.go:8) MOVQ $3, (SP)
0x0030 00048 (/home/nik/a.go:8) PCDATA $1, $0
0x0030 00048 (/home/nik/a.go:8) CALL runtime.convT64(SB)
0x0035 00053 (/home/nik/a.go:8) LEAQ type.int(SB), AX
0x003c 00060 (/home/nik/a.go:8) MOVQ AX, (SP)
0x0040 00064 (/home/nik/a.go:8) CALL "".F(SB)
```

Where `runtime.convT64` is 
https://github.com/golang/go/blob/master/src/runtime/iface.go#L364,
which allocates (except some small optimization) new `*int` variable 
instead of just copying value itself.

So for interface declared (here 
https://github.com/golang/go/blob/master/src/runtime/runtime2.go#L208) as
```go
type eface struct {
_type *_type
data  unsafe.Pointer
}
```

`int` to `interface{}` conversion looks like
```go
v := new(int)
*v = value
return eface{
_type: &type.int,
data: unsafe.Pointer(&v),
}
```
instead of
```go
return eface{
_type: &type.int,
data: unsafe.Pointer(value),
}
```

I have some guess, that it is connected with garbage collection and 
requirement to know in advance if some piece of memory is pointer or not. 
But isn't it worth it to add some `if` in gc and do not make such 
allocations, reducing gc pressure?

-- 
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/aa399c5e-4bb8-475e-94aa-f999fb33cfd0n%40googlegroups.com.

[go-nuts] Cloud the current generic draft constraint a type parameter must be exactly some types

[tapi...@gmail.com]

instead of sharing the same underlying types with some types?

-- 
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/da70dc55-7730-4131-ab41-f6a8fdfb397en%40googlegroups.com.

[go-nuts] Gomobile xcframework generation

[Valeriy Palyvoda]

Is it possible to generate .xcframework file with gomobile?

I built the .framework file with gomobile with the following command:

gomobile bind -target ios -o ../frameworks/MyFramework.framework

After that I tried to build .xcframework file with this command

xcodebuild -create-xcframework -framework "MyFramework.framework"
-output "MyFramework.xcframework"

But it shows error:

error: binaries with multiple platforms are not supported
'/Users/nicco/myFramework/MyFramework.framework/MyFramework'

So looks like the problem is in gomobile framework generation process.

So I see 2 solutions:

   1. To generate .xcframework file with gomobile.
   2. Change the .framework build process for being able to convert 
   .framework generated file to .xcframework

How to do 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/e4f66b11-8f60-4256-8b48-4639beec8180n%40googlegroups.com.

[go-nuts] http.MaxByteReader & http: request body too large

[Jérôme LAFORGE]

Hello,

I want to use http.MaxByteReader, but I want to know if it possible to 
return an package level error (like context.DeadlineExceeded) instead of 
create a new one 
(https://github.com/golang/go/blob/06f7e655d1764f5ad57bc14f82326c181c37901c/src/net/http/request.go#L1158).
 
It seems more goish and it is easiest to test with simple switch case 
instead of check the content of error (as example below).

Do you think that is compliance with promise of compatibility with Go 1? (I 
think that it is the case)


func TestMaxBytesReader(t *testing.T) {
req := ioutil.NopCloser(bytes.NewBufferString("my too long request"))
_, err := http.MaxBytesReader(httptest.NewRecorder(), req, 
2).Read([]byte{10: 0})
if err == nil || err.Error() != "http: request body too large" {
t.FailNow()
}
}

-- 
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/83b1df54-9c2c-4991-bbe1-5fd10ed11e99n%40googlegroups.com.

Re: [go-nuts] What are the best practices for go build tools?

[Paul Jolly]

Hi Andi,

> 1) I cannot do go install tools.go:

go install takes main packages as arguments, so no, this will not
work. The tools.go file (like the example you present) is simply a way
of declaring a dependency on a main package through a file that will
never be built (hence the +build tools constraint). Even though this
file is, in normal operation, ignored by all build commands (go build,
go install etc) it _is_ seen by go mod tidy (which ignores build
constraints). Hence the requirement is considered when collating the
main module's requirements.

> instead I need to duplicate each tool installation in the Makefile

If you want to install these commands then yes, this needs to happen
somewhere (could even be a go:generate step)

However, you can simply go run $mainpkg and this will work (see below)

> 2) The internal tools are currently not installed in invoked during build:

Per my suggestion above, this is my preferred mechanism. It avoids any
unnecessary steps of ensuring the correct GOBIN, PATH etc.

> //go:generate go run ../cmd/tools/decorate.go ...
>
> This fails during cross-build:
> GOOS=linux GOARCH=arm make
> go install github.com/mjibson/esc
> go install github.com/golang/mock/mockgen
> Generating embedded assets
> go generate ./...
> ...
> fork/exec 
> /var/folders/pm/q2g_c0vn1hb414nqwdcsv4fmgn/T/go-build741389459/b001/exe/decorate:
>  exec format error
> charger/evsewifi.go:57: running "go": exit status 1
> fork/exec 
> /var/folders/pm/q2g_c0vn1hb414nqwdcsv4fmgn/T/go-build892585922/b001/exe/decorate:
>  exec format error
> meter/meter.go:16: running "go": exit status 1
>
> I've looked at https://golang.org/cmd/go/#hdr-Build_constraints but couldn't 
> find a description of best practices or even mention of +built tools.

I'm not sure how you are getting into this situation, because go run
will build a binary for the platform on which cmd/go is running.

Unless you have GOOS and GOARCH set, in which case the go run during
the go generate phase will be building for potentially a different
platform?


Paul

-- 
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/CACoUkn4O%2Byg2GxWRccoMCv9wjibq9QwGsmbP0t52FqZyw5Jq%2Bg%40mail.gmail.com.

Re: [go-nuts] Catch/handle cgo SIGSEGV

[Tamás Gulácsi]

Thank you very much!
It's way more complicated than I'd to deal with, so I'll leave it as is: 
crash the program if the C side gots a SIGSEGV.
Even the gRPC child seems more managable.

Ian Lance Taylor a következőt írta (2020. szeptember 17., csütörtök, 
22:11:18 UTC+2):

> On Thu, Sep 17, 2020 at 12:09 PM Tamás Gulácsi  wrote:
> >
> > Can you provide some skim of a C-side signal handler that could induce a 
> Go panic?
> > All I want is to have an error on Go side, instead of a crash (though it 
> may be safer to have a crash...).
>
> I can't think of any safe way that a C signal handler could cause a
> panic in the goroutine that called the C code that made the invalid
> memory reference.
>
> You could in principle have a C signal handler call a Go function that
> sends a message on a buffered channel that tells some other goroutine
> to panic. I think that could be safe. But it would not be safe for a
> C signal handler to call a Go function that calls panic. That would
> leave the program with most signals blocked.
>
> Ian
>
>
>
>
> > Ian Lance Taylor a következőt írta (2020. szeptember 17., csütörtök, 
> 21:00:52 UTC+2):
> >>
> >> On Thu, Sep 17, 2020 at 8:52 AM Tamás Gulácsi  
> wrote:
> >> >
> >> > I'm searching for help in https://github.com/godror/godror/issues/100 
> - I've added a recover, called debug.SetPanicOnFault, without success: the 
> extra free still panics with SIGSEGV, and the recover does not catch it (or 
> I coded it wrongly): 
> https://github.com/godror/godror/blob/2dab250ab19e158ba97699841f40c9de9d061f29/stmt.go#L306
> >> >
> >> > panic: 
> https://github.com/godror/godror/issues/100#issuecomment-694192603
> >>
> >> When a SIGSEGV occurs while running C code called via cgo, that
> >> SIGSEGV is not turned into a Go panic.
> >>
> >> It works this way both because 1) C is not a memory-safe language, and
> >> if the C code has not installed a signal handler there is no reason to
> >> think that the C code is prepared to carry on after a segmentation
> >> violation; 2) the mechanism that Go uses to turn a memory error into a
> >> panic can only work for Go code, not for C code.
> >>
> >> 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/30ca05ec-255b-4d67-b45f-89fde5396bb6n%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/aec55e3d-10ec-4542-8e67-9bae276d1a92n%40googlegroups.com.

Re: [go-nuts] flag: bug with shared values?

[Manfred Touron]

There are actually multiple cases of reusing the same XXXVar for the same 
variables:

* 
https://github.com/golang/go/blob/50bd1c4d4eb4fac8ddeb5f063c099daccfb71b26/src/flag/example_test.go#L29-L30
 
-> to support shortcuts within the same command
* projects with multiple flag.FlagSet (to manage various subcommands in the 
same binary), that shares various common flags, i.e. `--verbose` so they 
can globally configure their logger against the same variable

What is unusual and problematic in my case, is that I don't use the same 
default value (third param).

Bug or not, I would like to know:

1. if I need to open an issue or not on the go repo, if the fix is not 
about code, it can be about doc maybe?
2. if other gophers has ideas of workaround?

Thank you
On Friday, September 18, 2020 at 2:23:04 AM UTC+2 Ian Lance Taylor wrote:

> On Thu, Sep 17, 2020 at 5:04 PM Manfred Touron  wrote:
> >
> > I think that I discovered a bug in the stdlib flag package:
> >
> > sharedFlag := "init-value"
> > fooFs := flag.NewFlagSet("foo", flag.ContinueOnError)
> > barFs := flag.NewFlagSet("bar", flag.ContinueOnError)
> > fooFs.StringVar(&sharedFlag, "baz", "foo-default", "testing")
> > barFs.StringVar(&sharedFlag, "baz", "bar-default", "testing")
> > _ = fooFs.Parse([]string{""}) // no error
> > fmt.Println(*sharedFlag) // bar-default, instead of foo-default
> >
> > To quote @peterbourgon on this issue:
> >
> > > Haha! This is a bug (?) with stdlib flag.FlagSet.
> > > The default value provided to e.g. fs.StringVar isn't kept as metadata 
> associated with the flag in the corresponding flagset, but is rather 
> assigned to the associated variable. And that assignment happens at 
> declaration time, when you call fs.StringVar, and not when you call 
> fs.Parse. So the default value you see in any flag set will be the default 
> value provided to whichever StringVar declaration happens to occur last — 
> in your test, it's this one.
> > > This sucks.
> > > I think the only fix here would be, somehow, avoiding assigning a 
> default value in the declaration, and populating it later. Or defining a 
> separate e.g. DeferredFlagVar type that encapsulated this behavior? I don't 
> know offhand what's best. Ugh.
> >
> > I never contributed to the go repo yet, so I prefer to ask here your 
> opinion about this strange behavior, what you suggest in term of fix that 
> does not require to touch the stdlib, and if you think that I need to issue 
> a bug on the go repo and try to contribute a fix?
>
> What you say is true and I can see how it would be surprising but I
> don't personally consider this to be a bug. It's a design decision.
> Perhaps it should be documented more clearly: don't use the same
> variable for more than one XXXVar calls.
>
> 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/378e40d2-fb0e-4f8f-a576-839350723b44n%40googlegroups.com.