Re: [go-nuts] Closing a closed channel

[Andrey Tcherepanov]

Ian,
Sorry to revive this old thread. Would it be possible to add your answer 
(and a solution with sync.Once suggested on this thread) to a FAQ and/or 
Effective Go document?

Yes, I stepped on it too trying to use close() as a signal that work is 
done, and then doing close() in a cleanup goroutine :)

Thank you very much,
   Andrey

On Wednesday, April 27, 2016 at 8:18:07 AM UTC-6, Ian Lance Taylor wrote:
>
> On Wed, Apr 27, 2016 at 6:52 AM, Alex Bligh  > wrote: 
> > Closing a closed channel causes a panic - I know that. I'm interested in 
> why? 
> > 
> > I've seen (and written) lots of code that does 
> > 
> > func (x *X) Close() { 
> > x.mutex.Lock() 
> > defer x.mutex.Unlock() 
> > if !x.closed { 
> > x.closed = true 
> > close(x.chan) 
> > } 
> > } 
> > 
> > and have never seen a much simpler way to do it. A common reason is a 
> > 'done' signal on a chan struct{}. Yes I know you can use the context 
> > package, but that surely does something similar under the hood. 
> > 
> > Is there a good *reason* why closing a closed channel panics rather 
> > than does nothing? e.g. does making it safe add a lot of overhead? 
>
> Closing a channel is a signal to the goroutine reading from the 
> channel that there are no more values to send.  There should never be 
> any confusion as to whether there are more values to send or not. 
> Either you are done, and you close the channel, or you are not done, 
> and you do not close the channel.  Closing a channel twice implies 
> that you don't know whether you are done or not.  By that argument, 
> closing a channel twice does not make sense, so the runtime panics. 
>
> It's true that there can be cases, especially when you aren't really 
> writing any values to the channel but are just using it as a 
> signalling mechanism, that you don't know whether you are done or not. 
> The current sense is that those cases are sufficiently rare that it's 
> appropriate to push the responsibility for the double close onto the 
> closer.  Perhaps that should be rethought at some point, though not 
> for Go 1.7.  The way to change this would be to make a proposal that 
> surveys some amount of Go code to see how much of it is (correctly) 
> checking for whether the channel has been closed before closing it. 
> If there is a lot of such code then perhaps the runtime should change 
> to silently ignore a close of a closed channel. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Error when using go tool trace

[evan . explodes]

I ran into this same problem, and found this post!
It looks like you're making the same simple mistake I was:

# erroneous:
defer f.Close()
defer trace.Stop()

You must stop the trace *before* closing the output file.

# corrected:
defer func() {
  trace.Stop()
  panic(f.Close()) # Be sure to handle file-closing errors. They're 
important!!
}

On Tuesday, October 11, 2016 at 8:21:17 AM UTC-6, xavier zebier wrote:
>
> Hello,
> I m trying to use the go tool trace. My code is 
>
>
> package main
>
> import (
> "flag"
> "fmt"
> "math"
> "net/http"
> "os"
> "runtime"
> "runtime/trace"
> "time"
> )
>
> func indexHandler(w http.ResponseWriter, r *http.Request) {
> primesInRangeParallel(10, 64)
> fmt.Fprintf(w, "hello world, I'm running on %s with an %s CPU ", 
> runtime.GOOS, runtime.GOARCH)
>
> }
>
> func main() {
> flag.Parse()
> f, errs := os.Create(time.Now().Format("2006-01-02T150405.out"))
> if errs != nil {
> panic(errs)
> }
>
> if err := trace.Start(f); err != nil {
> panic(err)
> }
>
> defer f.Close()
> defer trace.Stop()
> http.HandleFunc("/", indexHandler)
>
> http.ListenAndServe(":8080", nil)
> }
>
> // We will use this struct to communicate results via a channel
> type PrimeResult struct {
> number int64 // A number
> prime  bool  // Is prime or not
> }
>
> /**
>  * A function to return a prime calculation over a channel. This way
>  * we don't need to have 2 versions of isPrime function, one for
>  * sequential calculations and another for paralel
>  */
>
> func isPrimeAsync(number int64, channel chan PrimeResult) {
>
> result := new(PrimeResult)
> result.number = number
> result.prime = isPrime(number)
> channel <- *result
> }
>
> /**
>  * Accepts a range of integers [min, max] and a channel and it executes
>  * in PARALEL the processes that check if a number is prime or not.
>  *
>  * This function does nothing with the result. In another point, somebody
>  * will have to read the channel and process the results
>  */
> func firePrimeCalculations(min int64, max int64, channel chan PrimeResult) 
> {
> var i int64
> for i = min; i <= max; i++ {
> go isPrimeAsync(i, channel)
> }
> }
>
> /**
>  * Accepts a range of integers [min, max] and
>  * returns an array with all the prime numbers in this range.
>  *
>  * Execution is done in paralel. First it fires all the
>  * processes that check for a prime number. These processes
>  * will write the result in a channel.
>  *
>  * We will receive the results over this channel creating the
>  * list of prime numbers and returning it
>  *
>  */
>
> func primesInRangeParallel(min int64, max int64) []int64 {
> var primeNumbers []int64
> var res PrimeResult
> var prev int64
>
> channel := make(chan PrimeResult)
> defer close(channel)
>
> go firePrimeCalculations(min, max, channel)
>
> prev = 0
> for i := min; i <= max; i++ {
> res = <-channel
> if res.prime {
> primeNumbers = append(primeNumbers, res.number)
>
> done := 100 * (i - min) / (max - min)
> if prev != done {
> fmt.Printf("%d %% done.\n", done)
> prev = done
> }
> }
> }
> return primeNumbers
> }
> func isPrime(candidate int64) bool {
> var i, limit int64
>
> if candidate == 2 {
> return true
> }
>
> if math.Mod(float64(candidate), 2) == 0 {
> return false
> }
>
> limit = int64(math.Ceil(math.Sqrt(float64(candidate
> for i = 3; i <= limit; i += 2 { //Only odd numbers
> if math.Mod(float64(candidate), float64(i)) == 0 {
> return false
> }
> }
> return true
> }
>
> The prime number calculation is basically there to get some calculation.
>
> My go env command gives  : 
>
> C:\repo\gonew\src\github.com\tixu\trace>go env
> set GOARCH=amd64
> set GOBIN=
> set GOEXE=.exe
> set GOHOSTARCH=amd64
> set GOHOSTOS=windows
> set GOOS=windows
> set GOPATH=c:\repo\gonew
> set GORACE=
> set GOROOT=C:\Go
> set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
> set CC=gcc
> set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
> set CXX=g++
> set CGO_ENABLED=1
>
>
>
> And I get the following error :
>
> C:\repo\gonew\src\github.com\tixu\trace>go tool trace Trace 
> 2016-10-11T153554.out
> 2016/10/11 15:36:45 Parsing trace...
> failed to parse trace: no EvFrequency event 
>
> Can you help me .?
>
> Thanks in advance,
>
> Xavier
>

-- 
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/optout.

[go-nuts] Re: Problems buildding go from source, tests "hangs"

[SauliusGurklys]

$(go env CC) --version
gcc (GCC) 7.1.1 20170630
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I want to add that I think that original issue was related to the fact that 
I had packaged "gcc-multilib" (not "gcc") installed.
After I switched to "gcc" problem was gone.

Also after  commit

commit b63db76c4ae4e154ed40b4ec3c782d7fe9c0d3b6
Author: Ian Lance Taylor  
Date:   Wed Aug 2 10:49:20 2017 -0700  
   
testsanitizers: check that tsan program runs, skip tsan10 on gcc   
   
Check not only that a tsan program can be built, but also that it runs.
This fails with some installations of GCC 7.   
   
Skip the tsan10 program when using GCC, as it reportedly hangs.
   
This is a patch to help people build 1.9; we may be able to do a   
better fix for 1.10.   
   
Updates #21196 
   
Change-Id: Icd1ffbd018dc65a97ff45cab1264b9b0c7fa0ab2   
Reviewed-on: https://go-review.googlesource.com/52790  
Run-TryBot: Ian Lance Taylor  
Run-TryBot: Bryan Mills    
Reviewed-by: Bryan Mills   
TryBot-Result: Gobot Gobot   


problem is gone and with "gcc-multilib" too.

On Wednesday, August 2, 2017 at 9:30:49 PM UTC+3, Bryan C. Mills wrote:
>
> What is the output of `$(go env CC) --version` on your machine?`
>
> On Wednesday, August 2, 2017 at 8:31:37 AM UTC-4, SauliusGurklys wrote:
>>
>> Hi,
>>
>> while building go from source:
>>
>> cd /usr/local/src/go
>> ./clean.bash
>> ./all.bash
>>
>> build succeeds without any problem and then when tests are started then 
>> they just "hangs"
>>
>> ...
>> # ../misc/cgo/testplugin
>> PASS
>> something
>>
>> # ../misc/cgo/testasan
>>
>> # ../misc/cgo/testsanitizers
>>
>> after this point nothing happens (tried to wait for a couple of days).
>> I tried many times, but "hanging" happens at this test(s).
>>
>> I building go, the same way, on several machines, and this problem 
>> happens only on one of them.
>>
>> The "problem" machine is
>>
>> $ lsb_release -a
>> LSB Version:n/a
>> Distributor ID: ManjaroLinux
>> Description:Manjaro Linux
>> Release:17.0.2
>> Codename:   Gellivara
>>
>> $ uname -a
>> Linux bubo 4.12.3-1-MANJARO #1 SMP PREEMPT Fri Jul 21 09:37:31 UTC 2017 
>> x86_64 GNU/Linux
>>
>> Maybe somebody had and solved such problem?
>> Any thoughts?
>>
>> Kind regards,
>> --
>> Saulius
>>
>>
>>

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[Lucio De Re]

Walter Bright, indeed. Thank you for the correction.

I hope it was clear enough in context and my slip-up did not offend anyone.

Lucio.

On 8/3/17, Russel Winder  wrote:
> On Thu, 2017-08-03 at 03:50 -0700, Lucio wrote:
>>
> […]
>> PS: I think David Bright is a genius. I still have my original copies of
>> Zortech C++ (versions 1 and 2) which almost certainly have only
>> antiquarian
>> value. But the man who produced that masterpiece deserves to be
>> recognised.
>> So if he happens to stumble on this discussion, let it be clear that my
>> lack of interest in D is no reflection of my respect for its originator.
>
> Walter rather than David?
>
> --
> Russel.
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824
FAX: +27 58 653 1435

-- 
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/optout.

[go-nuts] Re: Generics are overrated.

[Dorival Pedroso]

Agreed!

And I was a "heavy" user of templates (see e.g. http://mechsys.nongnu.org/, 
including extensive use of "expression templates") ~5 years ago before the 
"wonders of Go".

Let's focus on making Go faster instead!

Cheers.
Dorival

On Friday, July 28, 2017 at 10:41:10 PM UTC+10, dogan...@dodobyte.com wrote:
>
> *Everything in this thread is my personal opinions, they are not 
> necessarily the truth.*
>
> My main language was C for a decade. I also liked Python. When i started 
> learning Go, it almost felt like i knew the language in another life. 
> Everything was so obvious.
>
> CSP model of concurrency was new to me though. Interfaces were more 
> familiar due to unix's open,close,read,write interface, which is the 
> greatest idea.
>
> I didn't use generics or templates much (it's kind of stupid for me to 
> talk about it's necessity), therefore this is more like a meta-research.
>
> - Go developers created a great standard library and many great software 
> without generics in the language.
> - Many companies switched to Go from the languages that have generics in 
> it.
> - A little copying is better than having a big feature in the language.
> - Using generics everywhere is more of a design choice than a necessity.
>
>
> *A language that doesn’t have everything is actually easier to program in 
> than some that do. (Dennis Ritchie).*
>
> I wrote many different types of software in C. A country wide (a big one) 
> server, two AV engines for two major AV companies etc. I needed generics 
> only few times, but i could handle it in C without using smart tricks. In 
> Go however, there are much safer, better and elegant solutions to achieve 
> the same results. Do we really need a big feature for it?
>
> I didn't hear a complaint about the lack of generics in Go from a C 
> programmer, although i'm sure there are. 
> Maybe java programmers use generics more than they are supposed to. Maybe 
> they should stop writing java in Go. I am confident that they would abuse 
> generics if Go had one.
>
> That brings me to my point.
>
> I believe that generics would divide the Go community.
>
> It's well known that everybody uses a subset of C++ language. Google 
> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
> C++ in my last company and i felt the pain.
>
> Rob Pike himself talked about it. 
> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>
> Now Go is unique because people come to Go from all kind of different 
> languages, (javascript, Python, C,...). see 
> https://blog.golang.org/survey2016-results
>
> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
> will look alien to Go 1 programmers. Some people will not use generics at 
> all while others overuse it.
>
> For a language like Go, this is disastrous because it's against Go's 
> philosophy. I love gofmt because it enforces a standart format and saves 
> our time of debating about indention and other things. What good it is to 
> have a standard format while you have completely different programming 
> styles.
>
> Dear Go experts;
>
> Please provide some best practices to achieve generic behavior for the 
> most common cases, instead of implementing Generics in Go.
>
> Let's end this debate and help keeping Go small and simple. It's the real 
> virtue of Go. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Computations with complex numbers may be slow if care is not taken

[Dorival Pedroso]

This is the version of a pure imaginary real number raised to the power of 
n (integer):

// ImagXpowN computes (x⋅i)ⁿ
//
//   (x⋅i)¹ = x¹⋅i  (x⋅i)²  = -x²   (x⋅i)³  = -x³ ⋅i  (x⋅i)⁴  = 
x⁴
//   (x⋅i)⁵ = x⁵⋅i  (x⋅i)⁶  = -x⁶   (x⋅i)⁷  = -x⁷ ⋅i  (x⋅i)⁸  = 
x⁸
//   (x⋅i)⁹ = x⁹⋅i  (x⋅i)¹⁰ = -x¹⁰  (x⋅i)¹¹ = -x¹¹⋅i  (x⋅i)¹² = 
x¹²
//
func ImagXpowN(x float64, n int) complex128 {
if n == 0 {
return 1
}
xn := math.Pow(x, float64(n))
switch n % 4 {
case 1:
return complex(0, xn)
case 2:
return complex(-xn, 0)
case 3:
return complex(0, -xn)
}
return complex(xn, 0)
}


These are the benchmark functions:

func BenchmarkImagXpowN(b *testing.B) {
x := 2.5
for i := 0; i < b.N; i++ {
for n := 0; n < 200; n++ {
ImagXpowN(x, n)
}
}
}

func BenchmarkImagXpowNcmplx(b *testing.B) {
x := 2.5
for i := 0; i < b.N; i++ {
for n := 0; n < 200; n++ {
cmplx.Pow(complex(0, x), complex(float64(n), 0))
}
}
}


With the following results:
BenchmarkImagXpowN-32  20 10299 ns/op
BenchmarkImagXpowNcmplx-32  10 18595 ns/op

Now it's "just" 1.8x faster.

Cheers
D



On Friday, August 4, 2017 at 10:43:41 AM UTC+10, Dorival Pedroso wrote:
>
> Hi,
>
> This is an interesting benchmark:
>
> Given this function:
> // ImagPowN computes iⁿ = (√-1)ⁿ
> //
> //   i¹ = i  i²  = -1  i³  = -i  i⁴  = 1
> //   i⁵ = i  i⁶  = -1  i⁷  = -i  i⁸  = 1
> //   i⁹ = i  i¹⁰ = -1  i¹¹ = -i  i¹² = 1
> //
> func ImagPowN(n int) complex128 {
> if n == 0 {
> return 1
> }
> switch n % 4 {
> case 1:
> return 1i
> case 2:
> return -1
> case 3:
> return -1i
> }
> return 1
> }
>
> And this benchmark test:
> var (
> imagpownRes complex128
> )
>
> func BenchmarkImagPowN(b *testing.B) {
> var res complex128
> for i := 0; i < b.N; i++ {
> for n := 0; n < 200; n++ {
> res = ImagPowN(n)
> }
> }
> imagpownRes = res
> }
>
> func BenchmarkImagPowNcmplx(b *testing.B) {
> var res complex128
> for i := 0; i < b.N; i++ {
> for n := 0; n < 200; n++ {
> res = cmplx.Pow(1i, complex(float64(n), 0))
> }
> }
> imagpownRes = res
> }
>
> We get this output (  go test -run=XXX -bench=.  ):
> BenchmarkImagPowN-32 300   470 ns/op
> BenchmarkImagPowNcmplx-32  20 10050 ns/op
>
> A 20x speed up...
>
> Cheers.
> Dorival
>

-- 
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/optout.

Re: [go-nuts] Computations with complex numbers may be slow if care is not taken

[Matt Harden]

So it sounds like the special case that would be helpful is when the real
part of the complex base is 0.

On Thu, Aug 3, 2017, 18:26 Dorival Pedroso 
wrote:

> Thanks for the advice.
>
> This is the piece of code where I use that function:
> // compute hat(Du)
> pf := float64(p)
> for j := 0; j < N; j++ {
> ikp := ImagPowN(p) * complex(math.Pow(K[j], pf), 0)
> DuHat[j] = ikp * S[j] * A[j]
> }
>
> where p is an integer (unbounded), K[j] is a real number from -Inf to +Inf
> and S[j] and A[j] are complex (unbounded too)
>
> By using the ImagPowN(p) function, the code is much faster now...
>
> Cheers.
> D
>
>
>
> On Friday, August 4, 2017 at 10:54:14 AM UTC+10, Michael Jones wrote:
>
>> the complex power function is a difficult (time consuming) general
>> computation.
>>
>> are you saying that you actually have a program that uses boolean
>> gaussian integers and needs to do lots of power operations?
>>
>> if so, i highly recommend that you special case this for your own use.
>>
>> if this is common then the power code could stop and check for Re(x) in
>> {-1,0,1} and Im(x) in {-1,0,1} before undertaking the general computation.
>>
> On Thu, Aug 3, 2017 at 5:43 PM, Dorival Pedroso 
>> wrote:
>>
> Hi,
>>>
>>> This is an interesting benchmark:
>>>
>>> Given this function:
>>> // ImagPowN computes iⁿ = (√-1)ⁿ
>>> //
>>> //   i¹ = i  i²  = -1  i³  = -i  i⁴  = 1
>>> //   i⁵ = i  i⁶  = -1  i⁷  = -i  i⁸  = 1
>>> //   i⁹ = i  i¹⁰ = -1  i¹¹ = -i  i¹² = 1
>>> //
>>> func ImagPowN(n int) complex128 {
>>> if n == 0 {
>>> return 1
>>> }
>>> switch n % 4 {
>>> case 1:
>>> return 1i
>>> case 2:
>>> return -1
>>> case 3:
>>> return -1i
>>> }
>>> return 1
>>> }
>>>
>>> And this benchmark test:
>>> var (
>>> imagpownRes complex128
>>> )
>>>
>>> func BenchmarkImagPowN(b *testing.B) {
>>> var res complex128
>>> for i := 0; i < b.N; i++ {
>>> for n := 0; n < 200; n++ {
>>> res = ImagPowN(n)
>>> }
>>> }
>>> imagpownRes = res
>>> }
>>>
>>> func BenchmarkImagPowNcmplx(b *testing.B) {
>>> var res complex128
>>> for i := 0; i < b.N; i++ {
>>> for n := 0; n < 200; n++ {
>>> res = cmplx.Pow(1i, complex(float64(n), 0))
>>> }
>>> }
>>> imagpownRes = res
>>> }
>>>
>>> We get this output (  go test -run=XXX -bench=.  ):
>>> BenchmarkImagPowN-32 300   470 ns/op
>>> BenchmarkImagPowNcmplx-32  20 10050 ns/op
>>>
>>> A 20x speed up...
>>>
>>> Cheers.
>>> Dorival
>>>
>> --
>>> 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.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> Michael T. Jones
>> michae...@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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/optout.

Re: [go-nuts] Computations with complex numbers may be slow if care is not taken

[Dorival Pedroso]

Thanks for the advice.

This is the piece of code where I use that function:
// compute hat(Du)
pf := float64(p)
for j := 0; j < N; j++ {
ikp := ImagPowN(p) * complex(math.Pow(K[j], pf), 0)
DuHat[j] = ikp * S[j] * A[j]
}

where p is an integer (unbounded), K[j] is a real number from -Inf to +Inf 
and S[j] and A[j] are complex (unbounded too)

By using the ImagPowN(p) function, the code is much faster now...

Cheers.
D



On Friday, August 4, 2017 at 10:54:14 AM UTC+10, Michael Jones wrote:
>
> the complex power function is a difficult (time consuming) general 
> computation.
>
> are you saying that you actually have a program that uses boolean gaussian 
> integers and needs to do lots of power operations?
>
> if so, i highly recommend that you special case this for your own use. 
>
> if this is common then the power code could stop and check for Re(x) in 
> {-1,0,1} and Im(x) in {-1,0,1} before undertaking the general computation.
>
> On Thu, Aug 3, 2017 at 5:43 PM, Dorival Pedroso  > wrote:
>
>> Hi,
>>
>> This is an interesting benchmark:
>>
>> Given this function:
>> // ImagPowN computes iⁿ = (√-1)ⁿ
>> //
>> //   i¹ = i  i²  = -1  i³  = -i  i⁴  = 1
>> //   i⁵ = i  i⁶  = -1  i⁷  = -i  i⁸  = 1
>> //   i⁹ = i  i¹⁰ = -1  i¹¹ = -i  i¹² = 1
>> //
>> func ImagPowN(n int) complex128 {
>> if n == 0 {
>> return 1
>> }
>> switch n % 4 {
>> case 1:
>> return 1i
>> case 2:
>> return -1
>> case 3:
>> return -1i
>> }
>> return 1
>> }
>>
>> And this benchmark test:
>> var (
>> imagpownRes complex128
>> )
>>
>> func BenchmarkImagPowN(b *testing.B) {
>> var res complex128
>> for i := 0; i < b.N; i++ {
>> for n := 0; n < 200; n++ {
>> res = ImagPowN(n)
>> }
>> }
>> imagpownRes = res
>> }
>>
>> func BenchmarkImagPowNcmplx(b *testing.B) {
>> var res complex128
>> for i := 0; i < b.N; i++ {
>> for n := 0; n < 200; n++ {
>> res = cmplx.Pow(1i, complex(float64(n), 0))
>> }
>> }
>> imagpownRes = res
>> }
>>
>> We get this output (  go test -run=XXX -bench=.  ):
>> BenchmarkImagPowN-32 300   470 ns/op
>> BenchmarkImagPowNcmplx-32  20 10050 ns/op
>>
>> A 20x speed up...
>>
>> Cheers.
>> Dorival
>>
>> -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Michael T. Jones
> michae...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Computations with complex numbers may be slow if care is not taken

[Michael Jones]

the complex power function is a difficult (time consuming) general
computation.

are you saying that you actually have a program that uses boolean gaussian
integers and needs to do lots of power operations?

if so, i highly recommend that you special case this for your own use.

if this is common then the power code could stop and check for Re(x) in
{-1,0,1} and Im(x) in {-1,0,1} before undertaking the general computation.

On Thu, Aug 3, 2017 at 5:43 PM, Dorival Pedroso 
wrote:

> Hi,
>
> This is an interesting benchmark:
>
> Given this function:
> // ImagPowN computes iⁿ = (√-1)ⁿ
> //
> //   i¹ = i  i²  = -1  i³  = -i  i⁴  = 1
> //   i⁵ = i  i⁶  = -1  i⁷  = -i  i⁸  = 1
> //   i⁹ = i  i¹⁰ = -1  i¹¹ = -i  i¹² = 1
> //
> func ImagPowN(n int) complex128 {
> if n == 0 {
> return 1
> }
> switch n % 4 {
> case 1:
> return 1i
> case 2:
> return -1
> case 3:
> return -1i
> }
> return 1
> }
>
> And this benchmark test:
> var (
> imagpownRes complex128
> )
>
> func BenchmarkImagPowN(b *testing.B) {
> var res complex128
> for i := 0; i < b.N; i++ {
> for n := 0; n < 200; n++ {
> res = ImagPowN(n)
> }
> }
> imagpownRes = res
> }
>
> func BenchmarkImagPowNcmplx(b *testing.B) {
> var res complex128
> for i := 0; i < b.N; i++ {
> for n := 0; n < 200; n++ {
> res = cmplx.Pow(1i, complex(float64(n), 0))
> }
> }
> imagpownRes = res
> }
>
> We get this output (  go test -run=XXX -bench=.  ):
> BenchmarkImagPowN-32 300   470 ns/op
> BenchmarkImagPowNcmplx-32  20 10050 ns/op
>
> A 20x speed up...
>
> Cheers.
> Dorival
>
> --
> 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/optout.
>



-- 
Michael T. Jones
michael.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Computations with complex numbers may be slow if care is not taken

[Dorival Pedroso]

Hi,

This is an interesting benchmark:

Given this function:
// ImagPowN computes iⁿ = (√-1)ⁿ
//
//   i¹ = i  i²  = -1  i³  = -i  i⁴  = 1
//   i⁵ = i  i⁶  = -1  i⁷  = -i  i⁸  = 1
//   i⁹ = i  i¹⁰ = -1  i¹¹ = -i  i¹² = 1
//
func ImagPowN(n int) complex128 {
if n == 0 {
return 1
}
switch n % 4 {
case 1:
return 1i
case 2:
return -1
case 3:
return -1i
}
return 1
}

And this benchmark test:
var (
imagpownRes complex128
)

func BenchmarkImagPowN(b *testing.B) {
var res complex128
for i := 0; i < b.N; i++ {
for n := 0; n < 200; n++ {
res = ImagPowN(n)
}
}
imagpownRes = res
}

func BenchmarkImagPowNcmplx(b *testing.B) {
var res complex128
for i := 0; i < b.N; i++ {
for n := 0; n < 200; n++ {
res = cmplx.Pow(1i, complex(float64(n), 0))
}
}
imagpownRes = res
}

We get this output (  go test -run=XXX -bench=.  ):
BenchmarkImagPowN-32 300   470 ns/op
BenchmarkImagPowNcmplx-32  20 10050 ns/op

A 20x speed up...

Cheers.
Dorival

-- 
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/optout.

Re: [go-nuts] Re: gobind generated constructor for struct containing []byte sometimes corrupts data

[Antonio Marcedone]

Thanks! The only information I could find about this on the gobind 
documentation is (https://godoc.org/golang.org/x/mobile/cmd/gobind)

- Byte slice types. Note that byte slices are passed by reference,
  and support mutation.

However, this version of the code still shows the problem:

> String s = "This is a test string";
> byte[] b = s.getBytes();
> MyStruct struct = new MyStruct(b);
> tv.append("\nFirst time: "+ new String(struct.getE(), "UTF-8"));
> tv.append("\nOriginal: "+ new String(b, "UTF-8"));
>
>
which is confusing as here b shold not be garbage collected, so even a pass 
by reference should work. Can you point me somewhere I can read more about 
this issue please?

Also, are the automatically generated setters (i.e. struct.setE() ) doing 
the necessary cloning, or should I implement my own?

Thanks a lot again!
 
On Thursday, August 3, 2017 at 1:33:03 AM UTC-7, Elias Naur wrote:
>
> Yes, byte slices are special and are not reference counted like other 
> objects. You need to copy it on the Go side.
>
> - elias
>
> Den tor. 3. aug. 2017 03.21 skrev Antonio Marcedone  >:
>
>> My intuition above seems to contrast with 
>> https://godoc.org/golang.org/x/mobile/cmd/gobind:
>>
>> Avoid reference cycles
>>> The language bindings maintain a reference to each object that has been 
>>> proxied. When a proxy object becomes unreachable, its finalizer reports 
>>> this fact to the object's native side, so that the reference can be 
>>> removed, potentially allowing the object to be reclaimed by its native 
>>> garbage collector. The mechanism is symmetric.
>>
>>  
>>
>> On Wednesday, August 2, 2017 at 5:30:16 PM UTC-7, Antonio Marcedone wrote:
>>>
>>> I am not sure I understand what is going on here.
>>> For reference, the relevant code is:
>>>
>>> String s = "This is a test string";
>>>
>>> MyStruct struct = new MyStruct(s.getBytes("UTF-8"));
>>> //struct.setE(s.getBytes("UTF-8"));
>>> tv.append("\nFirst time: "+ new String(struct.getE(), "UTF-8"));
>>>
>>>
>>> with corresponding go part:
>>>
>>> package test
>>>
>>> type MyStruct struct{
>>> E []byte}
>>>
>>> func NewMyStruct(e []byte) *MyStruct{
>>> return {e}}
>>>
>>>
>>> so s.getBytes allocates a new byte[] (in Java). Then the MyStruct 
>>> constructor is called, and it gets a reference to such byte[]. 
>>> Are you saying that since the Java garbage collector is not aware that a 
>>> reference to that array is stored in some variable in the go code, then it 
>>> just deletes it as soon as the constructor returns? 
>>> And then the getE method just reads whatever happens to be in memory 
>>> where the old array was without throwing any error despite the fact that 
>>> the old byte[] has been garbage collected and might have been overwritten 
>>> by arbitrary data?
>>>
>>> Thanks a lot for your response!
>>> Antonio
>>>
>>> On Wednesday, August 2, 2017 at 3:30:06 PM UTC-7, Elias Naur wrote:

 []byte arguments are passed by reference, not copied. You need to copy 
 any byte slices you retain after the function or method call.

  - elias

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/TLy4sa3XRec/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/optout.

Re: [go-nuts] Re: Generics are overrated.

[Doğan Kurt]

>
>  it's amazing to see what people were able to accomplish with 2KB RAM, 
> *one* general-purpose register, no hardware multiply/divide,
>
 
Constraints boost creativity and discipline programmer. You may like this 
.

Today's mainstream programmers of mainstream languages just don't give a 
damn about simplicity or smallness. They don't spend any time for thinking 
a small and elegant design, they just start writing and writing as it's how 
they are taught.

This is 
grep from unix v7. It's still compiles* and runs perfectly and it's only 
478 sloc. Also see this. 

Go to me is an awesome little house on a beach. I love going to it in the 
> summer. Everything is great about it. Almost. It just doesn't have hot 
> water. I have to heat water myself and carry it for a 1/4 mile every time I 
> want to shower. It's kind of annoying, but not a big deal in itself to make 
> me stop going to the awesome super fun summer house. 
>

You are not only overestimating generics here, you are also underestimating 
programmers who code in languages without generics, such as C.

**i just needed to replace BSIZE with LBSIZE, it might be a typo.*

On Thursday, August 3, 2017 at 6:10:24 PM UTC+2, DV wrote:
>
> I think "need" is indeed one of those special words that means different 
> things for different people.
> Go doesn't "need" generics and you technically don't "need" anything 
> except air, water, food, a sharp spear, and shelter, to survive.
>
> I recently started toying with writing quick-n-dirty programs for the 
> original NES and it's amazing to see what people were able to accomplish 
> with 2KB RAM, *one* general-purpose register, no hardware multiply/divide, 
> etc Heck, it's even *fun* to do some of those things using 6502 assembly 
> from scratch! Doesn't mean I sometimes don't wish for certain 
> quality-of-life improvements with that experience, even though I can 
> definitely do it all from scratch, given infinite free time. 
>
> Does Go "need" (in the hunter-gatherer sense) generics? Absolutely not! 
>
> Go to me is an awesome little house on a beach. I love going to it in the 
> summer. Everything is great about it. Almost. It just doesn't have hot 
> water. I have to heat water myself and carry it for a 1/4 mile every time I 
> want to shower. It's kind of annoying, but not a big deal in itself to make 
> me stop going to the awesome super fun summer house. 
>
> I really like functional programming paradigms for data transformation 
> tasks. I like chaining 
> map(...).reduce().filter(.).skip(.).drop().select() 
> etc. and building a nice pipeline through which my data can flow. I *can* 
> do it all with loops, of course. Just like I can carry hot water for a 1/4 
> mile every day. 
>
> I'd love to be able to write generic compile-time type-safe functions but 
> I can live without them. 
>
>
> On Saturday, July 29, 2017 at 4:59:55 PM UTC-6, Shawn Milochik wrote:
>>
>> As with every community, there's the silent majority and the vocal 
>> minority. 
>>
>> It's easy to be confused, and think that the lack generics is a major 
>> issue in the Go community. It is *not*.
>>
>> The number 500,000 Go developers worldwide has been thrown around a lot 
>> this month. (https://research.swtch.com/gophercount)
>>
>> Evidently most of them are using Go just fine -- as individuals, at 
>> startups, and at huge companies.
>>
>> At every scale, Go's adoption is amazing and the the projects they're 
>> building are changing the world:
>>
>>- You don't need generics to write Docker.
>>- You don't need generics to write Kubernetes.
>>- We could add so much more to this list, but you get my point.
>>
>> So, let's stop feeding the trolls. The far fewer than 1% of the people 
>> who have not yet taken the time to appreciate Go for what it is, and 
>> therefore find it lacking in comparison to something they have taken the 
>> time to appreciate. I don't mean to belittle those people by calling them 
>> trolls, but they are trolling. I'm sure most of them who give the language 
>> an honest, unbiased try will come around.
>>
>> Imagine if Go programmers went to other language mailing lists and 
>> complained about the lack of goroutines and channels, which clearly make 
>> those other language "unfit for concurrent programming." That would be 
>> equally unhelpful.
>>
>>
>>

-- 
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/optout.

[go-nuts] When to use custom string type and custom int type

[Kaviraj Kanagaraj]

Can someone help me understand whats the main difference two different 
UserType in below snippet.?

More importantly when to use which.

```
type UserType string

const (
Undefined UserType = "undefined"
Admin UserType = "admin"
)

type UserType int

const (
Undefined UserType = iota
Admin
)

func (u UserType) String() string {
switch u {
case Undefined:
return "undefined"
case Admin:
return "admin"
}
return "UserType" + strconv.Itoa(int(u))
}
```

Some obvious differences including
1. More memory usage in case string based type
2. Usefull zero-value in case of int based type.

I just wanted to know is there any rule of thumb to decide when to use 
which.

Thanks in advance.

-- 
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/optout.

Re: [go-nuts] Re: Generics are overrated.

[DV]

I think "need" is indeed one of those special words that means different 
things for different people.
Go doesn't "need" generics and you technically don't "need" anything except 
air, water, food, a sharp spear, and shelter, to survive.

I recently started toying with writing quick-n-dirty programs for the 
original NES and it's amazing to see what people were able to accomplish 
with 2KB RAM, *one* general-purpose register, no hardware multiply/divide, 
etc Heck, it's even *fun* to do some of those things using 6502 assembly 
from scratch! Doesn't mean I sometimes don't wish for certain 
quality-of-life improvements with that experience, even though I can 
definitely do it all from scratch, given infinite free time. 

Does Go "need" (in the hunter-gatherer sense) generics? Absolutely not! 

Go to me is an awesome little house on a beach. I love going to it in the 
summer. Everything is great about it. Almost. It just doesn't have hot 
water. I have to heat water myself and carry it for a 1/4 mile every time I 
want to shower. It's kind of annoying, but not a big deal in itself to make 
me stop going to the awesome super fun summer house. 

I really like functional programming paradigms for data transformation 
tasks. I like chaining 
map(...).reduce().filter(.).skip(.).drop().select() 
etc. and building a nice pipeline through which my data can flow. I *can* 
do it all with loops, of course. Just like I can carry hot water for a 1/4 
mile every day. 

I'd love to be able to write generic compile-time type-safe functions but I 
can live without them. 


On Saturday, July 29, 2017 at 4:59:55 PM UTC-6, Shawn Milochik wrote:
>
> As with every community, there's the silent majority and the vocal 
> minority. 
>
> It's easy to be confused, and think that the lack generics is a major 
> issue in the Go community. It is *not*.
>
> The number 500,000 Go developers worldwide has been thrown around a lot 
> this month. (https://research.swtch.com/gophercount)
>
> Evidently most of them are using Go just fine -- as individuals, at 
> startups, and at huge companies.
>
> At every scale, Go's adoption is amazing and the the projects they're 
> building are changing the world:
>
>- You don't need generics to write Docker.
>- You don't need generics to write Kubernetes.
>- We could add so much more to this list, but you get my point.
>
> So, let's stop feeding the trolls. The far fewer than 1% of the people who 
> have not yet taken the time to appreciate Go for what it is, and therefore 
> find it lacking in comparison to something they have taken the time to 
> appreciate. I don't mean to belittle those people by calling them trolls, 
> but they are trolling. I'm sure most of them who give the language an 
> honest, unbiased try will come around.
>
> Imagine if Go programmers went to other language mailing lists and 
> complained about the lack of goroutines and channels, which clearly make 
> those other language "unfit for concurrent programming." That would be 
> equally unhelpful.
>
>
>

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[Russel Winder]

On Thu, 2017-08-03 at 03:50 -0700, Lucio wrote:
> 
[…]
> PS: I think David Bright is a genius. I still have my original copies of 
> Zortech C++ (versions 1 and 2) which almost certainly have only antiquarian 
> value. But the man who produced that masterpiece deserves to be recognised. 
> So if he happens to stumble on this discussion, let it be clear that my 
> lack of interest in D is no reflection of my respect for its originator.

Walter rather than David?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
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/optout.


signature.asc
Description: This is a digitally signed message part

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

I've already apologized for my misinterpretation. I want to point out that 
I was 100% sincere in what I was saying. 

Sorry if some of you have taken this for a bold lie, this wasn't absolutely 
meant this way. 

To be completely honest, I still believe what I was saying, even if I admit 
now that this was subject to interpretation.

And I agree that the addition of generics to Go is not especially relevant 
to this discussion on Go vs D.

On Thursday, August 3, 2017 at 3:03:18 PM UTC+1, Ian Lance Taylor wrote:
>
> I don't think this thread is going anywhere useful. 
>
> If people want to discuss technical comparisons between Go and D, that is 
> fine. 
>
> I want to encourage people to stop second guessing motives and 
> comments.  That does not seem helpful. 
>
> Thanks. 
>
> Ian 
>
>
>
> On Thu, Aug 3, 2017 at 6:51 AM,   
> wrote: 
> > Honestly, I didn't know what I was saying was not true. Sincerely. As I 
> > said, I'm a developer, not a psychologist. Interpreting people's thought 
> is 
> > not my job, I'm just a developer, and I haven't even graduated from 
> > university, I just have a bachelor's degree in software development. 
> > 
> > Sorry for my mistake... 
> > 
> > On Thursday, August 3, 2017 at 2:34:01 PM UTC+1, Jan Mercl wrote: 
> >> 
> >> On Thu, Aug 3, 2017 at 3:27 PM  wrote: 
> >> 
> >> > So you mean these 16% thought that Genericity would improve the 
> >> > language, but that it should not be added to the language. 
> >> 
> >> True version: I meant precisely only what I wrote. 
> >> 
> >> -- 
> >> 
> >> -j 
> > 
> > -- 
> > 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 . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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/optout.

[go-nuts] Go-based Smart Home Hub

[Tim]

Not 100% sure if this is the right group to post to, but just want to let 
everyone know that we've launched AERIFAI, a Go based smart home hub on 
Indiegogo:

https://www.indiegogo.com/projects/aerifai-breathe-easier-with-a-mindful-home-smartphone-energy#/

Our goals is to make this open for developers with an API and scripting 
engine if we meet our stretch goals. Note, only just started to publicize 
so no one really knows about this yet.

I'd love to hear from anyone that has any feedback or a wish list of things 
that they'd like to see.

Apologies if this is not an appropriate place to post Go hardware 
announcements.

Tim

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[Jan Mercl]

On Thu, Aug 3, 2017 at 3:52 PM  wrote:

>  Honestly, I didn't know what I was saying was not true. Sincerely. As I
said, I'm a developer, not a psychologist. Interpreting people's thought is
not my job, I'm just a developer, and I haven't even graduated from
university, I just have a bachelor's degree in software development.

I've only presented the facts, not any interpretation of them, so there are
none of my thoughts to interpret.

-- 

-j

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

Honestly, I didn't know what I was saying was not true. Sincerely. As I 
said, I'm a developer, not a psychologist. Interpreting people's thought is 
not my job, I'm just a developer, and I haven't even graduated from 
university, I just have a bachelor's degree in software development.

Sorry for my mistake...

On Thursday, August 3, 2017 at 2:34:01 PM UTC+1, Jan Mercl wrote:
>
> On Thu, Aug 3, 2017 at 3:27 PM  wrote:
>
> > So you mean these 16% thought that Genericity would improve the 
> language, but that it should not be added to the language.
>
> True version: I meant precisely only what I wrote.
>
> -- 
>
> -j
>

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[Jan Mercl]

On Thu, Aug 3, 2017 at 3:27 PM  wrote:

> So you mean these 16% thought that Genericity would improve the language,
but that it should not be added to the language.

True version: I meant precisely only what I wrote.

-- 

-j

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[ecstatic . coder]

So you mean these 16% thought that Genericity would improve the language, 
but that it should not be added to the language.

Ok, maybe I've misinterpreted the survey, I'm not a psychologist, I 
agree... ;)

Le jeudi 3 août 2017 14:15:31 UTC+1, Jan Mercl a écrit :
>
> On Thu, Aug 3, 2017 at 3:04 PM  wrote:
>
> > I agree that despite genericity is the #1 feature requested by Go 
> developers in Google's last official survey, ...
>
> True version: 16% of the respondents answered "generics" to the question 
> "What 
> changes would improve Go most?"
>
>
> -- 
>
> -j
>

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[Jan Mercl]

On Thu, Aug 3, 2017 at 3:04 PM  wrote:

> I agree that despite genericity is the #1 feature requested by Go
developers in Google's last official survey, ...

True version: 16% of the respondents answered "generics" to the question "What
changes would improve Go most?"


-- 

-j

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[eric . pelzer]

I agree that despite genericity is the #1 feature requested by Go 
developers in Google's last official survey, there are few chances they 
change their mind.

Idem for polymorphism.

So indeed, I've clearly understood that Google and most Go developers don't 
care at all about having templating, genericity and polymorphism features 
added to the language.

Anyway, I've already followed your advice, don't worry ;)

I've developped an open source generic preprocessor (Genesis) that can be 
used to add Allman style and a form of genericity to Go, and whetever 
language feature can be implemented using its macro system.

And I've recently developed a compiler for Helix, a PHP-like language which 
has more or less the same syntax as my Phoenix language, but which emits Go 
code instead of PHP code. 

It's not finished yet, but at least the templating and the primitive 
genericity system works already well enough for my personal use cases.

So as you see, I'm not just uselessly trying to "move the mountain"...

Le jeudi 3 août 2017 11:50:44 UTC+1, Lucio a écrit :
>
> Maybe, just maybe, you should consider that your opinion of the Go 
> language is a long list of wishful thinking and given that you already have 
> an alternative, you should accept that few Go developers/users are going to 
> take your side.
>
> Hoping that Go's vast library should magically materialise in D, or that 
> Google will be persuaded by your arguments to invest effort in D, is idle 
> sophism. Perhaps more useful would be some effort to translate the rather 
> simpler language Go to the more powerful (at least in your opinion) D. That 
> may in fact be productive and may prove rather than merely state your case.
>
> Lucio.
>
> PS: I think David Bright is a genius. I still have my original copies of 
> Zortech C++ (versions 1 and 2) which almost certainly have only antiquarian 
> value. But the man who produced that masterpiece deserves to be recognised. 
> So if he happens to stumble on this discussion, let it be clear that my 
> lack of interest in D is no reflection of my respect for its originator.
>
> On Wednesday, 2 August 2017 10:03:59 UTC+2, ecstati...@gmail.com wrote:
>>
>> I agree with you that the code must be developped using the KISS 
>> principle.
>>
>> Look at the D code of my github account. All you will see is "baby-code".
>>
>> Maybe, just maybe,The more complex stuff I use in D are genericy and 
>> polymorphism.
>>
>> And, from my personal experience, the lack of genericity and polymorphism 
>> in Go often forces me code in a less straightforward manner than in D.
>>
>> I have to find an indirect way (interface, etc) of doing something that 
>> would be simple and straightforward in D.
>>
>> Maybe I'm force to develop more powerful or sophisticated code in Go's 
>> way, I don't know, but I will never say that my Go code is much easier to 
>> program or to maintain than the same implementation in D.
>>
>> My github account is now full of tools progressively converted to D from 
>> an initial implementation in Go or Node.js, so I begin to have some 
>> experience in switching a tool from a language to another...
>>
>> On Wednesday, August 2, 2017 at 8:36:18 AM UTC+1, ohir wrote:
>>>
>>> On Tue, 1 Aug 2017 05:04:24 -0700 (PDT) 
>>> ecstati...@gmail.com wrote: 
>>>
>>> > But D also gives you reference classes, genericity, function 
>>> polymorphism, 
>>> > conditional compilation, design by contract assertions, compile-time 
>>> meta 
>>> > programming, 
>>>
>>> All things above to be avoided in _maintainable_ software. 
>>>
>>> Mantra: every working line of code is written once by one person 
>>> then it is read hundreds/thousands of times by dozens of people. 
>>>
>>> Go spares your pair, then supervisor, from manually enforcing on 
>>> you hard local rules: "We use C++ but you are forbidden to use: 
>>> exceptions, overloading, auto, weak ... ". Go language by itself gives 
>>> you all that -do-not-use-this-and-that- checks for free ;) 
>>>
>>> > and many other features that are severely lacking in Go. 
>>> Luckily. These and many other features _luckily_ lacking in Go. 
>>> Something that can't be used also can't be abused. 
>>>
>>> From the software maintainer pov Go is both readable and debuggable. 
>>> In Go one may grasp execution path and functionality from the very 
>>> fragment of source s/he is reading now. With very few exceptions. 
>>>
>>> Throw in any level of meta programming, even simple function overload, 
>>> and suddenly reader of a fragment of code is forced to read entirety of 
>>> entangled sources then map it mentally - all that just to grasp 
>>> importance 
>>> of that fragment s/he has read a while ago. Rinse and repeat on each 
>>> level 
>>> deep. 
>>>
>>> Any business gain (man-hour wise) form higher level 'features' is null, 
>>> void 
>>> and negative at first bug hunt on production code. More so if said code 
>>> authors are long gone from the team. Many businesses learnt this 
>>> hard 

Re: [go-nuts] look for a example: call a DLL's function on Windows by CGO

[Konstantin Khomoutov]

Hi!

Unfortunately you forgot to use the "reply to all" or "reply to list"
action so the message has only been sent to me, not to the list.
Please re-send/re-post correctly.

On Thu, Aug 03, 2017 at 07:33:03PM +0800, Fino Meng wrote:

>>> yesterday I just found that, the syscall way to use DLL on Windows cannot
>>> use float32 as parameters,
>>
>> Could you please elaborate on that as I do not beleive this is not
>> possible: IIRC Go's float types follow IEEE 754 semantics and you should
>> be able to use them "as is".
>>
>> If not, maybe it would be possible to use the Float64bits,
>> Float64FromBits from the math package (for doubles) and their 32-bit
>> counterparts (for floats).
>>
>>> so I am look for a example:  call a DLL's function on Windows in the
>>> CGO way, the DLL is not Windows' own DLL, but a third-party DLL
>>> which have a lot of double parameters,
>>
>> I would do this only as a last resort: you'd need a working C compiler
>> to build your package (and that wouldn't be MSVC++, IIRC).
>>
> after one day's study, I can use CGO with DLL on Windows now, it seems that
> the CGO's code is same for static or dynmatic libs.
> 
> but I still don't know the right way to tell ld where is the DLL.
> 
> now I need to put the DLL into this MINGW64's lib path:
> C:\Bin\mingw-w64\x86_64-7.1.0-win32-seh-rt_v5-rev0\mingw64\x86_64-w64-mingw32\lib

Please see the help on the cmd/cgo "package" (running `go help cmd/cgo`
is one way to get this help, or navigate to [1].

Basically you use something like

  // #cgo LDFLAGS=-Lpath/to/the/dll -ldllname

in your cgo comment block to make the contents of that variable passed
to the linker.

> for syscall's float problem, I found this:
> 
> I'm wondering if we can link a go code via cgo with a dll created with
> mingw-gcc?
> 
> It's possible. Add the path to the DLL to the cgo LDFLAGS, and use cgo to
> 
> call exported function from DLL as usual.
> 
> To call integer functions from DLL, you can also use the syscall package
> (search for DLL
> 
> in godoc), but there are some constrains in calling functions using the
> syscall package
> 
> (you can't pass floating point arguments, and the stack size is limited to
> 64K if it's a pure
> 
> Go program), so the recommended way to use a windows DLL (no matter how
> it's created,
> 
> MSVC or mingw) is to use cgo.

I was able to google for one of the exact phrase out of this citation,
and found out that most probably you were referring to this post on
golang-nuts [2].  Next time, please do this yourself so we have a proper
context of the citation (which can be studied and used for future
reference).

I'm not sure what to say about that: minux is definitely a knowledgeable
person; I had extensive experience calling Windows DLLs via the syscall
package but I never had a chance of calling functions which would
require passing double/float arguments from Go.

I wonder whether Alex Brainman maybe has something to say on these
matters.

1. https://golang.org/pkg/cmd/cgo/
2. https://groups.google.com/d/msg/golang-nuts/EdqqBX1EolI/SQ1HXhfoaAsJ

-- 
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/optout.

Re: [go-nuts] Re: HTTP/2 multiplexing

[Henrik Johansson]

Out of curiosity do you do something like this in wireshark?

ip.dst_host=="duckduckgo.com" && tcp.flags.syn == 0

My wireshark fu is really weak...

tors 3 aug. 2017 kl 11:35 skrev :

> Works, thanks a lot!!!
> Also found this related discussion:
> https://github.com/golang/go/issues/13397
>
> BR
> Daniele
>
>
> Il giorno giovedì 3 agosto 2017 11:21:18 UTC+2, Christian Joergensen ha
> scritto:
>>
>> On Thursday, August 3, 2017 at 11:07:50 AM UTC+2, pala.d...@gmail.com
>> wrote:
>>>
>>> Example code with DuckDuckGo as default target:
>>>
>>> https://play.golang.org/p/_iI5-MDJ5t
>>>
>>
>> This looks like a thundering herd race on connection setup. So there is
>> no connection to reuse as none of them has been setup yet.
>>
>> Try completing a single request and then run the rest of the requests in
>> parallel afterwards.
>>
>> Cheers,
>>
>> Christian
>>
>

-- 
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/optout.

Re: [go-nuts] lock for assigning to different elements of an array

[Henrik Johansson]

It does help, thank you Konstantin.

tors 3 aug. 2017 kl 10:25 skrev Konstantin Khomoutov :

> On Thu, Aug 03, 2017 at 07:21:24AM +, Henrik Johansson wrote:
>
> [...]
> > It gets hypothetical pretty quick and usually when this happens I make
> sure
> > to create a new array/slice/whatever and then atomically swap it before
> > some other goroutine uses it but I generally avoid indexing assignment
> from
> > go routines like this even though it seems to be ok.
> >
> > Does this hold for slices as well as for arrays? What about assignments
> to
> > fields in structs? Can several goroutines safely write to different
> fields
> > in the same struct assuming they are word sized? Does this hold for all
> > architectures?
> [...]
>
> From past discussions on this list, I gathered that two facts should be
> considered when reasoning about the conditions ...
>
> 1) When Go memory model discusses happens-before relationships between
>concurrently executing goroutines, it talks about *variables* operated
> on
>by those goroutines.
>
>This is sort of logical since Go does not allow access to arbitrary
>memory locations (as you could do in C, for instance): any writes and
>reads happen on variables.
>
>To cite the memory model document [1]:
>
>| The Go memory model specifies the conditions under which reads of a
>| variable in one goroutine can be guaranteed to observe values produced
>| by writes to the same variable in a different goroutine.
>
> 2) The Go language spec again talks about variables when it discusses
>types, and a crucial point of that discussion is that *structured*
>types are defined to behave like compositions of variables.
>
>To cite the spec:
>
>| A variable is a storage location for holding a value. The set of
>| permissible values is determined by the variable's type.
>| <...>
>| Structured variables of array, slice, and struct types have elements
> and
>| fields that may be addressed individually. Each such element acts
> like a
>| variable.
>
>To provide a slighly different view: a variable is a (typed) memory
>location which is addressable.  That's why invididual elements of
>arrays and slices are variables, and fields of the values of struct
>types are values, too, but the elements of maps are not: they are not
>addressable.
>
> Of course, certain caveats apply.
>
> For instance, a slice itself (the descriptor which contains the pointer
> to the underlying array, the length and the capacity) stored in a
> variable can be modified concurrently with any element of that slice
> without breaking the memory model rules, but the question of whether
> that would be a sensible superposition of operations is moot.
>
> Another example is modifying a variable containing a pointer to some
> variable of a struct type concurrently with the pointed-to value: this
> is not against the memory model but may be nonsensical from the point of
> view of the desired outcome of the program.
>
> Hope that helps.
>
>

-- 
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/optout.

Re: [go-nuts] Re: GO Vs D

[Lucio]

Maybe, just maybe, you should consider that your opinion of the Go language 
is a long list of wishful thinking and given that you already have an 
alternative, you should accept that few Go developers/users are going to 
take your side.

Hoping that Go's vast library should magically materialise in D, or that 
Google will be persuaded by your arguments to invest effort in D, is idle 
sophism. Perhaps more useful would be some effort to translate the rather 
simpler language Go to the more powerful (at least in your opinion) D. That 
may in fact be productive and may prove rather than merely state your case.

Lucio.

PS: I think David Bright is a genius. I still have my original copies of 
Zortech C++ (versions 1 and 2) which almost certainly have only antiquarian 
value. But the man who produced that masterpiece deserves to be recognised. 
So if he happens to stumble on this discussion, let it be clear that my 
lack of interest in D is no reflection of my respect for its originator.

On Wednesday, 2 August 2017 10:03:59 UTC+2, ecstati...@gmail.com wrote:
>
> I agree with you that the code must be developped using the KISS principle.
>
> Look at the D code of my github account. All you will see is "baby-code".
>
> Maybe, just maybe,The more complex stuff I use in D are genericy and 
> polymorphism.
>
> And, from my personal experience, the lack of genericity and polymorphism 
> in Go often forces me code in a less straightforward manner than in D.
>
> I have to find an indirect way (interface, etc) of doing something that 
> would be simple and straightforward in D.
>
> Maybe I'm force to develop more powerful or sophisticated code in Go's 
> way, I don't know, but I will never say that my Go code is much easier to 
> program or to maintain than the same implementation in D.
>
> My github account is now full of tools progressively converted to D from 
> an initial implementation in Go or Node.js, so I begin to have some 
> experience in switching a tool from a language to another...
>
> On Wednesday, August 2, 2017 at 8:36:18 AM UTC+1, ohir wrote:
>>
>> On Tue, 1 Aug 2017 05:04:24 -0700 (PDT) 
>> ecstati...@gmail.com wrote: 
>>
>> > But D also gives you reference classes, genericity, function 
>> polymorphism, 
>> > conditional compilation, design by contract assertions, compile-time 
>> meta 
>> > programming, 
>>
>> All things above to be avoided in _maintainable_ software. 
>>
>> Mantra: every working line of code is written once by one person 
>> then it is read hundreds/thousands of times by dozens of people. 
>>
>> Go spares your pair, then supervisor, from manually enforcing on 
>> you hard local rules: "We use C++ but you are forbidden to use: 
>> exceptions, overloading, auto, weak ... ". Go language by itself gives 
>> you all that -do-not-use-this-and-that- checks for free ;) 
>>
>> > and many other features that are severely lacking in Go. 
>> Luckily. These and many other features _luckily_ lacking in Go. 
>> Something that can't be used also can't be abused. 
>>
>> From the software maintainer pov Go is both readable and debuggable. 
>> In Go one may grasp execution path and functionality from the very 
>> fragment of source s/he is reading now. With very few exceptions. 
>>
>> Throw in any level of meta programming, even simple function overload, 
>> and suddenly reader of a fragment of code is forced to read entirety of 
>> entangled sources then map it mentally - all that just to grasp 
>> importance 
>> of that fragment s/he has read a while ago. Rinse and repeat on each 
>> level 
>> deep. 
>>
>> Any business gain (man-hour wise) form higher level 'features' is null, 
>> void 
>> and negative at first bug hunt on production code. More so if said code 
>> authors are long gone from the team. Many businesses learnt this 
>> hard way and now they know better; now they go for Go. 
>>
>> > But for your command line or desktop developments, I think D could be 
>> much 
>> > more appropriate than Go... 
>>
>> Unless your CLI/desktop is supposed to be easily maintained for years to 
>> come. 
>>
>> PS. If one want some joy and entertainment off writing, one may go for 
>> Racket [https://racket-lang.org/]. Every program in it sooner than later 
>> evolves into separate language of its own. Language only author can 
>> understand. Even if just for a while ;). 
>>
>> -- 
>> Wojciech S. Czarnecki 
>>  << ^oo^ >> OHIR-RIPE 
>>
>

-- 
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/optout.

Re: [go-nuts] Re: HTTP/2 multiplexing

[Christian Joergensen]

On Thursday, August 3, 2017 at 11:07:50 AM UTC+2, pala.d...@gmail.com wrote:
>
> Example code with DuckDuckGo as default target:
>
> https://play.golang.org/p/_iI5-MDJ5t
>

This looks like a thundering herd race on connection setup. So there is no 
connection to reuse as none of them has been setup yet.

Try completing a single request and then run the rest of the requests in 
parallel afterwards.

Cheers,

Christian

-- 
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/optout.

Re: [go-nuts] Re: gobind generated constructor for struct containing []byte sometimes corrupts data

[Elias Naur]

Yes, byte slices are special and are not reference counted like other
objects. You need to copy it on the Go side.

- elias

Den tor. 3. aug. 2017 03.21 skrev Antonio Marcedone :

> My intuition above seems to contrast with
> https://godoc.org/golang.org/x/mobile/cmd/gobind:
>
> Avoid reference cycles
>> The language bindings maintain a reference to each object that has been
>> proxied. When a proxy object becomes unreachable, its finalizer reports
>> this fact to the object's native side, so that the reference can be
>> removed, potentially allowing the object to be reclaimed by its native
>> garbage collector. The mechanism is symmetric.
>
>
>
> On Wednesday, August 2, 2017 at 5:30:16 PM UTC-7, Antonio Marcedone wrote:
>>
>> I am not sure I understand what is going on here.
>> For reference, the relevant code is:
>>
>> String s = "This is a test string";
>>
>> MyStruct struct = new MyStruct(s.getBytes("UTF-8"));
>> //struct.setE(s.getBytes("UTF-8"));
>> tv.append("\nFirst time: "+ new String(struct.getE(), "UTF-8"));
>>
>>
>> with corresponding go part:
>>
>> package test
>>
>> type MyStruct struct{
>> E []byte}
>>
>> func NewMyStruct(e []byte) *MyStruct{
>> return {e}}
>>
>>
>> so s.getBytes allocates a new byte[] (in Java). Then the MyStruct
>> constructor is called, and it gets a reference to such byte[].
>> Are you saying that since the Java garbage collector is not aware that a
>> reference to that array is stored in some variable in the go code, then it
>> just deletes it as soon as the constructor returns?
>> And then the getE method just reads whatever happens to be in memory
>> where the old array was without throwing any error despite the fact that
>> the old byte[] has been garbage collected and might have been overwritten
>> by arbitrary data?
>>
>> Thanks a lot for your response!
>> Antonio
>>
>> On Wednesday, August 2, 2017 at 3:30:06 PM UTC-7, Elias Naur wrote:
>>>
>>> []byte arguments are passed by reference, not copied. You need to copy
>>> any byte slices you retain after the function or method call.
>>>
>>>  - elias
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/TLy4sa3XRec/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/optout.

Re: [go-nuts] lock for assigning to different elements of an array

[Konstantin Khomoutov]

On Thu, Aug 03, 2017 at 07:21:24AM +, Henrik Johansson wrote:

[...]
> It gets hypothetical pretty quick and usually when this happens I make sure
> to create a new array/slice/whatever and then atomically swap it before
> some other goroutine uses it but I generally avoid indexing assignment from
> go routines like this even though it seems to be ok.
> 
> Does this hold for slices as well as for arrays? What about assignments to
> fields in structs? Can several goroutines safely write to different fields
> in the same struct assuming they are word sized? Does this hold for all
> architectures?
[...]

>From past discussions on this list, I gathered that two facts should be
considered when reasoning about the conditions ...

1) When Go memory model discusses happens-before relationships between
   concurrently executing goroutines, it talks about *variables* operated on
   by those goroutines.

   This is sort of logical since Go does not allow access to arbitrary
   memory locations (as you could do in C, for instance): any writes and
   reads happen on variables.

   To cite the memory model document [1]:

   | The Go memory model specifies the conditions under which reads of a
   | variable in one goroutine can be guaranteed to observe values produced
   | by writes to the same variable in a different goroutine.

2) The Go language spec again talks about variables when it discusses
   types, and a crucial point of that discussion is that *structured*
   types are defined to behave like compositions of variables.

   To cite the spec:

   | A variable is a storage location for holding a value. The set of
   | permissible values is determined by the variable's type.
   | <...>
   | Structured variables of array, slice, and struct types have elements and
   | fields that may be addressed individually. Each such element acts like a
   | variable.

   To provide a slighly different view: a variable is a (typed) memory
   location which is addressable.  That's why invididual elements of
   arrays and slices are variables, and fields of the values of struct
   types are values, too, but the elements of maps are not: they are not
   addressable.

Of course, certain caveats apply.

For instance, a slice itself (the descriptor which contains the pointer
to the underlying array, the length and the capacity) stored in a
variable can be modified concurrently with any element of that slice
without breaking the memory model rules, but the question of whether
that would be a sensible superposition of operations is moot.

Another example is modifying a variable containing a pointer to some
variable of a struct type concurrently with the pointed-to value: this
is not against the memory model but may be nonsensical from the point of
view of the desired outcome of the program.

Hope that helps.

-- 
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/optout.

Re: [go-nuts] lock for assigning to different elements of an array

[Henrik Johansson]

Excellent, thank you Dave!

tors 3 aug. 2017 kl 09:45 skrev Dave Cheney :

>
>
> On Thu, 3 Aug 2017, 17:39 Dave Cheney  wrote:
>
>> Your first program has a data race, well it has two races, the first is a
>> data race between the goroutines writing to the slice and the println which
>> will read the contents of the slice. That is, if those writing goroutines
>> get a chance to run before main exits.
>>
>> The second program doesn't have a data race as the waitgroup.done / wait
>> creates a happens before relationship between reader and writer.
>>
>> On Thu, 3 Aug 2017, 17:33 Henrik Johansson  wrote:
>>
>>> But isn't this what is happening in the example? Or is write-only not
>>> sharing?
>>>
>>> On Thu, 3 Aug 2017, 09:23 Dave Cheney,  wrote:
>>>
 IMO you need a lock whenever you are sharing a value between goroutines
 by storing it in memory.

 On Thu, 3 Aug 2017, 17:21 Henrik Johansson 
 wrote:

> I think I am mostly after a mental pattern to easily recognise when
> synchronizations are needed.
>
> I am decently good at this but I tend to be very conservative and use
> locks and atomics perhaps when they are not needed.
> But here we have several goroutines all taking part in the
> initialisation itself concurrently writing to the same array. How can this
> be safe in light of https://golang.org/ref/mem#tmp_10 . I get that
> your comment about "happens before" comes in here if there were any 
> readers
> but eventually there will be readers or we would never need to do this. If
> the main after some time wants to access these values is it enough to make
> sure the goroutines are done perhaps using a WaitGroup or do we have to 
> use
> some other synchronisation to ensure the visibility of the data in the
> array?
>
>  https://play.golang.org/p/8BfrPhyIEb
>
> Or is it needed to do something like this:
>
> https://play.golang.org/p/9QgTP5Dqc7
>
> I mean aside from the poor form of sleeping like this, the idea is to
> simulate usage "at some point later in time".
>
> It gets hypothetical pretty quick and usually when this happens I make
> sure to create a new array/slice/whatever and then atomically swap it
> before some other goroutine uses it but I generally avoid indexing
> assignment from go routines like this even though it seems to be ok.
>
> Does this hold for slices as well as for arrays?
>

> Yes, it is safe for multiple goroutines to write to different array
> elements, the same is true for slices as they are backed by an array
>
> What about assignments to fields in structs?
>

> Yes.
>
> Can several goroutines safely write to different fields in the same struct
> assuming they are word sized?
>

> Yes, although they should also be naturally aligned.
>
> Does this hold for all architectures?
>

> Some architectures have issues with atomic writes to values smaller than a
> word. Look for xor8 in the runtime source.
>
> Writing to adjacent memory locations will cause false sharing between CPU
> caches. This is a performance, not a correctness issue.
>
>
> I am sorry if I am still a bit unclear but I find it hard to ask
> properly when I am a bit unsure of the topic. :D
>
>
>
> tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :
>
>> I'm not really sure what you are asking. I think your second
>> paragraph got eaten by autocorrect at the critical point. Could try maybe
>> asking your question in a different way?
>
>
>>
>> --
>> 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/optout.
>>
>

-- 
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/optout.

Re: [go-nuts] lock for assigning to different elements of an array

[Dave Cheney]

On Thu, 3 Aug 2017, 17:39 Dave Cheney  wrote:

> Your first program has a data race, well it has two races, the first is a
> data race between the goroutines writing to the slice and the println which
> will read the contents of the slice. That is, if those writing goroutines
> get a chance to run before main exits.
>
> The second program doesn't have a data race as the waitgroup.done / wait
> creates a happens before relationship between reader and writer.
>
> On Thu, 3 Aug 2017, 17:33 Henrik Johansson  wrote:
>
>> But isn't this what is happening in the example? Or is write-only not
>> sharing?
>>
>> On Thu, 3 Aug 2017, 09:23 Dave Cheney,  wrote:
>>
>>> IMO you need a lock whenever you are sharing a value between goroutines
>>> by storing it in memory.
>>>
>>> On Thu, 3 Aug 2017, 17:21 Henrik Johansson  wrote:
>>>
 I think I am mostly after a mental pattern to easily recognise when
 synchronizations are needed.

 I am decently good at this but I tend to be very conservative and use
 locks and atomics perhaps when they are not needed.
 But here we have several goroutines all taking part in the
 initialisation itself concurrently writing to the same array. How can this
 be safe in light of https://golang.org/ref/mem#tmp_10 . I get that
 your comment about "happens before" comes in here if there were any readers
 but eventually there will be readers or we would never need to do this. If
 the main after some time wants to access these values is it enough to make
 sure the goroutines are done perhaps using a WaitGroup or do we have to use
 some other synchronisation to ensure the visibility of the data in the
 array?

  https://play.golang.org/p/8BfrPhyIEb

 Or is it needed to do something like this:

 https://play.golang.org/p/9QgTP5Dqc7

 I mean aside from the poor form of sleeping like this, the idea is to
 simulate usage "at some point later in time".

 It gets hypothetical pretty quick and usually when this happens I make
 sure to create a new array/slice/whatever and then atomically swap it
 before some other goroutine uses it but I generally avoid indexing
 assignment from go routines like this even though it seems to be ok.

 Does this hold for slices as well as for arrays?

>>>
Yes, it is safe for multiple goroutines to write to different array
elements, the same is true for slices as they are backed by an array

What about assignments to fields in structs?

>>>
Yes.

Can several goroutines safely write to different fields in the same struct
 assuming they are word sized?

>>>
Yes, although they should also be naturally aligned.

Does this hold for all architectures?

>>>
Some architectures have issues with atomic writes to values smaller than a
word. Look for xor8 in the runtime source.

Writing to adjacent memory locations will cause false sharing between CPU
caches. This is a performance, not a correctness issue.


 I am sorry if I am still a bit unclear but I find it hard to ask
 properly when I am a bit unsure of the topic. :D



 tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :

> I'm not really sure what you are asking. I think your second paragraph
> got eaten by autocorrect at the critical point. Could try maybe asking 
> your
> question in a different way?


>
> --
> 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/optout.
>


-- 
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/optout.

Re: [go-nuts] lock for assigning to different elements of an array

[Dave Cheney]

Your first program has a data race, well it has two races, the first is a
data race between the goroutines writing to the slice and the println which
will read the contents of the slice. That is, if those writing goroutines
get a chance to run before main exits.

The second program doesn't have a data race as the waitgroup.done / wait
creates a happens before relationship between reader and writer.

On Thu, 3 Aug 2017, 17:33 Henrik Johansson  wrote:

> But isn't this what is happening in the example? Or is write-only not
> sharing?
>
> On Thu, 3 Aug 2017, 09:23 Dave Cheney,  wrote:
>
>> IMO you need a lock whenever you are sharing a value between goroutines
>> by storing it in memory.
>>
>> On Thu, 3 Aug 2017, 17:21 Henrik Johansson  wrote:
>>
>>> I think I am mostly after a mental pattern to easily recognise when
>>> synchronizations are needed.
>>>
>>> I am decently good at this but I tend to be very conservative and use
>>> locks and atomics perhaps when they are not needed.
>>> But here we have several goroutines all taking part in the
>>> initialisation itself concurrently writing to the same array. How can this
>>> be safe in light of https://golang.org/ref/mem#tmp_10 . I get that your
>>> comment about "happens before" comes in here if there were any readers but
>>> eventually there will be readers or we would never need to do this. If the
>>> main after some time wants to access these values is it enough to make sure
>>> the goroutines are done perhaps using a WaitGroup or do we have to use some
>>> other synchronisation to ensure the visibility of the data in the array?
>>>
>>>  https://play.golang.org/p/8BfrPhyIEb
>>>
>>> Or is it needed to do something like this:
>>>
>>> https://play.golang.org/p/9QgTP5Dqc7
>>>
>>> I mean aside from the poor form of sleeping like this, the idea is to
>>> simulate usage "at some point later in time".
>>>
>>> It gets hypothetical pretty quick and usually when this happens I make
>>> sure to create a new array/slice/whatever and then atomically swap it
>>> before some other goroutine uses it but I generally avoid indexing
>>> assignment from go routines like this even though it seems to be ok.
>>>
>>> Does this hold for slices as well as for arrays? What about assignments
>>> to fields in structs? Can several goroutines safely write to different
>>> fields in the same struct assuming they are word sized? Does this hold for
>>> all architectures?
>>>
>>> I am sorry if I am still a bit unclear but I find it hard to ask
>>> properly when I am a bit unsure of the topic. :D
>>>
>>>
>>>
>>> tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :
>>>
 I'm not really sure what you are asking. I think your second paragraph
 got eaten by autocorrect at the critical point. Could try maybe asking your
 question in a different way?
>>>
>>>

 --
 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/optout.

>>>

-- 
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/optout.

Re: [go-nuts] lock for assigning to different elements of an array

[Henrik Johansson]

But isn't this what is happening in the example? Or is write-only not
sharing?

On Thu, 3 Aug 2017, 09:23 Dave Cheney,  wrote:

> IMO you need a lock whenever you are sharing a value between goroutines by
> storing it in memory.
>
> On Thu, 3 Aug 2017, 17:21 Henrik Johansson  wrote:
>
>> I think I am mostly after a mental pattern to easily recognise when
>> synchronizations are needed.
>>
>> I am decently good at this but I tend to be very conservative and use
>> locks and atomics perhaps when they are not needed.
>> But here we have several goroutines all taking part in the initialisation
>> itself concurrently writing to the same array. How can this be safe in
>> light of https://golang.org/ref/mem#tmp_10 . I get that your comment
>> about "happens before" comes in here if there were any readers but
>> eventually there will be readers or we would never need to do this. If the
>> main after some time wants to access these values is it enough to make sure
>> the goroutines are done perhaps using a WaitGroup or do we have to use some
>> other synchronisation to ensure the visibility of the data in the array?
>>
>>  https://play.golang.org/p/8BfrPhyIEb
>>
>> Or is it needed to do something like this:
>>
>> https://play.golang.org/p/9QgTP5Dqc7
>>
>> I mean aside from the poor form of sleeping like this, the idea is to
>> simulate usage "at some point later in time".
>>
>> It gets hypothetical pretty quick and usually when this happens I make
>> sure to create a new array/slice/whatever and then atomically swap it
>> before some other goroutine uses it but I generally avoid indexing
>> assignment from go routines like this even though it seems to be ok.
>>
>> Does this hold for slices as well as for arrays? What about assignments
>> to fields in structs? Can several goroutines safely write to different
>> fields in the same struct assuming they are word sized? Does this hold for
>> all architectures?
>>
>> I am sorry if I am still a bit unclear but I find it hard to ask properly
>> when I am a bit unsure of the topic. :D
>>
>>
>>
>> tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :
>>
>>> I'm not really sure what you are asking. I think your second paragraph
>>> got eaten by autocorrect at the critical point. Could try maybe asking your
>>> question in a different way?
>>
>>
>>>
>>> --
>>> 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/optout.
>>>
>>

-- 
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/optout.

Re: [go-nuts] lock for assigning to different elements of an array

[Henrik Johansson]

I think I am mostly after a mental pattern to easily recognise when
synchronizations are needed.

I am decently good at this but I tend to be very conservative and use locks
and atomics perhaps when they are not needed.
But here we have several goroutines all taking part in the initialisation
itself concurrently writing to the same array. How can this be safe in
light of https://golang.org/ref/mem#tmp_10 . I get that your comment about
"happens before" comes in here if there were any readers but eventually
there will be readers or we would never need to do this. If the main after
some time wants to access these values is it enough to make sure the
goroutines are done perhaps using a WaitGroup or do we have to use some
other synchronisation to ensure the visibility of the data in the array?

 https://play.golang.org/p/8BfrPhyIEb

Or is it needed to do something like this:

https://play.golang.org/p/9QgTP5Dqc7

I mean aside from the poor form of sleeping like this, the idea is to
simulate usage "at some point later in time".

It gets hypothetical pretty quick and usually when this happens I make sure
to create a new array/slice/whatever and then atomically swap it before
some other goroutine uses it but I generally avoid indexing assignment from
go routines like this even though it seems to be ok.

Does this hold for slices as well as for arrays? What about assignments to
fields in structs? Can several goroutines safely write to different fields
in the same struct assuming they are word sized? Does this hold for all
architectures?

I am sorry if I am still a bit unclear but I find it hard to ask properly
when I am a bit unsure of the topic. :D



tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :

> I'm not really sure what you are asking. I think your second paragraph got
> eaten by autocorrect at the critical point. Could try maybe asking your
> question in a different way?
>
> --
> 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/optout.
>

-- 
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/optout.

Re: [go-nuts] lock for assigning to different elements of an array

[Dave Cheney]

IMO you need a lock whenever you are sharing a value between goroutines by
storing it in memory.

On Thu, 3 Aug 2017, 17:21 Henrik Johansson  wrote:

> I think I am mostly after a mental pattern to easily recognise when
> synchronizations are needed.
>
> I am decently good at this but I tend to be very conservative and use
> locks and atomics perhaps when they are not needed.
> But here we have several goroutines all taking part in the initialisation
> itself concurrently writing to the same array. How can this be safe in
> light of https://golang.org/ref/mem#tmp_10 . I get that your comment
> about "happens before" comes in here if there were any readers but
> eventually there will be readers or we would never need to do this. If the
> main after some time wants to access these values is it enough to make sure
> the goroutines are done perhaps using a WaitGroup or do we have to use some
> other synchronisation to ensure the visibility of the data in the array?
>
>  https://play.golang.org/p/8BfrPhyIEb
>
> Or is it needed to do something like this:
>
> https://play.golang.org/p/9QgTP5Dqc7
>
> I mean aside from the poor form of sleeping like this, the idea is to
> simulate usage "at some point later in time".
>
> It gets hypothetical pretty quick and usually when this happens I make
> sure to create a new array/slice/whatever and then atomically swap it
> before some other goroutine uses it but I generally avoid indexing
> assignment from go routines like this even though it seems to be ok.
>
> Does this hold for slices as well as for arrays? What about assignments to
> fields in structs? Can several goroutines safely write to different fields
> in the same struct assuming they are word sized? Does this hold for all
> architectures?
>
> I am sorry if I am still a bit unclear but I find it hard to ask properly
> when I am a bit unsure of the topic. :D
>
>
>
> tors 3 aug. 2017 kl 07:49 skrev Dave Cheney :
>
>> I'm not really sure what you are asking. I think your second paragraph
>> got eaten by autocorrect at the critical point. Could try maybe asking your
>> question in a different way?
>
>
>>
>> --
>> 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/optout.
>>
>

-- 
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/optout.

Re: [go-nuts] look for a example: call a DLL's function on Windows by CGO

[Konstantin Khomoutov]

On Wed, Aug 02, 2017 at 08:33:53PM -0700, Fino wrote:

> yesterday I just found that, the syscall way to use DLL on Windows cannot 
> use float32 as parameters, 

Could you please elaborate on that as I do not beleive this is not
possible: IIRC Go's float types follow IEEE 754 semantics and you should
be able to use them "as is".

If not, maybe it would be possible to use the Float64bits,
Float64FromBits from the math package (for doubles) and their 32-bit
counterparts (for floats).

> so I am look for a example:  call a DLL's function on Windows in the  CGO 
> way, 
> 
> the DLL is not Windows' own DLL, but a third-party DLL which have a lot of 
> double parameters, 

I would do this only as a last resort: you'd need a working C compiler
to build your package (and that wouldn't be MSVC++, IIRC).

-- 
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/optout.

Re: [go-nuts] Twitter search go code

[Tyler Compton]

I don't believe Shawn was trying to be condescending. He didn't link you to
https://lmgtfy.com/ after all ;)

You're likely to get better responses if you include info about your use
case and the libraries you have looked at so far.

On Tue, Aug 1, 2017 at 7:34 PM Tong Sun  wrote:

>
>
> On Wednesday, July 26, 2017 at 2:07:30 PM UTC-4, Shawn Milochik wrote:
>
>> On Wed, Jul 26, 2017 at 11:47 AM, Tong Sun wrote:
>>
>>> Any simple go code out there that can search Twitter? Thx.
>>>
>>
>> With a question this broad, you'd get much better and faster results by
>> using Google.
>>
>
> Funny there are people out there showing off by saying that they can
> do Google search, as if no one else knows it but he.
>
> , so impatient, judgmental and condescending.
> If you had paid a little more attention, it is not at all so broad as you
> think. Now read it again --
> The keywords are: "*simple*" and "*search*".
> The monster tool that emphasizes on *re-tweeting* does NOT qualify as the
> answer. Period.
>
> Luckily, with a bit more patient, I'm able to find a *simple* go code
> that *can* *search* Twitter --
> https://github.com/cathalgarvey/sqrape/blob/master/examples/tweetgrab.go
>
> Nice one!
>
> Going along that direction, I think the cascadia
>  the command line tool is even more
> simpler, in a sense of less dependency and less/no Go coding:
>
> $ cascadia -i 
> 'https://twitter.com/search?q=%22Gas%20Price%20Alert%22%20%23GTA%20from%3AGasBuddyDan=typd'
>  -o -c 'div.stream div.original-tweet div.content' --piece Time='small.time' 
> --piece Tweet='div.js-tweet-text-container > p'
> TimeTweet
>
>   Jul 31
> Gas Price Alert #Toronto #GTA #Hamilton #Ottawa #LdnOnt #Barrie 
> #Kitchener #Niagara #Windsor N/C Tues and to a 2ct/l HIKE gor Wednesday
>
>   Jul 6
> Gas Price Alert #Toronto #GTA #LdnOnt #Hamilton #Ottawa #Barrie #KW 
> to see a 1 ct/l drop @ for Friday July 7
>
>   May 30
> Gas Price Alert #Toronto #GTA #Ottawa #LdnOnt #Hamilton #KW #Barrie 
> #Windsor prices won't change Wednesday but will DROP 1 ct/l Thursday
>
>   May 15
> Gas Price Alert #Toronto #GTA #Barrie #Hamilton #LdnOnt #Ottawa #KW 
> #Windsor NO CHANGE @  except gas bar shenanigans for Tues & Wednesday
>
>   Mar 7
> Gas Price Alert #Toronto #GTHA #LdnOnt #Ottawa #Barrie #KW #Windsor 
> to see a 1 cent a litre HIKE Wed March 8 (to 107.9 in the #GTA)
>
>
>
> Check out the details at
> https://github.com/suntong/cascadia#twitter-search, which I updated just
> now.
>
>
>
> --
> 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/optout.
>

-- 
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/optout.

Re: [go-nuts] Re: Go one-line installer

[Tyler Compton]

> No, most Linux users are used to installing from package managers.

I don't know if that's true. Many popular distributions provide undesirably
out-of-date versions of common tools and require users to use other means
to install them. But both of our assertions are valueless without data, so
it may not be worth discussing.

> Unless you were referring to installing Go in particular, where I
> conjecture that most Linux users who don't use some package manager
> to install Go, are installing from source.

I would have thought users would be more likely to reach for the pre-built
versions of Go, but again, we need data.

> I can't speak for Windows, but macOS (or OS X, or Mac OS X) never
> had executable installers like Windows had.

Fair enough, I admit I don't know a lot about the Mac sphere.

> The problem you are mentioning is the halting problem. There is no way
> reliably set configuration variables without solving the halting
> problem.
> I do not consider time spent on the halting problem to be productive
> time. Sorry.

I was referring to the problem of security, not the problem of
configuration variables. Certainly some of the security concerns with this
project can be addressed without solving the halting problem.


On Wed, Aug 2, 2017 at 6:50 AM  wrote:

> Hi,
>
> As you at this kind of work, have you considered a reliable one-liner to
> install dependencies ?
>
> I got that own, just today, from a gae repo (?), anyways here it is,
>
> go get -u -v $(go list -f '{{join .Imports "\n"}}{{"\n"}}{{join
> .TestImports "\n"}}' ./... | sort | uniq | grep -v golang-samples)
>
> Problem is, it did not quiet work for me when i put that into my travis :x
> https://travis-ci.org/mh-cbon/dht/jobs/260206514
>
> even when i restart the job.
>
> Do you have any ideas how to fix that ?
>
>
> thanks
>
>
> On Tuesday, August 1, 2017 at 9:42:00 PM UTC+2, Steve Francia wrote:
>
>> Greetings Gophers,
>>
>> I've been working on a "one line installer" for Go with Jess Frazelle and
>> Chris Broadfoot and we think it's ready to share a bit more broadly.
>>
>> The installer is designed to both install Go as well as do the initial
>> configuration of setting up the right environment variables and paths.
>> It will install the Go distribution (tools & stdlib) to "/.go" inside
>> your home directory by default.
>> It will setup "$HOME/go" as your GOPATH.
>>
>> If Go is already installed *via this installer* it will upgrade it to
>> the latest version of Go.
>>
>> Currently supported systems:
>>   linux, darwin, windows / amd64, 386 / bash, zsh, powershell
>>
>>
>> *Usage*
>> Windows Powershell:
>> (New-Object System.Net.WebClient).DownloadFile('
>> https://get.golang.org/installer.exe', 'installer.exe'); Start-Process
>> -Wait -NonewWindow installer.exe; Remove-Item installer.exe
>>
>> Shell (Linux/macOS/Windows):
>> curl -LO https://get.golang.org/$(uname)/go_installer && chmod +x
>> go_installer && ./go_installer && rm go_installer
>>
>>
>> As we discovered developing this, installers are really all edge cases.
>> We're certain we've not found many of them.
>> *Our goal is that this becomes the primary mechanism to install Go. *
>> *To do that, we need your help testing, improving and fixing it. *
>>
>> The source can be found at
>> https://go.googlesource.com/tools/+/master/cmd/getgo/
>> If you find any issues please report them on Github
>> https://github.com/golang/go/issues/new?title=tools/cmd/getgo:
>>
>> Thanks,
>> Steve
>>
> --
> 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/optout.
>

-- 
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/optout.