Stephen Gutekanst | 20 Nov 21:21 2014
Picon

runtime: where do main_init and main_main come from?

Hi,

I am trying to figure out what exactly is guaranteed to run on the main OS thread. I already know quite a lot about it all, but I want to understand it fully. To do this I am trying to understand the runtime code, in proc.go line 34-63 (see below).

Please help me confirm:
  • main_init and main_main come from the linker?
  • main_init is ALL imported package's init functions combined together into a single function, right?
  • main_main is package "main" and function "main", right? (i.e. the Go program's main function / entry point)
  • Runtime ensures main_init runs on the main thread (i.e. init functions in packages do not need to call LockOSThread to ensure they run on the main OS thread).
  • Runtime ensures main_main starts execution the main thread, but it might be moved to a different one e.g. when making syscalls (LockOSThread is needed to ensure it runs on the main OS thread).
The portion of code I am talking about:

// Lock the main goroutine onto this, the main OS thread,
// during initialization.  Most programs won't care, but a few
// do require certain calls to be made by the main thread.
// Those can arrange for main.main to run in the main thread
// by calling runtime.LockOSThread during initialization
// to preserve the lock.
lockOSThread()

if g.m != &m0 {
gothrow("runtime.main not on m0")
}

runtime_init() // must be before defer

// Defer unlock so that runtime.Goexit during init does the unlock too.
needUnlock := true
defer func() {
if needUnlock {
unlockOSThread()
}
}()

memstats.enablegc = true // now that runtime is initialized, GC is okay

main_init()

needUnlock = false
unlockOSThread()

main_main()

I really appreciate any insight you can give,
Stephen

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Brian Marete | 20 Nov 19:18 2014

`go get -v all' currently broken?

Hello all,

I am trying to upgrade my Go installation to the current tip of branch release-branch.go1.4.

I am using all.bash in this manner: `env GOROOT_FINAL=/opt/go ./all.bash' and I take care to copy the root of the Go repo to /opt/go when done.

Subsequently, I do: `go get -v -u all' and then `go get -v all'. But the latter fails at the very beginning with: 

can't load package: the code.google.com/p/go.tools/cmd/cover command has moved; use golang.org/x/tools/cmd/cover instead.
can't load package: the code.google.com/p/go.tools/cmd/godoc command has moved; use golang.org/x/tools/cmd/godoc instead.
can't load package: the code.google.com/p/go.tools/cmd/vet command has moved; use golang.org/x/tools/cmd/vet instead.

which is rather puzzling because all the golang/x/* repos are installed on my $GOPATH.

Thanks,

BGM.


--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
John Berthels | 20 Nov 12:08 2014
Picon

go test import cycle detection, symlinks and failure mode

Hi gophers,

I had been using symlinks from my GOPATH to disparate projects, to:

- allow a single project repo per-project which mixes golang and other code (so the golang code doesn't have a single repo of it's own)
- avoid the need for an ever-growing GOPATH with one entry per project

I hit a problem (details below) and have subsequently discovered that symlinks from GOPATH are not supported - so I'm now using multiple-entry GOPATH to support the "golang code in a larger repo" use case.


I'm posting to describe a failure mode in this case, which was sufficiently interesting to me that I think some might consider it a tooling bug. If others agree, please let me know and I'll raise an issue. Even if not, I scratched my head long enough that describing the symptoms here might help someone else chasing the same problem.


Basically in this case (symlink from GOPATH to code), go test fails to detect a test-only import cycle.

This can mean we end up "successfully" compiling with the cycle in place, resulting in running code which is sufficiently confused about types that whether type-asserting succeeds or not depends on which package you do it in. If you do an unchecked type assertion you can get a nicely confusing panic: "interface is foo.Quux, not foo.Quux".

Steps to reproduce below.

regards,

jb

# Pretend our golang code is part of a larger repo
mkdir -p proj/foo proj/bar
cat << EOF > proj/foo/foo.go
package foo

type Quux int
EOF
cat << EOF > proj/foo/foo_test.go
package foo

import (
        "proj/bar"
        "testing"
)

func TestFoo(t *testing.T) {
        var i interface{}
        i = Quux(10)
        bar.DoBar(i)
}
EOF
cat << EOF > proj/bar/bar.go
package bar

import (
        "proj/foo"
        "fmt"
)

func DoBar(i interface{}) {
        q := i.(foo.Quux)
        fmt.Printf("q has type %T\n", q) // not reached - panic on previous line
}
EOF
# Symlink from GOPATH (assumes you have single-entry GOPATH)
ln -s $PWD/proj $GOPATH/src/proj
# Run your tests...
cd proj
go test -v ./foo


--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
reno.esper | 20 Nov 11:36 2014
Picon

*string vs string

Can anyone give me some explanation about *string and string? I tried to use go-toml-config but it gave me *string type instead of string. I can't find any explanation in http://golang.org/pkg/strings/. Thanks before.


Best regards,
Boy Sandy G.A.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Serge Hulne | 20 Nov 15:54 2014
Picon

https://code.google.com/p/go/source/checkout

Hi,

I was in the process of reinstalling Google Go on a new Mac when I noticed that the vim configuration files which used to be hosted unde $GOROOT/misc/vim (or something like that appear to me missing).

Without these file, vim is fairly useless (no code highlighting, no "gocode", etc ...)

A these files relocated somewhere else or have they just missing ?

Thanks,
Serge.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Manlio Perillo | 20 Nov 15:36 2014
Picon

gofmt inconsistent formatting

Hi.

I don't understand how gofmt formatting rules are implemented.
Please consider the following source file:
http://play.golang.org/p/VKmJnD_rTE

When I format it, I get (only the interesting part):

mask := 1 << uint(fd) % nbits
bits[fd/nbits] |= mask
_ = (bits[fd/nbits] & mask) == 0

mask = 1<<uint(fd)%nbits + 0
bits[(fd / nbits)] |= mask
_ = (bits[(fd/nbits)] & mask) == 0


This does not seems consistent, to me.

As far as I can see, gofmt removes spaces around a binary operator when there may be ambiguity about precedence.
However bits[fd/nbits] is safe, so spaces should be added around the operator.

If spaces are removed in case of ambiguities, isn't it better to add parenthesis?
Finally: what is the reason why there is no space around the "/" operator in the last statement?

P.S.: should I use golang-dev for these questions?
P.S: is gofmt allowed to change formatting rules in new versions of go compiler?


Thanks   Manlio Perillo

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Manlio Perillo | 20 Nov 14:37 2014
Picon

gofmt and short variable declarations

Hi.

What is the reason why gofmt aligns a variable declaration "block" like:

var (
    a = 10
    ab = 20
    abc = 30
)

but it does not align multiple variable declarations like:

a := 10
ab := 20
abc: 30

I was expecting the latter to be aligned, since it is a logical variable declaration "block".
Should I always be explicit and use the first declaration, when I need to declare multiple variable in a function?


Thanks  Manlio Perillo

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Tim Heckman | 20 Nov 08:14 2014

Previewing godoc for your project

Hello,

Apologies if I'm asking a question that's been answered, or is easy to find... I've not found the right documentation yet.

I'm trying to find the best way to preview the comments of my code as it would appear when parsed by godoc. The problem is that I'd like to view it when in http server mode, and can't seem to find a way to do that. Is this possible?

I've seen how to dump it in plain text. However, when doing that my function-specific Examples don't show up even with "-ex=true".

Thanks in advance!

Cheers!
-TIm

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
andrey mirtchovski | 20 Nov 02:09 2014
Picon

Re: pprof and OSX Yosemite.

Forgot to CC go-nuts...

On Nov 19, 2014 6:04 PM, "andrey mirtchovski" <mirtchovski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> It's now in /System/Library/Kernels/
>

On top of that the debugging kernels come as a .pkg that only installs on Yosemite and won't let you debug a panic from a different osx version without manually extracting the pkg, and so on and so forth. Brave new world.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Andy Balholm | 20 Nov 00:00 2014
Picon

Re: archive/tar help trying to split a tar stream into two result tar streams

Does it need to be the first 80% that goes to one file, and the last 20% that goes to the other, or should it be
evenly distributed throughout the list of files?

--

-- 
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+unsubscribe@...
For more options, visit https://groups.google.com/d/optout.

mnbbrown | 19 Nov 07:33 2014
Picon

net.Conn = nil panicing with logentries and gin-gonic

I'm trying to use logentries (via https://github.com/bsphere/le_go) with my 
application that is using the gin web framework (https://github.com/gin-gonic/gin) and it keeps panicing when checking if the logger.conn (net.Conn) is nil.

2014/11/18 22:31:34 PANIC: runtime error: invalid memory address or nil pointer dereference
/usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/panic.c:552 (0x147cd)
panicstring: runtime·panic(err);
/usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/os_darwin.c:454 (0x1346e)
sigpanic: runtime·panicstring("invalid memory address or nil pointer dereference");
/Users/mnbbrown/Code/go/src/github.com/bsphere/le_go/le.go:68 (0xd2999)
(*Logger).isOpenConnection: if logger.conn == nil {
/Users/mnbbrown/Code/go/src/github.com/bsphere/le_go/le.go:93 (0xd2c39)
(*Logger).ensureOpenConnection: if !logger.isOpenConnection() {
/Users/mnbbrown/Code/go/src/github.com/bsphere/le_go/le.go:173 (0xd339f)
(*Logger).Write: if err := logger.ensureOpenConnection(); err != nil {
/Users/mnbbrown/Code/go/src/github.com/bsphere/le_go/le.go:122 (0xd2ec7)
(*Logger).Output: _, err := logger.Write([]byte(s))
/Users/mnbbrown/Code/go/src/github.com/bsphere/le_go/le.go:158 (0xd32e0)
(*Logger).Println: logger.Output(2, fmt.Sprintln(v...))
/Users/mnbbrown/Code/go/src/bitbucket.org/mnbbrown/sewca/sewca.go:65 (0x3644)
SendEmail: logger.Println(l)
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/context.go:106 (0x35796)
(*Context).Next: c.handlers[c.index](c)
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/logger.go:19 (0x3b3a0)
func.007: c.Next()
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/context.go:106 (0x35796)
(*Context).Next: c.handlers[c.index](c)
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/recovery.go:96 (0x3bc8e)
func.010: c.Next()
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/context.go:106 (0x35796)
(*Context).Next: c.handlers[c.index](c)
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/logger.go:46 (0x3b4c9)
func.008: c.Next()
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/context.go:106 (0x35796)
(*Context).Next: c.handlers[c.index](c)
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/gin.go:197 (0x3b1aa)
func.004: c.Next()
/Users/mnbbrown/Code/go/src/github.com/julienschmidt/httprouter/router.go:276 (0x11f156)
(*Router).ServeHTTP: handle(w, req, ps)
/Users/mnbbrown/Code/go/src/github.com/gin-gonic/gin/gin.go:125 (0x37d59)
(*Engine).ServeHTTP: engine.router.ServeHTTP(w, req)
/usr/local/Cellar/go/1.3.3/libexec/src/pkg/net/http/server.go:1673 (0x5954f)
serverHandler.ServeHTTP: handler.ServeHTTP(rw, req)
/usr/local/Cellar/go/1.3.3/libexec/src/pkg/net/http/server.go:1174 (0x5702e)
(*conn).serve: serverHandler{c.server}.ServeHTTP(w, w.req)
/usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/proc.c:1445 (0x18540)
goexit: runtime·goexit(void)

Has this got something to do with access net.Conn from multiple goroutines?
Is there a more efficient way to stream text to a tcp connection?
Should the le_go library be written differently? 

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Gmane