Re: [go-nuts] Re: Packaging a Go module for Nix

I'm going to describe how I ended up packaging the go modules (and so far it seems to work correctly). I have also replied inline below I'm using a two-phase approach to package Go modules for Nix: 1. During the first phase, a package named after the module with the suffix *-go-modules* i

[go-nuts] gdb go optimized out

Very strange, when I compile with go build -o main -gcflags "-N -l" main.go, it appears optimized out when debugging with gdb. Who knows why? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving ema

Re: [go-nuts] Re: Persistence of value, or Safely close what you expected

On Wed, Mar 13, 2019 at 4:01 PM Andrey Tcherepanov < xnow4fippy...@sneakemail.com> wrote: > Roger, it is not that I wondering it is async assignments are bad, it is > more of a question "why does it have to be SO complicated"? > > (please forgive me for a long ranty post) > > There were couple of

[go-nuts] Re: Persistence of value, or Safely close what you expected

You may have to copy-paste the playground link as clicking appears to load a previous version of the message that I deleted. (Not sure if this is just a bug on my end) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this gro

[go-nuts] Re: Persistence of value, or Safely close what you expected

Hi, Just wanted to put it out there, that one way of handling a situation where you try to close on a chanel which may already be closed is to catch the panic with a recover like so: https://play.golang.org/p/nEeZ6ddXRR_O -K -- You received this messag

[go-nuts] Re: Persistence of value, or Safely close what you expected

Hi, Just wanted to put it out there, that one way of handling a situation where you try to close on a chanel which may already be closed is to catch the panic with a recover like so: https://play.golang.org/p/8uRq8J2TH2i -K -- You received this message because you are subscribed to the Google

Re: [go-nuts] Re: Persistence of value, or Safely close what you expected

Roger, it is not that I wondering it is async assignments are bad, it is more of a question "why does it have to be SO complicated"? (please forgive me for a long ranty post) There were couple of things I was implementing for our little in-house server app. One was (in)famous fan-out pattern

Re: [go-nuts] Pointer declaration syntax

I may be misunderstanding, but var name = &someOtherVariable is fine but the point is & is a unary operator that means 'return the pointer to the variable to the right of this operator' and is not a type specification, whereas *typename is a type specification that tells the compiler and hin

Re: [go-nuts] Re: Packaging a Go module for Nix

On Wednesday, March 13, 2019 at 7:25:35 PM UTC+1, Wael Nasreddine wrote: > > On Monday, March 11, 2019 at 10:01:04 AM UTC-7, Manlio Perillo wrote: >> >> Do you perhaps have the same requirements as in the thread >> https://groups.google.com/forum/#!topic/golang-dev/DD88cds-LuI >> as reported by Nic

Re: [go-nuts] Re: Packaging a Go module for Nix

On Wednesday, March 13, 2019 at 7:25:35 PM UTC+1, Wael Nasreddine wrote: > > On Monday, March 11, 2019 at 10:01:04 AM UTC-7, Manlio Perillo wrote: >> >> Do you perhaps have the same requirements as in the thread >> https://groups.google.com/forum/#!topic/golang-dev/DD88cds-LuI >> as reported by Nic

Re: [go-nuts] Re: Packaging a Go module for Nix

On Monday, March 11, 2019 at 12:33:29 PM UTC-7, thepud...@gmail.com wrote: > > Hi Wael, > > Sorry, I am not quite following what you have and have not tried yet, and > which issues you have hit with which techniques. > No worries, I'll try to address your questions to clarify the issues I'm havi

Re: [go-nuts] Re: Packaging a Go module for Nix

On Monday, March 11, 2019 at 10:01:04 AM UTC-7, Manlio Perillo wrote: > > Do you perhaps have the same requirements as in the thread > https://groups.google.com/forum/#!topic/golang-dev/DD88cds-LuI > as reported by Nicolas Mailhot? > > That is, you need to patch the upstream source but keep the sam

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

On Tuesday, March 12, 2019, 12:54:47 PM PDT, Robert Engels wrote: I swear you are just trolling now or looking at the wrong things. Review > https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gpp-2.html > > and > https://benchmarksgame-team.pages.debian.net/benchma

Re: [go-nuts] Re: Persistence of value, or Safely close what you expected

It might be helpful to have a better idea of what you're actually trying to do here. Specifically, why do you feel the need to assign to c concurrently? On Wed, 13 Mar 2019 at 16:38, Andrey Tcherepanov < xnow4fippy...@sneakemail.com> wrote: > Thank you Peter, I know that - I wrote that example on

[go-nuts] Re: Persistence of value, or Safely close what you expected

Thank you Peter, I know that - I wrote that example on purpose to be undefined. To make it "well-defined" requires an enormous "fluff" which I am mentioned and trying to avoid. Andrey On Wednesday, March 13, 2019 at 9:02:53 AM UTC-6, peterGo wrote: > > Andrey, > > Your program has a data race.

[go-nuts] Regarding "gocv.io/x/gocv" library function call

I tried using the function - func MatchTemplate(image Mat, templ Mat, result *Mat, method TemplateMatchMode, mask Mat) from "gocv.io/x/gocv". There is no clear guidance regarding the use case of "mask" parameter. How do we use it ?

[go-nuts] Re: Persistence of value, or Safely close what you expected

Andrey, Your program has a data race. The results are undefined. Data Race Detector https://golang.org/doc/articles/race_detector.html $ go run -race racer.go == WARNING: DATA RACE Write at 0x0050dfa0 by goroutine 6: main.niller() /home/peter/gopath/src/racer.go:6 +0

Re: [go-nuts] Persistence of value, or Safely close what you expected

Your program is most certainly non-deterministic, and you will sometimes close a closed channel and panic. There is no thread safe way to test if a channel is closed, then close it if it isn't. I think of channel ownership in a similar way as of memory ownership in C/C++. If this channel is being

[go-nuts] IPv6 address and http.ServeMux

The documentation of ServeMux is not clear if IP addresses are supported in the HTTP Host header or in the pattern. The stripHostPort function: https://github.com/golang/go/blob/master/src/net/http/server.go#L2221 has a comment that ignores IPv6 address, and there are no test that ensure IP addr

Re: [go-nuts] Persistence of value, or Safely close what you expected

Hello. I apologize if my previous mail was cut unexpectedly short. My e-mail client did something that I do not completely understand. ISTM that there are no guarantees about the behavior of that program at all. Access to c from niller and closer is not synchronized, so it's not really possible t