Re: [go-nuts] How to use build tags with go run

[Gert]

Thanks :) working 

On Monday, September 14, 2020 at 5:12:47 AM UTC+2 Kurtis Rader wrote:

> I'll bet that `go run -tags local .` works. Because `go run` allows 
> arguments after the package name that are passed to the program you have to 
> specify build flags before the package name.
>
> On Sun, Sep 13, 2020 at 8:07 PM Gert  wrote:
>
>> // +build local
>>
>> This works for
>> go build -tags local
>> go test -tags local
>>
>> But for some reason go run ignores the local tag?
>> go run . -tags local
>>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/071b3e6c-1bea-447c-9311-5a357f5a2e57n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/071b3e6c-1bea-447c-9311-5a357f5a2e57n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3d64b3bd-bf1a-44a8-8cc0-d7a2aa785ad4n%40googlegroups.com.

[go-nuts] How to use build tags with go run

[Gert]

// +build local

This works for
go build -tags local
go test -tags local

But for some reason go run ignores the local tag?
go run . -tags local

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/071b3e6c-1bea-447c-9311-5a357f5a2e57n%40googlegroups.com.

Re: [go-nuts] var fn myHandler = func(){ fn }

[Gert]

On Sunday, July 12, 2020 at 9:33:43 PM UTC+2 ba...@iitbombay.org wrote:

> The issue is that fn's type can't be completely determined until 
> the RHS func is fully analyzed but for that to work fn must be 
> known! This is not a problem when a "const" function references 
> itself as in `func foo() { ... foo() ... }`. 
>
> Also note that the first definition won't do what you may be thinking 
> it does. The`fn.GET` call will be to the existing value of fn, not 
> the result of the assignment. 
>

Ok 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4c921c21-906b-463b-9df6-08951ed8488dn%40googlegroups.com.

[go-nuts] var fn myHandler = func(){ fn }

[Gert]

https://play.golang.org/p/6xMgjr1IyFD

var fn myHandler
fn = func(w http.ResponseWriter, r *http.Request) {
  fn.GET(w, r)
}

Just wondering if it's possible somehow to write this in one line like so

var fn myHandler = func(w http.ResponseWriter, r *http.Request) {
  fn.GET(w, r)
}

and if that would break Go if it was allowed to do 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/87d4b11d-2c74-4416-a18d-6cda83f84003n%40googlegroups.com.

[go-nuts] [generics] go vet -generic flag

[Gert]

As far as I can tell there are already a lot of closed working as intended 
tickets related to

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#using-generic-types-as-unnamed-function-parameter-types

My suggestion is to be more proactive about this specific problem as soon 
as consensus is reached by introducing a `go vet -generic` flag that does 
nothing more then just highlight this specific very rare problem. And 
introduce this small language change now so it's more than a year in 
advance in place.

The concern I think will come forward is when we don't give it a high 
enough priority early enough it will significantly handicap the generic 
error compiler messages if we don't be concrete about it?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f396c1dc-1766-452f-8fc8-aaa09c42ba6cn%40googlegroups.com.

Re: [go-nuts] [generics] another parsing ambiguity

[Gert]

Thanks, can you maybe at the complete working code snippet in your issue too

```
type R(type T) struct{}
func F(type T)() {
_ = func() (_ R(T)) { return R(T){} }
}
```

I think it's not trivial code even after reading the issue what your 
solution was to the 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7c7bf287-f8f5-4c31-9de8-70997970a40cn%40googlegroups.com.

Re: [go-nuts] [generics] another parsing ambiguity

[Gert]

At Ben did you made a github issue yet for it? Can't seem to find it 
https://github.com/golang/go/issues?q=is%3Aissue+cmd%2Fgo2go 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/469d667e-df10-4dd3-80dc-a7c606c1af0bn%40googlegroups.com.

Re: [go-nuts] Re: Trampoline example

[Gert]

On Sunday, May 10, 2020 at 12:33:08 AM UTC+2, Ian Lance Taylor wrote:
>
> On Sat, May 9, 2020 at 12:56 PM Gert > 
> wrote: 
> > 
> > This is the closest I get, I am out of ideas. Don't know why it runs but 
> doesn't update the string. 
>
> I don't know what you are really trying to do, but I want to be clear 
> that this code is not supported.  The supported way to call from Go to 
> C is to use cgo.  See https://golang.org/cmd/cgo and 
> https://blog.golang.org/cgo. 
>
> One big problem I see in your code is that you are assuming that Go 
> and C use the same ABI.  That is, that the arguments passed to the Go 
> function will be seen as the arguments passed to the C function.  That 
> is not the case.  When using the gc compiler, Go and C pass arguments 
> in different locations. 
>
> Ian 
>
>
The attempt was based on this aprouch 
https://go-review.googlesource.com/c/go/+/227037/17/src/crypto/x509/internal/macOS/corefoundation.go
 
<https://go-review.googlesource.com/c/go/+/227037/17/src/crypto/x509/internal/macOS/corefoundation.go#112>
 but 
trying to apply it to the most simple example I can think. Filippo Valsorda 
believes its possible to link sqlite into go without using cgo. I made the 
assumption a trampoline assembler jump is the only way to do that?


> > go run . 
> > test [116 101 115 116 0 0 0 0 0 0] 4 0 0 
> > 
> > #include  
> > #include  
> > 
> > int hello(char *s) { 
> >  char c[80]; 
> >  strcpy (c, s); 
> >  sprintf(s, "hello %s", c); 
> >  printf("--\n"); 
> >  return 0; 
> > } 
> > 
> > #include "textflag.h" 
> > 
> > TEXT ·hello_trampoline(SB),NOSPLIT,$0-0 
> >  JMP hello_c(SB) 
> > 
> > package main 
> > 
> > import ( 
> >  "fmt" 
> >  "unsafe" 
> > 
> >  "golang.org/x/sys/unix" 
> > ) 
> > 
> > //go:linkname hello_t hello_c 
> > //go:cgo_import_dynamic hello_c hello "./c/hello.dylib" 
> > 
> > //go:nosplit 
> > func hello_t(s unsafe.Pointer) (uintptr, uintptr, unix.Errno) { 
> >  return unix.Syscall(funcPC(hello_trampoline), uintptr(s), 0, 0) 
> > } 
> > 
> > func hello_trampoline() 
> > 
> > //go:nosplit 
> > func funcPC(f func()) uintptr { 
> >  return **(**uintptr)(unsafe.Pointer()) 
> > } 
> > 
> > func main() { 
> >  b := make([]byte, 10, 10) 
> >  copy(b, []byte("test")) 
> >  r1, r2, err := hello_t(unsafe.Pointer([0])) 
> >  fmt.Printf("%s %v %d %d %d\n", b, b, r1, r2, err) 
> > } 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/68003925-1a44-4b7c-8cec-21849784bee5%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7b86244d-44e1-48c7-b651-d7b53627749b%40googlegroups.com.

[go-nuts] Re: Trampoline example

[Gert]

This is the closest I get, I am out of ideas. Don't know why it runs but 
doesn't update the string.

go run .
test [116 101 115 116 0 0 0 0 0 0] 4 0 0

#include 
#include 

int hello(char *s) {
 char c[80];
 strcpy (c, s);
 sprintf(s, "hello %s", c);
 printf("--\n");
 return 0;
}

#include "textflag.h"

TEXT ·hello_trampoline(SB),NOSPLIT,$0-0
 JMP hello_c(SB)

package main

import (
 "fmt"
 "unsafe"

 "golang.org/x/sys/unix"
)

//go:linkname hello_t hello_c
//go:cgo_import_dynamic hello_c hello "./c/hello.dylib"

//go:nosplit
func hello_t(s unsafe.Pointer) (uintptr, uintptr, unix.Errno) {
 return unix.Syscall(funcPC(hello_trampoline), uintptr(s), 0, 0)
}

func hello_trampoline()

//go:nosplit
func funcPC(f func()) uintptr {
 return **(**uintptr)(unsafe.Pointer())
}

func main() {
 b := make([]byte, 10, 10)
 copy(b, []byte("test"))
 r1, r2, err := hello_t(unsafe.Pointer([0]))
 fmt.Printf("%s %v %d %d %d\n", b, b, r1, r2, err)
}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/68003925-1a44-4b7c-8cec-21849784bee5%40googlegroups.com.

[go-nuts] Re: Why I fear Go

[Gert]

On Saturday, May 9, 2020 at 7:57:23 PM UTC+2, shammah Zealsham Agwor wrote:
>
> I have been programming since 2016 but I have never really dived deep into 
> any language and haven't got a job with any . I decided to change all that 
> and focus with every soul in me on golang. But I have my fear as every go 
> job I have seen are looking for senior developers. And from what I noticed 
> in big corps and small ones alike ,people writing go there are senior who 
> wants to port existing large scale system to go . I'm afraid I'll never be 
> able to get an entry job with it and all my hard work will be a waste and 
> I'll have to put in such efforts again into another language . Should I 
> still go for it . I've been learning it for months now and I'm scared.


The good news is we are lucky to be able to learn new things, the bad news 
food and shelter cost money. The purpose of any language is to communicate 
with others that's it, nothing more. So the question always comes down to 
how long can you survive without food before you can convince others you 
speak their language. I am in the same boat and yes it sucks nobody can 
promise you anything but I much rather live a life of hunger then a life of 
regret.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7f0519f3-0ea0-4fb7-9350-76c845613e37%40googlegroups.com.

[go-nuts] Re: Trampoline example

[Gert]

I am getting it to compile and run with this but I am struggling how you 
send a string pointer across a syscall that c can send back. Also not sure 
about the //go:nosplit I sprinkel around which one is actually right?

package main

import (
 "syscall"
 "unsafe"

 "golang.org/x/sys/unix"
)

//go:linkname hello_t hello_c
//go:cgo_import_dynamic hello_c hello "./c/hello.dylib"
//go:nosplit
func hello_t(s unsafe.Pointer) (uintptr, uintptr, syscall.Errno) {
 return unix.Syscall6(funcPC(hello_trampoline), uintptr(s), uintptr(0),
 0, 0, uintptr(s), 0)
}

func hello_trampoline()

//go:nosplit
func funcPC(f func()) uintptr {
 return **(**uintptr)(unsafe.Pointer())
}

func main() {
 s := "test"
 hello_t(unsafe.Pointer())
 print(s)
}

> go build
> ./trampoline
> test%
> 









-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e53e7a50-cdf1-43ee-8f88-c68d63677bda%40googlegroups.com.

[go-nuts] Trampoline example

[Gert]

Hi, this is the smallest example I can think of but I have know idea how I 
am suppose to do the syscall and trampoline part?

./c/hello.c
-
#include 
#include 


int hello(char *s) {
  char c[80];
  strcpy (c, s);
  sprintf(s, "hello %s", c);
  return 0;
}

clang -shared -fpic hello.c -o hello.dylib

./trampoline.s
-

#include "textflag.h"

TEXT ·hello_trampoline(SB),NOSPLIT,$0-0
  JMP hello(SB)

./main.go
---

package main

import "unsafe"

//go:linkname hello_c hello_c
//go:cgo_import_dynamic hello_c hello "./c/hello.dylib"
func hello_c(s unsafe.Pointer) uintptr {
return syscall(funcPC(hello_trampoline), uintptr(s), uintptr(0), 0, 0, 
uintptr(s), 0)
}

func hello_trampoline()

func syscall(fn, a1, a2, a3, a4, a5, a6 uintptr) uintptr

//go:nosplit
func funcPC(f func()) uintptr {
   return **(**uintptr)(unsafe.Pointer())
}

func main() {
  s := "test"
  hello_c(unsafe.Pointer())
  print(s)
}

(go version devel +98d20fb235 Fri May 8 02:31:13 2020 + darwin/amd64)

main.main: relocation target main.syscall not defined
main.hello_trampoline: relocation target hello not defined

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6e9eae3e-d060-44e3-9361-e9ef89d82515%40googlegroups.com.

Re: [go-nuts] C datagram recvfrom unix domain socket

[Gert]

Thanks to the examples you provided I found that in my very first attempt I 
needed to use `net.DialUnix` instead of `net.Dial`

net.DialUnix("unixgram", {CLIENT_SOCK_FILE, "unixgram"}, 
{SERVER_SOCK_FILE, "unixgram"})

Now the C server knows where to send a msg back

On Sunday, February 16, 2020 at 1:20:11 AM UTC+1, Gert wrote:
>
> Your are right about sendto, when I remove the connect part before the 
> sendto, I get the exact same as the very first attempt where the server 
> receives the message but can't send anything back.
>
> Note that as far as I understand 'unixpacket' is for streaming where a 
> open connection get established between server client. I would like a 
> connectionless solution, as in sending a datagram and forget about it and 
> just see if a datagram is fired back to the client. Like the current 
> working C code does.
>
> On Sunday, February 16, 2020 at 12:58:13 AM UTC+1, robert engels wrote:
>>
>> Here is some code (I can’t run it because not supported on osx):
>>
>> server: https://play.golang.org/p/rO2C27iW8NM
>> client: https://play.golang.org/p/NF3yPerSc0u
>>
>>
>> On Feb 15, 2020, at 5:48 PM, robert engels  wrote:
>>
>> Actually this will be more helpful since it is datagram based:
>>
>>
>> https://golang-examples.tumblr.com/post/92024612569/unix-domain-socket-server-and-client
>>
>> On Feb 15, 2020, at 5:45 PM, robert engels  wrote:
>>
>> You might find this helpful 
>> https://eli.thegreenplace.net/2019/unix-domain-sockets-in-go/
>>
>> On Feb 15, 2020, at 5:37 PM, robert engels  wrote:
>>
>> You really should ‘panic on err’ when diagnosing these sort of issues - 
>> because I need the full error information.
>>
>> That being said, if you ‘Connect()’ then many times you can’t use 
>> Sendto(), you need to use Send() - or don’t Connect().
>>
>> When you “Connect” you are connecting the socket which controls the 
>> destination for packets.
>>
>> On Feb 15, 2020, at 5:25 PM, Gert  wrote:
>>
>> Another attempt but now I get `socket is already connected`
>>
>> https://play.golang.org/p/-klJZPnKFRk
>>
>> On Saturday, February 15, 2020 at 8:53:46 PM UTC+1, Gert wrote:
>>>
>>> Thx when looking for Recv() and Send() I found this package 
>>> https://pkg.go.dev/golang.org/x/sys/unix 
>>>
>>> I don't understand how I'm suppose to create a new SockaddrUnix when raw 
>>> is a private field?
>>>
>>> https://play.golang.org/p/fe1f_A92BgI
>>>
>>> Also don't know if my strcpy is the way to fill in path?
>>>
>>> On Saturday, February 15, 2020 at 4:31:00 PM UTC+1, Robert Engels wrote:
>>>>
>>>> You want to use Recv() and Send() not Read() and Write() in order to 
>>>> get the address information. 
>>>>
>>>> Read() and Write() are for connected sockets and usually streaming. 
>>>>
>>>> On Feb 15, 2020, at 9:27 AM, Robert Engels  
>>>> wrote:
>>>>
>>>> 
>>>> Sorry. I missed the part about “domain” socket. 
>>>>
>>>> On Feb 15, 2020, at 9:26 AM, Robert Engels  
>>>> wrote:
>>>>
>>>> 
>>>> See github.com/robaho/go-trader for an example of sending / receiving 
>>>> udp traffic. There’s no reason to use the low level Unix interfaces. 
>>>>
>>>> On Feb 15, 2020, at 9:22 AM, Gert  wrote:
>>>>
>>>> 
>>>> Hi, leaving out a lot of details I basically do this in a C client
>>>>
>>>> fd = socket(PF_UNIX, SOCK_DGRAM, 0)
>>>> bind(fd, (struct sockaddr*) ,sizeof(struct sockaddr_un)
>>>> connect(fd, (struct sockaddr*) ,sizeof(struct sockaddr_un)
>>>> send(fd, buff, strlen(buff)+1, 0)
>>>> recv(fd, buff, 8192, 0)
>>>>
>>>> Which means I have a client socket where I receive datagrams and a 
>>>> server socket where I sent datagrams to.
>>>>
>>>> It works in my C client above but having troubles understanding how to 
>>>> talk to the same C server using a Go client instead. This is my attempt
>>>>
>>>>
>>>>  addr, err :=net.ResolveUnixAddr("unixgram","client.sock")
>>>>  if err != nil {
>>>>log.Fatal(err)
>>>>  }
>>>>
>>>>  client, err :=net.ListenUnixgram("unixgram", addr)
>>>>  if err != nil {
>>>>log.Fatal(err)
>>>>  }
>&

Re: [go-nuts] C datagram recvfrom unix domain socket

[Gert]

Your are right about sendto, when I remove the connect part before the 
sendto, I get the exact same as the very first attempt where the server 
receives the message but can't send anything back.

Note that as far as I understand 'unixpacket' is for streaming where a open 
connection get established between server client. I would like a 
connectionless solution, as in sending a datagram and forget about it and 
just see if a datagram is fired back to the client. Like the current 
working C code does.

On Sunday, February 16, 2020 at 12:58:13 AM UTC+1, robert engels wrote:
>
> Here is some code (I can’t run it because not supported on osx):
>
> server: https://play.golang.org/p/rO2C27iW8NM
> client: https://play.golang.org/p/NF3yPerSc0u
>
>
> On Feb 15, 2020, at 5:48 PM, robert engels  > wrote:
>
> Actually this will be more helpful since it is datagram based:
>
>
> https://golang-examples.tumblr.com/post/92024612569/unix-domain-socket-server-and-client
>
> On Feb 15, 2020, at 5:45 PM, robert engels  > wrote:
>
> You might find this helpful 
> https://eli.thegreenplace.net/2019/unix-domain-sockets-in-go/
>
> On Feb 15, 2020, at 5:37 PM, robert engels  > wrote:
>
> You really should ‘panic on err’ when diagnosing these sort of issues - 
> because I need the full error information.
>
> That being said, if you ‘Connect()’ then many times you can’t use 
> Sendto(), you need to use Send() - or don’t Connect().
>
> When you “Connect” you are connecting the socket which controls the 
> destination for packets.
>
> On Feb 15, 2020, at 5:25 PM, Gert > 
> wrote:
>
> Another attempt but now I get `socket is already connected`
>
> https://play.golang.org/p/-klJZPnKFRk
>
> On Saturday, February 15, 2020 at 8:53:46 PM UTC+1, Gert wrote:
>>
>> Thx when looking for Recv() and Send() I found this package 
>> https://pkg.go.dev/golang.org/x/sys/unix 
>>
>> I don't understand how I'm suppose to create a new SockaddrUnix when raw 
>> is a private field?
>>
>> https://play.golang.org/p/fe1f_A92BgI
>>
>> Also don't know if my strcpy is the way to fill in path?
>>
>> On Saturday, February 15, 2020 at 4:31:00 PM UTC+1, Robert Engels wrote:
>>>
>>> You want to use Recv() and Send() not Read() and Write() in order to get 
>>> the address information. 
>>>
>>> Read() and Write() are for connected sockets and usually streaming. 
>>>
>>> On Feb 15, 2020, at 9:27 AM, Robert Engels  wrote:
>>>
>>> 
>>> Sorry. I missed the part about “domain” socket. 
>>>
>>> On Feb 15, 2020, at 9:26 AM, Robert Engels  wrote:
>>>
>>> 
>>> See github.com/robaho/go-trader for an example of sending / receiving 
>>> udp traffic. There’s no reason to use the low level Unix interfaces. 
>>>
>>> On Feb 15, 2020, at 9:22 AM, Gert  wrote:
>>>
>>> 
>>> Hi, leaving out a lot of details I basically do this in a C client
>>>
>>> fd = socket(PF_UNIX, SOCK_DGRAM, 0)
>>> bind(fd, (struct sockaddr*) ,sizeof(struct sockaddr_un)
>>> connect(fd, (struct sockaddr*) ,sizeof(struct sockaddr_un)
>>> send(fd, buff, strlen(buff)+1, 0)
>>> recv(fd, buff, 8192, 0)
>>>
>>> Which means I have a client socket where I receive datagrams and a 
>>> server socket where I sent datagrams to.
>>>
>>> It works in my C client above but having troubles understanding how to 
>>> talk to the same C server using a Go client instead. This is my attempt
>>>
>>>
>>>  addr, err :=net.ResolveUnixAddr("unixgram","client.sock")
>>>  if err != nil {
>>>log.Fatal(err)
>>>  }
>>>
>>>  client, err :=net.ListenUnixgram("unixgram", addr)
>>>  if err != nil {
>>>log.Fatal(err)
>>>  }
>>>  defer client.Close()
>>>
>>>  server, err := net.Dial("unixgram","server.sock")
>>>  if err != nil {
>>>log.Fatal(err)
>>>  }
>>>  defer server.Close()
>>>
>>>  _, err = server.Write([]byte("hi"))
>>>  if err != nil {
>>>log.Fatal(err)
>>>  }
>>>
>>>  buf := make([]byte, 1024)
>>>  n, err := client.Read(buf[:])
>>>  if err != nil {
>>>println(err)
>>>  }
>>>  println(string(buf[0:n]))
>>>
>>>  if err := os.RemoveAll("client.sock");err != nil {
>>>log.Fatal(err)
>>>  }
>>>
>>>
>>> What happens in the Go implementat

Re: [go-nuts] C datagram recvfrom unix domain socket

[Gert]

Another attempt but now I get `socket is already connected`

https://play.golang.org/p/-klJZPnKFRk

On Saturday, February 15, 2020 at 8:53:46 PM UTC+1, Gert wrote:
>
> Thx when looking for Recv() and Send() I found this package 
> https://pkg.go.dev/golang.org/x/sys/unix 
>
> I don't understand how I'm suppose to create a new SockaddrUnix when raw 
> is a private field?
>
> https://play.golang.org/p/fe1f_A92BgI
>
> Also don't know if my strcpy is the way to fill in path?
>
> On Saturday, February 15, 2020 at 4:31:00 PM UTC+1, Robert Engels wrote:
>>
>> You want to use Recv() and Send() not Read() and Write() in order to get 
>> the address information. 
>>
>> Read() and Write() are for connected sockets and usually streaming. 
>>
>> On Feb 15, 2020, at 9:27 AM, Robert Engels  wrote:
>>
>> 
>> Sorry. I missed the part about “domain” socket. 
>>
>> On Feb 15, 2020, at 9:26 AM, Robert Engels  wrote:
>>
>> 
>> See github.com/robaho/go-trader for an example of sending / receiving 
>> udp traffic. There’s no reason to use the low level Unix interfaces. 
>>
>> On Feb 15, 2020, at 9:22 AM, Gert  wrote:
>>
>> 
>> Hi, leaving out a lot of details I basically do this in a C client
>>
>> fd = socket(PF_UNIX, SOCK_DGRAM, 0)
>> bind(fd, (struct sockaddr*) , sizeof(struct sockaddr_un)
>> connect(fd, (struct sockaddr*) , sizeof(struct sockaddr_un)
>> send(fd, buff, strlen(buff)+1, 0)
>> recv(fd, buff, 8192, 0)
>>
>> Which means I have a client socket where I receive datagrams and a server 
>> socket where I sent datagrams to.
>>
>> It works in my C client above but having troubles understanding how to 
>> talk to the same C server using a Go client instead. This is my attempt
>>
>>
>>  addr, err := net.ResolveUnixAddr("unixgram", "client.sock")
>>  if err != nil {
>>log.Fatal(err)
>>  }
>>
>>  client, err := net.ListenUnixgram("unixgram", addr)
>>  if err != nil {
>>log.Fatal(err)
>>  }
>>  defer client.Close()
>>
>>  server, err := net.Dial("unixgram", "server.sock")
>>  if err != nil {
>>log.Fatal(err)
>>  }
>>  defer server.Close()
>>
>>  _, err = server.Write([]byte("hi"))
>>  if err != nil {
>>log.Fatal(err)
>>  }
>>
>>  buf := make([]byte, 1024)
>>  n, err := client.Read(buf[:])
>>  if err != nil {
>>println(err)
>>  }
>>  println(string(buf[0:n]))
>>
>>  if err := os.RemoveAll("client.sock"); err != nil {
>>log.Fatal(err)
>>  }
>>
>>
>> What happens in the Go implementation is that it successfully send a 
>> datagram, the server receives it but then the server can't figure out where 
>> to send a answer back with a error from the server sendto: `No such file or 
>> directory`
>>
>> This is basically what the the C server code is doing.
>>
>> recvfrom(fd, buff, 8192, 0, (struct sockaddr*) , )
>> sendto(fd, buff, strlen(buff)+1, 0, (struct sockaddr*) , len)
>>
>> My socket knowledge is limited and https://golang.org/pkg/net/ is 
>> overwhelming, if I would make a guess is that de C client shares fd between 
>> bind and connect and my Go implementation doesn't ?
>>
>>
>> -- 
>> 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 golan...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/644fa128-96c9-47f8-abc5-5fcc19d01e6e%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/644fa128-96c9-47f8-abc5-5fcc19d01e6e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a2c197f9-ceb2-49d7-af4d-f8485a5b69ba%40googlegroups.com.

Re: [go-nuts] C datagram recvfrom unix domain socket

[Gert]

Thx when looking for Recv() and Send() I found this package 
https://pkg.go.dev/golang.org/x/sys/unix 

I don't understand how I'm suppose to create a new SockaddrUnix when raw is 
a private field?

https://play.golang.org/p/fe1f_A92BgI

Also don't know if my strcpy is the way to fill in path?

On Saturday, February 15, 2020 at 4:31:00 PM UTC+1, Robert Engels wrote:
>
> You want to use Recv() and Send() not Read() and Write() in order to get 
> the address information. 
>
> Read() and Write() are for connected sockets and usually streaming. 
>
> On Feb 15, 2020, at 9:27 AM, Robert Engels  > wrote:
>
> 
> Sorry. I missed the part about “domain” socket. 
>
> On Feb 15, 2020, at 9:26 AM, Robert Engels  > wrote:
>
> 
> See github.com/robaho/go-trader for an example of sending / receiving udp 
> traffic. There’s no reason to use the low level Unix interfaces. 
>
> On Feb 15, 2020, at 9:22 AM, Gert > 
> wrote:
>
> 
> Hi, leaving out a lot of details I basically do this in a C client
>
> fd = socket(PF_UNIX, SOCK_DGRAM, 0)
> bind(fd, (struct sockaddr*) , sizeof(struct sockaddr_un)
> connect(fd, (struct sockaddr*) , sizeof(struct sockaddr_un)
> send(fd, buff, strlen(buff)+1, 0)
> recv(fd, buff, 8192, 0)
>
> Which means I have a client socket where I receive datagrams and a server 
> socket where I sent datagrams to.
>
> It works in my C client above but having troubles understanding how to 
> talk to the same C server using a Go client instead. This is my attempt
>
>
>  addr, err := net.ResolveUnixAddr("unixgram", "client.sock")
>  if err != nil {
>log.Fatal(err)
>  }
>
>  client, err := net.ListenUnixgram("unixgram", addr)
>  if err != nil {
>log.Fatal(err)
>  }
>  defer client.Close()
>
>  server, err := net.Dial("unixgram", "server.sock")
>  if err != nil {
>log.Fatal(err)
>  }
>  defer server.Close()
>
>  _, err = server.Write([]byte("hi"))
>  if err != nil {
>log.Fatal(err)
>  }
>
>  buf := make([]byte, 1024)
>  n, err := client.Read(buf[:])
>  if err != nil {
>println(err)
>  }
>  println(string(buf[0:n]))
>
>  if err := os.RemoveAll("client.sock"); err != nil {
>log.Fatal(err)
>  }
>
>
> What happens in the Go implementation is that it successfully send a 
> datagram, the server receives it but then the server can't figure out where 
> to send a answer back with a error from the server sendto: `No such file or 
> directory`
>
> This is basically what the the C server code is doing.
>
> recvfrom(fd, buff, 8192, 0, (struct sockaddr*) , )
> sendto(fd, buff, strlen(buff)+1, 0, (struct sockaddr*) , len)
>
> My socket knowledge is limited and https://golang.org/pkg/net/ is 
> overwhelming, if I would make a guess is that de C client shares fd between 
> bind and connect and my Go implementation doesn't ?
>
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/644fa128-96c9-47f8-abc5-5fcc19d01e6e%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/644fa128-96c9-47f8-abc5-5fcc19d01e6e%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5d98b413-850f-4937-b8f8-1ad0d28aadf7%40googlegroups.com.

[go-nuts] C datagram recvfrom unix domain socket

[Gert]

Hi, leaving out a lot of details I basically do this in a C client

fd = socket(PF_UNIX, SOCK_DGRAM, 0)
bind(fd, (struct sockaddr*) , sizeof(struct sockaddr_un)
connect(fd, (struct sockaddr*) , sizeof(struct sockaddr_un)
send(fd, buff, strlen(buff)+1, 0)
recv(fd, buff, 8192, 0)

Which means I have a client socket where I receive datagrams and a server 
socket where I sent datagrams to.

It works in my C client above but having troubles understanding how to talk 
to the same C server using a Go client instead. This is my attempt


 addr, err := net.ResolveUnixAddr("unixgram", "client.sock")
 if err != nil {
   log.Fatal(err)
 }

 client, err := net.ListenUnixgram("unixgram", addr)
 if err != nil {
   log.Fatal(err)
 }
 defer client.Close()

 server, err := net.Dial("unixgram", "server.sock")
 if err != nil {
   log.Fatal(err)
 }
 defer server.Close()

 _, err = server.Write([]byte("hi"))
 if err != nil {
   log.Fatal(err)
 }

 buf := make([]byte, 1024)
 n, err := client.Read(buf[:])
 if err != nil {
   println(err)
 }
 println(string(buf[0:n]))

 if err := os.RemoveAll("client.sock"); err != nil {
   log.Fatal(err)
 }


What happens in the Go implementation is that it successfully send a 
datagram, the server receives it but then the server can't figure out where 
to send a answer back with a error from the server sendto: `No such file or 
directory`

This is basically what the the C server code is doing.

recvfrom(fd, buff, 8192, 0, (struct sockaddr*) , )
sendto(fd, buff, strlen(buff)+1, 0, (struct sockaddr*) , len)

My socket knowledge is limited and https://golang.org/pkg/net/ is 
overwhelming, if I would make a guess is that de C client shares fd between 
bind and connect and my Go implementation doesn't ?


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/644fa128-96c9-47f8-abc5-5fcc19d01e6e%40googlegroups.com.

Re: [go-nuts] MarshalJSON() output encrypted json

[Gert Cuykens]

Ok thanks, I will try that but don't think it will be elegant for
turning on and off plain json in a code base, because I have to change
every json.Marshal and json.Umarshal

On Fri, Dec 27, 2019 at 10:21 AM Dan Kortschak  wrote:
>
> MarshalText?
>
> On Fri, 2019-12-27 at 09:51 +0100, Gert Cuykens wrote:
> > Thanks, Which should I use instead then? The reason I use it is so I
> > can easily switch between regular json payloads for debugging and
> > encrypted/signed urlencode payloads
> >
> > On Fri, Dec 27, 2019 at 9:39 AM Axel Wagner
> >  wrote:
> > >
> > > `MarshalJSON` needs to output a valid JSON value, according to the
> > > interface. If you don't need the result to be valid JSON, then
> > > don't use encoding/json. If you want to use JSON to use it as part
> > > of a larger value, you could output a JSON string (but you should
> > > familiarize yourself with what a JSON string can and can't contain
> > > - e.g. if your encrypted bytes contain quotes, that'll be
> > > problematic).
> > >
> > > On Fri, Dec 27, 2019 at 7:55 AM Gert 
> > > wrote:
> > > >
> > > > https://play.golang.org/p/6qKkJhVsnU1
> > > >
> > > > type Payload struct{}
> > > >
> > > > func (p Payload) MarshalJSON() ([]byte, error) {
> > > > return []byte("my custom encryption stuf"), nil
> > > > }
> > > >
> > > > func main() {
> > > > p := Payload{}
> > > > j, err := json.Marshal(p)
> > > > if err != nil {
> > > > fmt.Println(err)
> > > > }
> > > > fmt.Println(string(j))
> > > > }
> > > >
> > > > json: error calling MarshalJSON for type main.Payload: invalid
> > > > character 'm' looking for beginning of value
> > > >
> > > >
> > > > How do you skip the check from json.Marshal and just return the
> > > > []byte directly whatever they are?
> > > >
> > > > --
> > > > 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.
> > > > To view this discussion on the web visit
> > > > https://groups.google.com/d/msgid/golang-nuts/554c8ca8-2bca-4321-9ee5-0524e28422a3%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAG7ytiv8VEAC3fjr3Ln9bwmHJOXUd%3DQiPpGtsua4%2BHK1zv4TfQ%40mail.gmail.com.

Re: [go-nuts] MarshalJSON() output encrypted json

[Gert Cuykens]

Thanks, Which should I use instead then? The reason I use it is so I
can easily switch between regular json payloads for debugging and
encrypted/signed urlencode payloads

On Fri, Dec 27, 2019 at 9:39 AM Axel Wagner
 wrote:
>
> `MarshalJSON` needs to output a valid JSON value, according to the interface. 
> If you don't need the result to be valid JSON, then don't use encoding/json. 
> If you want to use JSON to use it as part of a larger value, you could output 
> a JSON string (but you should familiarize yourself with what a JSON string 
> can and can't contain - e.g. if your encrypted bytes contain quotes, that'll 
> be problematic).
>
> On Fri, Dec 27, 2019 at 7:55 AM Gert  wrote:
>>
>> https://play.golang.org/p/6qKkJhVsnU1
>>
>> type Payload struct{}
>>
>> func (p Payload) MarshalJSON() ([]byte, error) {
>> return []byte("my custom encryption stuf"), nil
>> }
>>
>> func main() {
>> p := Payload{}
>> j, err := json.Marshal(p)
>> if err != nil {
>> fmt.Println(err)
>> }
>> fmt.Println(string(j))
>> }
>>
>> json: error calling MarshalJSON for type main.Payload: invalid character 'm' 
>> looking for beginning of value
>>
>>
>> How do you skip the check from json.Marshal and just return the []byte 
>> directly whatever they are?
>>
>> --
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/554c8ca8-2bca-4321-9ee5-0524e28422a3%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAG7ytitqTBT7CeGkPgwnm7UpFpNRUqmKzGoqj11OiAHTQu9BGA%40mail.gmail.com.

[go-nuts] MarshalJSON() output encrypted json

[Gert]

https://play.golang.org/p/6qKkJhVsnU1

type Payload struct{}

func (p Payload) MarshalJSON() ([]byte, error) {
return []byte("my custom encryption stuf"), nil
}

func main() {
p := Payload{}
j, err := json.Marshal(p)
if err != nil {
fmt.Println(err)
}
fmt.Println(string(j))
}

json: error calling MarshalJSON for type main.Payload: invalid character 'm' 
looking for beginning of value


How do you skip the check from json.Marshal and just return the []byte directly 
whatever they are?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/554c8ca8-2bca-4321-9ee5-0524e28422a3%40googlegroups.com.

Re: [go-nuts] slice pointer to type Token []byte

[Gert]

On Thursday, December 26, 2019 at 4:33:23 AM UTC+1, burak serdar wrote:
>
> On Wed, Dec 25, 2019 at 8:05 PM Gert > 
> wrote: 
> > 
> > Is there a cleaner way to write the 
> > 
> > s:= *t 
> > *t = s[i+1:] 
> > 
> > part? 
> > 
> > was hoping for something like *t = *t[i+1:] 
>
> Indexing comes before indirection, so use parens: 
>
> *t=(*t)[i+1:] 
>
>
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f1aaa213-a07f-4f04-aaf8-4625f1b642f2%40googlegroups.com.

[go-nuts] slice pointer to type Token []byte

[Gert]

Is there a cleaner way to write the 

s:= *t
*t = s[i+1:]

part?

was hoping for something like *t = *t[i+1:]


type Token []byte

func (t *Token) Next() bool {
if i := bytes.IndexByte(*t, '.'); i > -1 {
s := *t
*t = s[i+1:]
return true
}
return false
}

func (t Token) String() string {
if i := bytes.IndexByte(t, '.'); i > -1 {
return string(t[:i])
}
return string(t)
}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5f59f852-99e5-472f-9857-cac893907ad6%40googlegroups.com.

[go-nuts] Re: How do you escape a dot in a /usr/local/go/src/cmd/go/testdata/script pattern

[Gert]

never mind, just plain regex \[ \.

On Wednesday, December 18, 2019 at 2:38:52 AM UTC+1, Gert wrote:
>
>
> https://go-review.googlesource.com/c/go/+/201857/7/src/cmd/go/testdata/script/doc.txt
>
> go test cmd/go -run=Script/^doc$
>
> I guess this fails because of a dot located in the pattern 'go doc 
> [.]' 
>
> How do you escape it?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2b31b085-664d-432d-991f-0570d1ba0eff%40googlegroups.com.

[go-nuts] How do you escape a dot in a /usr/local/go/src/cmd/go/testdata/script pattern

[Gert]

https://go-review.googlesource.com/c/go/+/201857/7/src/cmd/go/testdata/script/doc.txt

go test cmd/go -run=Script/^doc$

I guess this fails because of a dot located in the pattern 'go doc 
[.]' 

How do you escape it?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0314701c-690b-48ee-80d4-63fa05c35f65%40googlegroups.com.

[go-nuts] Re: [64]byte()[:]

[Gert]

On Saturday, November 16, 2019 at 4:32:32 AM UTC+1, Gert wrote:

> Is it possible to write this without creating a separate var b64 first? 
> Basically just write it in one line?
>
> var b64 [64]byte // 64 zero bytes
> if bytes.Equal(b64[:], x) {}
>
>
if bytes.Equal(make([]byte, 64), x) {}

answer from slack (Dorian Thiessen)

 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/be6d79d2-b012-43e9-b967-37e919e6f53b%40googlegroups.com.

[go-nuts] [64]byte()[:]

[Gert]

Is it possible to write this without creating a separate var b64 first? 
Basically just write it in one line?

var b64 [64]byte // 64 zero bytes
if bytes.Equal(b64[:], x) {}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/52e310f4-1fd1-4eb7-833c-70c858edacad%40googlegroups.com.

[go-nuts] Re: go vet output

[Gert]

I think it needs to be fixed here somewhere? go/src/cmd/go/internal/work

On Saturday, October 26, 2019 at 1:47:24 PM UTC+2, Gert wrote:
>
> Stuck :( I am lost in a jungle of source code looking for `Report` 
> printers 
>
> On Saturday, October 26, 2019 at 1:33:29 PM UTC+2, Gert wrote:
>>
>> A no wait need to go other direction and find all type Pass structs
>>
>> pass.Report(Diagnostic{Pos: pos, Message: msg})
>>
>> On Saturday, October 26, 2019 at 1:23:40 PM UTC+2, Gert wrote:
>>>
>>>
>>> https://github.com/golang/tools/blob/master/go/analysis/analysis.go#L161-L173
>>>
>>> Can I assume every output of go vet passes through here? So basically 
>>> need to figure out all the references to this two functions and change the 
>>> format?
>>>
>>> On Saturday, October 26, 2019 at 12:59:59 PM UTC+2, Gert wrote:
>>>>
>>>> https://github.com/golang/go/issues/24344#issuecomment-546589062
>>>>
>>>> The start of the go vet rabbit hole is this right?
>>>>
>>>> https://github.com/golang/go/blob/master/src/cmd/vet/main.go
>>>>
>>>> So basically one of does or all of the analyzers is responsible for the 
>>>> print output right?
>>>> So if i want to fix it i need to go through all of them?
>>>>
>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fc3da1e9-cd7a-4d20-b5e1-2ef84605d85c%40googlegroups.com.

Re: [go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[Gert]

On Sunday, October 27, 2019 at 9:54:29 AM UTC+1, rog wrote:
>
>
> On Sun, 27 Oct 2019, 00:04 Gert, > wrote:
>
>> I believe it's going to be to hard to write a go vet analyser that could 
>> warn to detect unintended state change on a array from two different 
>> pointers.
>>
>
> Isn't that why we have the race detector?
>

I think it only catches concurrent access to the same address, so not sure 
if it catches everything.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39c04bde-2c9c-4396-84c1-a71143de5e39%40googlegroups.com.

Re: [go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[Gert]

On Saturday, October 26, 2019 at 10:22:42 PM UTC+2, atd...@gmail.com wrote:
>
>
> On Saturday, October 26, 2019 at 9:47:39 PM UTC+2, Ian Lance Taylor wrote:
>>
>> On Sat, Oct 26, 2019 at 10:50 AM atd...@gmail.com  
>> wrote: 
>> > 
>> > I get that we can do that but it's not strictly about slices operations 
>> such as appending or copying. 
>> > Of course, we could copy slices all the time but then there is no 
>> benefit in having them and it is not ergonomic as your example shows, nor 
>> does it fit your performance cost requirements. 
>> > 
>> > If you look at the code snippet I posted, I am merely assigning a value 
>> of type slice to a struct field. Now, that struct can be copied a number of 
>> times without its actual value changing. It looks immutable in some sense. 
>>  BUT, it's actually implicitly tied to an object that is mutable (backing 
>> array) and nowhere have we made sure that the mutation of this backing 
>> array is safe. 
>>
>> For better or for worse, the Go language has shared state.  This is 
>> most obvious when using pointers: if you copy a pointer, you do not 
>> copy the memory to which that pointer points.  If that is clear, then 
>> the thing to remember about slices is that they are pointers. 
>> Pointers in Go do not permit arithmetic.  
>
>  
>
>> Slices in Go are pointers 
>> that permit bounded arithmetic. 
>>
>> Oh, I hadn't thought about it that way! Interesting.
> I still feel like there should be a way to reign in the amount of shared 
> state in the cases of these "fat" pointers a little bit. Or at least, 
> inspect it, warn about it more because most people seem to think that 
> slices are just infinite arrays (hence the need for the extra-level of 
> indirection/pointer). 
> But perhaps, the coding patterns/idioms make it a non issue.  For future 
> considerations I guess.
>

I believe it's going to be to hard to write a go vet analyser that could 
warn to detect unintended state change on a array from two different 
pointers. Go made it this far without many programmers throwing monitors 
out of the window so I think will be fine by making sure we document slices 
pointers and interfaces in detail. Yes does 3 pages going to be heavy to 
understand but if you just remember when you encounter weird stuff to just 
look again at does 3 pages.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/30ac16bc-bc70-40a6-bc79-f41e3536d144%40googlegroups.com.

[go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[Gert]

Correct, so basically avoid x := y[i:j] if you actually meant copy

https://golang.org/ref/spec#Appending_and_copying_slices

var a = [...]int{0, 1, 2, 3, 4, 5, 6, 7}
var s = make([]int, 6)
var b = make([]byte, 5)
n1 := copy(s, a[0:])// n1 == 6, s == []int{0, 1, 2, 3, 4, 5}
n2 := copy(s, s[2:])// n2 == 4, s == []int{2, 3, 4, 5, 4, 5}
n3 := copy(b, "Hello, World!")  // n3 == 5, b == []byte("Hello")


On Saturday, October 26, 2019 at 3:02:37 PM UTC+2, atd...@gmail.com wrote:
>
> Hi,
>
> Thank you for the response.
>
> My issue is not really about append but can be illustrated by this :
>
> https://play.golang.org/p/YZlo1mqGDLz
>
> On Saturday, October 26, 2019 at 2:27:06 PM UTC+2, Gert wrote:
>>
>> Sorry, the performance cost is to high. But you can practice a few 
>> programming habits that can prevent this, like use x = append(x, y) and 
>> never x = append(y, x) Basically we only need a Go proverb bible mentioned 
>> in one of Rob Pike's talks and we will be fine :)
>>
>> On Saturday, October 26, 2019 at 1:40:23 PM UTC+2, atd...@gmail.com 
>> wrote:
>>>
>>> Hello,
>>>
>>> I've just realized that slices were much more delicate to use than 
>>> initially thought. The main issue is that when slices share the same 
>>> backing array, it is too easy to inadvertently have an unprotected 
>>> concurrent Read/Write  if one is not careful.
>>> That can easily happen for a struct that has a field of type slice for 
>>> instance. The object might be safe to copy and pass around to multiple 
>>> goroutine but reading a value from the slice field can still be problematic 
>>> if there is a write at the same time on one of the object's slice field.
>>>
>>> This is not a proposal but for later, would it make sense to have slices 
>>> become real snapshots (immutable) or copy/allocate on mutation?
>>> It will probably have perf repercussions.
>>>
>>> Or alternatively a tool that alerts of cases where there are such case 
>>> of unprotected concurrent use (perhaps the race detector already does this)
>>>
>>> Even better is if that's a non argument because the cases where it's 
>>> happen in real world code is sparse but I must admit that it took me a long 
>>> time to think about this and now, I'm worried that it's a mistake too 
>>> easily made.
>>>
>>> Also, I do not remember the specifics of the map code, but what happens 
>>> for a map of slices? Do the slice elements share the backing array? 
>>>
>>>
>>>
>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c8ed31a1-d7f9-4753-bcdc-14c98559c77a%40googlegroups.com.

[go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[Gert]

Sorry, the performance cost is to high. But you can practice a few 
programming habits that can prevent this, like use x = append(x, y) and 
never x = append(y, x) Basically we only need a Go proverb bible mentioned 
in one of Rob Pike's talks and we will be fine :)

On Saturday, October 26, 2019 at 1:40:23 PM UTC+2, atd...@gmail.com wrote:
>
> Hello,
>
> I've just realized that slices were much more delicate to use than 
> initially thought. The main issue is that when slices share the same 
> backing array, it is too easy to inadvertently have an unprotected 
> concurrent Read/Write  if one is not careful.
> That can easily happen for a struct that has a field of type slice for 
> instance. The object might be safe to copy and pass around to multiple 
> goroutine but reading a value from the slice field can still be problematic 
> if there is a write at the same time on one of the object's slice field.
>
> This is not a proposal but for later, would it make sense to have slices 
> become real snapshots (immutable) or copy/allocate on mutation?
> It will probably have perf repercussions.
>
> Or alternatively a tool that alerts of cases where there are such case of 
> unprotected concurrent use (perhaps the race detector already does this)
>
> Even better is if that's a non argument because the cases where it's 
> happen in real world code is sparse but I must admit that it took me a long 
> time to think about this and now, I'm worried that it's a mistake too 
> easily made.
>
> Also, I do not remember the specifics of the map code, but what happens 
> for a map of slices? Do the slice elements share the backing array? 
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dfe39769-e5d1-4abc-aec2-e91807cd1b71%40googlegroups.com.

[go-nuts] Re: go vet output

[Gert]

Stuck :( I am lost in a jungle of source code looking for `Report` printers 

On Saturday, October 26, 2019 at 1:33:29 PM UTC+2, Gert wrote:
>
> A no wait need to go other direction and find all type Pass structs
>
> pass.Report(Diagnostic{Pos: pos, Message: msg})
>
> On Saturday, October 26, 2019 at 1:23:40 PM UTC+2, Gert wrote:
>>
>>
>> https://github.com/golang/tools/blob/master/go/analysis/analysis.go#L161-L173
>>
>> Can I assume every output of go vet passes through here? So basically 
>> need to figure out all the references to this two functions and change the 
>> format?
>>
>> On Saturday, October 26, 2019 at 12:59:59 PM UTC+2, Gert wrote:
>>>
>>> https://github.com/golang/go/issues/24344#issuecomment-546589062
>>>
>>> The start of the go vet rabbit hole is this right?
>>>
>>> https://github.com/golang/go/blob/master/src/cmd/vet/main.go
>>>
>>> So basically one of does or all of the analyzers is responsible for the 
>>> print output right?
>>> So if i want to fix it i need to go through all of them?
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1abec5bf-b928-4bdf-b5e4-d91c0de0bca4%40googlegroups.com.

[go-nuts] Re: go vet output

[Gert]

A no wait need to go other direction and find all type Pass structs

pass.Report(Diagnostic{Pos: pos, Message: msg})

On Saturday, October 26, 2019 at 1:23:40 PM UTC+2, Gert wrote:
>
>
> https://github.com/golang/tools/blob/master/go/analysis/analysis.go#L161-L173
>
> Can I assume every output of go vet passes through here? So basically need 
> to figure out all the references to this two functions and change the 
> format?
>
> On Saturday, October 26, 2019 at 12:59:59 PM UTC+2, Gert wrote:
>>
>> https://github.com/golang/go/issues/24344#issuecomment-546589062
>>
>> The start of the go vet rabbit hole is this right?
>>
>> https://github.com/golang/go/blob/master/src/cmd/vet/main.go
>>
>> So basically one of does or all of the analyzers is responsible for the 
>> print output right?
>> So if i want to fix it i need to go through all of them?
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/53103a9a-1689-4051-a20e-18288b8228f0%40googlegroups.com.

[go-nuts] Re: go vet output

[Gert]

https://github.com/golang/tools/blob/master/go/analysis/analysis.go#L161-L173

Can I assume every output of go vet passes through here? So basically need 
to figure out all the references to this two functions and change the 
format?

On Saturday, October 26, 2019 at 12:59:59 PM UTC+2, Gert wrote:
>
> https://github.com/golang/go/issues/24344#issuecomment-546589062
>
> The start of the go vet rabbit hole is this right?
>
> https://github.com/golang/go/blob/master/src/cmd/vet/main.go
>
> So basically one of does or all of the analyzers is responsible for the 
> print output right?
> So if i want to fix it i need to go through all of them?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/82ac77b1-1cfb-473c-9577-763c5b6ece48%40googlegroups.com.

[go-nuts] go vet output

[Gert]

https://github.com/golang/go/issues/24344#issuecomment-546589062

The start of the go vet rabbit hole is this right?

https://github.com/golang/go/blob/master/src/cmd/vet/main.go

So basically one of does or all of the analyzers is responsible for the 
print output right?
So if i want to fix it i need to go through all of them?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7178cf3d-52f2-4025-80f1-06140e12fd46%40googlegroups.com.

[go-nuts] Re: errors custom As

[Gert]

Thx, examples helped allot in understanding

On Thursday, October 24, 2019 at 6:53:32 PM UTC+2, Jake Montgomery wrote:
>
> I have not done much with the new errors stuff, but I'll try to help. 
>
> I assume you have read https://github.com/golang/go/wiki/ErrorValueFAQ  
> and https://blog.golang.org/go1.13-errors. There may be other posts as 
> well. 
>
> These new error functions, Is() and As() are about error types. It looks 
> like you are trying to transform an error of type PathErr into another 
> error of type PathErr with a different value. That's not how it works. 
>
> I think most of the time As() will work because the error wraps another 
> error of a different type. In that case the error should implement Unwrap() 
> not As(). If your error encapsulates multiple error types, then you would 
> need to implement As(). At least that is my understanding. For example, 
> taking your code, and modifying it, so that PathErr can also be treated as 
> an OtherErr could look like https://play.golang.org/p/qa4VU0PEP3v. But 
> again, since there is only one type encompassed in PathErr, I think this 
> might be more easily done with Unwrap like this: 
> https://play.golang.org/p/v4gDgtlNxcQ
>
> Good luck. 
>  
>
> On Thursday, October 24, 2019 at 4:26:25 AM UTC-4, Gert wrote:
>>
>> Hi, I fail to understand how the custom As is suppose to work?
>>
>> see example https://play.golang.org/p/tjuItX5dHoJ
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f2257101-3c6f-4808-987b-3817e69733b3%40googlegroups.com.

[go-nuts] Re: Roadblock for user-implemented JIT compiler

[Gert]

This kind of low level is way out of my league but what about using 
https://github.com/tinygo-org/tinygo instead to build your JIT? I only know 
tinygo has no garbage collector at all.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/80735530-71c1-49b9-abc3-9d04179328c5%40googlegroups.com.

[go-nuts] errors custom As

[Gert]

Hi, I fail to understand how the custom As is suppose to work?

see example https://play.golang.org/p/tjuItX5dHoJ

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0199fd13-975e-4f9e-b885-f0805009557e%40googlegroups.com.

[go-nuts] Re: Empty go.mod file in root directory containing only version maps

[Gert]

Thanks, the branch approach makes much more sense 
https://github.com/gertcuykens/module/tree/v5.0.0

On Tuesday, October 22, 2019 at 5:03:26 PM UTC+2, t hepudds wrote:
>
> Hello Gert,
>
> It looks like you are experimenting with the "major subdirectory" layout 
> for modules.
>
> It looks like your v1 module is incorrectly specified, including with an 
> incorrect trailing "/v1":
>
>https://github.com/gertcuykens/module/blob/v4.0.0/v1 
> <https://github.com/gertcuykens/module/blob/v4.0.0/v1/go.mod#L1>
>
> Usually you would not have a "/v1" subdirectory if you are following the 
> "major subdirectory" layout. If you have the v1 module in the same branch 
> as your v2, v3, and v4 modules, then usually the v1 module would be in the 
> root directory of the repo, and not a /v1 subdirectory, and there would be 
> no traililng "/v1" on the module line of the go.mod there.
>
> This is described in more detail here:
>
>
> https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
>
> Note that section also describes an alternative layout called the "major 
> branch" layout for modules, which does not use any "/vN" subdirectories, 
> and which some people find simpler to manage at this point.
>
> There is also a much longer discussion of those two alternative layouts 
> here:
>
>https://research.swtch.com/vgo-module
>   <https://research.swtch.com/vgo-module>
> In summary, I think the answer to your question is "no, that is not a 
> standard practice".
>
> Regards,
> thepudds
>
> On Tuesday, October 22, 2019 at 2:42:34 AM UTC-4, Gert wrote:
>>
>>
>> Example https://github.com/gertcuykens/module/tree/v4.0.0 can I assume 
>> it to be good practice to put a empty go.mod file in the root directory 
>> that doesn't contain other go files, only the version folders, so the root 
>> itself doesn't get recognised as a module itself?
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/feedd4ea-1f74-4792-abf9-b244a537d891%40googlegroups.com.

[go-nuts] Empty go.mod file in root directory containing only version maps

[Gert]

Example https://github.com/gertcuykens/module/tree/v4.0.0 can I assume it 
to be good practice to put a empty go.mod file in the root directory that 
doesn't contain other go files, only the version folders, so the root 
itself doesn't get recognised as a module itself?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0b050304-2d69-4377-b1c9-b8fd1ddbc0e5%40googlegroups.com.

[go-nuts] flag.PrintDefaults() messes up flags description new lines ?

[Gert]

Compared to go help doc output, it seems flag.PrintDefaults() messes up 
flags descriptions of go doc --help ?

go doc --help
Usage of [go] doc:
go doc
go doc 
go doc [.]
go doc [].[.]
go doc  [.]
For more information run
go help doc


Flags:
-all
show all documentation for package
-c symbol matching honors case (paths not affected)
-cmd
show symbols with package docs even if package is a command
-short
one-line representation for each symbol
-src
show source code for symbol
-u show unexported symbols as well as exported
exit status 2

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/198cbf13-cb7c-4443-a3df-0c813a2fdc92%40googlegroups.com.

[go-nuts] Re: net: conn.WriteToUDP([]byte("not ok"), addr)

[Gert]

thx Andrey Mirtchovski 

err was `write udp 127.0.0.1:59864->127.0.0.1:5127: use of WriteTo with 
pre-connected connection`

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/66a26345-576d-4a16-bd2e-fcecfbdcf8d3%40googlegroups.com.

[go-nuts] net: conn.WriteToUDP([]byte("not ok"), addr)

[Gert]

Hi, I am trying to figure out why what's going on?

conn.Write([]byte("ok"))

https://play.golang.org/p/8Fq1XyYTFs1

vs

conn.WriteToUDP([]byte("not ok"), addr)

https://play.golang.org/p/NkUKn-Oz8XA

I assumed it was unintended behavior and opened a issue at

https://github.com/golang/go/issues/34758

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b1f3f10b-7e96-429a-95ca-80c1979745f5%40googlegroups.com.

[go-nuts] asm: FUNCDATA PCDATA

[Gert]

https://golang.org/doc/asm

$ cat x.go
package main

func main() {
println(3)
}
$ GOOS=linux GOARCH=amd64 go tool compile -S x.go# or: go build 
-gcflags -S x.go

--- prog list "main" ---
 (x.go:3) TEXTmain+0(SB),$8-0
0001 (x.go:3) FUNCDATA $0,gcargs·0+0(SB)
0002 (x.go:3) FUNCDATA $1,gclocals·0+0(SB)
0003 (x.go:4) MOVQ$3,(SP)
0004 (x.go:4) PCDATA  $0,$8
0005 (x.go:4) CALL,runtime.printint+0(SB)
0006 (x.go:4) PCDATA  $0,$-1
0007 (x.go:4) PCDATA  $0,$0
0008 (x.go:4) CALL,runtime.printnl+0(SB)
0009 (x.go:4) PCDATA  $0,$-1
0010 (x.go:5) RET ,
...


The FUNCDATA and PCDATA directives contain information for use by the 
garbage collector; they are introduced by the compiler.


1) funcdata What is this .0 which is not a dot :)

2) pcdata what does $-1 mean here

3) Is there some more information on funcdata and pcdata? Doesn't have to 
be in detail, because i know its a can of worms, but just enough so I can 
tell what the garbage collector will be doing :)


--


When defining a TEXT, specifying frame size $-4 tells the linker that this 
is a leaf function that does not need to save LR on entry.


4) What is LR?

5) Leaf as in closure function?


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/34c742e7-a594-4985-adfe-38c20757099c%40googlegroups.com.

[go-nuts] Re: Go compiler backlog

[Gert]

Ok thx

On Monday, July 8, 2019 at 6:29:34 AM UTC+2, Liam wrote:
>
> Get, you may get more response on this by posting to golang-dev...
>
> On Sunday, July 7, 2019 at 3:06:55 PM UTC-7, Gert wrote:
>>
>> My intelligence is that of a ping pong ball but think it's time to clean 
>> up de go compiler backlog so ping pong balls like me have a chance to 
>> understand the compiler code.
>>
>> For example from the compiler readme
>> ```
>> Note that the `go/*` family of packages, such as `go/parser` and 
>> `go/types`,
>> have no relation to the compiler. Since the compiler was initially 
>> written in C,
>> the `go/*` packages were developed to enable writing tools working with 
>> Go code,
>> such as `gofmt` and `vet`.
>> ```
>>
>> Assuming it doesn't refer to /usr/local/go/src/go but to 
>> /usr/local/go/src/cmd/go can we remove this completely to prevent confusion 
>> and eliminate dead code especially in very complicated stuff like compiler 
>> code. I think clarity is nr 1 priority before any new feature?
>>
>> And then there is /usr/local/go/src/cmd/vendor which my first instinct 
>> was based on the folder structure. 'O that must be the place where they 
>> implement the vendor mechanism.` But then I realised its actually a vendor 
>> map which is even more confusing when go modules is suppose to be the thing 
>> for this now.
>>
>> Also before we steam role Go 2.0 can we for example address this first? 
>> ```
>> The gc package includes an AST definition carried over from when it was 
>> written
>> in C. All of its code is written in terms of it, so the first thing that 
>> the gc
>> package must do is convert the syntax package's syntax tree to the 
>> compiler's
>> AST representation. This extra step may be refactored away in the future.
>> ```
>>
>> I am sure every single thing has a perfect reason and explanation, but I 
>> am just giving feedback that me the ping pong ball will never be able to 
>> understand how to change even the tiniest thing in there.
>>
>> For example I wanted to just try 
>> https://go-review.googlesource.com/c/go/+/184818 and from trying to find 
>> documentation and asking github issues / golang-nuts / golang slack to help 
>> me, only a select few are able to help me with it. Understandably they 
>> don't have time to explain it all. But this is for me a big warning that 
>> the Go compiler itself is still very heavily dependant on a few individuals 
>> who truly understand the compiler inside out.
>>
>>  
>>
>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b97fcd6c-9842-449c-a703-a4a3626012e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Citation Needed

[Gert]

On Saturday, July 6, 2019 at 8:51:19 AM UTC+2, go je wrote:
>
> Is the Category "Games" gaining attention in the go community?
> Are the Developers writing for production level?
> Do we have an examples?
>

There is no game engine in the standard library but you will find Go game 
engines on github. Triple A games require low level hardware features from 
the graphics card and does libraries are mostly closed source. As soon as 
the mayor vendors like Nvidia have better open source drivers and library 
support only then does percentage can increase. Unfortunately I don't see 
any big improvement form does manufacturers in the near future. If you want 
to make a game, I suggest to first do some research at the available 
libraries in general not limited by programing language to have a better 
estimate how much work it's going to be to rewrite them in Go. Also don't 
underestimate the art work you going to need to acquire for your games. 
Another good question to maybe ask yourself is why games on linux is still 
a fraction of windows games. It's going to be the more or less the same 
answer. O and please ignore all the comments about Go not suited for games 
because of garbage collection at runtime because garbage collection is 
going to be the least of your concern when developing a game :)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ae1b51ca-834c-48b9-be2b-b3643ec74613%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go compiler backlog

[Gert]

My intelligence is that of a ping pong ball but think it's time to clean up 
de go compiler backlog so ping pong balls like me have a chance to 
understand the compiler code.

For example from the compiler readme
```
Note that the `go/*` family of packages, such as `go/parser` and `go/types`,
have no relation to the compiler. Since the compiler was initially written 
in C,
the `go/*` packages were developed to enable writing tools working with Go 
code,
such as `gofmt` and `vet`.
```

Assuming it doesn't refer to /usr/local/go/src/go but to 
/usr/local/go/src/cmd/go can we remove this completely to prevent confusion 
and eliminate dead code especially in very complicated stuff like compiler 
code. I think clarity is nr 1 priority before any new feature?

And then there is /usr/local/go/src/cmd/vendor which my first instinct was 
based on the folder structure. 'O that must be the place where they 
implement the vendor mechanism.` But then I realised its actually a vendor 
map which is even more confusing when go modules is suppose to be the thing 
for this now.

Also before we steam role Go 2.0 can we for example address this first? 
```
The gc package includes an AST definition carried over from when it was 
written
in C. All of its code is written in terms of it, so the first thing that 
the gc
package must do is convert the syntax package's syntax tree to the 
compiler's
AST representation. This extra step may be refactored away in the future.
```

I am sure every single thing has a perfect reason and explanation, but I am 
just giving feedback that me the ping pong ball will never be able to 
understand how to change even the tiniest thing in there.

For example I wanted to just try 
https://go-review.googlesource.com/c/go/+/184818 and from trying to find 
documentation and asking github issues / golang-nuts / golang slack to help 
me, only a select few are able to help me with it. Understandably they 
don't have time to explain it all. But this is for me a big warning that 
the Go compiler itself is still very heavily dependant on a few individuals 
who truly understand the compiler inside out.

 



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b6ff09e7-4e6f-433e-8130-d3b2e60e23ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] gc: have Unwrap() wrapper, want Unwrap()

[Gert]

Does somebody have some time please to explain what I am forgetting to 
change in the go compiler. Why my added wrapper type is reconiest as  
instead of wrapper, thanks :)

When you do ./all.bash you get

errorString does not implement error (wrong type for Unwrap method)
have Unwrap() wrapper
want Unwrap() 

https://go-review.googlesource.com/c/go/+/184818

PS I assume this is the right place to ask, no idea where I should ask 
otherwise?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b5b7ccde-3063-40c3-a30c-4378b3e98d86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] can't change build in type error interface

[Gert]

On Thursday, July 4, 2019 at 3:28:01 AM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Jul 3, 2019 at 6:19 PM Gert > 
> wrote: 
> > 
> > On Thursday, July 4, 2019 at 2:52:42 AM UTC+2, Ian Lance Taylor wrote: 
> >> 
> >> On Wed, Jul 3, 2019 at 4:39 PM Gert  wrote: 
> >> > 
> >> > On Thursday, July 4, 2019 at 12:39:34 AM UTC+2, Ian Lance Taylor 
> wrote: 
> >> >> 
> >> >> On Wed, Jul 3, 2019 at 3:30 PM Gert  wrote: 
> >> >> > 
> >> >> > I changed /usr/local/go/src/builtin/builtin.go 
> >> >> > 
> >> >> > type error interface { 
> >> >> >   Error() string 
> >> >> >   Unwrap() wrapper.Wrapper 
> >> >> > } 
> >> >> > 
> >> >> > But after compiling go successfully with ./all.bash it seems type 
> error is stil 
> >> >> > 
> >> >> > type error interface { 
> >> >> >   Error() string 
> >> >> > } 
> >> >> 
> >> >> The type "error" is implemented directly in the Go compiler.  The 
> code 
> >> >> in builtin/builtin.go only exists for documentation purposes.  If 
> you 
> >> >> want to change error, you'll need to change the compiler. 
> >> > 
> >> > 
> >> > Ok thx trying to dig my way in /usr/local/go/src/go but grepping for 
> error interface doesn't give me a clue where I can find the predefined 
> error interface :( do you perhaps have a path of a filename for me please 
> where it get defined? 
> >> 
> >> It's created by makeErrorInterface in 
> >> cmd/compile/internal/gc/universe.go.  But I have no idea what the 
> >> consequences of changing that function would be.  I would not be 
> >> surprised if other code in the compiler implicitly assumes the current 
> >> definition. 
> >> 
> >> Ian 
> > 
> > 
> > Thanks before I going to shoot myself in the foot let start by making a 
> new build in wrapper interface first in that file 
> > 
> > func makeWrapperInterface() *types.Type { 
> > field := types.NewField() 
> > field.Type = types.Types[TSTRING] 
> > f := functypefield(fakeRecvField(), nil, []*types.Field{field}) 
> > 
> > field = types.NewField() 
> > field.Sym = lookup("Wrapper") 
> > field.Type = f 
> > 
> > t := types.New(TINTER) 
> > t.SetInterface([]*types.Field{field}) 
> > return t 
> > } 
> > 
> > So basically this should generate a new build in 
> > 
> > type wrapper interface { 
> > Unwrap() wrapper 
> > } 
> > 
> > Because referencing to a wrapper.Wrapper pretty sure that's already out 
> of the question :) 
> > The lookup function gives me a hint that there might be some definition 
> files that describe the interface in plain text? If true do you know where 
> I can find does files specifically the error interface definition file? 
>
> As far as I know there is no definition file that defines the interface in 
> text. 
>
> As you can see by looking at the source of the lookup function, all it 
> does is look up a symbol in the local package's symbol table, and 
> create the symbol if it does not exist. 
>
> I encourage you to pursue this approach if you are interested in it, 
> but in order to do so you are going to have to learn to read and 
> understand the compiler code yourself, or find someone to work with 
> who has the time to go through it in the detail you need. 
>
> Ian 
>

Ok thanks, this my best try so far to make it happen, hopefully good enough 
to find out if it's worth it to go for a more general built-in wrapper 
interface for all types instead of a error wrapper only.

https://go-review.googlesource.com/c/go/+/184818/5 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a90e743b-5212-4470-a06d-80dbe42169da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] can't change build in type error interface

[Gert]

On Thursday, July 4, 2019 at 2:52:42 AM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Jul 3, 2019 at 4:39 PM Gert > 
> wrote: 
> > 
> > On Thursday, July 4, 2019 at 12:39:34 AM UTC+2, Ian Lance Taylor wrote: 
> >> 
> >> On Wed, Jul 3, 2019 at 3:30 PM Gert  wrote: 
> >> > 
> >> > I changed /usr/local/go/src/builtin/builtin.go 
> >> > 
> >> > type error interface { 
> >> >   Error() string 
> >> >   Unwrap() wrapper.Wrapper 
> >> > } 
> >> > 
> >> > But after compiling go successfully with ./all.bash it seems type 
> error is stil 
> >> > 
> >> > type error interface { 
> >> >   Error() string 
> >> > } 
> >> 
> >> The type "error" is implemented directly in the Go compiler.  The code 
> >> in builtin/builtin.go only exists for documentation purposes.  If you 
> >> want to change error, you'll need to change the compiler. 
> > 
> > 
> > Ok thx trying to dig my way in /usr/local/go/src/go but grepping for 
> error interface doesn't give me a clue where I can find the predefined 
> error interface :( do you perhaps have a path of a filename for me please 
> where it get defined? 
>
> It's created by makeErrorInterface in 
> cmd/compile/internal/gc/universe.go.  But I have no idea what the 
> consequences of changing that function would be.  I would not be 
> surprised if other code in the compiler implicitly assumes the current 
> definition. 
>
> Ian 
>

Thanks before I going to shoot myself in the foot let start by making a new 
build in wrapper interface first in that file

func makeWrapperInterface() *types.Type {
field := types.NewField()
field.Type = types.Types[TSTRING]
f := functypefield(fakeRecvField(), nil, []*types.Field{field})

field = types.NewField()
field.Sym = lookup("Wrapper")
field.Type = f

t := types.New(TINTER)
t.SetInterface([]*types.Field{field})
return t
} 

So basically this should generate a new build in

type wrapper interface {
Unwrap() wrapper
}

Because referencing to a wrapper.Wrapper pretty sure that's already out of 
the question :)
The lookup function gives me a hint that there might be some definition 
files that describe the interface in plain text? If true do you know where 
I can find does files specifically the error interface definition file? 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c57c0bb2-cb52-47ec-9293-63f35e34f3e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] can't change build in type error interface

[Gert]

I changed /usr/local/go/src/builtin/builtin.go

type error interface {
  Error() string
  Unwrap() wrapper.Wrapper
}

But after compiling go successfully with ./all.bash it seems type error is 
stil 

type error interface {
  Error() string
}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/466919e0-3ed5-45d6-a360-9b5836b56ba5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: errors/wrap.go looks like it could be made into a more general monad package?

[Gert]

Fine I can change the name to wrapper no problem, but I do think there are 
cases where you have general types like for example xml and json and 
wrapped in types like html and geojson. I just think we going to be to late 
to realise that the new Unwrap Is As %w is very useful for other types too. 
Like we where to late with the io.File vs io.Writer debate because we 
simple didn't got enough experience with it.

On Wednesday, July 3, 2019 at 5:28:25 AM UTC+2, Michal Strba wrote:
>
> First of all, this is not at all what "monad" means. A monad is a way to 
> express threading of values between computations. A result of one 
> computation gets threaded as an input to the next one, and so on.
>
> Second, what would be the use-case of this other than errors?
>
> On Wed, Jul 3, 2019, 04:52 Gert > wrote:
>
>> On Wednesday, July 3, 2019 at 3:03:20 AM UTC+2, Gert wrote:
>>>
>>> https://github.com/golang/go/blob/master/src/errors/wrap.go
>>>
>>> What if we replaced all error types in that file with a empty interface 
>>> or a general monad interface? Can we make it work for other types too and 
>>> introduce a new monad package instead a new error package only?
>>>
>>>
>> ```
>> package monad
>>
>> type Monad interface {
>> Unwrap() Monad
>> }
>>
>> func Unwrap(m Monad) Monad {
>> if m != nil {
>> return m.Unwrap()
>> }
>> return nil
>> }
>> ```
>>
>> ```
>> package monad_test
>>
>> import (
>> "monad"
>> "testing"
>> )
>>
>> type monadT struct{ s string }
>>
>> func (m monadT) Unwrap() monad.Monad { return nil }
>>
>> type wrappedT struct {
>> s string
>> m monad.Monad
>> }
>>
>> func (w wrappedT) Unwrap() monad.Monad { return w.m }
>>
>> func TestUnwrap(t *testing.T) {
>> m1 := monadT{"monad"}
>> m2 := wrappedT{"monad wrap", m1}
>>
>> testCases := []struct {
>> mmonad.Monad
>> want monad.Monad
>> }{
>> {nil, nil},
>> {wrappedT{"wrapped", nil}, nil},
>> {m1, nil},
>> {m2, m1},
>> {wrappedT{"wrap 3", m2}, m2},
>> }
>> for _, tc := range testCases {
>> if got := monad.Unwrap(tc.m); got != tc.want {
>> t.Errorf("Unwrap(%v) = %v, want %v", tc.m, got, tc.want)
>> }
>> }
>> }
>> ```
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/92fe566f-3f18-43a2-91a6-4db21a1ef4ee%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/92fe566f-3f18-43a2-91a6-4db21a1ef4ee%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/56658275-49de-4cac-aeeb-c770b3da5ed4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: errors/wrap.go looks like it could be made into a more general monad package?

[Gert]

On Wednesday, July 3, 2019 at 3:03:20 AM UTC+2, Gert wrote:
>
> https://github.com/golang/go/blob/master/src/errors/wrap.go
>
> What if we replaced all error types in that file with a empty interface or 
> a general monad interface? Can we make it work for other types too and 
> introduce a new monad package instead a new error package only?
>
>
```
package monad

type Monad interface {
Unwrap() Monad
}

func Unwrap(m Monad) Monad {
if m != nil {
return m.Unwrap()
}
return nil
}
```

```
package monad_test

import (
"monad"
"testing"
)

type monadT struct{ s string }

func (m monadT) Unwrap() monad.Monad { return nil }

type wrappedT struct {
s string
m monad.Monad
}

func (w wrappedT) Unwrap() monad.Monad { return w.m }

func TestUnwrap(t *testing.T) {
m1 := monadT{"monad"}
m2 := wrappedT{"monad wrap", m1}

testCases := []struct {
mmonad.Monad
want monad.Monad
}{
{nil, nil},
{wrappedT{"wrapped", nil}, nil},
{m1, nil},
{m2, m1},
{wrappedT{"wrap 3", m2}, m2},
}
for _, tc := range testCases {
if got := monad.Unwrap(tc.m); got != tc.want {
t.Errorf("Unwrap(%v) = %v, want %v", tc.m, got, tc.want)
}
}
}
```

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/92fe566f-3f18-43a2-91a6-4db21a1ef4ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: errors/wrap.go looks like it could be made into a more general monad package?

[Gert]

On Wednesday, July 3, 2019 at 3:03:20 AM UTC+2, Gert wrote:
>
> https://github.com/golang/go/blob/master/src/errors/wrap.go
>
> What if we replaced all error types in that file with a empty interface or 
> a general monad interface? Can we make it work for other types too and 
> introduce a new monad package instead a new error package only?
>
>
package monad

type Monad interface {
Unwrap() Monad
} 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e4bdcb15-40ed-4501-8c07-6b51ab213365%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: errors/wrap.go looks like it could be made into a more general monad package?

[Gert]

On Wednesday, July 3, 2019 at 3:03:20 AM UTC+2, Gert wrote:
>
> https://github.com/golang/go/blob/master/src/errors/wrap.go
>
> What if we replaced all error types in that file with a empty interface or 
> a general monad interface? Can we make it work for other types too and 
> introduce a new monad package instead a new error package only?
>
>
package monad

type Monad interface {
Unwrap(m monad) monad
Is(m, target monad) bool
As(m monad, target interface{}) bool
}
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/676f1ceb-2704-4534-ac5b-70c033767fa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] errors/wrap.go looks like it could be made into a more general monad package?

[Gert]

https://github.com/golang/go/blob/master/src/errors/wrap.go

What if we replaced all error types in that file with a empty interface or 
a general monad interface? Can we make it work for other types too and 
introduce a new monad package instead a new error package only?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e4d546dd-2032-43f3-8d3b-40398ac63527%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go build src code of `go doc`

[Gert]

On Thursday, June 27, 2019 at 1:44:20 AM UTC+2, Gert wrote:
>
> On Thursday, June 27, 2019 at 12:11:58 AM UTC+2, Ian Lance Taylor wrote:
>>
>> On Wed, Jun 26, 2019 at 1:39 PM Gert  wrote: 
>> > 
>> > Hmm trying to work on the src code of `go doc` but every time I try to 
>> compile a ./doc binary it uses other src code, it doesn't look in the 
>> current directory am in, I have to force it `go build main.go` what going 
>> on here? 
>> > 
>> > gert@gert ~/Desktop/go/src/cmd/doc:master> go build 
>> > 
>> > gert@gert ~/Desktop/go/src/cmd/doc:master> ls 
>> > dirs.go doc doc_test.go main.go pkg.go 
>>  testdata 
>> > 
>> > I can see a doc binary getting created but its not build form the 
>> main.go in current directory, I deliberately put a syntax error in main? 
>> > 
>> > gert@gert ~/Desktop/go/src/cmd/doc:master> go build main.go 
>> > # command-line-arguments 
>> > ./main.go:78:2: syntax error: unexpected --, expecting } 
>> > 
>> > gert@gert ~/Desktop/go/src/cmd/doc:master> go env 
>> > GOARCH="amd64" 
>> > GOBIN="/Users/gert/bin" 
>> > GOCACHE="/Users/gert/Library/Caches/go-build" 
>> > GOEXE="" 
>> > GOFLAGS="" 
>> > GOHOSTARCH="amd64" 
>> > GOHOSTOS="darwin" 
>> > GOOS="darwin" 
>> > GOPATH="/Users/gert/go" 
>> > GOPROXY="" 
>> > GORACE="" 
>> > GOROOT="/usr/local/go" 
>> > GOTMPDIR="" 
>> > GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" 
>> > GCCGO="gccgo" 
>> > CC="clang" 
>> > CXX="clang++" 
>> > CGO_ENABLED="1" 
>> > GOMOD="/Users/gert/Desktop/go/src/cmd/go.mod" 
>> > CGO_CFLAGS="-g -O2" 
>> > CGO_CPPFLAGS="" 
>> > CGO_CXXFLAGS="-g -O2" 
>> > CGO_FFLAGS="-g -O2" 
>> > CGO_LDFLAGS="-g -O2" 
>> > PKG_CONFIG="pkg-config" 
>> > GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics 
>> -Qunused-arguments -fmessage-length=0 
>> -fdebug-prefix-map=/var/folders/dv/8tlwvjr91zjdyq4rk14lkkfmgn/T/go-build645754300=/tmp/go-build
>>  
>> -gno-record-gcc-switches -fno-common" 
>>
>>
>> This may be related to https://golang.org/issue/32724.  Is your 
>> cmd/doc directory underneath the directory displayed by `go env 
>> GOROOT`? 
>>
>> Ian 
>>
>
> Nope `~/Desktop/go/src/cmd/doc` (git clone of go itself) is not in GOROOT 
> nor in GOPATH using a seperate bootstrap go version devel +f938b9b33b Wed 
> Jun 26 20:26:48 2019 + darwin/amd64 in /usr/local/go
>
> So I assume if I match GOROOT with the repo as in git clone everything in 
> /usr/local/go and bootstrap using a /usr/local/go1 then i can work on go 
> doc. Going to try that now
>

Yep working when I develop in GOROOT directly, but not sure if this 
intended by design that you can only develop on go src itself that way.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e4baf719-a801-4a68-8141-637200da0405%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go build src code of `go doc`

[Gert]

On Thursday, June 27, 2019 at 12:11:58 AM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Jun 26, 2019 at 1:39 PM Gert > 
> wrote: 
> > 
> > Hmm trying to work on the src code of `go doc` but every time I try to 
> compile a ./doc binary it uses other src code, it doesn't look in the 
> current directory am in, I have to force it `go build main.go` what going 
> on here? 
> > 
> > gert@gert ~/Desktop/go/src/cmd/doc:master> go build 
> > 
> > gert@gert ~/Desktop/go/src/cmd/doc:master> ls 
> > dirs.go doc doc_test.go main.go pkg.go   
>testdata 
> > 
> > I can see a doc binary getting created but its not build form the 
> main.go in current directory, I deliberately put a syntax error in main? 
> > 
> > gert@gert ~/Desktop/go/src/cmd/doc:master> go build main.go 
> > # command-line-arguments 
> > ./main.go:78:2: syntax error: unexpected --, expecting } 
> > 
> > gert@gert ~/Desktop/go/src/cmd/doc:master> go env 
> > GOARCH="amd64" 
> > GOBIN="/Users/gert/bin" 
> > GOCACHE="/Users/gert/Library/Caches/go-build" 
> > GOEXE="" 
> > GOFLAGS="" 
> > GOHOSTARCH="amd64" 
> > GOHOSTOS="darwin" 
> > GOOS="darwin" 
> > GOPATH="/Users/gert/go" 
> > GOPROXY="" 
> > GORACE="" 
> > GOROOT="/usr/local/go" 
> > GOTMPDIR="" 
> > GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" 
> > GCCGO="gccgo" 
> > CC="clang" 
> > CXX="clang++" 
> > CGO_ENABLED="1" 
> > GOMOD="/Users/gert/Desktop/go/src/cmd/go.mod" 
> > CGO_CFLAGS="-g -O2" 
> > CGO_CPPFLAGS="" 
> > CGO_CXXFLAGS="-g -O2" 
> > CGO_FFLAGS="-g -O2" 
> > CGO_LDFLAGS="-g -O2" 
> > PKG_CONFIG="pkg-config" 
> > GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics 
> -Qunused-arguments -fmessage-length=0 
> -fdebug-prefix-map=/var/folders/dv/8tlwvjr91zjdyq4rk14lkkfmgn/T/go-build645754300=/tmp/go-build
>  
> -gno-record-gcc-switches -fno-common" 
>
>
> This may be related to https://golang.org/issue/32724.  Is your 
> cmd/doc directory underneath the directory displayed by `go env 
> GOROOT`? 
>
> Ian 
>

Nope `~/Desktop/go/src/cmd/doc` (git clone of go itself) is not in GOROOT 
nor in GOPATH using a seperate bootstrap go version devel +f938b9b33b Wed 
Jun 26 20:26:48 2019 + darwin/amd64 in /usr/local/go

So I assume if I match GOROOT with the repo as in git clone everything in 
/usr/local/go and bootstrap using a /usr/local/go1 then i can work on go 
doc. Going to try that now

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c12f9d61-5c8d-4880-80a4-aa9b749a560d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] go build src code of `go doc`

[Gert]

Hmm trying to work on the src code of `go doc` but every time I try to 
compile a ./doc binary it uses other src code, it doesn't look in the 
current directory am in, I have to force it `go build main.go` what going 
on here? 

gert@gert ~/Desktop/go/src/cmd/doc:master> go build

gert@gert ~/Desktop/go/src/cmd/doc:master> ls
dirs.go doc doc_test.go main.go pkg.go  
testdata

I can see a doc binary getting created but its not build form the main.go 
in current directory, I deliberately put a syntax error in main?

gert@gert ~/Desktop/go/src/cmd/doc:master> go build main.go 
# command-line-arguments
./main.go:78:2: syntax error: unexpected --, expecting }

gert@gert ~/Desktop/go/src/cmd/doc:master> go env
GOARCH="amd64"
GOBIN="/Users/gert/bin"
GOCACHE="/Users/gert/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/gert/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/gert/Desktop/go/src/cmd/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 
-fdebug-prefix-map=/var/folders/dv/8tlwvjr91zjdyq4rk14lkkfmgn/T/go-build645754300=/tmp/go-build
 
-gno-record-gcc-switches -fno-common"



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4c3e47ca-f73d-4593-ba36-d0974ad36239%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] interface{private()}

[Gert]

Thanks, does the go standard library have a use case where a private() 
function in a interface is needed? Looking for more examples to understand 
the benefit to do so.

On Friday, June 21, 2019 at 2:36:01 AM UTC+2, Ian Lance Taylor wrote:
>
> On Thu, Jun 20, 2019 at 5:25 PM Gert > 
> wrote: 
> > 
> > Trying to get my mind around why the private() function is necessary 
> here. I fail to understand the comment provided 
> > 
> > type Geometry interface { 
> >   GeoJSONType() string 
> >   Dimensions() int // e.g. 0d, 1d, 2d 
> >   Bound() Bound 
> > 
> >   // requiring because sub package type switch over all possible types. 
> >   private() 
> > } 
> > 
> > https://github.com/paulmach/orb/blob/master/geometry.go#L10 
>
> Some packages use an unexported method like this to ensure that no 
> type defined outside of the package can implement the interface. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d5e8602c-7fdc-477e-806e-7e675bd5a2d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] interface{private()}

[Gert]

Trying to get my mind around why the private() function is necessary here. 
I fail to understand the comment provided

type Geometry interface {
  GeoJSONType() string
  Dimensions() int // e.g. 0d, 1d, 2d
  Bound() Bound

  // requiring because sub package type switch over all possible types.
  private()
}

https://github.com/paulmach/orb/blob/master/geometry.go#L10

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/32e99338-dd59-4c34-8d0a-1d892a8a0655%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] https://godoc.org/github.com/couchbase/moss

[Gert]

thx, filed at https://github.com/golang/go/issues/32588

On Wednesday, June 12, 2019 at 11:48:20 PM UTC+2, andrey mirtchovski wrote:
>
> collection is not an exported type: 
> https://github.com/couchbase/moss/blob/master/collection.go#L24 
>
> the ?m=all parameter should enable you to see those, but it's not 
> working for me on your link. perhaps because "collection" and 
> "Collection" are not considered by godoc to be two different things? 
> you may have to file a bug. 
>
> here's more info on m=all: https://godoc.org/golang.org/x/tools/cmd/godoc 
>
> On Wed, Jun 12, 2019 at 3:25 PM Gert > 
> wrote: 
> > 
> > Is it just me or is stuff missing in godoc like for example 
> > 
> > // NewBatch returns a new Batch instance with hinted amount of 
> > // resources expected to be required. 
> > func (m *collection) NewBatch(totalOps, totalKeyValBytes int) ( 
> > ... 
> > } 
> > 
> > from collection.go 
> > 
> > https://godoc.org/github.com/couchbase/moss 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0a178836-4d40-4d3b-ba6d-44d1da2ea9a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] https://godoc.org/github.com/couchbase/moss

[Gert]

aaa ok thx

On Wednesday, June 12, 2019 at 11:40:29 PM UTC+2, David Anderson wrote:
>
> collection is an unexported type. Godoc doesn't show unexported types by 
> default, so none of the methods of collection will appear.
>
> On Wed, Jun 12, 2019 at 2:25 PM Gert > 
> wrote:
>
>> Is it just me or is stuff missing in godoc like for example
>>
>> // NewBatch returns a new Batch instance with hinted amount of
>> // resources expected to be required.
>> func (m *collection) NewBatch(totalOps, totalKeyValBytes int) (
>> ...
>> }
>>
>> from collection.go
>>
>> https://godoc.org/github.com/couchbase/moss
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9bb9d420-e320-42fd-9b4f-4106ea47982e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] https://godoc.org/github.com/couchbase/moss

[Gert]

Is it just me or is stuff missing in godoc like for example

// NewBatch returns a new Batch instance with hinted amount of
// resources expected to be required.
func (m *collection) NewBatch(totalOps, totalKeyValBytes int) (
...
}

from collection.go

https://godoc.org/github.com/couchbase/moss

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fd93525d-f221-4d95-9f20-44dc60308538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [Go2] move everything to gopath so goroot isn't required anymore

[Gert]

https://github.com/golang/go/issues/29070

On Monday, December 3, 2018 at 5:01:59 AM UTC+1, Gert wrote:
>
> Ok thx I will also look on the github repo if I can find it, if not I 
> create a new one
>
> On Monday, December 3, 2018 at 4:22:48 AM UTC+1, Sam Whited wrote:
>>
>> There has been some discussion of making packages in the standard library 
>> into modules (once that's the default versioning system) which could be 
>> versioned separately from Go so that fixes could be released without having 
>> to wait on the full Go release cycle. I can't find a link at the moment, 
>> but the Go team has mentioned the possibility of doing this. 
>>
>> —Sam 
>>
>> On Sun, Dec 2, 2018, at 21:04, Gert wrote: 
>> > Can we move stdlib (goroot) to gopath in Go2? On install you can do go 
>> get 
>> > -u stdlib to download the stdlib into gopath. Basically getting rid of 
>> > goroot. 
>>
>

-- 
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] [Go2] move everything to gopath so goroot isn't required anymore

[Gert]

Ok thx I will also look on the github repo if I can find it, if not I 
create a new one

On Monday, December 3, 2018 at 4:22:48 AM UTC+1, Sam Whited wrote:
>
> There has been some discussion of making packages in the standard library 
> into modules (once that's the default versioning system) which could be 
> versioned separately from Go so that fixes could be released without having 
> to wait on the full Go release cycle. I can't find a link at the moment, 
> but the Go team has mentioned the possibility of doing this. 
>
> —Sam 
>
> On Sun, Dec 2, 2018, at 21:04, Gert wrote: 
> > Can we move stdlib (goroot) to gopath in Go2? On install you can do go 
> get 
> > -u stdlib to download the stdlib into gopath. Basically getting rid of 
> > goroot. 
>

-- 
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] [Go2] move everything to gopath so goroot isn't required anymore

[Gert]

Can we move stdlib (goroot) to gopath in Go2? On install you can do go get 
-u stdlib to download the stdlib into gopath. Basically getting rid of 
goroot.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: `go test -c` skips init from main while `go test` doesn't

[Gert]

I made a wrong conclusion and run a executable not representing the build 
because it failed so it didn't replaced the old executable. Unrelated with 
the title I am a bit confused why it didn't build in the first place? 
Thanks.

go build -a -tags 'netgo noplugin' -ldflags '-d -extldflags "-static"' -gcflags 
"all=-N -l" -o main

/usr/local/go/pkg/tool/darwin_amd64/link: $WORK/b072/_pkg_.a(_go_.o): cannot 
use dynamic imports with -d flag
/usr/local/go/pkg/tool/darwin_amd64/link: $WORK/b085/_pkg_.a(_go_.o): cannot 
use dynamic imports with -d flag
/usr/local/go/pkg/tool/darwin_amd64/link: $WORK/b086/_pkg_.a(_go_.o): cannot 
use dynamic imports with -d flag
crypto/x509(__TEXT/__text): relocation target SecTrustCopyAnchorCertificates 
not defined
crypto/x509(__TEXT/__text): relocation target kCFAllocatorDefault not defined
crypto/x509(__TEXT/__text): relocation target CFDataCreateMutable not defined
crypto/x509(__TEXT/__text): relocation target CFArrayGetCount not defined
crypto/x509(__TEXT/__text): relocation target CFArrayGetValueAtIndex not defined
crypto/x509(__TEXT/__text): relocation target SecKeychainItemExport not defined
crypto/x509(__TEXT/__text): relocation target CFDataGetBytePtr not defined
crypto/x509(__TEXT/__text): relocation target CFDataGetLength not defined
crypto/x509(__TEXT/__text): relocation target CFDataAppendBytes not defined
crypto/x509(__TEXT/__text): relocation target CFRelease not defined
crypto/x509(__TEXT/__text): relocation target CFRelease not defined
crypto/x509(__TEXT/__text): relocation target __stack_chk_guard not defined
crypto/x509(__TEXT/__text): relocation target sysctlbyname not defined
crypto/x509(__TEXT/__text): relocation target __stack_chk_guard not defined
crypto/x509(__TEXT/__text): relocation target __stack_chk_fail not defined
crypto/x509(__TEXT/__text): relocation target __stack_chk_guard not defined
crypto/x509(__TEXT/__text): relocation target sysctlbyname not defined
crypto/x509(__TEXT/__text): relocation target CFStringCreateWithCString not 
defined
/usr/local/go/pkg/tool/darwin_amd64/link: too many errors


On Wednesday, August 15, 2018 at 2:10:23 AM UTC+2, Jake Montgomery wrote:
I am unable to reproduce using a small test app on either Windows or 
Ubuntu, using go 1.10.3. In all cases the init() function in main is run 
when the test binary is run. Perhaps you could provide a minimal 
reproducible example?

On Monday, August 13, 2018 at 8:21:30 PM UTC-4, Gert wrote:
Hi, `go test` runs the main init but the binary created by 


go test -c -a -tags 'netgo noplugin' -gcflags "all=-N -l"


doesn't. Is this a bug? Also it's seems you can't compile static test 
binaries only non test binaries can be compiled static?
I made a wrong conclusion and run a executable not representing the build 
because it failed so it didn't replaced the old executable. Unrelated with 
the title am a bit confused why I can't build the following? sasa 

go build -a -tags 'netgo noplugin' -ldflags '-d -extldflags "-static"' -gcflags 
"all=-N -l" -o main

/usr/local/go/pkg/tool/darwin_amd64/link: $WORK/b072/_pkg_.a(_go_.o): cannot 
use dynamic imports with -d flag
/usr/local/go/pkg/tool/darwin_amd64/link: $WORK/b085/_pkg_.a(_go_.o): cannot 
use dynamic imports with -d flag
/usr/local/go/pkg/tool/darwin_amd64/link: $WORK/b086/_pkg_.a(_go_.o): cannot 
use dynamic imports with -d flag
crypto/x509(__TEXT/__text): relocation target SecTrustCopyAnchorCertificates 
not defined
crypto/x509(__TEXT/__text): relocation target kCFAllocatorDefault not defined
crypto/x509(__TEXT/__text): relocation target CFDataCreateMutable not defined
crypto/x509(__TEXT/__text): relocation target CFArrayGetCount not defined
crypto/x509(__TEXT/__text): relocation target CFArrayGetValueAtIndex not defined
crypto/x509(__TEXT/__text): relocation target SecKeychainItemExport not defined
crypto/x509(__TEXT/__text): relocation target CFDataGetBytePtr not defined
crypto/x509(__TEXT/__text): relocation target CFDataGetLength not defined
crypto/x509(__TEXT/__text): relocation target CFDataAppendBytes not defined
crypto/x509(__TEXT/__text): relocation target CFRelease not defined
crypto/x509(__TEXT/__text): relocation target CFRelease not defined
crypto/x509(__TEXT/__text): relocation target __stack_chk_guard not defined
crypto/x509(__TEXT/__text): relocation target sysctlbyname not defined
crypto/x509(__TEXT/__text): relocation target __stack_chk_guard not defined
crypto/x509(__TEXT/__text): relocation target __stack_chk_fail not defined
crypto/x509(__TEXT/__text): relocation target __stack_chk_guard not defined
crypto/x509(__TEXT/__text): relocation target sysctlbyname not defined
crypto/x509(__TEXT/__text): relocation target CFStringCreateWithCString not 
defined
/usr/local/go/pkg/tool/darwin_amd64/link: too many errors


On Wednesday, August 15, 2018 at 2:10:23 AM UTC+2, Jake Montgomery wrote:
>
> I am unable to reproduce using a small test app on either Wind

[go-nuts] `go test -c` skips init from main while `go test` doesn't

[Gert]

Hi, `go test` runs the main init but the binary created by 

go test -c -a -tags 'netgo noplugin' -gcflags "all=-N -l"

doesn't. Is this a bug? Also it's seems you can't compile static test 
binaries only non test binaries can be compiled static?

-- 
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] [Go2] cleanup deprecated code

[Gert]

Make sure you can track all deprecated code for Go2 for removal

example https://golang.org/src/encoding/csv/reader.go#L109

`TrailingComma bool  // ignored; here 
for backwards compatibility`

Life is to short to wait another 10 years to fix things

Thx

-- 
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: defer func() { _ = resp.Body.Close() }()

[Gert]

Never mind the tool is right I could print the error or something like 
that, I assumed you couldn't do anything useful with the error anyway in a 
defer

On Wednesday, August 16, 2017 at 2:05:39 PM UTC+2, Gert wrote:
>
> To pass errcheck I need to do something like
>
> defer func() { _ = resp.Body.Close() }()
>
> instead of 
>
> defer resp.Body.Close()
>
> Is this something the errcheck tool can figure out to mark as valid 
> instead or does the errcheck tool need help from the compiler so the second 
> case is also ok?
>
>

-- 
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] defer func() { _ = resp.Body.Close() }()

[Gert]

To pass errcheck I need to do something like

defer func() { _ = resp.Body.Close() }()

instead of 

defer resp.Body.Close()

Is this something the errcheck tool can figure out to mark as valid instead 
or does the errcheck tool need help from the compiler so the second case is 
also ok?

-- 
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] [Go2] append

[Gert]

On Monday, August 7, 2017 at 9:39:06 PM UTC+2, Jan Mercl wrote:
>
>
> Does this code really output what you want it to output? 
> https://play.golang.org/p/DWQXtkGByv
>
> Assigning the result value of append to a different variable than its 
> first argument is completely valid, but one has to be really sure why to do 
> that. Did you mean https://play.golang.org/p/-OMw3qGYjU ?
>
>
Exactly, pretty sure some day if Go get used in a power plant or something 
we will have a outage for bugs like this that fly under the radar so easily 
passing all tooling, error checks and probably unit tests too :) 

-- 
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: [Go2] Reflect

[Gert]

On Monday, August 7, 2017 at 5:59:15 PM UTC+2, rog wrote: 
>
> What is this supposed to do? What does it do if the value 
> isn't an integer? 


Same error as you do int("4") 
  

> Are you thinking that it would be the same as fmt.Println("value:", 
> r.Interface().(int)) ? 
>

Nope more that it acts as a basic type like a int(4) so that reflect is the 
same as any other basic types float int byte string etc

-- 
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] [Go2] append

[Gert]

Can append or the compiler be made to prevent or warn for bugs like this?

package main

import (
"fmt"
)

func main() {
a := []byte("Help")
b := append(a, []byte(" Me ")...)
c := append(a, []byte(" Her")...)
fmt.Println(string(a), "-", string(b), "-", string(c))
}

-- 
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: [Go2] Reflect

[Gert Cuykens]

On Mon, Aug 7, 2017 at 12:03 PM, roger peppe  wrote:
> ISTM that the only thing you're suggesting is to change
> the spelling of "reflect.ValueOf" to "reflect".
>
> I don't understand what semantics you'd expect
>
> fmt.Println("value:", r.Value(int))
>
> to have. What's the parameter to that Value method?
>

Merge ValueOf and TypeOf into one reflect() build in and make the
reflect type transform easier with other types fmt.Println("value:",
int(r.Value))

-- 
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: [Go2] Reflect

[Gert]

On Monday, August 7, 2017 at 12:41:18 AM UTC+2, kortschak wrote:
>
> The reflect package is not mentioned in the spec (except once to 
> discuss struct tags), adding a built-in would require its definition 
> there, and complicate the language. Making it easier to use would also 
> have the disadvantage of increasing its use, packages with heavy 
> reflect use tend to be harder to reason about by virtue of having 
> reduced type constraints. 
>
> https://blog.golang.org/laws-of-reflection 
>
>
 I agree but so is cgo and disabling reflect by default i would not mind, 
but the fact is sometimes you have to use it. And when you need to use it 
you already drowning in complicated code to begin with, no need to make it 
even more complicated. Lets meet in the middle by only allowing reflect 
with a build flag.

-- 
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: [Go2] Reflect

[Gert]

Yes but its the way it's done that i think could be made more 
straightforward, why not merge ValueOf and TypeOf in a build in 
intermediate reflect type as in for example int(4) but then reflect(4)

On Sunday, August 6, 2017 at 5:57:40 PM UTC+2, Rich wrote:
>
> I don't understand... doesn't Reflect already do this?
> https://play.golang.org/p/CIm7aISztv
>
>
> On Saturday, August 5, 2017 at 12:58:52 PM UTC-4, Gert wrote:
>>
>> package main
>>
>> import (
>> "fmt"
>> "reflect"
>> )
>>
>> func main() {
>> x := 4
>> v1 := reflect.ValueOf(x)
>> fmt.Println("type:", v1.Type())
>> v2 := reflect.TypeOf(x)
>> fmt.Println("type:", v2)
>> }
>>
>> Kan we have something like this instead please
>>
>> package main
>>
>> import (
>> "fmt"
>> "reflect"
>> )
>>
>> func main() {
>> x := 4
>> r := reflect(x)
>> fmt.Println("type:", r.Type())
>> fmt.Println("value:", r.Value(int))
>> }
>>
>> Reflect should be a generic way of Go2, but everytime i need to reflect 
>> around a Go1 interface i want to go on a vacation...
>>
>>

-- 
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] [Go2] Reflect

[Gert]

package main

import (
"fmt"
"reflect"
)

func main() {
x := 4
v1 := reflect.ValueOf(x)
fmt.Println("type:", v1.Type())
v2 := reflect.TypeOf(x)
fmt.Println("type:", v2)
}

Kan we have something like this instead please

package main

import (
"fmt"
"reflect"
)

func main() {
x := 4
r := reflect(x)
fmt.Println("type:", r.Type())
fmt.Println("value:", r.Value(int))
}

Reflect should be a generic way of Go2, but everytime i need to reflect 
around a Go1 interface i want to go on a vacation...

-- 
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] [Go2] Proposal remove function return type brackets

[Gert Cuykens]

Valid argument thx

On Sun, Jul 23, 2017 at 7:23 PM, Rémy Oudompheng
<remyoudomph...@gmail.com> wrote:
> With this proposal, can you tell whether the following function F
> returns one argument (a function) or two arguments (a function and an
> error) :
>
> func F() func(string) []byte, error {
>blah
> }
>
> Rémy.
>
> 2017-07-23 18:18 GMT+02:00 Gert <gert.cuyk...@gmail.com>:
>> I personally don't think () is necessary for output types and is only
>> confusing with the function attributes
>>
>> Example
>>
>> func Hello(b string) ([]byte, error) {
>>   
>> }
>>
>> func Hello(b string) []byte, error {
>>   
>> }
>>
>> func Hello(b string) a []byte, b error {
>>   
>> }
>>
>> Feel free to counter argument against the proposal or if already proposed
>>
>> --
>> 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] [Go2] Proposal remove function return type brackets

[Gert]

I personally don't think () is necessary for output types and is only 
confusing with the function attributes 

Example 

func Hello(b string) ([]byte, error) {
  
}

func Hello(b string) []byte, error {
  
}

func Hello(b string) a []byte, b error {
  
}

Feel free to counter argument against the proposal or if already proposed

-- 
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: [Go2] toward-go2

[Gert]

Let me ask it differently what is going to happen with all the Go2 labeled 
issues on github? For me experience report is nothing different then a 
github issue and also nobody of the go team will be able to handle all the 
incoming false positives of people like me that think have a great idea but 
actually isn't or already has been addressed. Sorry I just prefer the other 
way around, the go team makes a report looking at golang code on github and 
question on stackoverflow and make proposal to clean up standard library 
and improve the language. The same way to go team did with Go 1.9 and type 
aliases. Reporting the issue listen to feedback and implement it. Go2 
should be a breath of fresh air to finally undo a few mistakes and clean 
things up, it should definitely not be a publicity stunt and just leave all 
the mistakes in to be backward compatible.

On Monday, July 17, 2017 at 7:06:15 AM UTC+2, Nathan Kerr wrote:
>
> The active work for Go2 right now is gathering experience reports 
> <http://golang.org/wiki/ExperienceReports>. Most of the changes resulting 
> from these reports will land in Go1.x. It is expected that Go2 will only 
> have a few major changes that will not be compatible with Go1. It is also 
> possible there will be none (and Go1.20 will be called Go2)
>
> The Go2 label in the issue tracker has meant, more or less, that the 
> issue/proposal was something that could't be considered for Go1, usually 
> because it would be the Go1 compatibility promise, but should be kept track 
> of.
>
> Apple didn't mention Swift because Apple doesn't mention things it is 
> working on. Working in private and then releasing when things are ready is 
> how Apple does things.
>
> On Monday, July 17, 2017 at 5:42:34 AM UTC+2, Gert wrote:
>>
>> There are so many 
>> https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+go2+label%3AGo2 
>> proposals already I can barely figure out if feature x y or z is already 
>> asked.
>>
>> Can we have a Go2 branch / milestone please? PS now that you announced 
>> toward-go2 you are going to actively work on Go2 right? Its not some kind 
>> of lets try to trick developers to keep using Go who are looking for 
>> alternatives because they made a Go2 proposal many years ago and gave up 
>> hope right? Don't get me wrong I love Go but I hate false promises or 
>> making plans ridiculous far in the future. Not saying Go2 can't take a long 
>> time to make, just saying i would like to see small bits of code emerging 
>> on a weekly bases we can test and play around with and give feedback on 
>> real things not just imaginary ideas :) If you can't make a Go2 branch yet 
>> and more important things need to be done first on Go1 I understand 
>> completely, but once you pull the Go2 card companies will pull back and 
>> start waiting for Go2. Its the number one reason Apple didn't mention a 
>> single word about Swift until they could deliver a fully functioning 
>> compiler just because of that reasons to not jeopardise developers stop 
>> learning objective c and waiting for Swift
>>
>

-- 
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] [Go2] toward-go2

[Gert]

There are so 
many https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+go2+label%3AGo2 
proposals already I can barely figure out if feature x y or z is already 
asked.

Can we have a Go2 branch / milestone please? PS now that you announced 
toward-go2 you are going to actively work on Go2 right? Its not some kind 
of lets try to trick developers to keep using Go who are looking for 
alternatives because they made a Go2 proposal many years ago and gave up 
hope right? Don't get me wrong I love Go but I hate false promises or 
making plans ridiculous far in the future. Not saying Go2 can't take a long 
time to make, just saying i would like to see small bits of code emerging 
on a weekly bases we can test and play around with and give feedback on 
real things not just imaginary ideas :) If you can't make a Go2 branch yet 
and more important things need to be done first on Go1 I understand 
completely, but once you pull the Go2 card companies will pull back and 
start waiting for Go2. Its the number one reason Apple didn't mention a 
single word about Swift until they could deliver a fully functioning 
compiler just because of that reasons to not jeopardise developers stop 
learning objective c and waiting for Swift

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