Maria-Hendrike Peetz | 1 Apr 18:28 2015
Picon

Go for teenagers

Hi all,

I have a very eager and interested teenager who wants to learn programming. I thought Go would be a nice starter language :).
Are there any resources for go for teenagers as first programming language? She is 15.

Hendrike


--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Gyu-Ho Lee | 1 Apr 18:03 2015
Picon

Parallelizing merge sort

http://play.golang.org/p/T9Ad_FnGpX

Concurrency looks perfect fit for divide and conquer algorithms.


I did bench-marks on 3 sorting implementations. 

MergeSortTwoWay with goroutines is slower than
merge sort with no concurrency.

I did not expect it to be faster than standard sort package but faster than normal merge sort.


func BenchmarkStandardPackage(b *testing.B) {
for i := 0; i < b.N; i++ {
sort.Ints(sampleIntSlice)
}
}

func BenchmarkMergeSortTwoWayNoConcurrency(b *testing.B) {
for i := 0; i < b.N; i++ {
mergeSortTwoWayNoConcurrency(sampleIntSlice)
}
}

func BenchmarkMergeSortTwoWay(b *testing.B) {
maxCPU := runtime.NumCPU()
runtime.GOMAXPROCS(maxCPU)
for i := 0; i < b.N; i++ {
MergeSortTwoWay(sampleIntSlice)
}
}

Result is:

go test -bench . -cpu 1,2,4

PASS
BenchmarkStandardPackage      20  92095193 ns/op
BenchmarkStandardPackage-2      20  91267537 ns/op
BenchmarkStandardPackage-4      20  92154893 ns/op
BenchmarkMergeSortTwoWay       1 1123574855 ns/op
testing: BenchmarkMergeSortTwoWay left GOMAXPROCS set to 8
BenchmarkMergeSortTwoWay-2       2 805631783 ns/op
testing: BenchmarkMergeSortTwoWay-2 left GOMAXPROCS set to 8
BenchmarkMergeSortTwoWay-4       2 814916071 ns/op
testing: BenchmarkMergeSortTwoWay-4 left GOMAXPROCS set to 8
BenchmarkMergeSortTwoWayNoConcurrency       5 265530219 ns/op
BenchmarkMergeSortTwoWayNoConcurrency-2      10 187821042 ns/op
BenchmarkMergeSortTwoWayNoConcurrency-4      10 171412893 ns/op


Here's my implementation:


func mergeTwoWay(s1, s2 []int) []int {
final := make([]int, len(s1)+len(s2))
i, j := 0, 0
for i < len(s1) && j < len(s2) {
if s1[i] <= s2[j] {
final[i+j] = s1[i]
i++
continue
}
final[i+j] = s2[j]
j++
}
for i < len(s1) {
final[i+j] = s1[i]
i++
}
for j < len(s2) {
final[i+j] = s2[j]
j++
}
return final
}


func MergeSortTwoWay(slice []int) []int {
ch := make(chan []int)
go mergeSortTwoWay(slice, ch)
return <-ch
}

func mergeSortTwoWay(slice []int, ch chan []int) {
if len(slice) < 2 {
ch <- slice
return
}

idx := len(slice) / 2
ch1, ch2 := make(chan []int), make(chan []int)

go mergeSortTwoWay(slice[:idx], ch1)
go mergeSortTwoWay(slice[idx:], ch2)

left := <-ch1
right := <-ch2

// close after waiting to receive all
close(ch1)
close(ch2)

ch <- mergeTwoWay(left, right)
}


func mergeSortTwoWayNoConcurrency(slice []int) []int {
if len(slice) < 2 {
return slice
}
idx := len(slice) / 2
left := mergeSortTwoWayNoConcurrency(slice[:idx])
right := mergeSortTwoWayNoConcurrency(slice[idx:])
return mergeTwoWay(left, right)
}


Is there anything to be improved? 
It doesn't need to be sophisticated as standard sort package.
I just wanted to know if it can be faster with concurrency.

Could anybody explain why this merge sort slows down with channels?
What would be the best practice when we want to parallelize sorting? (I am still learning.)

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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Anindya Chatterjee | 1 Apr 17:43 2015
Picon

Proposal: Stack Exchange Q&A site dedicated to golang enthusiasts

Hello, I have proposed a dedicated Q&A site for golang in stack-exchange area-51. Here is the link:


I hope it might help all golang enthusiasts like us. So if you guys feel we need this, please follow the above proposal and help it grow.

Regards,
Anindya Chatterjee

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
xiaowl | 1 Apr 06:33 2015

Tens of thousands goroutines blocked at the DNS resolving requests

One of our production service wen down during the past few days occasionally. After digging into the goroutings' stacks, I'm afraid it's related to DNS resolving process. Briefly, all DNS resolving requests are wrapped into a singleflight call, and if one DNS resolving requests failed to return in time, all other requests for the same host will Wait forever. Here is a partial output:

500 <at> 0x4103d5 0x5ab606 0x5a03a1 0x5a0b69 0x591416 0x5a3b64 0x594db2 0x5907de 0x590abb 0x58f08a 0x573605 0x57382f 0x5736f4 0x477bd4 0x47812b 0x47ca61 0x41fb60 #▸ 0x5ab606▸ net._C2func_getaddrinfo+0x36▸ ▸ net/_obj/_cgo_defun.c:52 #▸ 0x5a03a1▸ net.cgoLookupIPCNAME+0x1e1▸ ▸ /usr/local/go/src/pkg/net/cgo_unix.go:96 #▸ 0x5a0b69▸ net.cgoLookupIP+0x69▸ ▸ ▸ /usr/local/go/src/pkg/net/cgo_unix.go:148 #▸ 0x591416▸ net.lookupIP+0x66▸ ▸ ▸ /usr/local/go/src/pkg/net/lookup_unix.go:64 #▸ 0x5a3b64▸ net.func·024+0x54▸ ▸ ▸ /usr/local/go/src/pkg/net/lookup.go:41 #▸ 0x594db2▸ net.(*singleflight).Do+0x232▸ ▸ /usr/local/go/src/pkg/net/singleflight.go:45 #▸ 0x5907de▸ net.lookupIPMerge+0xae▸ ▸ ▸ /usr/local/go/src/pkg/net/lookup.go:42 #▸ 0x590abb▸ net.lookupIPDeadline+0x12b▸ ▸ /usr/local/go/src/pkg/net/lookup.go:57 #▸ 0x58f08a▸ net.resolveInternetAddr+0x49a▸ ▸ /usr/local/go/src/pkg/net/ipsock.go:285 #▸ 0x573605▸ net.resolveAddr+0x385▸ ▸ ▸ /usr/local/go/src/pkg/net/dial.go:110 #▸ 0x57382f▸ net.(*Dialer).Dial+0xff▸▸ ▸ /usr/local/go/src/pkg/net/dial.go:159 #▸ 0x5736f4▸ net.Dial+0xa4▸ ▸ ▸ ▸ /usr/local/go/src/pkg/net/dial.go:144 #▸ 0x477bd4▸ net/http.(*Transport).dial+0xd4▸▸ /usr/local/go/src/pkg/net/http/transport.go:444 #▸ 0x47812b▸ net/http.(*Transport).dialConn+0x9b▸ /usr/local/go/src/pkg/net/http/transport.go:496 #▸ 0x47ca61▸ net/http.func·018+0x41▸ ▸ ▸ /usr/local/go/src/pkg/net/http/transport.go:472 60457 <at> 0x41f8c9 0x41f94b 0x43462e 0x434870 0x503afb 0x594ca7 0x5907de 0x590abb 0x58f08a 0x573605 0x57382f 0x5736f4 0x477bd4 0x47812b 0x47ca61 0x41fb60 #▸ 0x434870▸ sync.runtime_Semacquire+0x30▸ ▸ /usr/local/go/src/pkg/runtime/sema.goc:199 #▸ 0x503afb▸ sync.(*WaitGroup).Wait+0x14b▸ ▸ /usr/local/go/src/pkg/sync/waitgroup.go:129 #▸ 0x594ca7▸ net.(*singleflight).Do+0x127▸ ▸ /usr/local/go/src/pkg/net/singleflight.go:37 #▸ 0x5907de▸ net.lookupIPMerge+0xae▸ ▸ ▸ /usr/local/go/src/pkg/net/lookup.go:42 #▸ 0x590abb▸ net.lookupIPDeadline+0x12b▸ ▸ /usr/local/go/src/pkg/net/lookup.go:57 #▸ 0x58f08a▸ net.resolveInternetAddr+0x49a▸ ▸ /usr/local/go/src/pkg/net/ipsock.go:285 #▸ 0x573605▸ net.resolveAddr+0x385▸ ▸ ▸ /usr/local/go/src/pkg/net/dial.go:110 #▸ 0x57382f▸ net.(*Dialer).Dial+0xff▸▸ ▸ /usr/local/go/src/pkg/net/dial.go:159 #▸ 0x5736f4▸ net.Dial+0xa4▸ ▸ ▸ ▸ /usr/local/go/src/pkg/net/dial.go:144 #▸ 0x477bd4▸ net/http.(*Transport).dial+0xd4▸▸ /usr/local/go/src/pkg/net/http/transport.go:444 #▸ 0x47812b▸ net/http.(*Transport).dialConn+0x9b▸ /usr/local/go/src/pkg/net/http/transport.go:496 #▸ 0x47ca61▸ net/http.func·018+0x41▸ ▸ ▸ /usr/local/go/src/pkg/net/http/transport.go:472

And most the these goroutines have been waiting for more than 3 hours.

I've went through the closed issues and found no similar reports, so I'm not sure if this is a bug. Seems set a timeout to the transport used by http client can fix this, but I think giving DNS resolving requests a default small timeout value, say 5 seconds, is a better option than setting an overall timeout value to the http client's transport.

go version go version go1.3.3 linux/amd64


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
dumpmailtje | 1 Apr 15:18 2015
Picon

Not able to fing header files of c source file

Hi,

I'm from the python world and recently tried my luck go and so far I like it.

I'm no trying to compile package github.com/vendco/go-sdl2/sdl.
First I tried it on linux and everthing goes as planned.
Now I try it on windows7 and I run into a problem of not finding the header files of SDL2.

Error message:
In file included from ./audio.go:3:0:
sdl_wrapper.h:2:23: fatal error: SDL/SDL.h: No such file or directory
       #include <SDL2/SDL.h>

compilation terminated.

I put the sdl header files in about every place I could think of and modified the windows PATH.
I'v tried the GOPATH/src/xxxxx/xxxxx/xxxxx/go-sdl2/sdl, GOPATH/pkg/go-sdl2/sdl
c:\SDL but no luck

My question: Where do I put the source files of the c library on windows if I want to compile SDL2 or any other C library?

I have mingw-64 installed.

Regards,
Cor

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Sokolov Yura | 1 Apr 15:22 2015
Picon

Is following right? "Optimizing Concurrent Map Access in Go"

Good day,

Just found article http://misfra.me/optimizing-concurrent-map-access-in-go .

Previously I thought that it is buggy to fetch value from map while it is concurrently modified.

Is article's author right or not? Should read from map be also protected or it is safe?

With regards,
Sokolov Yura aka funny_falcon

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Bayan Khalili | 1 Apr 13:42 2015
Picon

Iterating over slices of different types and calling a method with the same return type and arguments - failing to avoid verbosity in Go

I am trying to reduce the amount of code duplication where I iterate through a number of slices of different types, but where the same method is called for each type.
I've constructed a (much shorter and simpler) example to illustrate.

Assume we have the following types defined:

type ComputerSystem   struct { ... }
type BiologicalSystem struct { ... }
type PlumbingSystem   struct { ... }
type AllSystems struct {
ComputerSystems   []*ComputerSystem
BiologicalSystems []*BiologicalSystem
PlumbingSystems   []*PlumbingSystem
}


And each of the "System" types have an "IsGo" method defined with the same arguments and return type. I.e.:

func (s *ComputerSystem)   IsGo() bool { ... }
func (s *BiologicalSystem) IsGo() bool { ... }
func (s *PlumbingSystem)   IsGo() bool { ... }

I have written a method that checks if an AllSystems instance returns false for any of it's subsystems:

func (allSystems *AllSystems) AreGo() bool {
for _, system := range(allSystems.ComputerSystems) {
if !system.IsGo() {
return false
}
}
for _, system := range(allSystems.BiologicalSystems) {
if !system.IsGo() {
return false
}
}
for _, system := range(allSystems.PlumbingSystems) {
if !system.IsGo() {
return false
}
}
return true
}

The code includes an identical for loop for each sub system slice.

Is there a way to DRY this up?

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Picon

[ANN] httprs, a ReadSeeker for http.Response.Body


Hi !

httprs adds Seek to http.Response.Body by doing range requests. A HttpReadSeeker implements io.ReadCloser and io.Seeker.

Usage :

resp, err := http.Get(url)
rs := httprs.NewHttpReadSeeker(resp)
defer rs.Close()
io.ReadFull(rs, buf) // reads the first bytes from the response body
rs.Seek(1024, 0) // moves the position, but does no range request
io.ReadFull(rs, buf) // does a range request and reads from the response body

https://github.com/jfbus/httprs

Enjoy !

Jean-François

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Siddon Tang | 1 Apr 08:51 2015
Picon

database/sql SetMaxOpenConns block whole db operations, deadlock?

Hi Gophers

I use database sql SetMaxOpenConns to guarantee not too many connections for MySQL at same time, but to my surprise, it may block my whole application sometimes. 

A simple example here: http://play.golang.org/p/mBzBSs9sqE

I use 100 max connections and do db operations with 1000 goroutines at same time, but after some query over, the whole application is blocked and "hello world" will not be printed. 
If I don't use SetMaxOpenConns, all goroutines will be done.

Maybe some deadlock occurs, but I don't know. Does anyone meet the same problem?

Best regards

SiddonTang


--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Steve Powell | 1 Apr 08:37 2015
Picon

Go-2 Considered harmless


The Go community cannot have failed to miss the recent announcement (here [1], not here [3]) of G0-2, the follow-on to the populist 'Go' language, compiler and development system. Go-2 promises a "simplified, extended subset" of the language and ambitious—if not miraculous—expansions to the power of Go-ers everywhere.

SiliGon Valley is buzzing with excitement; once again we Go aboard the express-train of innovation, and with the press of a return-key (go-2 fmt -1->2 ./... anyone?) we enter the Go-lden land of opportunity.

Can it be true? Has Go become Go-old-hat? Go-ne out of fashion? Go-tten it's come-uppance? Of course not!  Go-2 here [2] for some details of the changes that are to come to Go. And that won't be the last of it; we can expect more in Go-2 to come, too.

But don't despair; even though the changes are sweeping and profound, the incredible and detailed thought that must have Go-ne into the design of Go-2 ensures that not a single old Go-ist will suffer. There is nothing new to know!  There is no learning curve! Even though your converted programs will run more smoothly and more thoughtfully—and even though successful compilation guarantees compiler conformance to the highest degree—your idioms, comments, favourite algorithms and tricks, and some common typos, will be preserved intact!  In the new world we Go-2, no-one will need to change they way they work—or think—hardly anyone will notice that development has fundamentally changed!

Go-2 is completely harmless.

[1] group:golang-nuts-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org/go-2_considered_harmless

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
hanbo zhang | 1 Apr 07:18 2015
Picon

Some trouble when using golang(cgo) to compile docker on linux/arm64

I have install golang on the linux/arm64 successfuly two days ago. And when I tried to compile a project called docker ,coded by go , an ERROR has existed:


../../../runtime/cgo/gcc_util.c:46: undefined reference to '_cgo_sys_thread_start'
collect2:error:ld returned 1 exit status

I found that the cgo.a file in the pkg/linux_arm64/cgo has not existed. The cgo.a are existed when I compiled docker using go on linux/x86, and the docker can be compiled successfully. So I sumrise that cgo.a's  disappearing may be the problem. And the cgo are not supported by official now.Can someone give me an advise how to compile an cgo.a which can be used on linux/arm64 or how to solve this error?

My experiments environment are as follow:
os :linux
arch: aarch64
kernel version:3.14-rc1
gcc version:4.9.1

Thanks,
Hanbo Zhang

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Gmane