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 unsubscribe
> 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:
https://github.com
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 ar
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:30x2e4483b61
t just needs to be
>> 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.
e Go 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/i
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:
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, 2
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).
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) {
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):
fun
https://play.golang.org/p/NnACN5fLPT3
I was taking the address of the for-loop variable ("&v" 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 t
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 UTC-
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
b
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 think you need print st
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
captures
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 "se
17 matches
Mail list logo
