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

[a . curious . programmer]

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 am I expected to type assert the element's 
> Value? 
>
> Yes. 
>
> > And is this pattern of returning an interface{} and then "casting" it 
> > typically accepted in practice to avoid duplication of larger code? 
>
> Pretty much, yes.  It's a trade-off between code duplication and 
> compile-time type safety. 
>
> Note that in general you don't want to use container/list.  Use a 
> slice instead.  There are only a few special cases where 
> container/list is better than a slice.  And if you use a slice you 
> don't need to worry about a type assertion. 
>
> Ian 
>

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

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

[Rob Pike]

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 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([]byte(nil), scanner.Bytes()...)
>   // or:
>   outChannel <- append([]byte{}, scanner.Bytes()...)
>
> though as to efficiency, I can't say much.
>
> /M.
>
> --
> 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.
>

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

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

[Ian Lance Taylor]

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 "casting" it
> typically accepted in practice to avoid duplication of larger code?

Pretty much, yes.  It's a trade-off between code duplication and
compile-time type safety.

Note that in general you don't want to use container/list.  Use a
slice instead.  There are only a few special cases where
container/list is better than a slice.  And if you use a slice you
don't need to worry about a type assertion.

Ian

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

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

['Isaac Gouy' via golang-nuts]

> 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 emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mateusz Czapliński]

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([]byte(nil), scanner.Bytes()...)
  // or:
  outChannel <- append([]byte{}, scanner.Bytes()...)

though as to efficiency, I can't say much.

/M.

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

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

[Michael Jones]

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

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

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

Re: [go-nuts] Win xp

[Andy Balholm]

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

[go-nuts] Win xp

[Robert Solomon]

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

Google
Groups


Topic digest
View all 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

Eric Johnson : 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 : 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 : 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 : 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 : 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=commits_name%5B%5D=c_name%5B%
5D=golang_name%5B%5D=java_name%5B%5D=rust&
language_name%5B%5D=-1=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 : Aug 30 07:44AM 

Re: [go-nuts] dynamic frequency ticker

[Edward Muller]

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 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.
>
> Aaron
>
> On 8/30/16, seb.st...@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 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?
> >
> > --
> > 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.
> >
>
> --
> 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.
>

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

Re: [go-nuts] dynamic frequency ticker

[Aaron Cannon]

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.

Aaron

On 8/30/16, seb.st...@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 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?
>
> --
> 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.
>

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

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

['Isaac Gouy' via golang-nuts]

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. 


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

[go-nuts] dynamic frequency ticker

[seb . stark]

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?

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

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

[Scott Pakin]

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

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

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

['Isaac Gouy' via golang-nuts]

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=commits_name%5B%5D=c_name%5B%5D=golang_name%5B%5D=javascript_name%5B%5D=python_name%5B%5D=-1=Update

What fun!

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

[go-nuts] Re: Go package management committee

[paraiso . marc]

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 :
>
> As a reminder, in July I started the Go Packaging Proposal doc[0] with 
> the goal “To produce, have accepted, and implement a complete proposal 
> which addresses the concern of package management.” Thanks to everyone 
> who’s signaled interest. That process involves creating a small 
> committee to drive the proposal from start to finish. 
>
> In forming the committee I’ve focused on three important points— 
>
> 1. First and foremost, that the design and discussion process, and 
> ultimate technical solution, should be driven by a data- and 
> user-needs-centric methodology. 
>
> 2. That the schedule outlined in the process doc should be adhered to 
> as closely as possible. That means design-complete by end September, 
> and proposal-complete by end October, so that any possible language or 
> tooling changes can make the 1 November feature freeze for Go 1.8. 
>
> 3. Each member should have or make time to devote to this process, so 
> that both points above are feasible :) 
>
> A committee size of four I believe most effectively balances a variety 
> of voice and opinion, and an ability to effectively decide and act. 
> After a great deal of consultation with, and feedback from, key 
> members of the Go language and package management/vendoring 
> communities, I'm happy to announce that Andrew Gerrand, Edward Muller, 
> Jessie Frazelle, and Sam Boyer have all agreed to serve on the package 
> management committee. 
>
> Andrew needs no introduction, as he's been leading the Go community 
> advocacy efforts from within the Go team since nearly the very 
> beginning. Andrew brings an unmatched perspective on the current state 
> and evolution of the Go language and tooling, and will be instrumental 
> in shepherding any possible language or tooling changes through the 
> proposal process. 
>
> Ed has been maintaining the godep project for the past two years, and 
> brings a pragmatic and user-centric perspective to the committee. 
>
> Jessie has been on the Go package management front lines for years, 
> originally with Docker and now with Kubernetes. I can't think of 
> anyone better to represent the needs of large Go projects and 
> organizations. 
>
> Sam may be best known in the Go community for his article "So you want 
> to write a package manager[1]." With his background and work on the Go 
> Package Solver, Sam brings theoretical depth and rigor to the 
> committee. 
>
> Keeping the committee small was absolutely essential, but it quickly 
> became apparent that several unquestionably qualified individuals, 
> whose efforts and experience would be critical to our success, would 
> be excluded. We decided that an advisory group, while not part of the 
> original Process doc, would enable the committee to remain small and 
> nimble, while leveraging the value, effort, and experience of a larger 
> group. The maintainers of popular package management tools Glide (Matt 
> Farina), govendor (Daniel Theophanes) and gb (Dave Cheney), as well as 
> Steve 'spf13' Francia (Hugo, Cobra) have all graciously agreed to 
> support in this role. Their job will be to help compile user and 
> domain research, and to represent user needs whenever the committee 
> needs input. Matt and Steve in particular have been hard at work on an 
> updated tool survey and user requirement doc; details forthcoming. 
> Both I and the committee are incredibly grateful to each of them for 
> their support. 
>
> I'll act as secretary, note-taker, and communications director for the 
> committee on an as-needed basis, to free them from the overhead. If 
> you have any questions about the process, please direct them to me. 
> And stay tuned for links to research and design Google Docs. 
>
> [0] 
> https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8
>  
> [1] 
> https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.iqtluxnrr
>  
>

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

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

[Ian Lance Taylor]

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 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(0x, 0xc0421b52b0, 0x0, 0xc04201c000,
> 0x0, 0x0, 0x7fff, 0x46d898, 0x6fc38, 0x0, ...)
> C:/go/go1.7.windows-amd64/src/runtime/traceback.go:378 +0x10aa
> runtime.copystack(0xc04201c000, 0x10, 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

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

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

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

[martin . strenge]

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

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

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

[Torsten Bronger]

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 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=commits_name%5B%5D=c_name%5B%5D=golang_name%5B%5D=java_name%5B%5D=rust_name%5B%5D=-1=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 BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de

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

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

[Dave Cheney]

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

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