[go-nuts] Re: mongodb driver for go

[Jérôme LAFORGE]

Sorry, mistyping:
We are using globalsign driver without problem in production. 
For your information, globalsign is fork of https://godoc.org/gopkg.in/mgo.v2 
since mgo.v2 is unmaintained. 

-- 
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] Go assembly interface calls

[robert engels]

Are there any examples of a hand-written assembly function that accepts an 
interface and then makes calls on the interface methods?

In reviewing the documentation, it seems impossible, as the PCDATA, and 
FUNCDATA are not documented, and thus, I think the GC scanner ends up barfing 
when these are omitted.

Although, since the interface is passed as a parameter, I would expect that the 
caller would retain the reference, so adding NO_LOCAL_POINTERS should suffice, 
but it is failing.

Any help would be appreciated. Thanks.

-- 
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: Machine readable https://golang.org/dl/

[Agniva De Sarker]

https://golang.org/dl/?mode=json

On Saturday, 15 December 2018 10:38:51 UTC+5:30, bolson wrote:
>
> I'm looking at the tables at https://golang.org/dl/ and hoping there's 
> data behind that which could be made visible. I'm hoping to write a script 
> for a build server such that nightly it could ensure it's running the 
> latest version of go1.*.linux-amd64.tar.gz
> https://golang.org/dl/index.json or so?
>

-- 
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] Machine readable https://golang.org/dl/

[bolson]

I'm looking at the tables at https://golang.org/dl/ and hoping there's data 
behind that which could be made visible. I'm hoping to write a script for a 
build server such that nightly it could ensure it's running the latest 
version of go1.*.linux-amd64.tar.gz
https://golang.org/dl/index.json or so?

-- 
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: mongodb driver for go

[Brian van den Broek]

On Friday, 14 December 2018 13:01:09 UTC-5, Badhmanaban M wrote:
>
> Hi, is there any native mongodb driver for golang
>

Mongodb is working on one. Beta1 was last 
week. https://github.com/mongodb/mongo-go-driver/releases

Best,

Brian vdB 

-- 
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] Pause failures, GC, & StopTheWorld

[robert engels]

Usually if it is hung doing an allocation, that means that the STW cannot 
complete, which means some go routine is in a tight loop no yielding to the 
scheduler.

The only other possibility (I would think) is if you placed a cap on the memory 
size of the process, and it is trying to allocate but cannot get any more 
memory for the OS, so it keeps trying to GC to free some memory - but this 
seems doubtful.

> On Dec 14, 2018, at 7:27 PM, Eric Hamilton  wrote:
> 
> I've captured a trace-- I don't yet have much experience with "go tool 
> trace", but certainly looks to me like it's hung doing an allocation and that 
> interferes with STW.
> 
> I've attached the trace.  Any thoughts?  Should I open an issue?
> 
> Thanks,
> Eric
> 
> 
> -- 
> 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] Go 1.11.4 and Go 1.10.7 are released

[Filippo Valsorda]

Hello gophers,

We have just released Go versions 1.11.4 and 1.10.7, minor point releases.

These releases include fixes to cgo, the compiler, linker, runtime,
documentation, go command, and the net/http and go/types packages.
They include a fix to a bug introduced in Go 1.11.3 and Go 1.10.6
that broke "go get" for import path patterns containing "...".

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.11.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.11.4" and build as usual.

Thanks to everyone who contributed to the release.

Alla prossima,
Filippo for the Go team

-- 
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: Zombie Child process not being claimed by wait

[Jason E. Aten]

Totally just a guess, but when I saw slow Process.Wait(), I was able to 
solve it by using syscall.wait4() directly per Ian's suggestion. Made a 
little library:

https://github.com/glycerine/bark

that will call
pid, err := syscall.Wait4(w.proc.Pid, &ws, syscall.WNOHANG, nil)


On Thursday, December 13, 2018 at 11:33:20 PM UTC-6, Rodrigo Toste Gomes 
wrote:
>
> I'm debugging an odd issue with Process.Wait, and wondering if anyone 
> would have any ideas / hit this before:
>
> I have a go process, which starts a child process (it sets DEATH_SIGNAL on 
> that process, not sure if it's relevant).
> Then, a background go routine runs Wait on that process in order to send a 
> signal to the main go routine which causes it to shutdown.
>
> A separate process sends `kill -9` to the child process, and then waits 
> until the go process exits.
> This separate process waits up to a minute before quitting, and erroring 
> out. We're reaching that timeout, and decided to look further into it.
>
> This is what we see:
> 1. The child process is a zombie
> 2. The go process is alive and well
> 3. The go process is wainting on the child process (we double checked the 
> pid)
> 4. It's stuck in this stack for that whole minute:
> ```
> goroutine 22 [syscall]:
> 
> 
>
> syscall.Syscall6(0xf7, 0x1, 0x136b, 0xc420034de8, 0x104, 0x0, 0x0, 
> 0x1000901, 0x0, 0x30)  
> 
> 
> 
> /nix/store/yvw2v009phsdwj191jm4j2wsk28b2gxx-go-1.9.2/share/go/src/syscall/asm_linux_amd64.s:44
>  
> +0x5 fp=0xc420034d90 sp=0xc420034d88 pc=0x4784e5
> 
>
> os.(*Process).blockUntilWaitable(0xc4200b4e10, 0xc420034ec8, 0x48e364, 
> 0x136b)
> 
> 
> 
> /nix/store/yvw2v009phsdwj191jm4j2wsk28b2gxx-go-1.9.2/share/go/src/os/wait_waitid.go:31
>  
> +0xa5 fp=0xc420034e98 sp=0xc420034d90 pc=0x493775  
> 
> 
> os.(*Process).wait(0xc4200b4e10, 0x0, 0x0, 0xc4200b4e10)  
> 
> 
> 
> 
> /nix/store/yvw2v009phsdwj191jm4j2wsk28b2gxx-go-1.9.2/share/go/src/os/exec_unix.go:22
>  
> +0x42 fp=0xc420034f20 sp=0xc420034e98 pc=0x48dd12  
> 
>   
> os.(*Process).Wait(0xc4200b4e10, 0xc4200b4e10, 0x0, 0x0)  
> 
> 
> 
> 
> /nix/store/yvw2v009phsdwj191jm4j2wsk28b2gxx-go-1.9.2/share/go/src/os/exec.go:115
>  
> +0x2b fp=0xc420034f50 sp=0xc420034f20 pc=0x48d33b  
> 
>   
> ```
> 5. This happens rarely, and only happens when the system is under a lot of 
> stress, so our best guess is that the system is taking a long time to 
> respond to the syscall (which is odd because we were able to abort the go 
> process, and run ps aux without issues - it doesn't look like a completely 
> stalled system), or some other issue.
>

-- 
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] How to add a new operator

[Jason E. Aten]

In order to see where the "expected operand" syntax error is coming from 
(it could be many places), add a panic
at the top of the error handling parser methods in 
go/src/cmd/compile/internal/syntax/parser.go's error handling routines, 
which may
be called variously parser.error(), parser.syntaxErrorAt(), 
parser.errorAt(), parser.error_at(), or parser.syntaxError(), or 
errorExpected() depending
on your Go version.  The panic will give you a stack trace, and you can go 
from there. e.g.

func (p *parser) error_at(pos src.Pos, msg string) { // for go1.9.7, this 
is line 112 of parser.go
panic("claygod's custom debug statement: error_at where??") // add this 
line
...

On Sunday, December 9, 2018 at 1:24:55 PM UTC-6, Claygod wrote:
>
> This is how I do it (and go/src/cmd/compile/internal/gc) , but I still get 
> errors "expected operand" .
> I would like a little more details from those who have already done this.
>
> воскресенье, 9 декабря 2018 г., 19:48:58 UTC+3 пользователь Aram 
> Hăvărneanu написал:
>>
>> Start with go/src/cmd/compile/internal/syntax and go from there. 
>>
>> -- 
>> Aram Hăvărneanu 
>>
>

-- 
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: mongodb driver for go

[oldCoderException]

We've been using this one in production for quite some 
time:  https://godoc.org/gopkg.in/mgo.v2
Interesting to see the MongoDB folks doing one now too.  :)

Paul

On Friday, 14 December 2018 10:01:09 UTC-8, Badhmanaban M wrote:
>
> Hi, is there any native mongodb driver for golang
>

-- 
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] Pure functions and Go2

['Axel Wagner' via golang-nuts]

On Fri, Dec 14, 2018 at 9:51 PM Michael Jones 
wrote:

> There is no absolute reason why a, b, and c could not be evaluated at
> compile time.
>

Being pure is not enough for that. You need at least pure and total -
otherwise you could have

pure func Foo(x int) int {
for {}
return x
}

However, (dis)proving totality is not possible (not even touching on the
fact that totality alone isn't even enough, when you also want speedy
compilation). So to actually get this to work, you'd need to restrict pure
functions to a non-turing-complete subset of Go (that is still useful),
which is pretty complex to do.

Especially given that the cases you mention (and all the cases I can think
of where I'd definitely want that to happen) are just inlining + constant
folding (+ maybe common subexpression elimination), Ians suggestion of
keeping this a compiler optimization seems more sensible.


> There are many practical reasons why it cannot be done today.
>
> If a function was labeled as pure ("pure func ...") the compiler would not
> even need think hard, and if purity were a reflectable attribute, then it
> is imaginable that compiling a function invocation could be:
>
> "if package is a standard one (like math) and the function is a pure one,
> then call func on argument and use the result here"
>
> Doing this for user packages brings up deeper issues and is harder.
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.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.
>

-- 
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: json and interface unmarshalling

[Sam Whited]

Hi,

In the future, please don't apply formatting when you're emailing code. Lots of 
people will have lots of different mail clients, and it's not always obvious 
how the colors will interact or whether they'll be readable against different 
backgrounds, or by people with various visual disabilities.

Plain text emails are your friend; everyone's individual client (including 
yours when you're composing it, probably) can style those in such a way that 
they'll be able to read it.

Thanks,
Sam

On Fri, Dec 14, 2018, at 13:24, Darko Luketic wrote:
> Of course after I ask my question I find the answer on my own.
> It's always like this.
> 
> The solution is to change
> 
> type MessageRequest struct {
>Typestring  `json:"type"`
>Payload json.RawMessage `json:"payload"`
> }
> 
> 
> So the payload isn't unmarshalled.
> 
> Now, after the MessageRequest is unmarshalled I can check for the type and 
> then
> 
> payload := new(model.ChatMessage)
> if e := json.Unmarshal(m.Payload, payload); e != nil {
>logrus.Error(e)
>return
> }
> 
> 
> 
> On Friday, December 14, 2018 at 8:17:25 PM UTC+1, Darko Luketic wrote:
> >
> > Hello,
> >
> > I'm sending messages over websocket.
> > I have a "generic" MessageRequest and MessageResponse struct.
> >
> > type MessageRequest struct {
> >Typestring  `json:"type"`
> >Payload interface{} `json:"payload"`
> > }
> >
> > type MessageResponse struct {
> >Typestring  `json:"type"`
> >Payload interface{} `json:"payload"`
> > }
> >
> >
> >
> > I'm trying to unmarshall this.
> >
> > m := new(MessageRequest)
> > if e := json.Unmarshal(msg, m); e != nil {
> >logrus.Error(e)
> >return
> > }
> >
> >
> > Then I switch by MessageRequest.Type to know what kind of message was sent 
> > by the client.
> >
> > However, when I do something like
> > payload, ok := m.Payload.(*MessageRequest)
> > if !ok {
> > //error
> > }
> >
> > It isn't compatible to type *MessageRequest
> > As a workaround I could imagine marshalling the interface again, then 
> > unmarshalling into the correct message payload type (e.g. ChatMessage)
> > But that is unnecessary overhead. However it beats marshalling into 
> > map[string]interface and manually assigning values in terms of code 
> > readability.
> >
> > tmp, e := json.Marshal(m.Payload)
> > if e != nil {
> >logrus.Error(e)
> >return
> > }
> > payload := new(model.ChatMessage)
> > if e := json.Unmarshal(tmp, payload); e != nil {
> >logrus.Error(e)
> >return
> > }
> >
> >
> >
> > vs
> >
> > pmap, ok := m.Payload.(map[string]interface{})
> > if !ok {
> >logrus.Error("can not convert to map[string]interface{}")
> >return
> > }
> > payload := new(model.ChatMessage)
> > user := pmap["user"].(string)
> > payload.User = user
> >
> > message := pmap["message"].(string)
> > payload.Message = message
> >
> > tme := pmap["time"].(string)
> > tmee, e := time.Parse(time.RFC3339, tme)
> > if e != nil {
> >logrus.Error("time parse error")
> >return
> > }
> > payload.Time = tmee
> >
> >
> > Is there a better solution to solve this?
> >
> >
> 
> -- 
> 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.


-- 
Sam Whited
s...@samwhited.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.

Re: [go-nuts] Pure functions and Go2

[Michael Jones]

I can't deny proposing it, but i'd much rather it be inferred...if fo no
other reason than because the developer could be wrong and that would be an
insidious flaw to debug.

I proposed it defensively so that the initial reactions might not all be
that it is to recognize purity as it was for Diogenes to find an honest man.

On Fri, Dec 14, 2018 at 1:28 PM Bakul Shah  wrote:

>
>
> > On Dec 14, 2018, at 1:17 PM, Michael Jones 
> wrote:
> >
> > I don't actually prefer marking a func as pure. best if it is a
> discovered attribute during compilation.
>
> You said
> > If a function was labeled as pure ("pure func ...") the compiler would
> not even need think hard
>
> I thought you were advocating this. Compilers can already discover
> non-mutating functions with some analysis. But the more such tricks a
> compiler discovers, the slower it becomes So there is some value
> in helping the compiler by marking functions as pure but I think the
> cost of doing so is language complexity that a user has to face.
>
> Personally I'd rather see Go become a better higher level language.
>
> >
> > Not sure what you mean about complexity. The compiler would not be
> obligated.
> >
> >
> > On Fri, Dec 14, 2018 at 1:12 PM Bakul Shah  wrote:
> > On Dec 14, 2018, at 12:50 PM, Michael Jones 
> wrote:
> > >
> > > Have been thinking about pure functions (in the Scheme sense of no
> externalities other than constants and pure functions and no side effects)
> in the context of weak metaprogramming and compiler optimization. Here is
> the idea.
> >
> > Scheme does permit impure functions. Such functions by *convention* have
> > a "!" suffix but there is nothing special about that.
> >
> > > :
> > > a := math.Sin(0.1234)
> > > :
> > > b := bits.RotateLeft64(0x12345678, 7)
> > > :
> > > func myFunc(x int) byte { return x>>2 }
> > > :
> > > c := myFunc(42):
> > >
> > > There is no absolute reason why a, b, and c could not be evaluated at
> compile time.
> > >
> > > There are many practical reasons why it cannot be done today.
> > >
> > > If a function was labeled as pure ("pure func ...") the compiler would
> not even need think hard, and if purity were a reflectable attribute, then
> it is imaginable that compiling a function invocation could be:
> >
> > This would complicate the language unnecessarily in the name
> > of optimization. Next on the slipper slope would be declaring
> > parameters "pure" and then having two versions of things. e.g.
> >
> > func intReduce(func(x, y int)int, []int) int
> >
> > This can be evaluated at compile time if the given func is pure.
> > Not worth it, IMHO.
> >
> > >
> > > "if package is a standard one (like math) and the function is a pure
> one, then call func on argument and use the result here"
> > >
> > > Doing this for user packages brings up deeper issues and is harder.
> > >
> > > --
> > > Michael T. Jones
> > > michael.jo...@gmail.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.
> >
> >
> >
> > --
> > Michael T. Jones
> > michael.jo...@gmail.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.
>
>

-- 

*Michael T. jonesmichael.jo...@gmail.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.

Re: [go-nuts] go assembly question

[robert engels]

Thanks, I have already replied - would of saved you the typing trouble. As I 
pointed out, the lack of register prefixes (which would screen AT&T at me), was 
what really confused me.

> On Dec 14, 2018, at 4:09 PM, Ian Denhardt  wrote:
> 
> If you pass `-M intel` to objdump it will display intel syntax.
> 
> Quoting robert engels (2018-12-14 16:41:39)
>>   but the operands are backwards according to MOVQ on Intel, it
>>   should be
>>   dst,src
>>   SO, I'm thinking "intermediate code", so different syntax. Fine, but
>>   then when I use objdump or otool, the assembly still looks backwards,
>>   but matches the above.
>>   Is this because LLVM is also "backwards" ?
> 
> It's not about intermediate code, Intel just uses different syntax than
> both the Go and GNU assemblers, which are descendants (in tradition, if
> not actual code) of the old AT&T assemblers. The AT&T syntax uses
> src,dst.
> 
>>   It there anyway to get objdump or otool to output intel assembly that
>>   matches their documentation ?
> 
> You can pass objdump `-M intel`.
> 
> -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.

-- 
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] go assembly question

[robert engels]

The tools all emit AT&T/amd syntax by default and you can use -M intel to get 
the intel format.

The confusing thing is that they don’t use the ‘register prefixes’, so it looks 
like intel but it is backwards.

Oh well.

> On Dec 14, 2018, at 3:41 PM, robert engels  wrote:
> 
> In the go assembly docs, for example:
> 
> 64-bit Intel 386 (a.k.a. amd64)
> 
> The two architectures behave largely the same at the assembler level. 
> Assembly code to access the m and gpointers on the 64-bit version is the same 
> as on the 32-bit 386, except it uses MOVQ rather than MOVL:
> 
> get_tls(CX)
> MOVQ  g(CX), AX // Move g into AX.
> MOVQ  g_m(AX), BX   // Move g.m into BX.
> but the operands are backwards according to MOVQ on Intel, it should be 
> dst,src
> 
> SO, I’m thinking “intermediate code”, so different syntax. Fine, but then 
> when I use objdump or otool, the assembly still looks backwards, but matches 
> the above.
> 
> Is this because LLVM is also “backwards” ?
> It there anyway to get objdump or otool to output intel assembly that matches 
> their documentation ?
> 
> Thanks.
> 
> -- 
> 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] go assembly question

[Ian Denhardt]

If you pass `-M intel` to objdump it will display intel syntax.

Quoting robert engels (2018-12-14 16:41:39)
>but the operands are backwards according to MOVQ on Intel, it
>should be
>dst,src
>SO, I'm thinking "intermediate code", so different syntax. Fine, but
>then when I use objdump or otool, the assembly still looks backwards,
>but matches the above.
>Is this because LLVM is also "backwards" ?

It's not about intermediate code, Intel just uses different syntax than
both the Go and GNU assemblers, which are descendants (in tradition, if
not actual code) of the old AT&T assemblers. The AT&T syntax uses
src,dst.

>It there anyway to get objdump or otool to output intel assembly that
>matches their documentation ?

You can pass objdump `-M intel`.

-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] Re: Q on using reflect: how to distinguish methods from functions?

[Jason E. Aten]

On Friday, December 14, 2018 at 2:45:44 PM UTC-6, Jason E. Aten wrote:
>
>
>
> On Friday, December 14, 2018 at 2:19:05 PM UTC-6, Kevin Malachowski wrote:
>>
>> Why do you need to figure out whether something is a Method? Usually it 
>> doesn't really matter.
>>
>> (I don't have an answer for you, but if you give more background I or 
>> someone else may be able to be more useful; trying to avoid the X-Y 
>> problem.)
>>
>
> It matters for translating Go calls (method and function) properly into 
> Lua calls:
>
>
> https://github.com/glycerine/luar/commit/eccbbe2e420d5a2cffb2a80e2dca1c31a5b89d7d
>  
>
>
For full context, here is a small example of what gijit/gi -- my Golang 
REPL that uses LuaJIT as its back end -- can do. This is calling back into 
the Go standard libraries such as "time" to use their functionality, even 
after having translated from Go -> Lua.  Go compiled code can be invoked 
from the interpreter, for speed. Even though LuaJIT is quite speedy, 
compiled Go code is usually faster. The fix I pointed to above makes the 
b.After(a) call work. Otherwise the 'a' argument was getting used 
twice/mixed up with 'b'.

~/go/src/github.com/gijit/gi (master) $ gi

gijit: a go interpreter, just-in-time.

https://github.com/gijit/gi
Copyright (c) 2018, Jason E. Aten. All rights reserved.
License: 3-clause BSD. See the LICENSE file at
https://github.com/gijit/gi/blob/master/LICENSE

  [ gijit/gi is an interactive Golang environment,
also known as a REPL or Read-Eval-Print-Loop.]
  [ at the gi> prompt, type ctrl-d to exit.]
  [ at the gi> :?   or :help for help.]
  [ $ gi -h for flag help, when first launching gijit.]
  [ $ gi -q to start quietly, without this banner.]

built: '2018-12-14T15:58:00-0600'
last-git-commit-hash: 'b3294722551defbd98a98ad09965f87b30337af6'
nearest-git-tag: 'v1.9.8'
git-branch: 'master'
go-version: 'go_version_go1.10.3_darwin/amd64'
luajit-version: 'LuaJIT_2.1.0-beta3+jea-int64-additions'
==
Using static prelude.
gi> import "time"

elapsed: '203.041µs'
gi> a := time.Now()

elapsed: '176.173µs'
gi> b := time.Now()

elapsed: '168.676µs'
gi> println(a.After(b))
false

elapsed: '173.885µs'
gi> println(b.After(a))
true

elapsed: '265.616µs'
gi> a
2018-12-14 16:05:16.799067846 -0600 CST m=+5.198567213

elapsed: '202.912µs'
gi>
 

-- 
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] go assembly question

[robert engels]

In the go assembly docs, for example:

64-bit Intel 386 (a.k.a. amd64)

The two architectures behave largely the same at the assembler level. Assembly 
code to access the m and gpointers on the 64-bit version is the same as on the 
32-bit 386, except it uses MOVQ rather than MOVL:

get_tls(CX)
MOVQg(CX), AX // Move g into AX.
MOVQg_m(AX), BX   // Move g.m into BX.
but the operands are backwards according to MOVQ on Intel, it should be dst,src

SO, I’m thinking “intermediate code”, so different syntax. Fine, but then when 
I use objdump or otool, the assembly still looks backwards, but matches the 
above.

Is this because LLVM is also “backwards” ?
It there anyway to get objdump or otool to output intel assembly that matches 
their documentation ?

Thanks.

-- 
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] Pure functions and Go2

[Bakul Shah]

> On Dec 14, 2018, at 1:17 PM, Michael Jones  wrote:
> 
> I don't actually prefer marking a func as pure. best if it is a discovered 
> attribute during compilation.

You said
> If a function was labeled as pure ("pure func ...") the compiler would not 
> even need think hard

I thought you were advocating this. Compilers can already discover
non-mutating functions with some analysis. But the more such tricks a
compiler discovers, the slower it becomes So there is some value
in helping the compiler by marking functions as pure but I think the
cost of doing so is language complexity that a user has to face.

Personally I'd rather see Go become a better higher level language.

> 
> Not sure what you mean about complexity. The compiler would not be obligated.
> 
> 
> On Fri, Dec 14, 2018 at 1:12 PM Bakul Shah  wrote:
> On Dec 14, 2018, at 12:50 PM, Michael Jones  wrote:
> > 
> > Have been thinking about pure functions (in the Scheme sense of no 
> > externalities other than constants and pure functions and no side effects) 
> > in the context of weak metaprogramming and compiler optimization. Here is 
> > the idea.
> 
> Scheme does permit impure functions. Such functions by *convention* have
> a "!" suffix but there is nothing special about that.
> 
> > :
> > a := math.Sin(0.1234)
> > :
> > b := bits.RotateLeft64(0x12345678, 7)
> > :
> > func myFunc(x int) byte { return x>>2 }
> > :
> > c := myFunc(42):
> > 
> > There is no absolute reason why a, b, and c could not be evaluated at 
> > compile time. 
> > 
> > There are many practical reasons why it cannot be done today.
> > 
> > If a function was labeled as pure ("pure func ...") the compiler would not 
> > even need think hard, and if purity were a reflectable attribute, then it 
> > is imaginable that compiling a function invocation could be:
> 
> This would complicate the language unnecessarily in the name
> of optimization. Next on the slipper slope would be declaring
> parameters "pure" and then having two versions of things. e.g.
> 
> func intReduce(func(x, y int)int, []int) int
> 
> This can be evaluated at compile time if the given func is pure.
> Not worth it, IMHO.
> 
> > 
> > "if package is a standard one (like math) and the function is a pure one, 
> > then call func on argument and use the result here" 
> > 
> > Doing this for user packages brings up deeper issues and is harder.
> > 
> > -- 
> > Michael T. Jones
> > michael.jo...@gmail.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.
> 
> 
> 
> -- 
> Michael T. Jones
> michael.jo...@gmail.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.

-- 
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] Pure functions and Go2

[Ian Denhardt]

Quoting Bakul Shah (2018-12-14 16:11:51)
> > If a function was labeled as pure ("pure func ...") the compiler
> > would not even need think hard, and if purity were a reflectable
> > attribute, then it is imaginable that compiling a function
> > invocation could be:
>
> This would complicate the language unnecessarily in the name
> of optimization. Next on the slipper slope would be declaring
> parameters "pure" and then having two versions of things. e.g.
>
> func intReduce(func(x, y int)int, []int) int
>
> This can be evaluated at compile time if the given func is pure.
> Not worth it, IMHO.

A lot of this can also probably be inferred by the compiler, and then be
just part of the optimizer that isn't exposed to users. Functions only
composed of pure operations are pure, and when a compiler spots this it
can tag the function with some metadata, so it can tell when looking at
a function at a call site whether it is pure.

-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] Pure functions and Go2

[Michael Jones]

I don't actually prefer marking a func as pure. best if it is a discovered
attribute during compilation.

Not sure what you mean about complexity. The compiler would not be
obligated.


On Fri, Dec 14, 2018 at 1:12 PM Bakul Shah  wrote:

> On Dec 14, 2018, at 12:50 PM, Michael Jones 
> wrote:
> >
> > Have been thinking about pure functions (in the Scheme sense of no
> externalities other than constants and pure functions and no side effects)
> in the context of weak metaprogramming and compiler optimization. Here is
> the idea.
>
> Scheme does permit impure functions. Such functions by *convention* have
> a "!" suffix but there is nothing special about that.
>
> > :
> > a := math.Sin(0.1234)
> > :
> > b := bits.RotateLeft64(0x12345678, 7)
> > :
> > func myFunc(x int) byte { return x>>2 }
> > :
> > c := myFunc(42):
> >
> > There is no absolute reason why a, b, and c could not be evaluated at
> compile time.
> >
> > There are many practical reasons why it cannot be done today.
> >
> > If a function was labeled as pure ("pure func ...") the compiler would
> not even need think hard, and if purity were a reflectable attribute, then
> it is imaginable that compiling a function invocation could be:
>
> This would complicate the language unnecessarily in the name
> of optimization. Next on the slipper slope would be declaring
> parameters "pure" and then having two versions of things. e.g.
>
> func intReduce(func(x, y int)int, []int) int
>
> This can be evaluated at compile time if the given func is pure.
> Not worth it, IMHO.
>
> >
> > "if package is a standard one (like math) and the function is a pure
> one, then call func on argument and use the result here"
> >
> > Doing this for user packages brings up deeper issues and is harder.
> >
> > --
> > Michael T. Jones
> > michael.jo...@gmail.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.
>
>

-- 

*Michael T. jonesmichael.jo...@gmail.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.

Re: [go-nuts] Pure functions and Go2

[Bakul Shah]

On Dec 14, 2018, at 12:50 PM, Michael Jones  wrote:
> 
> Have been thinking about pure functions (in the Scheme sense of no 
> externalities other than constants and pure functions and no side effects) in 
> the context of weak metaprogramming and compiler optimization. Here is the 
> idea.

Scheme does permit impure functions. Such functions by *convention* have
a "!" suffix but there is nothing special about that.

> :
> a := math.Sin(0.1234)
> :
> b := bits.RotateLeft64(0x12345678, 7)
> :
> func myFunc(x int) byte { return x>>2 }
> :
> c := myFunc(42):
> 
> There is no absolute reason why a, b, and c could not be evaluated at compile 
> time. 
> 
> There are many practical reasons why it cannot be done today.
> 
> If a function was labeled as pure ("pure func ...") the compiler would not 
> even need think hard, and if purity were a reflectable attribute, then it is 
> imaginable that compiling a function invocation could be:

This would complicate the language unnecessarily in the name
of optimization. Next on the slipper slope would be declaring
parameters "pure" and then having two versions of things. e.g.

func intReduce(func(x, y int)int, []int) int

This can be evaluated at compile time if the given func is pure.
Not worth it, IMHO.

> 
> "if package is a standard one (like math) and the function is a pure one, 
> then call func on argument and use the result here" 
> 
> Doing this for user packages brings up deeper issues and is harder.
> 
> -- 
> Michael T. Jones
> michael.jo...@gmail.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.

-- 
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] Pure functions and Go2

[Michael Jones]

Have been thinking about pure functions (in the Scheme sense of no
externalities other than constants and pure functions and no side effects)
in the context of weak metaprogramming and compiler optimization. Here is
the idea.

:
a := math.Sin(0.1234)
:
b := bits.RotateLeft64(0x12345678, 7)
:
func myFunc(x int) byte { return x>>2 }
:
c := myFunc(42):

There is no absolute reason why a, b, and c could not be evaluated at
compile time.

There are many practical reasons why it cannot be done today.

If a function was labeled as pure ("pure func ...") the compiler would not
even need think hard, and if purity were a reflectable attribute, then it
is imaginable that compiling a function invocation could be:

"if package is a standard one (like math) and the function is a pure one,
then call func on argument and use the result here"

Doing this for user packages brings up deeper issues and is harder.

-- 

*Michael T. jonesmichael.jo...@gmail.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.

[go-nuts] Re: Q on using reflect: how to distinguish methods from functions?

[Jason E. Aten]

On Friday, December 14, 2018 at 2:19:05 PM UTC-6, Kevin Malachowski wrote:
>
> Why do you need to figure out whether something is a Method? Usually it 
> doesn't really matter.
>
> (I don't have an answer for you, but if you give more background I or 
> someone else may be able to be more useful; trying to avoid the X-Y 
> problem.)
>

It matters for translating Go calls (method and function) properly into Lua 
calls:

https://github.com/glycerine/luar/commit/eccbbe2e420d5a2cffb2a80e2dca1c31a5b89d7d
 



-- 
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] Homoiconic metaprogramming in Go

[Michael Jones]

I've been thinking about a related idea for the past while ... "pure
functions" ... i'll post an email about it now.

On Fri, Dec 14, 2018 at 6:06 AM roger peppe  wrote:

> On Fri, 14 Dec 2018 at 14:01,  wrote:
>
>> Not sure where you got this impression - commands run by go generate have
>> only the OS environment. They are just ordinary commands, as might be run
>> by any shell script, just the calls to them are integrated into the Go
>> tooling.
>>
>> Tools that seem to access go syntax trees and the like? They are simply
>> using the parser and AST tools made available by Go to parse go code, and
>> that can be done at any time, not just during go generate.
>>
>
> Yup. How is that not metaprogramming though?
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.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.

Re: [go-nuts] Plan9 reborn as a guest OS atop of Golang runtime

[Michael Jones]

I think we should have an effort to gather learnings from these efforts and
make Go2 proposals as appropriate. Perhaps best done simply by encouraging
these developers to say what they need changed, added, or removed and why.

On Fri, Dec 14, 2018 at 11:11 AM ct via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Michael,
>
> Thanks for mentioning Biscuit. I saw the paper a while back and have been
> toying with the idea of combining it it with the GoKrazy userland (
> https://gokrazy.org/) to produce a small, pure-Go OS of some kind.
>
>
> Best regards,
> Charlton Trezevant
>
>
> On Monday, December 10, 2018 at 9:24:43 PM UTC, Michael Jones wrote:
>>
>> Read about Biscuit:
>> https://pdos.csail.mit.edu/papers/biscuit.pdf
>>
>> https://www.usenix.org/sites/default/files/conference/protected-files/osdi18_slides_cutler.pdf
>>
>> This is encouraging--smart people making the most of Go in a new area, as
>> it is today, without an active iterative feedback loop. Several ideas they
>> want could be changed in Go with sufficient will (the reservation notion
>> for example).
>>
>> This says to me that that what you want could happen.
>>
>>
>> On Mon, Dec 10, 2018 at 9:53 AM Dmitry Ponyatov 
>> wrote:
>>
>>> Can Plan9 reborn as a *guest* OS atop of Golang runtime?
>>>
>>> Maybe somebody works on a clustering system can expand Go runtime to
>>> natively and transparently run over Beowulf-style message passing clusters?
>>>
>>> --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>>
>> *Michael T. jonesmichae...@gmail.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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.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.

[go-nuts] Re: mongodb driver for go

[Jérôme LAFORGE]

Hello,
We also use this driver https://godoc.org/github.com/globalsign/mgo in 
production with pb. 

-- 
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] Q on using reflect: how to distinguish methods from functions?

[Kevin Malachowski]

Why do you need to figure out whether something is a Method? Usually it doesn't 
really matter.

(I don't have an answer for you, but if you give more background I or someone 
else may be able to be more useful; trying to avoid the X-Y problem.)

-- 
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] Q on using reflect: how to distinguish methods from functions?

[Jason E. Aten]

I need to figure out if a reflect.Value that is a function (Func) has a 
receiver (i.e. it is a method) or if the Func is just a plain function with 
no receiver in its signature.

Here's what I came up (which does appear to solve the question in the 
limited cases I've tested)... but I'm wondering if there is a faster and/or 
guaranteed reliable approach that doesn't feel quite so hacky with the 
string comparison:

import (
"runtime"
"reflect"
...
)
...
func getFunctionName(fun reflect.Value) string {
   return runtime.FuncForPC(fun.Pointer()).Name()
}

func main() {

isMethod := getFunctionName(v) == "reflect.methodValueCall"
...
}

Is there a better way?  Thanks!

-- 
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] Presidence of Operators

[fgergo]

(please reply to the list, so others with a similar question can find
this thread.)

I'm sorry, I should have made it clear: for me it's hard to parse the question.
I'll try again: could you please write 1 working example in
play.golang.org with the assumed precedence rules?
If you could share a link to that example in your reply, that would
help clarify the question. (Use the share button on play.golang.org to
show a link to be shared.)

On 12/14/18, 伊藤和也  wrote:
> OUnary operators have the highest precedence.
> According to go language specification, unary operators have the highest
> precedence means binary operators are the 2nd highest precedence maybe.
> and binary operators also have the precedence in 5 levels. When I use
> parentheses with unary operators, unary operators are evaluated first and
> when I use parentheses with binary operators,  parentheses are evaluated
> first.
> Example of parentheses with binary operators
>
> fmt.Println(false && (false || true))
>
> fmt.Println(false && false || true)
>
> There is no example of  parentheses with unary operators.
> Yes, parenthesis isn't an operator, it's a punctuation.
> So can I say the precedence of parethesis which is a parenthesis is lower
> than unary operators and
> higher than binary operators.
> unary operators  (high)
>↑
> parentheses   ↑
>↑
> binary operators  (low)
> 2018年12月14日(金) 19:15 :
>
>> Could you please give 2 examples, where the results depend on the
>> precedence? Maybe on play.golang.org ?
>> Maybe this also helps: https://golang.org/ref/spec#Operators
>>
>> On 12/14/18, 伊藤和也  wrote:
>> > Can I say the precedence of paretheses are lower than unary operators
>> > and
>> > higher than binary operators.
>> > unary operators  (high)
>> >   ↑
>> >   parentheses ↑
>> > ↑
>> > binary operators  (low)
>> >
>> > --
>> > 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: json and interface unmarshalling

[Darko Luketic]

Of course after I ask my question I find the answer on my own.
It's always like this.

The solution is to change

type MessageRequest struct {
   Typestring  `json:"type"`
   Payload json.RawMessage `json:"payload"`
}


So the payload isn't unmarshalled.

Now, after the MessageRequest is unmarshalled I can check for the type and 
then

payload := new(model.ChatMessage)
if e := json.Unmarshal(m.Payload, payload); e != nil {
   logrus.Error(e)
   return
}



On Friday, December 14, 2018 at 8:17:25 PM UTC+1, Darko Luketic wrote:
>
> Hello,
>
> I'm sending messages over websocket.
> I have a "generic" MessageRequest and MessageResponse struct.
>
> type MessageRequest struct {
>Typestring  `json:"type"`
>Payload interface{} `json:"payload"`
> }
>
> type MessageResponse struct {
>Typestring  `json:"type"`
>Payload interface{} `json:"payload"`
> }
>
>
>
> I'm trying to unmarshall this.
>
> m := new(MessageRequest)
> if e := json.Unmarshal(msg, m); e != nil {
>logrus.Error(e)
>return
> }
>
>
> Then I switch by MessageRequest.Type to know what kind of message was sent 
> by the client.
>
> However, when I do something like
> payload, ok := m.Payload.(*MessageRequest)
> if !ok {
> //error
> }
>
> It isn't compatible to type *MessageRequest
> As a workaround I could imagine marshalling the interface again, then 
> unmarshalling into the correct message payload type (e.g. ChatMessage)
> But that is unnecessary overhead. However it beats marshalling into 
> map[string]interface and manually assigning values in terms of code 
> readability.
>
> tmp, e := json.Marshal(m.Payload)
> if e != nil {
>logrus.Error(e)
>return
> }
> payload := new(model.ChatMessage)
> if e := json.Unmarshal(tmp, payload); e != nil {
>logrus.Error(e)
>return
> }
>
>
>
> vs
>
> pmap, ok := m.Payload.(map[string]interface{})
> if !ok {
>logrus.Error("can not convert to map[string]interface{}")
>return
> }
> payload := new(model.ChatMessage)
> user := pmap["user"].(string)
> payload.User = user
>
> message := pmap["message"].(string)
> payload.Message = message
>
> tme := pmap["time"].(string)
> tmee, e := time.Parse(time.RFC3339, tme)
> if e != nil {
>logrus.Error("time parse error")
>return
> }
> payload.Time = tmee
>
>
> Is there a better solution to solve this?
>
>

-- 
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] json and interface unmarshalling

[Darko Luketic]

Hello,

I'm sending messages over websocket.
I have a "generic" MessageRequest and MessageResponse struct.

type MessageRequest struct {
   Typestring  `json:"type"`
   Payload interface{} `json:"payload"`
}

type MessageResponse struct {
   Typestring  `json:"type"`
   Payload interface{} `json:"payload"`
}



I'm trying to unmarshall this.

m := new(MessageRequest)
if e := json.Unmarshal(msg, m); e != nil {
   logrus.Error(e)
   return
}


Then I switch by MessageRequest.Type to know what kind of message was sent 
by the client.

However, when I do something like
payload, ok := m.Payload.(*MessageRequest)
if !ok {
//error
}

It isn't compatible to type *MessageRequest
As a workaround I could imagine marshalling the interface again, then 
unmarshalling into the correct message payload type (e.g. ChatMessage)
But that is unnecessary overhead. However it beats marshalling into 
map[string]interface and manually assigning values in terms of code 
readability.

tmp, e := json.Marshal(m.Payload)
if e != nil {
   logrus.Error(e)
   return
}
payload := new(model.ChatMessage)
if e := json.Unmarshal(tmp, payload); e != nil {
   logrus.Error(e)
   return
}



vs

pmap, ok := m.Payload.(map[string]interface{})
if !ok {
   logrus.Error("can not convert to map[string]interface{}")
   return
}
payload := new(model.ChatMessage)
user := pmap["user"].(string)
payload.User = user

message := pmap["message"].(string)
payload.Message = message

tme := pmap["time"].(string)
tmee, e := time.Parse(time.RFC3339, tme)
if e != nil {
   logrus.Error("time parse error")
   return
}
payload.Time = tmee


Is there a better solution to solve this?

-- 
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] Plan9 reborn as a guest OS atop of Golang runtime

[ct via golang-nuts]

Michael, 

Thanks for mentioning Biscuit. I saw the paper a while back and have been 
toying with the idea of combining it it with the GoKrazy userland (
https://gokrazy.org/) to produce a small, pure-Go OS of some kind.


Best regards,
Charlton Trezevant


On Monday, December 10, 2018 at 9:24:43 PM UTC, Michael Jones wrote:
>
> Read about Biscuit:
> https://pdos.csail.mit.edu/papers/biscuit.pdf
>
> https://www.usenix.org/sites/default/files/conference/protected-files/osdi18_slides_cutler.pdf
>
> This is encouraging--smart people making the most of Go in a new area, as 
> it is today, without an active iterative feedback loop. Several ideas they 
> want could be changed in Go with sufficient will (the reservation notion 
> for example).
>
> This says to me that that what you want could happen.
>
>
> On Mon, Dec 10, 2018 at 9:53 AM Dmitry Ponyatov  > wrote:
>
>> Can Plan9 reborn as a *guest* OS atop of Golang runtime?
>>
>> Maybe somebody works on a clustering system can expand Go runtime to 
>> natively and transparently run over Beowulf-style message passing clusters?
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@gmail.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.

[go-nuts] Re: mongodb driver for go

[scott.lhommedieu via golang-nuts]

Hi,
There is a driver available here 
.  It has recently reached 
a beta release and the team is looking for input and feedback.
Also, head over to the MongoDB GO Driver google group 
 to share your 
experience and get help.

Scott
Product @ MongoDB, Drivers

On Friday, December 14, 2018 at 11:01:09 AM UTC-7, Badhmanaban M wrote:
>
> Hi, is there any native mongodb driver for golang
>

-- 
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] A Numeric Type for Go?

[Burak Serdar]

On Fri, Dec 14, 2018 at 11:00 AM  wrote:
>
> When programmers complain about the lack of generics in Go, a common 
> mitigation proposed is to use a interface. In many cases, it's possible to 
> find an operation common to all the types to be supported; in the worst case, 
> an empty interface can be used.
>
> This doesn't satisfy many Go programmers, so a proposal for generic types has 
> been made, containing the contract keyword:
>
>
> contract Ordinal(t T) {
> t < t
> }
>
>
> So a contract looks basically like an interface, which doesn't require a type 
> to implement a certain method, but to support the use of certain operations 
> on it.
>
> When I think of operations and types that apply to them in Go, the following 
> categories come to my mind:
>
>
> Equality, expressed by == and !=, which is supported by most Go expressions.
> +, which adds up numbers and concatenates strings.
> Other operations for arithmetics and comparison: -, *, /, %, <, >, <=, >=.
> Accessors and qualifiers: . and []
>
>
> Complaints about the lack of generics in Go are often heard from programmers 
> that want to implement numeric libraries. They basically want a type, which 
> support the operations of the first three categories, which are basically the 
> numeric types: integer, floating point and complex numbers.
>
>
> So an abstract "numeric" or "number" type could eliminate a lot of the use 
> cases for contracts. Is this an option being considered? Or isn't there just 
> any benefit over using the double type for numeric computations?


I had the similar idea a while ago and wrote this up, but with
contracts expressed as existing types instead of a numeric interface:

https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3

There's been a lot of discussion about the generics proposal:

https://github.com/golang/go/wiki/Go2GenericsFeedback

>
>
> Patrick
>
> --
> 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: Add/Set URL Parameters on the http.Request struct

[tevin]

Thank you very much

-- 
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] A Numeric Type for Go?

[patrick . bucher87]

When programmers complain about the lack of generics in Go, a common 
mitigation proposed is to use a interface. In many cases, it's possible to 
find an operation common to all the types to be supported; in the worst 
case, an empty interface can be used.

This doesn't satisfy many Go programmers, so a proposal for generic types 
has been made, containing the contract keyword:


contract Ordinal(t T) {
t < t
}
 

So a contract looks basically like an interface, which doesn't require a 
type to implement a certain method, but to support the use of certain 
operations on it.

When I think of operations and types that apply to them in Go, the 
following categories come to my mind:



   1. Equality, expressed by == and !=, which is supported by most Go 
   expressions.
   2. +, which adds up numbers and concatenates strings.
   3. Other operations for arithmetics and comparison: -, *, /, %, <, >, 
   <=, >=.
   4. Accessors and qualifiers: . and []


Complaints about the lack of generics in Go are often heard from 
programmers that want to implement numeric libraries. They basically want a 
type, which support the operations of the first three categories, which are 
basically the numeric types: integer, floating point and complex numbers.


So an abstract "numeric" or "number" type could eliminate a lot of the use 
cases for contracts. Is this an option being considered? Or isn't there 
just any benefit over using the double type for numeric computations?


Patrick

-- 
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] mongodb driver for go

[Badhmanaban M]

Hi, is there any native mongodb driver for golang

-- 
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] Versioning golang.org/x/foo packages

[David Riley]

Oh man, I searched in vain for any kind of discussion exactly like that issue. 
Your Google-fu is clearly superior to mine. Thanks! :-)

> On Dec 14, 2018, at 10:08 AM, Paul Jolly  wrote:
> 
> Just to briefly note the discussion in
> https://github.com/golang/go/issues/27858 (and other issues linked
> within that one).

-- 
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: Unix binary installations for Go

['Rudolf Polzer' via golang-nuts]

On Fri, Dec 14, 2018 at 10:44 AM Ronny Bangsund 
wrote:

> Which Unix/derivative? The great thing about them is that they have so
> many standards to choose from ;)
>

Linux, and it should support the FHS :)


>
> "go build" isn't sufficient for most of my projects, if I want proper
> distribution of binaries. I might use "go generate" to create some
> data/source a program depends on, and I always embed the version tag as
> returned by "git describe --tags  --abbrev=0"  in the binaries with
> the -X flag. That requires a build script of some sort.
>

Yeah, that too.



>
> If you package with any common Linux distro's tools it's expected that the
> packager has a full build environment. It would of course be useful if you
> included a script to "go get" everything the build needs, and that can
> usually be done in pre-build hooks in these packaging systems.
>

Right, but the thing is - distribution packagers may be OK to have to do
some adjustments; I mainly want to target users who want to build and
install the tool "just like any other tool". Basically, the user shouldn't
notice that it's written in Go - it shouldn't be weird compared to anything
else they compile and install.



>
> If you're building server apps maybe you'd consider packaging as
> containers instead. If they're command line tools you're still going to
> have to consider the target OS and its conventions, but you can make the
> binary quite self-sufficient with per-platform source files or/and go
> generated settings, so that they look for or create a configuration file.
>
> I don't think the packaging itself is a problem, as there are tools like
> dh-make-golang to massage Go into Debian-derivative packages. You just need
> to specify and dependencies like databases, discovery services and so on
> you require.
>

dh-make-golang is actually a good hint, I'll have to check what that does -
whether that e.g. uses something like I want, or contains all logic in
itself.



>
> For my own stuff I make the programs themselves flexible enough that there
> aren't any hard requirements for configuration files and their locations,
> but Linux builds have a fallback to /etc// for server stuff,
> $HOME/./ for CLI tools, and macOS builds use
> $HOME/Library/Application Support//. I always leave in the option
> to specify an alternative path via -C or --config.
>

Even with that, I still want an install procedure that supports stuff like
--prefix and installs there. Config files indeed are the smallest problem
(and if I want, I can even rely on XDG for their locations rather than
using the --prefix).



>
> The config files define where to load all the other data and any logging
> options (/var/ and /log/ are possibilities there).
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/ycHR0LkdhL0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
No need to handle this message off-hours. E-Mail isn't realtime
communication. IM if urgent.
Default Borgmon graphs to Dygraph: go/nebgua-dygraph-extension
No more "borgcfg production/borg/.../foo.borg update"! Just run uborgcfg!
go/uborgcfg

-- 
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: Unix binary installations for Go

[Ronny Bangsund]

Which Unix/derivative? The great thing about them is that they have so many 
standards to choose from ;)

"go build" isn't sufficient for most of my projects, if I want proper 
distribution of binaries. I might use "go generate" to create some 
data/source a program depends on, and I always embed the version tag as 
returned by "git describe --tags  --abbrev=0"  in the binaries with 
the -X flag. That requires a build script of some sort.

If you package with any common Linux distro's tools it's expected that the 
packager has a full build environment. It would of course be useful if you 
included a script to "go get" everything the build needs, and that can 
usually be done in pre-build hooks in these packaging systems.

If you're building server apps maybe you'd consider packaging as containers 
instead. If they're command line tools you're still going to have to 
consider the target OS and its conventions, but you can make the binary 
quite self-sufficient with per-platform source files or/and go generated 
settings, so that they look for or create a configuration file.

I don't think the packaging itself is a problem, as there are tools like 
dh-make-golang to massage Go into Debian-derivative packages. You just need 
to specify and dependencies like databases, discovery services and so on 
you require.

For my own stuff I make the programs themselves flexible enough that there 
aren't any hard requirements for configuration files and their locations, 
but Linux builds have a fallback to /etc// for server stuff, 
$HOME/./ for CLI tools, and macOS builds use 
$HOME/Library/Application Support//. I always leave in the option 
to specify an alternative path via -C or --config.

The config files define where to load all the other data and any logging 
options (/var/ and /log/ are possibilities there).

-- 
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] Versioning golang.org/x/foo packages

[Paul Jolly]

Just to briefly note the discussion in
https://github.com/golang/go/issues/27858 (and other issues linked
within that one).
On Fri, 14 Dec 2018 at 15:00, David Riley  wrote:
>
> Hi all,
>
> We're building with go 1.10.x and dep for a project at work, and having been 
> bitten twice in the space of a week with unversioned upstream executables 
> fetched via "go get" causing strife with versioned vendor code fetched by 
> "dep", we've been working on making our build environment hermetic (we'll be 
> moving to modules soon when we move to 1.11, especially because we use 
> Artifactory, which supports vgo registries so we can protect our build chain, 
> but for now we're stuck with dep).
>
> Our common solution for this is to make sure the tool is put in the 
> "required" stanza in Gopkg.toml, then running "dep ensure" to make sure it 
> ends up in the Gopkg.lock file so the Docker build can pick it up when it 
> runs "dep ensure --vendor-only". This works pretty well for protoc-gen-go 
> from protobuf and mockgen (the two tools that broke our build this past 
> week), but I also want to do the same for goyacc, which lives in 
> golang.org/x/tools.
>
> I notice that nothing from the golang.org repository is at all versioned, so 
> as far as I can tell, it all comes from the master branch.  How do I version 
> these to ensure that they don't break with older/other Go versions?  Is there 
> some sort of guarantee that they'll work at least n revisions back?  I'm 
> already extremely skeptical about the practice of just fetching all packages 
> from git repositories, given how easy it is to slip malicious code in that 
> way, so requiring a "go get" for those tools doesn't exactly give me the warm 
> and fuzzies.
>
>
> - Dave
>
> --
> 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] Versioning golang.org/x/foo packages

[David Riley]

Hi all,

We're building with go 1.10.x and dep for a project at work, and having been 
bitten twice in the space of a week with unversioned upstream executables 
fetched via "go get" causing strife with versioned vendor code fetched by 
"dep", we've been working on making our build environment hermetic (we'll be 
moving to modules soon when we move to 1.11, especially because we use 
Artifactory, which supports vgo registries so we can protect our build chain, 
but for now we're stuck with dep).

Our common solution for this is to make sure the tool is put in the "required" 
stanza in Gopkg.toml, then running "dep ensure" to make sure it ends up in the 
Gopkg.lock file so the Docker build can pick it up when it runs "dep ensure 
--vendor-only". This works pretty well for protoc-gen-go from protobuf and 
mockgen (the two tools that broke our build this past week), but I also want to 
do the same for goyacc, which lives in golang.org/x/tools.

I notice that nothing from the golang.org repository is at all versioned, so as 
far as I can tell, it all comes from the master branch.  How do I version these 
to ensure that they don't break with older/other Go versions?  Is there some 
sort of guarantee that they'll work at least n revisions back?  I'm already 
extremely skeptical about the practice of just fetching all packages from git 
repositories, given how easy it is to slip malicious code in that way, so 
requiring a "go get" for those tools doesn't exactly give me the warm and 
fuzzies.


- Dave

-- 
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] Homoiconic metaprogramming in Go

[roger peppe]

On Fri, 14 Dec 2018 at 14:01,  wrote:

> Not sure where you got this impression - commands run by go generate have
> only the OS environment. They are just ordinary commands, as might be run
> by any shell script, just the calls to them are integrated into the Go
> tooling.
>
> Tools that seem to access go syntax trees and the like? They are simply
> using the parser and AST tools made available by Go to parse go code, and
> that can be done at any time, not just during go generate.
>

Yup. How is that not metaprogramming though?

-- 
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] Homoiconic metaprogramming in Go

[howardcshaw]

Not sure where you got this impression - commands run by go generate have 
only the OS environment. They are just ordinary commands, as might be run 
by any shell script, just the calls to them are integrated into the Go 
tooling.

Tools that seem to access go syntax trees and the like? They are simply 
using the parser and AST tools made available by Go to parse go code, and 
that can be done at any time, not just during go generate.

Howard

On Friday, December 14, 2018 at 3:40:40 AM UTC-6, rog wrote:
>
> To answer your original question, yes, it is possible to do 
> metaprogramming in Go, although not at compile time.
>
> That's essentially what the go generate command is about - a command run 
> by go generate has access to parsed syntax trees, type information and 
> anything else it likes (bar actual compiler internals), and can generate 
> whatever code it likes.
>
> For example, I think it's pretty clear that what the Wire project does 
> (see https://github.com/google/wire/blob/master/docs/guide.md) is 
> metaprogramming, to some degree or other.
>
>   cheers,
> rog.
>
>> -- 
>>
>>

-- 
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] Presidence of Operators

[fgergo]

Could you please give 2 examples, where the results depend on the
precedence? Maybe on play.golang.org ?
Maybe this also helps: https://golang.org/ref/spec#Operators

On 12/14/18, 伊藤和也  wrote:
> Can I say the precedence of paretheses are lower than unary operators and
> higher than binary operators.
> unary operators  (high)
>   ↑
>   parentheses ↑
> ↑
> binary operators  (low)
>
> --
> 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] Presidence of Operators

[Jan Mercl]

On Fri, Dec 14, 2018 at 7:45 AM 伊藤和也  wrote:

> Can I say the precedence of paretheses are lower than unary operators and
higher than binary operators.

As parenthesis are not operators they have no operator precedence. But see:
https://golang.org/ref/spec#Order_of_evaluation


Explicit parentheses affect the evaluation by overriding the default
associativity. In the expression x + (y + z) the addition y + z is
performed before adding x.


-- 

-j

-- 
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] Homoiconic metaprogramming in Go

[roger peppe]

On Fri, 14 Dec 2018 at 05:25, Dmitry Ponyatov  wrote:

> Is it possible to do metaprogramming in Go?
>
> What I want to have is a way to run arbitrary code in compile time, which
> has full access to compiler data structures
> (parsed syntax trees, compiler stages callbacks, direct code generator
> calls).
>
> As a variant, it can be some Lisp system runs between parser stage and the
> rest of  Go compiler.
>

To answer your original question, yes, it is possible to do metaprogramming
in Go, although not at compile time.

That's essentially what the go generate command is about - a command run by
go generate has access to parsed syntax trees, type information and
anything else it likes (bar actual compiler internals), and can generate
whatever code it likes.

For example, I think it's pretty clear that what the Wire project does (see
https://github.com/google/wire/blob/master/docs/guide.md) is
metaprogramming, to some degree or other.

  cheers,
rog.

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