[go-nuts] Re: dynamic frequency ticker

https://play.golang.org/p/FMs01ACKJv ? Djadala On Tuesday, August 30, 2016 at 8:46:23 PM UTC+3, seb@gmail.com wrote: > > In my application I select on a ticker channel, but sometimes need to have > the waiting time vary a bit. For not so frequent changes I could make a new > ticker everyti

Re: [go-nuts] dynamic frequency ticker

The problem I have with time.Sleep is that I am totally relying on the "exact" time guarantee a Ticker gives me. What I mean is that with a Ticker I can be sure that if it fires every 50ms, no matter what my code does (, after 10 minutes it ran exactly 12000 times. I don't know how I would do t

Re: [go-nuts] dynamic frequency ticker

Interesting. But it would give me two interfering frequencies at the same time, which is not what I want. Also it feels inflexible that for every possible frequency I would have to hardcode a separate select branch. Thanks anyway. Am Dienstag, 30. August 2016 21:46:46 UTC+2 schrieb freeformz:

Re: [go-nuts] type assertion on interface{} accepted practice?

Thanks for confirming! On Tuesday, August 30, 2016 at 5:16:45 PM UTC-7, Ian Lance Taylor wrote: > > On Tue, Aug 30, 2016 at 4:11 PM, > > wrote: > > > > I see that interface{} is used in go's container/list > > https://golang.org/src/container/list/list.go > > > > In using this container

Re: [go-nuts] Re: reading with scanner.Bytes()

There's a 50% chance the receiver wants a string, in which case it would be simpler to use scanner.Text(). -rob On Wed, Aug 31, 2016 at 9:11 AM, Mateusz Czapliński wrote: > > > W dniu wtorek, 30 sierpnia 2016 05:30:48 UTC+2 użytkownik chri...@uber.com > napisał: >> >> How to efficiently create

Re: [go-nuts] type assertion on interface{} accepted practice?

On Tue, Aug 30, 2016 at 4:11 PM, wrote: > > I see that interface{} is used in go's container/list > https://golang.org/src/container/list/list.go > > In using this container am I expected to type assert the element's Value? Yes. > And is this pattern of returning an interface{} and then "castin

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

I looked at the k-nucleotide program, and was unable to figure out a way to make it faster. Most of the time appears to be spent on this one line: pointer, ok := counts[key] pprof reports: 19080ms 56.50% 56.50%22100ms 65.44% runtime.mapaccess2_fast64 This is, of course, exactly

[go-nuts] type assertion on interface{} accepted practice?

I see that interface{} is used in go's container/list https://golang.org/src/container/list/list.go In using this container am I expected to type assert the element's Value? And is this pattern of returning an interface{} and then "casting" it typically accepted in practice to avoid duplication

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

> I looked at that this morning and sped it up a little. > *fyi "Contribute your programs" * -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] Re: reading with scanner.Bytes()

W dniu wtorek, 30 sierpnia 2016 05:30:48 UTC+2 użytkownik chri...@uber.com napisał: > > How to efficiently create a new []byte slice that's not shared? > The simple way I can think of is to []byte(string(bytes)). > Alternatively, I'd expect the following should work: outChannel <- append([]b

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

I looked at that this morning and sped it up a little. From: 'Isaac Gouy' via golang-nuts Reply-To: Isaac Gouy Date: Tuesday, August 30, 2016 at 12:15 PM To: golang-nuts Subject: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption On Tuesday, Aug

[go-nuts] Re: reading with scanner.Bytes()

On Monday, 29 August 2016 23:30:48 UTC-4, chri...@uber.com wrote: > > I am reading a file line by line, and send it to a chan []byte, and > consume it on another goroutine. > > However, I found I must create a new []byte, because the scanner.Bytes() > returned a []byte slice that's shared, and th

Re: [go-nuts] Win xp

https://golang.org/doc/install says that Windows XP is supported. Maybe your Windows 10 machine is 64-bit and your Windows XP machine is 32-bit. Try setting the GOARCH environment variable to 386 before you compile to generate 32-bit EXE files. Andy -- You rec

[go-nuts] Win xp

I'm just learning go. I wrote a trivial pgm on a Windows 10 machine. I noticed that the exe file runs on Windows 7 and 10 but not XP. Is that by design? Robert Solomon On Aug 30, 2016 2:21 PM, wrote: golang-nuts@googlegroups.com

Re: [go-nuts] dynamic frequency ticker

How about something like this? https://play.golang.org/p/U50n3cqIXg On Tue, Aug 30, 2016 at 12:42 PM Aaron Cannon < cann...@fireantproductions.com> wrote: > How about creating a custom ticker that uses time.Sleep. There might > be some hidden caveats when using time.Sleep verses a real ticker th

Re: [go-nuts] dynamic frequency ticker

How about creating a custom ticker that uses time.Sleep. There might be some hidden caveats when using time.Sleep verses a real ticker that I am unaware of, but it might meet your needs. You could then add a custom method, or inbound channel, which you could use to tweak its intervals on the fly.

[go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

On Tuesday, August 30, 2016 at 10:09:39 AM UTC-7, Scott Pakin wrote: > > > Go 1.7 is faster than C on the mandelbrot test and faster than C++ also > on reverse-complement? How did *that* happen? > mandelbrot -- look at the program source code.

Re: [go-nuts] Conditional compiling for android

I already tried this and it doesn't work . Also I need a way to enable certain code only for pure android and not linux. Any suggestions ?? On Mon, Aug 29, 2016 at 12:14 PM, andrey mirtchovski wrote: > you can do this for the pure linux stuff: > > // +build !android,linux > -- You received thi

[go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

Hallöchen! Scott Pakin writes: > On Monday, August 29, 2016 at 5:51:42 PM UTC-6, Eric Johnson wrote: >> >> Not that I think these account for much, but sort of fun to point at: >> >> https://benchmarksgame.alioth.debian.org/u64q/go.html (Short >> summary - now with Go 1.7, Go is faster for most b

[go-nuts] dynamic frequency ticker

In my application I select on a ticker channel, but sometimes need to have the waiting time vary a bit. For not so frequent changes I could make a new ticker everytime, but I have the feeling this is not the best solution for higher frequencies and many rate changes. Best would be if I could tel

[go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

On Monday, August 29, 2016 at 5:51:42 PM UTC-6, Eric Johnson wrote: > > Not that I think these account for much, but sort of fun to point at: > > https://benchmarksgame.alioth.debian.org/u64q/go.html > (Short summary - now with Go 1.7, Go is faster for most benchmarks.) > Go 1.7 is faster than C o

[go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

On Tuesday, August 30, 2016 at 1:01:51 AM UTC-7, Torsten Bronger wrote: > Obviously, C is on a steep decline in the OSS world, while Go (you > may switch off the C line to see it better) is gaining ground > steadily, and doing so faster than Rust. > Well, obviously, we find JavaScript on th

[go-nuts] Re: Go package management committee

Congrats. Please consider at least 2 use cases : - library authors - project authors These 2 use cases are widely different and if the solution doesn't address both cases it will not be useful. People using gb don't have the same use case and issues as people using glide. Ultimately the pro

Re: [go-nuts] Creating a crash dump file with Go and C stack traces

On Tue, Aug 30, 2016 at 6:06 AM, wrote: > > From my point of view, a better solution would be, when Go has an option > (maybe via GOTRACEBACK env var) to trace C threads as well, for example by > using the cgo traceback functions introduced in Go 1.7. I don't see how that would work. The Go cod

Re: [go-nuts] asm newbie questions: missing stackmap

On Tue, Aug 30, 2016 at 2:18 AM, chai2010 wrote: > The asm function `Sum` try call a Go function `sum`, > when the `sum` need morestack, it crashed: > > // main.go > func main() { > println(Sum(100)) > println(Sum(100 * 1000)) // panic! > } > > func Sum(n int) int > > func sum(i, j int) int { > if

[go-nuts] Creating a crash dump file with Go and C stack traces

Hi, I have a Go executable that uses a shared C library which spawns it own threads. In case of a crash (in Go or C code), I want to dump all stacktraces of all C threads and Go routines into a crash dump file. Go does not handle signals in non-Go threads executing non-Go code, so I have to in

[go-nuts] asm newbie questions: missing stackmap

The asm function `Sum` try call a Go function `sum`, when the `sum` need morestack, it crashed: // main.go func main() { println(Sum(100)) println(Sum(100 * 1000)) // panic! } func Sum(n int) int func sum(i, j int) int { if i <= 0 { return j } return sum(i-1, i+j) } // main_amd64.s TEXT ·Sum(SB

[go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

Hallöchen! 'Eric Johnson' via golang-nuts writes: > Not that I think these account for much, but sort of fun to point at: > > https://benchmarksgame.alioth.debian.org/u64q/go.html > (Short summary - now with Go 1.7, Go is faster for most benchmarks.) > > And then, for language adoption, the TIOBE