[go-nuts] Re: Debugging error: plugin.Open: plugin was built with a different version of package

This happened to me as well when using vendored dependencies. Is this your case? If so move the dependencies to GOPATH On Thursday, October 19, 2017 at 5:37:53 PM UTC+3, voidlogic wrote: > > Hey Everyone, > > Does anyone know how to debug "*plugin.Open: plugin was built with a > different versio

Re: [go-nuts] Re: Should you check error from ResponseWriter.Write()?

In thw concrete case, ResponseWriter.Write is buffered, so you won't get an error on network hiccups. -- 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

RE: [go-nuts] will the following code always print two 1?

Hi Dave. Oops! I read it as "pad". My bad. John John Souvestre - New Orleans LA From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On Behalf Of Dave Cheney Sent: 2017 October 22, Sun 22:27 To: golang-nuts Subject: Re: [go-nuts] will the following code alway

Re: [go-nuts] will the following code always print two 1?

On Sun, Oct 22, 2017 at 7:37 PM, wrote: > For the second section (the one with locks), the program is guaranteed to > print a 1 (if it prints anything). > The Go memory model guarantees this. This follows from the facts: > x = 1 @29 happens before m.Unlock() @31 > m.Unlock() @31 happens bef

Re: [go-nuts] will the following code always print two 1?

Thanks Keith. I fat fingered my response and it probably wasn’t clear that I was talking about the requirement to pair atomic stores and loads. I agree that if atomic store and loads are used for both variables, the program will print a 1 On Monday, 23 October 2017 14:01:17 UTC+11, John Souvest

RE: [go-nuts] will the following code always print two 1?

Interesting. I hadn't heard this. Do you happen to recall where you ran across it? I did a fast (not comprehensive) look at about 10 files in Go\src\... in which I found "atomic.StoreUint". None of them seemed to use any padding. John John Souvestre - New Orleans LA -Original Mess

Re: [go-nuts] will the following code always print two 1?

For the second section (the one with locks), the program is guaranteed to print a 1 (if it prints anything). The Go memory model guarantees this. This follows from the facts: x = 1 @29 happens before m.Unlock() @31 m.Unlock() @31 happens before m.Lock() @35 m.

RE: [go-nuts] will the following code always print two 1?

If that we’re the case then you wouldn’t need to paid an atomic.Store with an atomic.Load. But as I understand it, you do. -- 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

RE: [go-nuts] will the following code always print two 1?

Summarizing various conversations I've seen: The Go Memory Model says that "synchronization primitives" are in the sync and sync/atomic packages. It also says that a "synchronization mechanism" establishes relative ordering as observed by another goroutine. In other words, Go's atomics are fu

Re: [go-nuts] will the following code always print two 1?

On reflection, yes this program will always print 1. -- 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. For more options,

Re: [go-nuts] will the following code always print two 1?

Maybe, but I think it’s better to stick to only what is written I the Go memory model document. If it doesn’t reference ideas from other languages, you shouldn’t either. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

Re: [go-nuts] will the following code always print two 1?

Not guaranteed. -- 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. For more options, visit https://groups.google.com/d/opt

Re: [go-nuts] Re: Should you check error from ResponseWriter.Write()?

I don't have a specific situation in mind where I could correct an error returned from Write() but it feels nice to log the error if one occurs just for the sake of knowing. Is that silly? I'm picturing that it could be helpful if there is a spike in network trouble because then you would be ab

Re: [go-nuts] will the following code always print two 1?

Nope, as I understand it atomic load and store are not memory fencing operations. -- 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...@googleg

[go-nuts] Should you check error from ResponseWriter.Write()?

For context, you might log this as a specific error, if you find you need to. It would not be unlike nginx’s HTTP 499, which is logged when the client prematurely closes the connection. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubs

Re: [go-nuts] Sanitising a UTF-8 string

On Sun, Oct 22, 2017, at 09:29, Juliusz Chroboczek wrote: > I'm probably missing something obvious, but I've looked through the > standard library to no avail. How do I sanitise a []byte to make sure > it's a UTF-8 string by replacing all incorrect sequences by the > replacement character (or what

Re: [go-nuts] will the following code always print two 1?

Can I think the atomic store and load operation in go are equivalent to the atomic load and store with *memory_order_relaxed* in c++? On Sunday, October 22, 2017 at 12:12:19 PM UTC-4, T L wrote: > > And how about this one. Also no guarantees to always print 1? > > package main > > import "fmt" > i

Re: [go-nuts] Sanitising a UTF-8 string

Converting a string to a slice of runes gives you the individual code points, with the replacement character as necessary. Converting a slice of runes into a string gives you the UTF-8 representation. So sanitation of a string should be as simple as string([]rune(someString)). This will be O(n)

Re: [go-nuts] will the following code always print two 1?

And how about this one. Also no guarantees to always print 1? package main import "fmt" import "sync/atomic" import "runtime" func main() { runtime.GOMAXPROCS(1) var a, b int32 = 0, 0 go func() { atomic.AddInt32(&a, 1) atomic.AddInt32(&b, 1) }() for

Re: [go-nuts] Sanitising a UTF-8 string

See the section "For statements with range clause" in the spec: https://golang.org/ref/spec#For_statements "For a string value, the "range" clause iterates over the Unicode code points in the string starting at byte index 0. On successive iterations, the index value will be the index of the first

Re: [go-nuts] Re: Should you check error from ResponseWriter.Write()?

On 22 Oct 2017, at 17:29, "groenendaa...@gmail.com" mailto:groenendaa...@gmail.com>> wrote: So do you think this error should be checked and if yes, under what circumstances? I think Tamás already answered this. If you need to know whether the write succeeded a

Re: [go-nuts] Re: Should you check error from ResponseWriter.Write()?

So do you think this error should be checked and if yes, under what circumstances? On Sunday, October 22, 2017 at 2:05:37 AM UTC-5, Jakob Borg wrote: > > On 21 Oct 2017, at 21:20, "groene...@gmail.com " < > groene...@gmail.com > wrote: > > And again, when might Write() return an error at all? > >

[go-nuts] Sanitising a UTF-8 string

I'm probably missing something obvious, but I've looked through the standard library to no avail. How do I sanitise a []byte to make sure it's a UTF-8 string by replacing all incorrect sequences by the replacement character (or whatever)? I've found unicode/utf8.Valid, which tells me if a []byte

Re: [go-nuts] will the following code always print two 1?

So the Go 1 memory model really make no guarantees that the following program will print 1? package main import "fmt" import "sync/atomic" import "runtime" func main() { runtime.GOMAXPROCS(1) var a, b int32 = 0, 0 go func() { a = 1 atomic.AddInt32(&b, 1) }()

Re: [go-nuts] will the following code always print two 1?

On Sunday, October 22, 2017 at 5:55:54 AM UTC-4, Jan Mercl wrote: > > On Sun, Oct 22, 2017 at 9:19 AM T L > > wrote: > > > why? > > The OP code with line numbes: https://play.golang.org/p/4fmiWqDDc1 > > The main goroutine busy loops at lines 15-20. Because of that the > goroutine at line 10 may

Re: [go-nuts] Re: slice of pointer of struct vs slice of struct

No, you are right but then I have made an explicit decision that state is important and mutable so hopefully I would take that into consideration when exposing the data. lör 21 okt. 2017 kl 13:00 skrev Juliusz Chroboczek : > > I have started to use non pointer slices much more as of late. > > Eve

Re: [go-nuts] TCP writes without a corresponding read?

On 10/22/2017 06:06 AM, Ayan George wrote: > > > buf := make([]byte, 0, 20) > Sorry -- I meant: buf := make([]byte, 20) -- 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, se

Re: [go-nuts] TCP writes without a corresponding read?

On 10/22/2017 04:50 AM, Matt Mueller wrote: > Hey everyone! > > This question cropped up while testing. It's 2 related questions: > > *1. Why am I able to write to without accepting a connection?* > As I understand it, by the time you accept() a connection, the TCP stream has already been est

Re: [go-nuts] will the following code always print two 1?

On Sun, Oct 22, 2017 at 9:19 AM T L wrote: > why? The OP code with line numbes: https://play.golang.org/p/4fmiWqDDc1 The main goroutine busy loops at lines 15-20. Because of that the goroutine at line 10 may never run and thus line 17 may never get executed. If so, line 18 and thus also lines 2

Re: [go-nuts] TCP writes without a corresponding read?

With TCP a successful write means the bytes are now managed by your network stack. If there are no permanent errors, then it will get those bytes to the other end of the TCP connection eventually. A successful write is not a receipt from the other end. On Sun, Oct 22, 2017 at 4:50 AM, Matt Mueller

Re: [go-nuts] Easiest way to work with database

Here is a very basic example. No audio, just follow the code. https://www.youtube.com/watch?v=b81phqjXzEA Josh On Sun, Oct 22, 2017 at 4:47 AM, Shawn Milochik wrote: > Assumptions: > >- You're using the html/template package: https://golang.org/ >pkg/html/template/ >- You name your

[go-nuts] TCP writes without a corresponding read?

Hey everyone! This question cropped up while testing. It's 2 related questions: *1. Why am I able to write to without accepting a connection?* addr, err := net.ResolveTCPAddr("tcp", "127.0.0.1:0") if err != nil { t.Fatal(err) } ln, err := net.ListenTCP("tcp", addr) if err != nil {

[go-nuts] Re: Invalid Segment Alignment when pushing to iTunesConnect

Another thing: Is the problem present in go tip (to become 1.10) as well? And finally, can you reproduce the problem with the simple golang.org/x/mobile/example/bind example? - elias On Sunday, October 22, 2017 at 10:26:15 AM UTC+2, Elias Naur wrote: > > Hi Paul, > > What version of Go, Xcode

[go-nuts] Re: Invalid Segment Alignment when pushing to iTunesConnect

Hi Paul, What version of Go, Xcode an macOS are you using? I'd like to help you debug the problem, but Xcode doesn't seem to allow me to run the validation of an archived build without a developer account. - elias On Sunday, October 22, 2017 at 6:34:15 AM UTC+2, pru...@gmail.com wrote: > > I'

[go-nuts] Re: will the following code always print two 1?

On Saturday, October 21, 2017 at 6:38:29 PM UTC-4, Dave Cheney wrote: > > no to your first example, yes to the second. > Thanks. Yes, the second is really mentioned in the Lock section in https://golang.org/ref/mem BTW, I can't find the context for the *n* and *m* *(n < m) *in this section. W

Re: [go-nuts] will the following code always print two 1?

On Saturday, October 21, 2017 at 5:13:09 PM UTC-4, Jan Mercl wrote: > > On Sat, Oct 21, 2017 at 11:01 PM T L > > wrote: > > > fmt.Println(a) // always print 1? > > Possibly. But the statement may never execute. > > > //== > > > fmt.Println(x) // always print 1? > > Same answe

Re: [go-nuts] Re: Should you check error from ResponseWriter.Write()?

On 21 Oct 2017, at 21:20, "groenendaa...@gmail.com" mailto:groenendaa...@gmail.com>> wrote: And again, when might Write() return an error at all? For example if the client browser crashes, the user clicks "stop", or there is a network problem. //jb -- You rece