[go-nuts] Re: Learning the runtime

Turns out, other parts of the runtime have decent docs – mgc.go is very well commented, for example. I may have started my research in the darkest corners (itab, ptab, ftab, oh my). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] Re: Learning the runtime

> What part in particular are you interested in? I ended up in the runtime code because I'm interested in plugins, the linker, loader, and how the runtime manages types. In particular, I'm interested in https://github.com/golang/go/issues/28783. My comment here explains why:

[go-nuts] Learning the runtime

Is there any way to learn the internals of the runtime package, besides just reading all the code? There are a lot of types in the package with cryptic names and no documentation, so if all I have is the code, it's going to be a steep learning curve. -- You received this message because you

[go-nuts] What is the output of objdump?

Can someone please explain the columns printed by "go tool objdump"? For example: TEXT %22%22.main(SB) gofile../Users/abuchanan/projects/gobuild/simple/main. go main.go:30x2db65488b0c25MOVQ GS:0, CX [5:9]R_TLS_LE main.go:30x2e4

Re: [go-nuts] Locking goroutine to "main" thread

>> locked to a thread - use a native thread - and post the os events to a >> channel. >> >> Probably easiest to export a simple Go postToEventChannel() and have the >> native use this. >> >> On Jan 3, 2020, at 2:18 PM, buch...@gmail.com wrote: >>

Re: [go-nuts] Locking goroutine to "main" thread

postToEventChannel() and have the > native use this. > > On Jan 3, 2020, at 2:18 PM, buch...@gmail.com wrote: > >  > I've been getting by with a version of this that sends commands (closures) > to a loop on the main thread: > > https://github.com/buchanae/ink/blob/2a

Re: [go-nuts] Locking goroutine to "main" thread

I've been getting by with a version of this that sends commands (closures) to a loop on the main thread: https://github.com/buchanae/ink/blob/2af8781a960a0351b6b6b7ca23d81ae5c43535ec/win/window.go#L55 And here is where it pops those commands, and also integrates with the OS event loop: https

Re: [go-nuts] Locking goroutine to "main" thread

I found some existing discussion on this topic: https://github.com/golang/go/issues/14163 Not sure I fully understand the reasoning there. If there is a better way forward that doesn't involve adding a controversial function to the scheduling package, I'm all ears. On Saturday, December 14,

Re: [go-nuts] Locking goroutine to "main" thread

Would it be reasonable to make a Go proposal that adds something like runtime.MainThread(), which would cause the calling goroutine to only ever be scheduled on the main thread? Unlike runtime.LockOSThread, it would not need to prevent other goroutines from running on the main thread (I think).

Re: [go-nuts] Locking goroutine to "main" thread

If I understand correctly, that would prevent me from starting any other goroutines. The following program deadlocks: package main import ( "log" "runtime" "time" ) func init() { runtime.LockOSThread() } func main() { go func() { for range time.After(time.Second) {

[go-nuts] Locking goroutine to "main" thread

I've been experimenting with graphics programming using go+sdl2 for awhile now. I've always been uncertain how to deal with locking a goroutine to the main thread. MacOS requires interactions with the OS window to come from the main thread. So far, I have something like this (pseudocode):

[go-nuts] gotcha: don't take the address of a for-range loop variable

https://play.golang.org/p/NnACN5fLPT3 I was taking the address of the for-loop variable ("" in the example above) and was surprised to find that all my items pointed the same address. I thought I had found most of the Golang gotchas by now, but this is a new one to me. -A -- You received

[go-nuts] Re: Should we stop using a global logger?

Or, what if... type FunnelContext interface { context.Context logger.Logger } type RequestHandler struct { // No context specific fields here, instance stays reusable across requests } func (RequestHandler) Handle(ctx FunnelContext) {} On Thursday, August 24, 2017 at 8:58:15 PM

[go-nuts] Should we stop using a global logger?

In Funnel [1], we've been using a global logger, based on logrus [2]. This has worked fine through the early stages of the project, but it's starting to show a few cracks. In particular, we need to ensure that a request (task) ID is present in all log messages. Solutions to this have grown to

Re: [go-nuts] Capture test output per-function

On Thursday, July 6, 2017 at 12:40:30 AM UTC-7, Jan Mercl wrote: > > On Thu, Jul 6, 2017 at 12:56 AM wrote: > > > As far as I can tell, go test captures the output per-package, and when > one test fails it dumps all the captured logs. > > It's per test, not package. > > I

[go-nuts] Capture test output per-function

In Funnel, we have a growing end-to-end test suite which has many test functions. https://github.com/ohsu-comp-bio/funnel/tree/master/tests/e2e When one test fails, Funnel's logs are dumped, and there are lots of them. Debugging tests has become difficult. As far as I can tell, go test

[go-nuts] Re: Why there is no container/set

Back to the original question, container/set seems like a great addition. It could have a nicer interface than map[T]U and a single best implementation. Can we talk about whether the owners of that package agree? On Saturday, December 3, 2011 at 1:32:02 AM UTC-8, James Chow wrote: > > I used