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, <golang-nuts@googlegroups.com> wrote: golang-nuts@googlegroups.com <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/topics> Google Groups <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> Topic digest View all topics <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/topics> - In case you missed it: language benchmarks for Go 1.7, and language adoption <#m_755194757400116849_group_thread_0> - 8 Updates - dynamic frequency ticker <#m_755194757400116849_group_thread_1> - 1 Update - Go package management committee <#m_755194757400116849_group_thread_2> - 1 Update - Creating a crash dump file with Go and C stack traces <#m_755194757400116849_group_thread_3> - 2 Updates - asm newbie questions: missing stackmap <#m_755194757400116849_group_thread_4> - 2 Updates - labeled loop vs for statement inlining <#m_755194757400116849_group_thread_5> - 2 Updates - reading with scanner.Bytes() <#m_755194757400116849_group_thread_6> - 4 Updates - certificates at /etc/ssl/certs/ getting ignored on FreeBSD <#m_755194757400116849_group_thread_7> - 3 Updates - Performance Counters <#m_755194757400116849_group_thread_8> - 1 Update - Behavior of calling (Context).Err without calling (Context).Done <#m_755194757400116849_group_thread_9> - 1 Update In case you missed it: language benchmarks for Go 1.7, and language adoption <http://groups.google.com/group/golang-nuts/t/772ab7cf9756aab7?utm_source=digest&utm_medium=email> Eric Johnson <e...@tibco.com>: Aug 29 04:51PM -0700 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 language index for August of 2016: http://www.tiobe.com/tiobe-index/ (Note that the above is updated every six months, and I've not been able to find a link to previous versions of the reports, however, you can look for the trend for Go itself http://www.tiobe.com/tiobe-index/go/ ). Go finally breaks into the top twenty. As with any metrics, these are selective measures, and not really good indicators by themselves. But at least they're positive with respect to Go. Eric. Ian Lance Taylor <i...@golang.org>: Aug 29 05:22PM -0700 On Mon, Aug 29, 2016 at 4:51 PM, 'Eric Johnson' via golang-nuts > find a link to previous versions of the reports, however, you can look for > the trend for Go itself http://www.tiobe.com/tiobe-index/go/ ). > Go finally breaks into the top twenty. It's because they changed their definition of Go. Quoting from farther down the page: "The restriction "Google" has been removed from the search queries for the programming language Go. Ilja Heilager sorted out that without the search term "Google" the resulting Go hits are still referring to the Go language. After having removed this restriction Go jumped from position #55 to #20. Thanks Ilja!" Ian Eric Johnson <e...@tibco.com>: Aug 29 06:25PM -0700 Well, sure. I read that too. I think it is still useful that my intuition that Go is gaining adoption aligns with what prominent metrics are reporting, even if it is because the reporting changed how they measured. Eric. Asit Dhal <dhal.as...@gmail.com>: Aug 29 06:36PM -0700 Hi, Go1.7 is faster in most benchmarks, but still slower than Java in some benchmarks(like Go 1.6). GO Garbage Collector needs time to become mature like JVM. K-nucleotide, binary tree, Regex-dna are bad for GO(lack of fast GC and good standard libraries). But, for me, Go is an awesome substitute of Python and C++. Warm Regards, Asit http://asit-dhal.github.io On Tuesday, August 30, 2016 at 1:51:42 AM UTC+2, Eric Johnson wrote: Torsten Bronger <bron...@physik.rwth-aachen.de>: Aug 30 09:59AM +0200 Hallöchen! 'Eric Johnson' via golang-nuts writes: > And then, for language adoption, the TIOBE language index for August of > 2016: > http://www.tiobe.com/tiobe-index/ I don't think TIOBE is useful beyond position 10 or so. Anyway ... https://www.openhub.net/languages/compare?utf8=%E2%9C% 93&measure=commits&language_name%5B%5D=c&language_name%5B% 5D=golang&language_name%5B%5D=java&language_name%5B%5D=rust& language_name%5B%5D=-1&commit=Update is limited to open source, but covers a big corpus. Besides, "monthly commits" is a very expressive, clearly defined indicator. 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. Tschö, Torsten. -- Torsten Bronger Jabber ID: torsten.bron...@jabber.rwth-aachen.de Isaac Gouy <igo...@yahoo.com>: Aug 30 07:44AM -0700 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 the rise, but I admit to checking several others before finding a partial-match to that most-recent C down-tick -- https://www.openhub.net/languages/compare?utf8=%E2%9C% 93&measure=commits&language_name%5B%5D=c&language_name%5B% 5D=golang&language_name%5B%5D=javascript&language_name%5B% 5D=python&language_name%5B%5D=-1&commit=Update What fun! Scott Pakin <scott...@pakin.org>: Aug 30 10:09AM -0700 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 on the mandelbrot test and faster than C++ also on reverse-complement? How did *that* happen? — Scott Torsten Bronger <bron...@physik.rwth-aachen.de>: Aug 30 08:10PM +0200 Hallöchen! Scott Pakin writes: >> summary - now with Go 1.7, Go is faster for most benchmarks.) > Go 1.7 is faster than C on the mandelbrot test and faster than C++ > also on reverse-complement? How did *that* happen? For simple things, Go will produce almost the same machine code than a C/C++ compiler, at least in the inner loops. Besides, I think in some cases, the quality of the implementation is tested more than anything else. Tschö, Torsten. -- Torsten Bronger Jabber ID: torsten.bron...@jabber.rwth-aachen.de Back to top <#m_755194757400116849_digest_top> dynamic frequency ticker <http://groups.google.com/group/golang-nuts/t/4cc5fb0fa5eb4c79?utm_source=digest&utm_medium=email> seb.st...@gmail.com: Aug 30 09:57AM -0700 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 tell my existing ticker "from next tick on please use an interval of x". In fact what I want is that the frequency changes over time. Any tips how to achieve that? Back to top <#m_755194757400116849_digest_top> Go package management committee <http://groups.google.com/group/golang-nuts/t/6c4ad2ddf0f02205?utm_source=digest&utm_medium=email> paraiso.m...@gmail.com: Aug 30 08:58AM -0700 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 problem can only be solved with a third party tool that is NOT go get, but it must be an official tool sanctioned by the Go team. Good luck. Le vendredi 26 août 2016 20:45:26 UTC+2, Peter Bourgon a écrit : Back to top <#m_755194757400116849_digest_top> Creating a crash dump file with Go and C stack traces <http://groups.google.com/group/golang-nuts/t/853e64c7e9c2b89a?utm_source=digest&utm_medium=email> martin.stre...@gmail.com: Aug 30 06:06AM -0700 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 install a custom C signal handler to handle those cases. And as Go does not invoke a preinstalled C handler in case of crashes in Go code, the C handler has to be registered after the Go handler. After some experiments - restricted to Linux amd64 - I got it working somehow (https://gist.github.com/trxa/302c5dbe9055ef287da9139e68d0a93e). But it feels a bit hacky with some drawbacks and I wonder if somebody can propose a better solution or improvements. How it basically works: The Go handlers are stored when the C handler gets installed. If invoked, for example by a SIGSEGV, the handler opens a file and writes the stack trace of the current thread into that file. Then, it signals all other threads to dump their stack into the file too. After all threads are dumped, the IP of the failing instruction is saved and the Go handler is invoked by calling it directly to keep the ucontext of the crash. After the Go handler has returned, it is checked whether the IP of the uc_mcontext has been changed by Go. If it is changed, the IP points to runtime.sigpanic which triggers a panic and dumps the Go routine stacks to STDERR. If it is not changed, the crash was in non-Go code on a non-Go thread and Go does not handle the crash. In that case, the IP register in uc_mcontext is set to the function pointer of an exposed Cgo function which calls panic() to dump the stack to STDERR. Before returning from the C handler, the STDERR file descriptor is replaced by the crash dump file descriptor, so that Go panics into the file. (The Go handlers should probably be restored before returning, if Go still wants to backtrace the threads via SIGQUIT itself.) After the C handler has returned, runtime.sigaction or the cgo function is executed and does not return. Here are the disadvantages and things to watch out, which makes the solution a bit creepy: 1. signal.Notify has to be called for all signals you want to handle for C crashes, although they are not handled in Go. Otherwise the Go handler does not return in the "non-Go-code/thread" case, but creates a core dump. 2. Setting the IP to a cgo function to be executed when the handler returns, makes the program panicing synchronously, as with runtime.sigpanic, but is probably not async-signal-safe, for example if it has to request more stack. A workaround would be to panic in Go, if the signal is read from the notify channel. In addition, the C handler must not return to avoid reexecution of the faulting instruction. This can be done by putting the thread to sleep. Doing this is probably even more platform independent, but that way, a synchronous signal from C is handled as an asynchronous one and you don't have a chance to distinguish it in Go by the information you get (in case you only want to dump and continue for asynchronous signals). 3. Cloning the STDERR file descriptor to point to a file feels also a bit fragile compared to directly writing to it. Another thread might write to it. The fd cannot be closed (except maybe in a global destructor) and the OS would have to flush the buffers correctly (or I have to use synchronous write mode, which slows writing the dump down tremendously). 4. There are duplicate stack traces, and it's not always obvious to match a thread stack trace to the running go routine. 5. It would be desirable to have the stack trace of the failing instruction redundantly in the crash file and in the log file, but with this solution it is only possible for C frames and the first Go frame on top of the thread, at least if you use a common unwinder library. There might be more. >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. Also setting a file descriptor/handle as target for a dump should be allowed (maybe in addition to the dump on STDERR). In addition to the cgo traceback functions, there might be one or more functions for gathering additional information, which will be printed in the crash dump. A use case for that would be a list of loaded modules/libraries or environment variables. I can imagine that it's easier said than done, but that's what I would prefer. Thanks for your opinions! Martin Ian Lance Taylor <i...@golang.org>: Aug 30 07:27AM -0700 > 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 code has no idea what C threads exist. I'm not aware of any portable API that would let it determine that. > Also setting a file > descriptor/handle as target for a dump should be allowed (maybe in addition > to the dump on STDERR). To me that sounds like something to be handled when invoking the Go program, e.g., feed stderr into tee. > loaded modules/libraries or environment variables. > I can imagine that it's easier said than done, but that's what I would > prefer. Calling a user Go function while crashing definitely sounds problematic. If we are crashing because we have run out of memory or because the heap has been corrupted, there isn't anything reasonable that the user function can do. I'm impressed that your code works as well as it sounds, but in general Go is focused on dumping Go state. I can imagine adding another callback, along the lines of SetCgoTraceback, that would provide a C function that would be invoked when crashing, immediately before exiting. Perhaps in dieFromSignal or perhaps in runtime.exit. Would that help your case? If so, please open an issue and we can think about it. Of course such a function would be restricted to async-signal-safe function calls, so I don't know if that would really help. Ian Back to top <#m_755194757400116849_digest_top> asm newbie questions: missing stackmap <http://groups.google.com/group/golang-nuts/t/307941d2f8cd2903?utm_source=digest&utm_medium=email> chai2010 <chaishus...@gmail.com>: Aug 30 05:18PM +0800 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), $24-16 MOVQ n+0(FP), AX MOVQ AX, 0(SP) MOVQ $0, 8(SP) CALL ·sum(SB) MOVQ 16(SP), AX MOVQ AX, ret+8(FP) RET panic message: Sum(100): 50005000 runtime: frame ... untyped locals 0xc042233e88+0x18 fatal error: missing stackmap runtime stack: runtime.throw(0x467c4b, 0x10) C:/go/go1.7.windows-amd64/src/runtime/panic.go:566 +0x9c runtime.adjustframe(0x6fb40, 0x6fc38, 0x6f901) C:/go/go1.7.windows-amd64/src/runtime/stack.go:660 +0x7d2 runtime.gentraceback(0xffffffffffffffff, 0xc0421b52b0, 0x0, 0xc04201c000, 0x0, 0x0, 0x7fffffff, 0x46d898, 0x6fc38, 0x0, ...) C:/go/go1.7.windows-amd64/src/runtime/traceback.go:378 +0x10aa runtime.copystack(0xc04201c000, 0x100000, 0x6fe01) C:/go/go1.7.windows-amd64/src/runtime/stack.go:902 +0x388 runtime.newstack() C:/go/go1.7.windows-amd64/src/runtime/stack.go:1070 +0x37e runtime.morestack() C:/go/go1.7.windows-amd64/src/runtime/asm_amd64.s:366 +0x87 ... Thanks! -- https://github.com/golang-china/gopl-zh https://github.com/golang-china https://github.com/chai2010 Ian Lance Taylor <i...@golang.org>: Aug 30 07:00AM -0700 > C:/go/go1.7.windows-amd64/src/runtime/stack.go:1070 +0x37e > runtime.morestack() > C:/go/go1.7.windows-amd64/src/runtime/asm_amd64.s:366 +0x87 If an assembler function can call into Go, it needs to provide a stack map that tells the Go stack unwinder which local variables on the stack are pointers. In this case none of them are pointers, so you can just add NO_LOCAL_POINTERS as defined in runtime/funcdata.h. Ian Back to top <#m_755194757400116849_digest_top> labeled loop vs for statement inlining <http://groups.google.com/group/golang-nuts/t/9712d1bad1c9bd45?utm_source=digest&utm_medium=email> Sokolov Yura <funny.fal...@gmail.com>: Aug 29 10:58PM -0700 But still question is interesting: why decision is based on source code and not on instructions size? Both functions likely to produce same assembler code. Dave Cheney <d...@cheney.net>: Aug 29 11:00PM -0700 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, Sokolov Yura wrote: Back to top <#m_755194757400116849_digest_top> reading with scanner.Bytes() <http://groups.google.com/group/golang-nuts/t/988e34834d880e67?utm_source=digest&utm_medium=email> chris...@uber.com: Aug 29 08:23PM -0700 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 the scanner may still write to the []byte slice. How to efficiently create a new []byte slice that's not shared? The simple way I can think of is to []byte(string(bytes)). Or am I approach this correctly at all? Chris scanner := bufio.NewScanner(file) for scanner.Scan() { // this conversion to string and then to []byte is needed. // calling scanner.Bytes() will cause malformed lines. outChannel <- []byte(scanner.Text()) } Caleb Spare <cesp...@gmail.com>: Aug 29 08:41PM -0700 You can do b0 := scanner.Bytes() b1 := make([]byte, len(b0)) copy(b0, b1) outChannel <- b0 On Mon, Aug 29, 2016 at 8:23 PM, chris.lu via golang-nuts Chris Lu <chris...@uber.com>: Aug 29 09:14PM -0700 Nice. Thanks! b0 := scanner.Bytes() b1 := make([]byte, len(b0)) copy(b1, b0) outChannel <- b1 Chris "Tamás Gulácsi" <tgulacs...@gmail.com>: Aug 29 09:32PM -0700 If you can, you should reuse those slices, e.g. with sync.Pool. Back to top <#m_755194757400116849_digest_top> certificates at /etc/ssl/certs/ getting ignored on FreeBSD <http://groups.google.com/group/golang-nuts/t/73c7e7b10e5665a7?utm_source=digest&utm_medium=email> niloy.debn...@gmail.com: Aug 29 04:55PM -0700 What version of Go are you using (go version)? go version devel +e6f9f39 Mon Aug 29 18:25:33 2016 +0000 linux/amd64 Checkout 1.7 from git master branch and compiled. What operating system and processor architecture are you using (go env)? GOARCH="amd64" GOBIN="" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/ndebnath/opensource" GORACE="" GOROOT="/home/ndebnath/golang/go" GOTOOLDIR="/home/ndebnath/golang/go/pkg/tool/linux_amd64" CC="gcc" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build614456670=/tmp/go-build -gno-record-gcc-switches" CXX="g++" CGO_ENABLED="1" What did you do? Install CAcert on FreeBSD system. I placed the certificate in /etc/ssl/certs, calculated the hash and then created a symlink from /etc/ssl/certs/.0 to cacert.pem. Now the problem is fetch doesn't even look there. It only looks at /usr/local/share/certs/ca-root-nss.crt. So if I remove cert.pem then getting below error, Certificate verification failed for /C=xx/ST=xx/OU=Server/L=unknown/CN=localhost 91426:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:974: fetch: https://ip:port/v1/agent/checks: Authentication error And other https request is not going through because of "x509: certificate signed by unknown authority". During investigation I have seen that go does not checks for /etc/ssl/certs/ location files if symbolic link for nss root exist ( https://golang.org/src/crypto/x509/root_unix.go: Line 32). If I comment out this return statement then it worked for me. What did you expect to see? Both, systems default ca cert and ca files inside /etc/ssl/certs/ location should work together on FreeBSD. What did you see instead? ca file at /etc/ssl/certs/ location is not getting validated when system default ca exist. Niloy Debnath <niloy.debn...@gmail.com>: Aug 29 04:56PM -0700 What version of Go are you using (go version)? go version devel +e6f9f39 Mon Aug 29 18:25:33 2016 +0000 linux/amd64 Checkout 1.7 from git master branch and compiled. What operating system and processor architecture are you using (go env)? GOARCH="amd64" GOBIN="" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/ndebnath/opensource" GORACE="" GOROOT="/home/ndebnath/golang/go" GOTOOLDIR="/home/ndebnath/golang/go/pkg/tool/linux_amd64" CC="gcc" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build614456670=/tmp/go-build -gno-record-gcc-switches" CXX="g++" CGO_ENABLED="1" What did you do? Install CAcert on FreeBSD system. I placed the certificate in /etc/ssl/certs, calculated the hash and then created a symlink from /etc/ssl/certs/.0 to cacert.pem. Now the problem is fetch doesn't even look there. It only looks at /usr/local/share/certs/ca-root-nss.crt. So if I remove cert.pem then getting below error, Certificate verification failed for /C=xx/ST=xx/OU=Server/L=unknown/CN=localhost 91426:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:974: fetch: https://ip:port/v1/agent/checks: Authentication error And other https request is not going through because of "x509: certificate signed by unknown authority". During investigation I have seen that go does not checks for /etc/ssl/certs/ location files if symbolic link for nss root exist ( https://golang.org/src/crypto/x509/root_unix.go: Line 32). If I comment out this return statement then it worked for me. What did you expect to see? Both, systems default ca cert and ca files inside /etc/ssl/certs/ location should work together on FreeBSD. What did you see instead? ca file at /etc/ssl/certs/ location is not getting validated when system default ca exist. Dave Cheney <d...@cheney.net>: Aug 29 07:20PM -0700 These are the locations that are searched on *BSD machines // Possible certificate files; stop after finding one. var certFiles = []string{ "/usr/local/share/certs/ca-root-nss.crt", // FreeBSD/DragonFly "/etc/ssl/cert.pem", // OpenBSD "/etc/openssl/certs/ca-certificates.crt", // NetBSD } On Tuesday, 30 August 2016 09:55:34 UTC+10, Niloy Debnath wrote: Back to top <#m_755194757400116849_digest_top> Performance Counters <http://groups.google.com/group/golang-nuts/t/19f08c0cc51a6498?utm_source=digest&utm_medium=email> Mark Richman <markarich...@gmail.com>: Aug 29 06:02PM -0700 Thanks Diego! I will check it out. Looks like it's what I'm after. On Monday, August 29, 2016 at 2:07:34 PM UTC-4, Diego Medina wrote: Back to top <#m_755194757400116849_digest_top> Behavior of calling (Context).Err without calling (Context).Done <http://groups.google.com/group/golang-nuts/t/55d142c52f56e673?utm_source=digest&utm_medium=email> Ian Lance Taylor <i...@golang.org>: Aug 29 05:13PM -0700 > thought was that we could mostly remove the need for a lock on the err field > if Done() always provides a barrier. However, incorrect usage of the > interface would lead to racy results if the field is unprotected. I would be inclined to say that it is a mistake to call Err before the Done channel is closed. I don't think we have to promise any particular behavior for that case, but it should not crash and it should not introduce a race condition. Ian Back to top <#m_755194757400116849_digest_top> You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/join> . To unsubscribe from this group and stop receiving emails from it send an email to golang-nuts+unsubscr...@googlegroups.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.
