Re: [go-nuts] flag: bug with shared values?
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(, "baz", "foo-default", "testing")
> barFs.StringVar(, "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/CAOyqgcW67XjKraQJxuCDsSWMELFkOvdE--VGGDrFH0wDAKAc7A%40mail.gmail.com.
[go-nuts] flag: bug with shared values?
Hi,
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(, "baz", "foo-default", "testing")
barFs.StringVar(, "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?
Thank you,
--
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/5aaa6fd9-4117-4f73-9cc8-b3d29ccf61b5n%40googlegroups.com.
[go-nuts] Re: Inject windows manifest into binary built by "go build"
ohh, then you can look into *windres* which comes with mingw. It can create a C object file (from a .rc file that then references the manifest) which you then should be able to link into using the apporiate flags through cgo On Friday, 18 September 2020 at 6:19:02 am UTC+8 aro...@gmail.com wrote: > Thanks! I'll look more into that. Unfortunately, we're not building on a > windows machine. :-( Might still be able to make something work, though. > > On Thursday, September 17, 2020 at 9:26:25 AM UTC-6 Alex wrote: > >> Yeah looks like *mt.exe* would be the most painless method assuming it >> works. >> >> On Thursday, 17 September 2020 at 11:14:36 pm UTC+8 aro...@gmail.com >> wrote: >> >>> Thanks for the reply. Yes, I want to override the manifest for a >>> particular build of the binary. >>> >>> I have two modules: >>> 1. foo.com/repo1 which contains foo.com/repo1/cmd/the-binary >>> 2. foo.com/repo2 which will build and package the-binary with specific >>> version and manifest information. I'd like to generate a resource.syso file >>> in repo2 while building foo.com/repo1/cmd/the-binary. >>> >>> For various unfortunate reasons, repo1 cannot have a checked-in >>> resource.syso file that is consistent. It's possible that repo2 will want >>> to build with multiple distinct syso manifests during a single build. >>> >>> We can override version information in the binary itself using `*-ldflags >>> "-X main.version=$(VERSION)"*` in repo2, but I can't figure out a way >>> to do the same with the manifest contents. >>> >>> Existing workarounds are: >>> 1. We duplicate the main package in repo2, so that >>> foo.com/repo2/cmd/the-binary basically defers to >>> foo.com/repo1/cmd/the-binary/restOfMain. Then we can build the repo2 >>> main package. This is annoying but works. Unfortunately, it means potential >>> deviation from repo1 binaries. >>> 2. We modify foo.com/repo1/cmd/the-binary in the go mod cache, >>> overwriting the resource.syso file for each build. Nobody like making the >>> mod cache rw. >>> >>> I was hoping for some equivalent of the ldflags symbol modification for >>> the resource.syso file. >>> >>> On Tuesday, September 15, 2020 at 3:27:26 PM UTC-6 Alex wrote: >>> > Is there a way to force the go linker to include the local manifest file? A syso file *is* the way. > Or somehow inject the manifest into a built exe? Readup on *mt.exe*, I haven't used it on go programs but it might work. https://docs.microsoft.com/en-us/cpp/build/how-to-embed-a-manifest-inside-a-c-cpp-application?view=vs-2019 Tho I'm not quite sure what you're trying to do and what the problem is. What do you mean by "locally-generated resource.syso" and how is it different from a syso file generated by goversioninfo? Do you have a package that contains a syso manifest file checked into version control and you want to override it's contents on your system somehow? On Tuesday, 15 September 2020 at 11:41:45 pm UTC+8 aro...@gmail.com wrote: > I’m trying to embed windows manifest information into an exe. I’ve > generated the resource.syso file using goversioninfo and it works fine > when > that file is in the target package. But now I want to do something > slightly > different: I want to use go build module/package/cmd/binary with a > locally-generated resource.syso. Is there a way to force the go linker to > include the local manifest file? Or somehow inject the manifest into a > built exe? Currently I have two workarounds that I’m trying to avoid: > >1. The main package of the target binary is incredibly thin and I >duplicate the main package locally and compile with the generated syso > file. >2. I can use modcacherw to allow modifications of the imported >module package and modify the source folder of the binary and inject > the >syso file. > > Any way to make go build just link in the file? > > - Augusto > -- 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/4d79a290-2510-42f0-9bc0-c36c1264bc68n%40googlegroups.com.
[go-nuts] Re: Inject windows manifest into binary built by "go build"
Thanks! I'll look more into that. Unfortunately, we're not building on a windows machine. :-( Might still be able to make something work, though. On Thursday, September 17, 2020 at 9:26:25 AM UTC-6 Alex wrote: > Yeah looks like *mt.exe* would be the most painless method assuming it > works. > > On Thursday, 17 September 2020 at 11:14:36 pm UTC+8 aro...@gmail.com > wrote: > >> Thanks for the reply. Yes, I want to override the manifest for a >> particular build of the binary. >> >> I have two modules: >> 1. foo.com/repo1 which contains foo.com/repo1/cmd/the-binary >> 2. foo.com/repo2 which will build and package the-binary with specific >> version and manifest information. I'd like to generate a resource.syso file >> in repo2 while building foo.com/repo1/cmd/the-binary. >> >> For various unfortunate reasons, repo1 cannot have a checked-in >> resource.syso file that is consistent. It's possible that repo2 will want >> to build with multiple distinct syso manifests during a single build. >> >> We can override version information in the binary itself using `*-ldflags >> "-X main.version=$(VERSION)"*` in repo2, but I can't figure out a way to >> do the same with the manifest contents. >> >> Existing workarounds are: >> 1. We duplicate the main package in repo2, so that >> foo.com/repo2/cmd/the-binary basically defers to >> foo.com/repo1/cmd/the-binary/restOfMain. Then we can build the repo2 >> main package. This is annoying but works. Unfortunately, it means potential >> deviation from repo1 binaries. >> 2. We modify foo.com/repo1/cmd/the-binary in the go mod cache, >> overwriting the resource.syso file for each build. Nobody like making the >> mod cache rw. >> >> I was hoping for some equivalent of the ldflags symbol modification for >> the resource.syso file. >> >> On Tuesday, September 15, 2020 at 3:27:26 PM UTC-6 Alex wrote: >> >>> > Is there a way to force the go linker to include the local manifest >>> file? >>> A syso file *is* the way. >>> >>> > Or somehow inject the manifest into a built exe? >>> Readup on *mt.exe*, I haven't used it on go programs but it might work. >>> >>> https://docs.microsoft.com/en-us/cpp/build/how-to-embed-a-manifest-inside-a-c-cpp-application?view=vs-2019 >>> >>> Tho I'm not quite sure what you're trying to do and what the problem is. >>> What do you mean by "locally-generated resource.syso" and how is it >>> different from a syso file generated by goversioninfo? >>> Do you have a package that contains a syso manifest file checked into >>> version control and you want to override it's contents on your system >>> somehow? >>> >>> On Tuesday, 15 September 2020 at 11:41:45 pm UTC+8 aro...@gmail.com >>> wrote: >>> I’m trying to embed windows manifest information into an exe. I’ve generated the resource.syso file using goversioninfo and it works fine when that file is in the target package. But now I want to do something slightly different: I want to use go build module/package/cmd/binary with a locally-generated resource.syso. Is there a way to force the go linker to include the local manifest file? Or somehow inject the manifest into a built exe? Currently I have two workarounds that I’m trying to avoid: 1. The main package of the target binary is incredibly thin and I duplicate the main package locally and compile with the generated syso file. 2. I can use modcacherw to allow modifications of the imported module package and modify the source folder of the binary and inject the syso file. Any way to make go build just link in the file? - Augusto >>> -- 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/35a7f3cd-e898-444f-b7d9-c4dffde7b998n%40googlegroups.com.
Re: [go-nuts] Catch/handle cgo SIGSEGV
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+unsubscr...@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/CAOyqgcU-fYa2Eg7WCxM97OjZW_rPkTF1H_C4wyieXKguY%2Bkcaw%40mail.gmail.com.
Re: [go-nuts] Catch/handle cgo SIGSEGV
It's very hard to think of a case where a SIGSEGV in a C program could continue safely. It typically means pointer access out of bounds, which in turn is usually because some data structure has become corrupted. My question is, where is this SEGV coming from? Is this a bug in the Oracle libraries? If so, you most likely want to find a way to work around that bug, to prevent the SEGV occurring in the first place. Does this SEGV occur when running a native C program which calls the ORA libraries in the same way? If not, why not? Could it be a threading issue, perhaps? Failing that, the only safe solution I can think of is to fork a child, run the Oracle client in the child, and communicate with the child over a socket (e.g. with gRPC). This would have the nice side-effect that the parent could be built without CGO; and if the child crashes, you can just fork and exec another one. -- 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/abd759fe-90ec-47c6-a79b-12f82d9854e5o%40googlegroups.com.
Re: [go-nuts] Catch/handle cgo SIGSEGV
Thanks, absolutely logical. 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...). 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+unsubscr...@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.
Re: [go-nuts] Catch/handle cgo SIGSEGV
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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVTYfoEmR0wy_Ka31nwMG0cr2sP45i6gZZWtT%2BEQUOkPw%40mail.gmail.com.
Re: [go-nuts] Should the program print true or false?
* 'Axel Wagner' via golang-nuts [200917 12:05]:
> I think you might've intended this, which does indeed print true:
> type S []S
> var a, b S
> a, b = S{0: b}, S{0: a}
> fmt.Println(reflect.DeepEqual(a, b))
I was guessing he meant:
type S []S
var a, b S
a = S{0: b}
b = S{0: a}
a[0] = b
fmt.Println(reflect.DeepEqual(a, b))
which also returns true, but for a slightly different reason; check out
the following for each of the two cases:
fmt.Printf("a[0] == nil: %t, b[0] == nil: %t\n", a[0] == nil, b[0] == nil)
...Marvin
--
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/20200917175916.dl4mifoq5stwhk6t%40basil.wdw.
Re: [go-nuts] Should the program print true or false?
Aha, you are totally right.
I made silly mistake here. ;D
On Thursday, September 17, 2020 at 12:05:31 PM UTC-4
axel.wa...@googlemail.com wrote:
> I think you might've intended this, which does indeed print true:
> type S []S
> var a, b S
> a, b = S{0: b}, S{0: a}
> fmt.Println(reflect.DeepEqual(a, b))
>
> On Thu, Sep 17, 2020 at 6:03 PM Axel Wagner
> wrote:
>
>> I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't.
>>
>> On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com
>> wrote:
>>
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "reflect"
>>> )
>>>
>>> func main() {
>>> f()
>>> }
>>>
>>> func f() {
>>> type S []S
>>> var a, b S
>>> a = S{0: b}
>>> b = S{0: a}
>>> fmt.Println(reflect.DeepEqual(a, b))
>>> }
>>>
>>> Now it prints false. But it looks the docs indicates it should print
>>> true.
>>>
>>> --
>>> 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/dbe73874-ec0f-413d-bed6-47f213bede91n%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/4b085282-3124-4c6e-9da4-ee4d10dbfae8n%40googlegroups.com.
Re: [go-nuts] Should the program print true or false?
Aha, you are totally wrong.
I made silly mistake here. ;D
On Thursday, September 17, 2020 at 12:05:31 PM UTC-4
axel.wa...@googlemail.com wrote:
> I think you might've intended this, which does indeed print true:
> type S []S
> var a, b S
> a, b = S{0: b}, S{0: a}
> fmt.Println(reflect.DeepEqual(a, b))
>
> On Thu, Sep 17, 2020 at 6:03 PM Axel Wagner
> wrote:
>
>> I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't.
>>
>> On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com
>> wrote:
>>
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "reflect"
>>> )
>>>
>>> func main() {
>>> f()
>>> }
>>>
>>> func f() {
>>> type S []S
>>> var a, b S
>>> a = S{0: b}
>>> b = S{0: a}
>>> fmt.Println(reflect.DeepEqual(a, b))
>>> }
>>>
>>> Now it prints false. But it looks the docs indicates it should print
>>> true.
>>>
>>> --
>>> 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/dbe73874-ec0f-413d-bed6-47f213bede91n%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/5dbbe944-1379-472e-b92a-4c77d3aadd4an%40googlegroups.com.
Re: [go-nuts] Should the program print true or false?
I think you might've intended this, which does indeed print true:
type S []S
var a, b S
a, b = S{0: b}, S{0: a}
fmt.Println(reflect.DeepEqual(a, b))
On Thu, Sep 17, 2020 at 6:03 PM Axel Wagner
wrote:
> I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't.
>
> On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com
> wrote:
>
>>
>> package main
>>
>> import (
>> "fmt"
>> "reflect"
>> )
>>
>> func main() {
>> f()
>> }
>>
>> func f() {
>> type S []S
>> var a, b S
>> a = S{0: b}
>> b = S{0: a}
>> fmt.Println(reflect.DeepEqual(a, b))
>> }
>>
>> Now it prints false. But it looks the docs indicates it should print true.
>>
>> --
>> 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/dbe73874-ec0f-413d-bed6-47f213bede91n%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/CAEkBMfGbqgMJEu09xRmRjFiQv7hbLP7jh5kzcJMGJGQJT6396w%40mail.gmail.com.
Re: [go-nuts] Should the program print true or false?
I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't.
On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com
wrote:
>
> package main
>
> import (
> "fmt"
> "reflect"
> )
>
> func main() {
> f()
> }
>
> func f() {
> type S []S
> var a, b S
> a = S{0: b}
> b = S{0: a}
> fmt.Println(reflect.DeepEqual(a, b))
> }
>
> Now it prints false. But it looks the docs indicates it should print true.
>
> --
> 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/dbe73874-ec0f-413d-bed6-47f213bede91n%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/CAEkBMfGRN4NWj1kzX4nPR_6%2BT4bz_fADr6NR6skktPg9vDv_KA%40mail.gmail.com.
[go-nuts] Should the program print true or false?
package main
import (
"fmt"
"reflect"
)
func main() {
f()
}
func f() {
type S []S
var a, b S
a = S{0: b}
b = S{0: a}
fmt.Println(reflect.DeepEqual(a, b))
}
Now it prints false. But it looks the docs indicates it should print true.
--
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/dbe73874-ec0f-413d-bed6-47f213bede91n%40googlegroups.com.
[go-nuts] Catch/handle cgo SIGSEGV
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 Thanks! -- 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/9c0a1e32-0738-4d93-811d-da1a5925aa9an%40googlegroups.com.
[go-nuts] Re: Inject windows manifest into binary built by "go build"
Yeah looks like *mt.exe* would be the most painless method assuming it works. On Thursday, 17 September 2020 at 11:14:36 pm UTC+8 aro...@gmail.com wrote: > Thanks for the reply. Yes, I want to override the manifest for a > particular build of the binary. > > I have two modules: > 1. foo.com/repo1 which contains foo.com/repo1/cmd/the-binary > 2. foo.com/repo2 which will build and package the-binary with specific > version and manifest information. I'd like to generate a resource.syso file > in repo2 while building foo.com/repo1/cmd/the-binary. > > For various unfortunate reasons, repo1 cannot have a checked-in > resource.syso file that is consistent. It's possible that repo2 will want > to build with multiple distinct syso manifests during a single build. > > We can override version information in the binary itself using `*-ldflags > "-X main.version=$(VERSION)"*` in repo2, but I can't figure out a way to > do the same with the manifest contents. > > Existing workarounds are: > 1. We duplicate the main package in repo2, so that > foo.com/repo2/cmd/the-binary basically defers to > foo.com/repo1/cmd/the-binary/restOfMain. Then we can build the repo2 main > package. This is annoying but works. Unfortunately, it means potential > deviation from repo1 binaries. > 2. We modify foo.com/repo1/cmd/the-binary in the go mod cache, > overwriting the resource.syso file for each build. Nobody like making the > mod cache rw. > > I was hoping for some equivalent of the ldflags symbol modification for > the resource.syso file. > > On Tuesday, September 15, 2020 at 3:27:26 PM UTC-6 Alex wrote: > >> > Is there a way to force the go linker to include the local manifest >> file? >> A syso file *is* the way. >> >> > Or somehow inject the manifest into a built exe? >> Readup on *mt.exe*, I haven't used it on go programs but it might work. >> >> https://docs.microsoft.com/en-us/cpp/build/how-to-embed-a-manifest-inside-a-c-cpp-application?view=vs-2019 >> >> Tho I'm not quite sure what you're trying to do and what the problem is. >> What do you mean by "locally-generated resource.syso" and how is it >> different from a syso file generated by goversioninfo? >> Do you have a package that contains a syso manifest file checked into >> version control and you want to override it's contents on your system >> somehow? >> >> On Tuesday, 15 September 2020 at 11:41:45 pm UTC+8 aro...@gmail.com >> wrote: >> >>> I’m trying to embed windows manifest information into an exe. I’ve >>> generated the resource.syso file using goversioninfo and it works fine when >>> that file is in the target package. But now I want to do something slightly >>> different: I want to use go build module/package/cmd/binary with a >>> locally-generated resource.syso. Is there a way to force the go linker to >>> include the local manifest file? Or somehow inject the manifest into a >>> built exe? Currently I have two workarounds that I’m trying to avoid: >>> >>>1. The main package of the target binary is incredibly thin and I >>>duplicate the main package locally and compile with the generated syso >>> file. >>>2. I can use modcacherw to allow modifications of the imported >>>module package and modify the source folder of the binary and inject the >>>syso file. >>> >>> Any way to make go build just link in the file? >>> >>> - Augusto >>> >> -- 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/9d04ac40-6fb2-4032-9b11-cde10ca6d722n%40googlegroups.com.
[go-nuts] Re: Inject windows manifest into binary built by "go build"
Thanks for the reply. Yes, I want to override the manifest for a particular build of the binary. I have two modules: 1. foo.com/repo1 which contains foo.com/repo1/cmd/the-binary 2. foo.com/repo2 which will build and package the-binary with specific version and manifest information. I'd like to generate a resource.syso file in repo2 while building foo.com/repo1/cmd/the-binary. For various unfortunate reasons, repo1 cannot have a checked-in resource.syso file that is consistent. It's possible that repo2 will want to build with multiple distinct syso manifests during a single build. We can override version information in the binary itself using `*-ldflags "-X main.version=$(VERSION)"*` in repo2, but I can't figure out a way to do the same with the manifest contents. Existing workarounds are: 1. We duplicate the main package in repo2, so that foo.com/repo2/cmd/the-binary basically defers to foo.com/repo1/cmd/the-binary/restOfMain. Then we can build the repo2 main package. This is annoying but works. Unfortunately, it means potential deviation from repo1 binaries. 2. We modify foo.com/repo1/cmd/the-binary in the go mod cache, overwriting the resource.syso file for each build. Nobody like making the mod cache rw. I was hoping for some equivalent of the ldflags symbol modification for the resource.syso file. On Tuesday, September 15, 2020 at 3:27:26 PM UTC-6 Alex wrote: > > Is there a way to force the go linker to include the local manifest > file? > A syso file *is* the way. > > > Or somehow inject the manifest into a built exe? > Readup on *mt.exe*, I haven't used it on go programs but it might work. > > https://docs.microsoft.com/en-us/cpp/build/how-to-embed-a-manifest-inside-a-c-cpp-application?view=vs-2019 > > Tho I'm not quite sure what you're trying to do and what the problem is. > What do you mean by "locally-generated resource.syso" and how is it > different from a syso file generated by goversioninfo? > Do you have a package that contains a syso manifest file checked into > version control and you want to override it's contents on your system > somehow? > > On Tuesday, 15 September 2020 at 11:41:45 pm UTC+8 aro...@gmail.com wrote: > >> I’m trying to embed windows manifest information into an exe. I’ve >> generated the resource.syso file using goversioninfo and it works fine when >> that file is in the target package. But now I want to do something slightly >> different: I want to use go build module/package/cmd/binary with a >> locally-generated resource.syso. Is there a way to force the go linker to >> include the local manifest file? Or somehow inject the manifest into a >> built exe? Currently I have two workarounds that I’m trying to avoid: >> >>1. The main package of the target binary is incredibly thin and I >>duplicate the main package locally and compile with the generated syso >> file. >>2. I can use modcacherw to allow modifications of the imported module >>package and modify the source folder of the binary and inject the syso >> file. >> >> Any way to make go build just link in the file? >> >> - Augusto >> > -- 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/a7d8d03c-521f-4fa2-a83e-0f716506c7dan%40googlegroups.com.
Re: [go-nuts] How to use "go/build".ImportDir to get Package struct?
Hi,
You want to be using https://pkg.go.dev/golang.org/x/tools/go/packages
The docs include an example of how to do this.
Thanks,
Paul
On Thu, 17 Sep 2020 at 12:29, Hein Meling wrote:
>
> Hi all,
>
> I'm trying to get info about the package, but the code below returns an empty
> build.Package struct... Anyone know how to use this API to get a populated
> Package struct?
>
> p, err := build.ImportDir("../paging", build.FindOnly)
> if err != nil {
> t.Error(err)
> }
> fmt.Println(p)
>
> Thanks,
> :) Hein
>
> --
> 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/eae52a72-8e4a-40b2-aa64-f83a5024328fn%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/CACoUkn4y57K3b-5Rm%3Dk9%2BDf8quk6MrOTK314hCNeGhOT9-w7oA%40mail.gmail.com.
[go-nuts] How to use "go/build".ImportDir to get Package struct?
Hi all,
I'm trying to get info about the package, but the code below returns an
empty build.Package struct... Anyone know how to use this API to get a
populated Package struct?
p, err := build.ImportDir("../paging", build.FindOnly)
if err != nil {
t.Error(err)
}
fmt.Println(p)
Thanks,
:) Hein
--
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/eae52a72-8e4a-40b2-aa64-f83a5024328fn%40googlegroups.com.
