Re: [go-nuts] fixed random number trouble

Il giorno mercoledì 14 marzo 2018 18:38:51 UTC+1, Burak Serdar ha scritto: > > It is explained here: > > https://golang.org/pkg/math/rand/ > > oh, thanks a lot. Now I can see that's a quite common doubt :-) https://stackoverflow.com/questions/45753397/why-does-golang-repeats-the-same-ran

Re: [go-nuts] Why not add unsafe.FreeMemory(unsafe.Pointer) to replace sync.Pool ?

Thanks. Keep using an object that was passed to Pool.Put, you may have a data race to write and read that object. I think the data race is not as critical as dangling pointers.At least a program with data race is difficult to predict, dangling pointers may be used to run arbitrary code. So the

[go-nuts] Re: confusing a lock demo about https://golang.org/ref/mem#tmp_8

Hi, First Lock - starts the Lock and executes the following statements until next Mutex functions are called. Here Sync.Mutex I is gloabal, called Unlock in function f(). As said second lock starts after function f() is executed. regards Subbu On Tuesday, March 13, 2018 at 6:27:08 AM UTC-7, 郎凯 w

[go-nuts] Re: [ANN] parwork - a fork-join package for processing work in parallel written in go

Hi Sotirios, Why not something like this? // Stops and returns if any error is encountered by a work function, otherwise returns nil. // Processes work at the pace of runtime.NumCPU() parallelization. func Process(callback func(interface{}), work ...func() (interface{}, error )) error Matt On

Re: [go-nuts] Re: infinite recursion in method lookup due to recursive embedded interface value: any way to statically catch this?

Hi folks, I think there may be two "bugs" in the discussion here. The first one is definite and it is the "Bg" in the original playground example, which is intended to illustrate a bug made by the programmer: the intended "Bug" method is missing, either due to a typo in an attempt, or simp

[go-nuts] Re: infinite recursion in method lookup due to recursive embedded interface value: any way to statically catch this?

Hi Christopher, Sharp eyes! Yes, in the current shape example, they are the same and so Dynamic() is redundant. Thanks for pointing it out! I have reviewed my projects and there are indeed some niche scenarios where I have the Dynamic() method of a descendant at, say, depth 2 return a VTable t

[go-nuts] [ANN] parwork - a fork-join package for processing work in parallel written in go

Hi, i have created a package which uses the fork-join model to parallelize work. Check out my blog and the Github repository. Any feedback is highly welcome. Thanks -- You r

Re: [go-nuts] Goroutines, Nonblocking I/O, And Memory Usage

On Wed, 14 Mar 2018 11:58:46 -0700 Rio wrote: > > While implementing a SOCKS proxy in Go, I ran into an issue which is better > explained in details by Evan Klitzke in this post > https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage > > In my case, each proxied connection costs two

[go-nuts] Re: Is there any tutorial or documentation on getting flame graphs with go 1.10?

I don't believe the version of pprof shipped with Go 1.10 includes the flame graph feature, but you can install a newer version of pprof manually and it will work fine. Some brief tutorial info here: https://rakyll.org/pprof-ui/ On Tuesday, March 13, 2018 at 10:35:12 AM UTC-4, Sathish VJ wrote:

Re: [go-nuts] Goroutines, Nonblocking I/O, And Memory Usage

On Wed, Mar 14, 2018 at 11:58 AM, Rio wrote: > > While implementing a SOCKS proxy in Go, I ran into an issue which is better > explained in details by Evan Klitzke in this post > https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage > > In my case, each proxied connection costs two gorou

[go-nuts] Goroutines, Nonblocking I/O, And Memory Usage

While implementing a SOCKS proxy in Go, I ran into an issue which is better explained in details by Evan Klitzke in this post https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage In my case, each proxied connection costs two goroutines and two buffers in blocking read. For TCP conne

[go-nuts] GopherCon 2018 CFP Ends March 15, 2018 7:59pm EST

Greetings Go Friends, Just wanted to post a quick reminder that the CFP for GopherCon 2018 closes tomorrow evening, at 7:59PM on March 15th to be exact. We would really love to hear your stories about Go, to learn the lessons you’ve learned, to see what you’d like to change in the future. Spea

Re: [go-nuts] fixed random number trouble

It is explained here: https://golang.org/pkg/math/rand/ On Wed, Mar 14, 2018 at 11:26 AM, Andrea Alessandrini wrote: > I wrote this simple code > > package main > import ( > "fmt" > "math/rand" > ) > func main() { > for i := 0; i < 6; i++ { > fmt.Println("My favorite number is", rand.

[go-nuts] fixed random number trouble

I wrote this simple code package main import ( "fmt" "math/rand" ) func main() { for i := 0; i < 6; i++ { fmt.Println("My favorite number is", rand.Intn(100)) fmt.Println("My favorite number is", rand.Int()) } } and I run it in my pc or in a web application (https://tour

Re: [go-nuts] Unexpected output on playground

On Wed, Mar 14, 2018 at 9:33 AM, andrey mirtchovski wrote: > > wanted: panic: runtime error: invalid memory address or nil pointer > dereference > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1090432] > > got: ** Signal 11 from untrusted code: pc=6559000898c0 > > is this just a

Re: [go-nuts] Why not add unsafe.FreeMemory(unsafe.Pointer) to replace sync.Pool ?

On Wed, Mar 14, 2018 at 8:50 AM, bronze man wrote: > > I just found that sync.Pool is almost equal to calloc/free in c language to > program except that forgot call free will not cause a memory leak. I wouldn't say that. Calling Pool.Put reserves the memory for that specific pool, unlike free wh

[go-nuts] Unexpected output on playground

wanted: panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1090432] got: ** Signal 11 from untrusted code: pc=6559000898c0 is this just an idiosyncrasy of the playground, or am I breaking something? -- You rece

[go-nuts] Why not add unsafe.FreeMemory(unsafe.Pointer) to replace sync.Pool ?

I just found that sync.Pool is almost equal to calloc/free in c language to program except that forgot call free will not cause a memory leak. I currently use sync.Pool to make the golang program use less memory. So why not just add unsafe.FreeMemory to the program. Let the programer decide to wh

Re: [go-nuts] infinite recursion in method lookup due to recursive embedded interface value: any way to statically catch this?

On 14 March 2018 at 01:22, Maverick Woo wrote: > Having said the above, in your example, you have a (morally) `shape.Print` > function that takes an interface value of the intended "descendants" and you > expose their fields using interface methods. This is all very idiomatic---no > doubt. However

Re: [go-nuts] Re: infinite recursion in method lookup due to recursive embedded interface value: any way to statically catch this?

How is this a bug? I don't think Go compiler can guess the intent of the developer at compile time. I don't think that qualifies as bug. Le mardi 13 mars 2018 16:48:32 UTC-3:30, Christopher Sebastian a écrit : > > @prades.marq , The solution that you pointed out is already obvious to > everyo