[go-nuts] Loading Go plugin from Go shared library ends up with `fatal error: runtime: no plugin module data`

Hello, This is probably an unusual situation, but I am working on a product that has the following chain of invocation. C (native shared library libfoo.so) -> Go (c-shared libbar.so) So basically, a native C shared library invokes a -buildmode=c-shared type Go shared library. This interaction

Re: [go-nuts] Panicking in public API ?

Speaking as someone who is probably to blame for a significant proliferation of public facing panics, that example is probably not a good place for it. There are uses in the standard library of public facing panics, but they generally fall into the categories of simulating the type system (in refl

Re: [go-nuts] Panicking in public API ?

On Tue, Jan 7, 2020 at 8:10 AM Tay wrote: > Hi, > > Just a quick question. I know it's well accepted that panics leaking to > the public API of a library is generally a no-go. > Not *that* well accepted :) I tend to disagree. But maybe I'm simply in a vanishingly small minority. Yet, are there

[go-nuts] Panicking in public API ?

Panic is for unrecoverable errors. If that query is provided by the user, then return an error. If it is part of your library, and cannot be wrong, then panic. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and st

[go-nuts] Panicking in public API ?

Hi, Just a quick question. I know it's well accepted that panics leaking to the public API of a library is generally a no-go. Yet, are there any exception to the rule? For instance, I have a library that instantiates some database prepared statements (so, the majority of the elements are insta

[go-nuts] How to get the index of a slice of type string

How to get the index of a slice of type string like in this example, I want to test if the index equals to 3 in slice b and print ok. a:=[int]string("hi","holla","salut") b=append(a) b =append(b,"c") for _, count:= range b{ if b[]=3 { fmt.Println("ok") }; Enter code here... -- You received

Re: [go-nuts] Query on Interfaces

Thank you, it is clear now. On Tue, Jan 7, 2020 at 11:10 AM Ian Lance Taylor wrote: > On Mon, Jan 6, 2020 at 9:18 PM Prabhu Chawandi > wrote: > > > > I was reading this article @ > https://blog.golang.org/laws-of-reflection > > > > Excerpt: > > > > One important detail is that the pair inside

Re: [go-nuts] Query on Interfaces

On Mon, Jan 6, 2020 at 9:18 PM Prabhu Chawandi wrote: > > I was reading this article @ https://blog.golang.org/laws-of-reflection > > Excerpt: > > One important detail is that the pair inside an interface always has the form > (value, concrete type) and cannot have the form (value, interface ty

Re: [go-nuts] channel synchronous, how to assure happens before ??

Thank you for your reply, I agree there should be a memory barrier for the channel, for it is different from the other assignment statements and not a write operation. Have you got some readings talk about this? On Tuesday, January 7, 2020 at 10:17:43 AM UTC+8, Kurtis Rader wrote: > > On Mon, Ja

[go-nuts] Query on Interfaces

Hello, I was reading this article @ https://blog.golang.org/laws-of-reflection Excerpt: One important detail is that the pair inside an interface always has the form (value, concrete type) and cannot have the form (value, interface type). Interfaces do not hold interface values. I could not u

Re: [go-nuts] channel synchronous, how to assure happens before ??

On Mon, Jan 6, 2020 at 5:47 PM hao dong wrote: > thanks for your reply. Could you guide me any readings or source code > about channel of happens before. > I think you have misunderstood this text in the https://golang.org/ref/mem document you linked to: Within a single goroutine, reads and wri

Re: [go-nuts] channel synchronous, how to assure happens before ??

thanks for your reply. Could you guide me any readings or source code about channel of happens before. On Tuesday, January 7, 2020 at 3:02:30 AM UTC+8, Ian Lance Taylor wrote: > > On Mon, Jan 6, 2020 at 10:55 AM hao dong > > wrote: > > > > After reading blog post : https://golang.org/ref/mem

Re: [go-nuts] doubt about reflect.Type.String and empty interface

On Sun, Jan 5, 2020 at 5:29 PM Ian Lance Taylor wrote: > > On Sun, Jan 5, 2020 at 8:23 AM Manlio Perillo > wrote: > > >> [...] > > I decided to run a simple test > > https://play.golang.org/p/QAX92NQDqO4. > > > > [...] > > > > The question is: why reflect.Type.String() returns `` instead of >

Re: [go-nuts] RecvMsgUDP / SendMsgUDP

On Mon, Jan 6, 2020 at 12:46 PM John Dreystadt wrote: > > I noticed that the documentation for net.RecvMesgUDP and net.SendMesgUDP > seemed a bit odd because it referred to “out of band” for some of the > parameters being passed and some of the return values. This caused me to look > closely at

[go-nuts] RecvMsgUDP / SendMsgUDP

I noticed that the documentation for net.RecvMesgUDP and net.SendMesgUDP seemed a bit odd because it referred to “out of band” for some of the parameters being passed and some of the return values. This caused me to look closely at these two functions and here are the results of my research. Fir

Re: [go-nuts] channel synchronous, how to assure happens before ??

On Mon, Jan 6, 2020 at 10:55 AM hao dong wrote: > > After reading blog post : https://golang.org/ref/mem > > I got one question, in the code below: > > > var c = make(chan int, 10) > var a string > > func f() { > a = "hello, world" > c <- 0 > } > > func main() { > go f() > <-c > print(a) > } > > >

[go-nuts] channel synchronous, how to assure happens before ??

After reading blog post : https://golang.org/ref/mem I got one question, in the code below: var c = make(chan int, 10) var a string func f() { a = "hello, world" c <- 0 } func main() { go f() <-c print(a) } How can the complier knows that a = "hello,

[go-nuts] Re: modules exclude version and above

I use this version: go version go1.13.5 linux/amd64 -- 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 discuss

[go-nuts] Re: modules exclude version and above

Thx for your support. > Could you provide explicit steps (ideally a `go.mod` file and a corresponding `.go` source file, and the version of the Go toolchain you are using) to reproduce the problem? With this go.mod https://play.golang.org/p/PeSbMFMAsHf & with go get -u ./... the version stills

[go-nuts] Re: modules exclude version and above

Could you provide explicit steps (ideally a `go.mod` file and a corresponding `.go` source file, and the version of the Go toolchain you are using) to reproduce the problem? All three of those `v2` versions appear to have `go.mod` files, so the `go` command should not allow them to be used as `

Re: [go-nuts] Publishing and using go module from tarball?

See also the golang.org/x/mod/zip package. On Monday, January 6, 2020 at 10:02:25 AM UTC-5, Amnon Baron Cohen wrote: > > > Go modules tooling does not seem to support http at > > all and as for the https I did not find any way to allow use of > self-sign

Re: [go-nuts] Publishing and using go module from tarball?

> Go modules tooling does not seem to support http at > all and as for the https I did not find any way to allow use of self-signed > certificate... In Go 1.14 (available as in beta) you can set the GOINSECURE env var to allow http download. https://tip.golang.org/cmd/go/#hdr-Environment_variabl

Re: [go-nuts] Publishing and using go module from tarball?

In Go 1.14 (available as in beta) you can set the GOINSECURE env var to allow http download. https://tip.golang.org/cmd/go/#hdr-Environment_variables On Sunday, 5 January 2020 17:34:50 UTC, volf...@gmail.com wrote: > > > > On Sunday, January 5, 2020 at 11:02:52 AM UTC, Amnon Baron Cohen wrote: >

Re: [go-nuts] Re: distributed runtime

I think you want to use “nats streaming”. It does throttling via ACKs. > On Jan 6, 2020, at 7:35 AM, Jason E. Aten wrote: > >  >>> On Mon, Jan 6, 2020 at 6:24 AM Robert Engels wrote: >>> I’m pretty sure Nats.io has all of the same delivery guarantees as >>> rabbitmq. What design is not accom

Re: [go-nuts] Re: distributed runtime

On Mon, Jan 6, 2020 at 6:24 AM Robert Engels wrote: > I’m pretty sure Nats.io has all of the same delivery guarantees as > rabbitmq. What design is not accommodated by mats? > Any design that needs flow control is not accommodated by Nats.io. I've used Nats extensively and consider it fundamenta

Re: [go-nuts] Re: distributed runtime

I’m pretty sure Nats.io has all of the same delivery guarantees as rabbitmq. What design is not accommodated by mats? > On Jan 6, 2020, at 4:56 AM, ffm2...@web.de wrote: > >  > >> >> However, if you want to apply supervision for distributed Go channels you >> have to change from channels to

[go-nuts] Re: distributed runtime

> > However, if you want to apply supervision for distributed Go channels you > have to change from channels to actors - at least behind the scenes of the > distributed channels. AFAIK, no one has done something like that for > anything writen in Go. Nats is very reliable, but does not provide

[go-nuts] Re: distributed runtime

Am Montag, 6. Januar 2020 09:54:49 UTC+1 schrieb Brian Candler: > > On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote: >> >> in Amoeba a thread can be suspended, thereafter be sent to some other >> machine where it is resumed. >> > > Thread migration doesn't solve the OP's issue, becau

[go-nuts] Re: A question !

> > 2 - What is the fastest resource to learn Golang ( efficiently ) > For me the best thing was Effective Go https://golang.org/doc/effective_go.html Helps to understand "the go way"of coding and the main characteristics of the language -- You received this message because you are subscribe

[go-nuts] Re: distributed runtime

On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote: > > in Amoeba a thread can be suspended, thereafter be sent to some other > machine where it is resumed. > Thread migration doesn't solve the OP's issue, because threads share memory with other threads: passing a copy of something is n

[go-nuts] Re: distributed runtime

On Monday, 6 January 2020 08:36:56 UTC, ffm...@web.de wrote: > > in Amoeba a thread can be suspended, thereafter be sent to some other > machine where it is resumed. > Thread migration doesn't solve the OP's issue, because threads share memory with other threads: passing a copy of something is n

[go-nuts] Re: distributed runtime

Have you heard of the Amoeba distributed OS? See https://en.wikipedia.org/wiki/Amoeba_(operating_system). Well, in Amoeba a thread can be suspended, thereafter be sent to some other machine where it is resumed. That you can't do with goroutines of course (and goroutines pursue a different appro