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

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

[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

[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

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

[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

[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

[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

[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] 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

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

Re: [go-nuts] labeled loop vs for statement inlining

Inlining is conservative. As well as the size of the code being inlined, current 40 units (unit has not scale), some operations are not inlined, as they are considered hairy. switch used to be considered hairy, 1.7 fixed that, for is still hairy. On Tuesday, 30 August 2016 15:58:30 UTC+10,

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 > > >

[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 <-

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

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

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

[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

[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