date:20210324

Sorry I forgot 1 more expectation/boundary condition: I'd like to be
able to tar both go code in the local filesystem and the referenced go
packages in the local filesystem and copy it to a different OS to
different absolute paths?
I believe I can't use replace?


On 3/24/21, fge...@gmail.com  wrote:
> Assuming GO111MODULE=on, if I don't want to publish anything and I
> only want to build go code in the local filesystem, referencing only
> go packages in the local filesystem.
>
> Can I do that without local version control software and a private module
> proxy?
>
> After reading most module documentation on golang.org, I still can't
> answer this question.
> If anybody already does that, could you please share your setup?
> If a local version control and a private module proxy is needed, could
> you also please share the details?
>
> 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/CA%2Bctqroy91XgrtAXN_kf%2B7xJZy1zmXJ8v4eADjcDDv5DSEHS0Q%40mail.gmail.com.

[go-nuts] what is a minimal setup for compiling go programs in module mode?

Assuming GO111MODULE=on, if I don't want to publish anything and I
only want to build go code in the local filesystem, referencing only
go packages in the local filesystem.

Can I do that without local version control software and a private module proxy?

After reading most module documentation on golang.org, I still can't
answer this question.
If anybody already does that, could you please share your setup?
If a local version control and a private module proxy is needed, could
you also please share the details?

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/CA%2Bctqron2z0tRfO1jtkurfmc_CXOogG9o4d28g%2Bfg8WaXH6wkw%40mail.gmail.com.

Re: [go-nuts] Re: what is a minimal setup for compiling go programs in module mode?

Thanks, that's exactly what I was looking for!

For the next go programmer looking for a solution in similar situation:
on page https://golang.org/ref/mod#vendoring
"... or to ensure that all files used for a build are stored in a
single file tree"



On 3/24/21, Miguel Angel Rivera Notararigo  wrote:
> You can use the vendor folder, just copy (or symlink, but you will need to
> keep them updated) what you need there and will work.
>

-- 
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/CA%2BctqrrSX%3DSi0iqRwBKrr0pSz_yd2n6by9RrowfwicBKMoCbjg%40mail.gmail.com.

Re: [go-nuts] sigTERM not intercepted

2021-03-24 Thread madscientist

On 3/23/21 11:59 PM, Kurtis Rader wrote:
> It sounds as if you might be running your "REST endpoint" program from
> an interactive shell (i.e., a terminal) and sending SIGTERM by
> pressing something like Ctrl-C. Interactive job control, which
> includes how signals generated by a "terminal" are handled, is a
> complex topic. So we need to know how you are sending SIGTERM to your
> process. Is it by something like the `kill` command or syscall to a
> specific PID or by pressing keys on your terminal to terminate the
> process?

The application is installed as a service and managed via systemctl
start/stop.

There are two types of children -- one type simply runs and then exits:
It's run like this...

funcextractFeatures(s session.Session) (string, error) {
output, err:= exec.Command(
"./signatureml",
//"-debug",
"-model",
"theModel",
"--no-csv-header",
"-csv",
s.ArtifactsPath(),
s.MessagePath()).CombinedOutput()
returnstring(output[:]), err
}

The other type is long-running and communicates via stdin/stdout: It's
run like this...


> typeLongRunningPredictorstruct{
> theCommand *exec.Cmd
> input io.WriteCloser
> output bytes.Buffer
> completionError error
> hasEnded bool
> }

> func(p *LongRunningPredictor) waitLoop() {
> p.hasEnded= false
> p.completionError= p.theCommand.Wait()
> p.hasEnded= true
> }
> func(p *LongRunningPredictor) start() string{
> p.theCommand= exec.Command("./long-running-predictor", "trained-model")
> p.theCommand.Stdout= 
> p.theCommand.Stderr= 
> p.input, _= p.theCommand.StdinPipe()
> p.theCommand.Start()
> startupText, _:= readLinesUpToPrefixBestEffort(, "Ready")
> gop.waitLoop()
> returnstartupText
> }

Long running predictors are cycled through a channel that acts like a
pool -- when one is needed it's pulled from the channel, and when it's
done it's put back to be re-used.

===

Once the rest endpoint app gets the signal to terminate these children
are killed even though, in theory, the signal was captured.

I know the signal was captured because the logic I have in place for a
clean shutdown begins to execute as expected.

Looking forward to a solution or at least an understanding.

Best,

_M


-- 
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/c14fa575-4536-1476-4222-8cfad52ce15f%40gmail.com.

[go-nuts] Re: Client certificate not sent to server

2021-03-24 Thread D.

Elaborating on the previous answer, which led me to the source of the issue 
I'm facing but did not quite solve the problem.

In case you have no control over the server, you are using private CA, and 
the server does not include Certificate Authorities 
 extension in TLS 
Handshake Certificate Request, in this case golang will not include 
certificates from private CAs even if they are included in the tls 
configuration. This can be solved by implementing 
tls.Config.GetClientCertificate and doing the cert, err := 
tls.LoadX509KeyPair(certFile, keyFile) part there.

Hope that helps.

On Wednesday, May 20, 2020 at 2:27:58 AM UTC+3 mspet...@gmail.com wrote:

> I know this is an old thread, but I found it, so others might, too.  
>
> I struggled with a similar problem of the Go HTTP client not sending 
> client certs when challenged by the server.  Yet, curl worked fine when 
> given the same client certs, calling the same server endpoint.  The cert 
> chains I was dealing with look like
>
> leaf + intermediate + root
>
>
> The solution for me was to provide the server (Envoy proxy) with a the 
> root cert AND intermediate cert, the latter of which signed my Go client 
> cert.  When the server challenges the client for its cert, the server will 
> send a TLS Certificate Request with, among other things, the certificate 
> authority that must have signed the client cert.  Without including the 
> intermediate cert with the root cert on the server side, the client cannot 
> not build a complete path from its client cert to the root and therefore 
> cannot determine which cert to send in response.  The client will not use 
> tls.Config.RootCAs in this analysis (RootCAs is for validating the server 
> cert chain).  Moreover, when the client parses its cert with 
>
> cert, err := tls.LoadX509KeyPair(*certFile, *keyFile)
>
>
> only the leaf is returned even if the certFile contains the concatenated 
> intermediate.
>
> Including the full cert bundle on the server side solves this for me.
>
> Hope that helps.
>
>
>
> On Tuesday, March 17, 2015 at 10:19:01 AM UTC-7, Dots Connected wrote:
>>
>> Hello!
>>
>> I am trying to access an API served by nginx (with a self-signed SSL 
>> cert) that requires client certificate authentication, and while I can 
>> successfully auth with curl, I unable to accomplish the same with golang.
>>
>> Example using curl:
>>
>> # Will not work
>> curl -k https://127.0.0.1/api
>>
>> # Works
>> curl -k -E example_key+cert.pem https://127.0.0.1/api
>>
>>
>> I found an example from this list that I've tried to adapt:
>>
>> https://groups.google.com/forum/#!topic/golang-nuts/dEfqPOSccIchttps://groups.google.com/forum/#!topic/golang-nuts/dEfqPOSccIc
>>  
>> 
>> And another from github:
>> https://gist.github.com/michaljemala/d6f4e01c4834bf47a9c4
>>
>> Despite this, golang gets the same result as the first curl with no 
>> client cert.
>> Am I missing something, or is this a regression in go?
>>
>> I'm on go version go1.4.2 linux/amd64. My code (or via 
>> http://pastebin.com/LGiXZpgx):
>>
>> package main
>>
>> import (
>> "crypto/tls"
>> "io/ioutil"
>> "log"
>> "net/http"
>> )
>>
>> func main() {
>>
>> certFile := "example_cert.pem"
>> keyFile := "example_key.pem"
>>
>> // Load client cert
>> cert, err := tls.LoadX509KeyPair(certFile, keyFile)
>> if err != nil {
>> log.Fatal(err)
>> }
>>
>> // Setup HTTPS client
>> tlsConfig := {
>> Certificates: []tls.Certificate{cert},
>> ClientAuth: tls.RequireAndVerifyClientCert,
>> InsecureSkipVerify: true,
>> }
>> tlsConfig.BuildNameToCertificate()
>>
>> transport := {
>> TLSClientConfig: tlsConfig,
>> }
>> client := {
>> Transport: transport,
>> }
>>
>> // Do GET something
>> resp, err := client.Get("https://localhost/api/;)
>> if err != nil {
>> log.Fatal(err)
>> }
>> defer resp.Body.Close()
>>
>> // Dump response
>> data, err := ioutil.ReadAll(resp.Body)
>> if err != nil {
>> log.Fatal(err)
>> }
>> log.Println(string(data))
>> }
>>
>>

-- 
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/dc66f3b0-36bb-4970-90e6-588282b4fbben%40googlegroups.com.

[go-nuts] Tool: envssh client

2021-03-24 Thread Heikki Hellgren

Hi from group newbie,

If anyone's interested I wrote a SSH client with go that allows to copy 
your configuration files and environment variables to the remote while you 
connect. 

You can find the tool from https://github.com/drodil/envssh and I made also 
short demo of the tool to Youtube 
https://www.youtube.com/watch?v=x_4UvVzQRNU

Please feel free to share your thoughs! And of contributions from more 
experienced gophers are more than welcome!

-- 
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/c2350d3c-fb35-4027-991b-8cbc73048a37n%40googlegroups.com.

[go-nuts] Inverting a template

2021-03-24 Thread Matthew Walster

I have a series of web pages generated from a template in OCaml and Perl
that I am able to express succinctly as a template in Go to replicate the
style of for my new implementation.

However, I'd like to do the "inverse" of that template and read a page back
into a struct of data, allowing me to synchronise data between these two
programs. I'm not in control of the applications that generate the data, so
I can't just put it into an intermediary form or API.

Is there any easy way to do that without having to parse and walk through
all the HTML manually, or without some hideous regex? Is that something
that's possible with the template package that I haven't discovered?

Matthew Walster

-- 
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/CADLW2vxw6xHk8yK7E179Wj1iATEErwTO-eoERKrmz0C0mYrO4w%40mail.gmail.com.

[go-nuts] Re: what is a minimal setup for compiling go programs in module mode?

2021-03-24 Thread Amnon

You can just tar up your ~/go/pkg/mod directory (plus your own sources) and 
you will be good.

On Wednesday, 24 March 2021 at 16:19:13 UTC jake...@gmail.com wrote:

> > I believe I can't use replace? 
>
> I'm glad the vendoring solution is what you want. But IIUC what you are 
> trying to do, then there is no reason you can not use replace. For example:
> require gergrly/otherpackage v0.0.0
> replace  gergrly/otherpackage => ../otherpackage 
> This works for me. You could then tar, the outer folder. 
>
>
>

-- 
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/03ecf1f1-7441-41cc-8e76-6049d62e3dccn%40googlegroups.com.

Re: [go-nuts] Re: what is a minimal setup for compiling go programs in module mode?

Thanks to both you and jake!
I remembered something similar to "import path should not be relative
paths". (Otoh the replace directive is not an import path, so I should
have checked before asking this.)
Anyways, thanks again!



On 3/24/21, Amnon  wrote:
> You can just tar up your ~/go/pkg/mod directory (plus your own sources) and
>
> you will be good.
>
> On Wednesday, 24 March 2021 at 16:19:13 UTC jake...@gmail.com wrote:
>
>> > I believe I can't use replace?
>>
>> I'm glad the vendoring solution is what you want. But IIUC what you are
>> trying to do, then there is no reason you can not use replace. For
>> example:
>> require gergrly/otherpackage v0.0.0
>> replace  gergrly/otherpackage => ../otherpackage
>> This works for me. You could then tar, the outer folder.
>>
>>
>>
>
> --
> 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/03ecf1f1-7441-41cc-8e76-6049d62e3dccn%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/CA%2BctqrrKjTrcoKeKjGsPzQcppk2BLvUXhCWANWZ4x3%3D7NtDjiQ%40mail.gmail.com.

Re: [go-nuts] Trying to port Go to HPE NonStop x86 - Need some guidance

2021-03-24 Thread Shiva

Thank you for that, Ian. 

Just to confirm, I see the following - 

*_linux.c, 
*_linux.h,
*_linux.go,
*_linux.s,
*_linux.pl 

They are in different directories - crypto, internal\syscall, net, os, 
runtime, sync\atomic and syscall under the src directory. But you had 
earlier mentioned only runtime and syscall packages so do I have to add the 
rest too?

After this I suppose I run bootstrap.bash which should create a go package 
that I should try and run on the Nonstop. 


On Tuesday, March 23, 2021 at 6:51:55 PM UTC Ian Lance Taylor wrote:

> On Tue, Mar 23, 2021 at 9:41 AM Shiva  wrote:
> >
> > Trying to pick this up where it was left, we have the list of files 
> *_linux.go, *_linux.s but not all of them have the build statements, do we 
> create new nsx files only for those which have build statements in them or 
> for all of those files?
>
> For all of them. And add build tags to all of them. The use of build
> tags in *_linux files is not consistent because the go tool has always
> recognized *_linux file names specially.
>
> Ian
>
> > On Sunday, June 7, 2020 at 2:38:09 AM UTC+1 Ian Lance Taylor wrote:
> >>
> >> On Sat, Jun 6, 2020 at 8:57 AM Randall Becker  
> wrote:
> >> >
> >> > Thanks. Where do fix the linker. I found the files to modify - so 
> will basically copy the *_linux.go, *_linux.s in both runtime and syscalls 
> to *_nsx.go and *_nsx.s, replacing +build lines with nsx instead of linux, 
> I assume. Currently looking for an assembler cross-compiler for the 
> platform (I may have to write one, something I'm much more comfortable with 
> than the GO port) - I can wrap asm in C code, but I don't know how to get 
> GO to recognize that.
> >>
> >> Go uses its own assembler, in cmd/asm.
> >>
> >> Ian
> >>
> >>
> >> > On Friday, 5 June 2020 19:03:07 UTC-4, Ian Lance Taylor wrote:
> >> >>
> >> >> On Fri, Jun 5, 2020 at 3:46 PM Randall Becker  
> wrote:
> >> >> >
> >> >> > That's actually what I figured. So where do I look to add nsx to 
> the toolchain?
> >> >>
> >> >> You'll have to fix the linker to generate whatever nsx expects.
> >> >> You'll have to add code to support nsx in the runtime and syscall
> >> >> packages. Pick which supported OS is most like nsx; let's say it's
> >> >> linux. Look for *_linux.go and *_linux.s files; you'll need nsx
> >> >> versions of those files. Look for +build lines in files that say
> >> >> linux; you'll need to add nsx, or write a separate file that works on
> >> >> nsx.
> >> >>
> >> >> It's a lot of work.
> >> >>
> >> >> Ian
> >> >>
> >> >>
> >> >> > On Friday, 5 June 2020 17:03:11 UTC-4, Ian Lance Taylor wrote:
> >> >> >>
> >> >> >> On Fri, Jun 5, 2020 at 12:49 PM Randall Becker  
> wrote:
> >> >> >> >
> >> >> >> > Some progress. I've managed to build 1.14.4 using the Windows 
> GO implementation. The trouble I was having was using cygwin64. After 
> figuring that part out...
> >> >> >> >
> >> >> >> > I checked out a new branch from release_go1.14 named 
> nonstop_port
> >> >> >> >
> >> >> >> > Then ran
> >> >> >> >
> >> >> >> > GOARCH=amd64 GOOS=nsx bootstrap.bash
> >> >> >> > which failed because I am using cygwin64, but then ran make.bat 
> from inside ../../go-nsx-amd64-bootstrap
> >> >> >> > That installed a go binary in go-nsx-amd64-bootstrap/bin
> >> >> >> >
> >> >> >> > This still used the whatever compiler it chose to use, 
> presumably gcc-generated code, but the executable will not run on the 
> NonStop platform at all. The key here is that I need to use c99 for 
> cross-compilation.
> >> >> >> >
> >> >> >> > Where do I go next, please?
> >> >> >>
> >> >> >> I'm sure how to answer that except to say that you need to add 
> support
> >> >> >> for nsx to the Go toolchain. The Go toolchain is written in Go, 
> not
> >> >> >> C, so the mention of c99 seems irrelevant. Your first step is to
> >> >> >> build a Go toolchain that runs on your host system (not your nsx
> >> >> >> system), which you've done. The second step is to add nsx support 
> to
> >> >> >> the toolchain. The third step is to run bootstrap.bash. The fact
> >> >> >> that bootstrap.bash gives you a program that won't run on nsx 
> suggests
> >> >> >> that the second step is not complete.
> >> >> >>
> >> >> >> Ian
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> > On Wednesday, 27 May 2020 08:01:17 UTC-4, Randall Becker wrote:
> >> >> >> >>
> >> >> >> >> We've gotten nowhere on this despite trying. Installing GO on 
> windows went fine, based on what Ian suggested, but specifying GOOS=nsx 
> fails immediately as being unrecognized (rather obvious). The archictture 
> is not a powerPC, so I'm not sure why I would start there - it is a 
> big-endian x86.
> >> >> >> >>
> >> >> >> >> On Wednesday, 13 May 2020 11:33:00 UTC-4, Bruno Albuquerque 
> wrote:
> >> >> >> >>>
> >> >> >> >>> Now you create your branch or whatever of the Go code and 
> start porting it to your platform. As a first step, you will probably want 
> to add the new nsx GOOS. Then you use your go1.14.2 installation to

[go-nuts] Re: what is a minimal setup for compiling go programs in module mode?

2021-03-24 Thread jake...@gmail.com

 > I believe I can't use replace? 

I'm glad the vendoring solution is what you want. But IIUC what you are 
trying to do, then there is no reason you can not use replace. For example:
require gergrly/otherpackage v0.0.0
replace  gergrly/otherpackage => ../otherpackage 
This works for me. You could then tar, the outer folder. 


-- 
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/7d5a3005-738f-4ac6-8155-b8a446193374n%40googlegroups.com.

Re: [go-nuts] Trying to port Go to HPE NonStop x86 - Need some guidance

On Wed, Mar 24, 2021 at 11:18 AM Shiva  wrote:
>
> Thank you for that, Ian.
>
> Just to confirm, I see the following -
>
> *_linux.c,
> *_linux.h,
> *_linux.go,
> *_linux.s,
> *_linux.pl
>
> They are in different directories - crypto, internal\syscall, net, os, 
> runtime, sync\atomic and syscall under the src directory. But you had earlier 
> mentioned only runtime and syscall packages so do I have to add the rest too?
>
> After this I suppose I run bootstrap.bash which should create a go package 
> that I should try and run on the Nonstop.

In the long run you will most likely have to handle all of those one
way or another, yes.  Except probably for mksysnum_linux.pl.

Ian



> On Tuesday, March 23, 2021 at 6:51:55 PM UTC Ian Lance Taylor wrote:
>>
>> On Tue, Mar 23, 2021 at 9:41 AM Shiva  wrote:
>> >
>> > Trying to pick this up where it was left, we have the list of files 
>> > *_linux.go, *_linux.s but not all of them have the build statements, do we 
>> > create new nsx files only for those which have build statements in them or 
>> > for all of those files?
>>
>> For all of them. And add build tags to all of them. The use of build
>> tags in *_linux files is not consistent because the go tool has always
>> recognized *_linux file names specially.
>>
>> Ian
>>
>> > On Sunday, June 7, 2020 at 2:38:09 AM UTC+1 Ian Lance Taylor wrote:
>> >>
>> >> On Sat, Jun 6, 2020 at 8:57 AM Randall Becker  wrote:
>> >> >
>> >> > Thanks. Where do fix the linker. I found the files to modify - so will 
>> >> > basically copy the *_linux.go, *_linux.s in both runtime and syscalls 
>> >> > to *_nsx.go and *_nsx.s, replacing +build lines with nsx instead of 
>> >> > linux, I assume. Currently looking for an assembler cross-compiler for 
>> >> > the platform (I may have to write one, something I'm much more 
>> >> > comfortable with than the GO port) - I can wrap asm in C code, but I 
>> >> > don't know how to get GO to recognize that.
>> >>
>> >> Go uses its own assembler, in cmd/asm.
>> >>
>> >> Ian
>> >>
>> >>
>> >> > On Friday, 5 June 2020 19:03:07 UTC-4, Ian Lance Taylor wrote:
>> >> >>
>> >> >> On Fri, Jun 5, 2020 at 3:46 PM Randall Becker  
>> >> >> wrote:
>> >> >> >
>> >> >> > That's actually what I figured. So where do I look to add nsx to the 
>> >> >> > toolchain?
>> >> >>
>> >> >> You'll have to fix the linker to generate whatever nsx expects.
>> >> >> You'll have to add code to support nsx in the runtime and syscall
>> >> >> packages. Pick which supported OS is most like nsx; let's say it's
>> >> >> linux. Look for *_linux.go and *_linux.s files; you'll need nsx
>> >> >> versions of those files. Look for +build lines in files that say
>> >> >> linux; you'll need to add nsx, or write a separate file that works on
>> >> >> nsx.
>> >> >>
>> >> >> It's a lot of work.
>> >> >>
>> >> >> Ian
>> >> >>
>> >> >>
>> >> >> > On Friday, 5 June 2020 17:03:11 UTC-4, Ian Lance Taylor wrote:
>> >> >> >>
>> >> >> >> On Fri, Jun 5, 2020 at 12:49 PM Randall Becker  
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > Some progress. I've managed to build 1.14.4 using the Windows GO 
>> >> >> >> > implementation. The trouble I was having was using cygwin64. 
>> >> >> >> > After figuring that part out...
>> >> >> >> >
>> >> >> >> > I checked out a new branch from release_go1.14 named nonstop_port
>> >> >> >> >
>> >> >> >> > Then ran
>> >> >> >> >
>> >> >> >> > GOARCH=amd64 GOOS=nsx bootstrap.bash
>> >> >> >> > which failed because I am using cygwin64, but then ran make.bat 
>> >> >> >> > from inside ../../go-nsx-amd64-bootstrap
>> >> >> >> > That installed a go binary in go-nsx-amd64-bootstrap/bin
>> >> >> >> >
>> >> >> >> > This still used the whatever compiler it chose to use, presumably 
>> >> >> >> > gcc-generated code, but the executable will not run on the 
>> >> >> >> > NonStop platform at all. The key here is that I need to use c99 
>> >> >> >> > for cross-compilation.
>> >> >> >> >
>> >> >> >> > Where do I go next, please?
>> >> >> >>
>> >> >> >> I'm sure how to answer that except to say that you need to add 
>> >> >> >> support
>> >> >> >> for nsx to the Go toolchain. The Go toolchain is written in Go, not
>> >> >> >> C, so the mention of c99 seems irrelevant. Your first step is to
>> >> >> >> build a Go toolchain that runs on your host system (not your nsx
>> >> >> >> system), which you've done. The second step is to add nsx support to
>> >> >> >> the toolchain. The third step is to run bootstrap.bash. The fact
>> >> >> >> that bootstrap.bash gives you a program that won't run on nsx 
>> >> >> >> suggests
>> >> >> >> that the second step is not complete.
>> >> >> >>
>> >> >> >> Ian
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> > On Wednesday, 27 May 2020 08:01:17 UTC-4, Randall Becker wrote:
>> >> >> >> >>
>> >> >> >> >> We've gotten nowhere on this despite trying. Installing GO on 
>> >> >> >> >> windows went fine, based on what Ian suggested, but specifying 
>> >> >> >> >> GOOS=nsx fails immediately as being unrecognized

Re: [go-nuts] sigTERM not intercepted

2021-03-24 Thread Brian Candler

That is, you're sending the SIGTERM via systemd?

Is it possible that systemd is sending it to the whole process group, and 
not just to the parent?  Is systemd running the go command directly, or via 
a shell?

If you want to be 100% sure, you can start the children in separate process 
groups.  For Linux it's something like this (not tried for a while):

p.theCommand.SysProcAttr = {Setsid: true}
err := p.theCommand.Start()

(BTW, I note you weren't checking the error return from Start, which I do 
recommend)

But I'd also check the systemd documentation.  Also try sending a kill 
-TERM  directly to the parent, just to compare.

-- 
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/b866f2a3-e9f8-47b4-bfa5-26c17ba30c60n%40googlegroups.com.

[go-nuts] Re: meaning of SSA operation

2021-03-24 Thread 'drc...@google.com' via golang-nuts

Also, be aware that work that we really hope lands in 1.17 will tinker with 
all the call operations.

The goal is to switch to an ABI that passes parameters to/from calls in 
registers, and the way
that ends up expressed in SSA is that first (and we do this part in 1.16) 
the parameters to the 
call will appear as inputs, and the results will be obtained with 
OpSelectN.  The call will still
receive and return a memory value, as last input and last element of result.

This is then lowered to a machine-agnostic level where some parameters are 
stored in memory,
the others in registers -- where the registers appear as inputs/outputs of 
the call -- and then
further lowered (simple OpCode rewrite) to machine-specific call 
instructions.  The registers themselves
are bound in the register allocator, by the "trick" of telling it that 
Calls have only a single appropriate
register for each of their inputs/outputs.

This might look a little odd the first time you see it.

And, also, the order in which the registers inputs/outputs are encoded is 
not fixed; for compiler
efficiency purposes, we *might* reorder them so that all the integer 
registers come first, etc.
(This would allow a lot more sharing of register masks.)

This full change is likely only for amd64 in 1.17, then for other 
architectures once we figure out
the exact recipe.  It touches many parts of the compiler and runtime.

On Wednesday, March 24, 2021 at 4:01:36 AM UTC-4 Ge wrote:

> Thank you Keith for clarification. It's really of great help.
>
> Ge
>
> 在2021年3月24日星期三 UTC+8 上午7:45:13 写道：
>
>> On Tuesday, March 23, 2021 at 9:11:13 AM UTC-7 Ge wrote:
>>
>>>
>>> Hi,
>>> Recently I encountered a problem which seems to be related to SSA 
>>> optimization 
>>> and feels hard to figure out what some SSA operation means.
>>>
>>> Code:
>>> case1:
>>> func main() {
>>> var x int
>>> go func() {
>>> for {   
>>> x++  //no matter "-N" compile flags is specified or 
>>> not, 'x++' will be optimized
>>> }
>>> }()
>>> println(x)
>>> }
>>>
>>> case2:
>>> func main() {
>>> var x int
>>> go func() {
>>> for {   
>>> x++  
>>> dummy()   // when empty function 'dummy' is added to this 
>>> infinite loop, ''x++' stays last
>>> }
>>> }()
>>> println(x)
>>> }
>>>
>>> //go:noinline
>>> func dummy() {
>>> }
>>>
>>> I tried 'GOSSAFUNC=main.func1 go tool compile case2.go' and found the 
>>> key point is
>>> deadcode phase in SSA. Here is CFG before 'early deadcode' phase:
>>>
>>> ``` *ssaoptx.go*
>>> 5  go func() {
>>> 6  for {
>>> 7  x++
>>> 8  dummy()
>>> 9  }
>>> 10 }()
>>> ```
>>>
>>> ``` *early copyelim*
>>>
>>>- b1:
>>>- 
>>>   - v1 (?) = InitMem 
>>>   - v2 (?) = SP 
>>>   - v3 (?) = SB 
>>>   - v4 (?) = LocalAddr <**int> {} v2 v1
>>>   - v5 (5) = Arg <*int> {} ([*int])
>>>   - v9 (?) = Const64  [1]
>>>- Plain → b2 (*+6*)
>>>
>>>
>>>- b2: ← b1 b4
>>>- 
>>>   - v14 (7) = Phi  v1 v12
>>>   - v15 (7) = Copy <*int> v5 ([*int])
>>>- Plain → b3 (7)
>>>
>>>
>>>- b3: ← b2
>>>- 
>>>   - v6 (7) = Copy <*int> v5 ([*int])
>>>   - v7 (7) = Copy  v14
>>>   - v8 (*+7*) = Load  v5 v14
>>>   - v10 (7) = Add64  v8 v9
>>>   - v11 (7) = Store  {int} v5 v10 v14
>>>   - v12 (*+8*) = StaticCall  {"".dummy} v11
>>>- Plain → b4 (8)
>>>
>>>
>>>- b4: ← b3
>>>- Plain → b2 (7)
>>>
>>>
>>>- b5:
>>>- 
>>>   - v13 (10) = Unknown 
>>>- Ret v13
>>>
>>> ```
>>> deadcode phase will traverse all blocks and find out the reachable 
>>> blocks 
>>> (In above example is b1,b2,b3,b4, while b5 is isolated block), Second it 
>>> will
>>> find out live values based on reachable blocks and eliminate dead values.
>>>
>>> The call of dummy function makes v8,v10,v11 all live so 'x++' isn't 
>>> optimized.
>>> I have read ssa/README.md but still had some questions.
>>>
>>> 1. The role of InitMem.
>>>  It seems that every function starts with it, are some initialize 
>>> work like 
>>>  stack space allocation and named return values initialization done 
>>> by it?
>>>
>>>
>> Not really. Stack space and any zeroing required are done when generating 
>> the preamble. They are not represented in SSA.
>> InitMem is just the initial state of memory on entry to the function. It 
>> does not generate any actual code.
>>  
>>
>>> 2.  The meaning of 'v14 (7) = Phi  v1 v12'.
>>>   It looks like v14 = Φ(v1, v12), but I don't know why InitMem and 
>>> dummy function
>>>   call will affect here.
>>>
>>> 3.  The meaning of of  StaticCall's argument .
>>>   Some ssa operations are easy to understand,  for example,  
>>>   'v8 (*+7*) = Load  v5 v14' means v8=Load(v5) and v14 is 
>>> the memory statewhich implies this load operation must happens 
>>> after v14 is determined.
>>>
>>>   That's all I know from README.md, but about other

Re: [go-nuts] Re: A message from the CoC committee

2021-03-24 Thread 'Thomas Bushnell BSG' via golang-nuts

On Wed, Mar 24, 2021 at 3:18 PM ben...@gmail.com  wrote:

> I'm comparing to various legal systems, in which there is almost always
> the possibility of appeal, even for heinous crimes.
>

Not forever; and especially not in cases of abuse of process. For example,
the United States Supreme Court has an "in forma pauperis" procedure, where
you don't have to pay normal filing fees and the clerks will be very
lenient in whether a petition is in proper form etc. This provides access
to people with worthy cases and no representation. (If the case might be
accepted, the court makes sure to appoint representation, of course.) But
some people will abuse this, and after there have been too many groundless
petitions, the court will order that no further petitions are to be
accepted from that party (in civil cases) without being in correct form
with the filing fee paid. This basically puts a stop to it, because people
repeatedly filing groundless petitions generally don't care to pay $300 for
each one, together with the expense of duplicating forty bound copies of
the petition in the exacting format required.

Thomas

-- 
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/CA%2BYjuxvXYEorS-SQNQpUfQLft3UHFFZ2Hq7hqz-LNdsfLEAHRQ%40mail.gmail.com.

Re: [go-nuts] Re: A message from the CoC committee

2021-03-24 Thread Ben Hoyt

Fair response - pragmatic and helpful. Thanks, Ian. -Ben

On Thu, Mar 25, 2021 at 8:34 AM Ian Lance Taylor  wrote:

> On Wed, Mar 24, 2021 at 12:19 PM ben...@gmail.com 
> wrote:
> >
> > > permanent bans were given to multiple individuals, with no possibility
> for appeal
> >
> > I don't disagree with the bans, but this part -- the "no possibility for
> appeal" seems very ... totalitarian. What if a mistake was made? (Again,
> not saying it was here, but in general, to err is human.) I'm comparing to
> various legal systems, in which there is almost always the possibility of
> appeal, even for heinous crimes. Another aspect is that sometimes people
> change and realize their mistake later, sometimes even because of an
> excommunication like this. What's the rationale for "no possibility of
> appeal"?
>
> My take on this is that if someone has chosen for whatever reason to
> attack a project, an appeals process just provides another mechanism
> for them to consume project resources.
>
> Also, in practice, we are all pseudonyms here anyhow.  If people
> change their ways, they will likely benefit from adopting a new
> pseudonym that is free of any toxicity attached to the old one.
>
> Finally, this is a process run by human beings, not computer code or
> even a legal system.  There can always be adjustments and exceptions
> over time if there are good reasons for them.
>
> 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/CAL9jXCF%2BOXG0srpJcw64yXgBgoqH%2B-bgqc3RA98p0-G9oEQgfg%40mail.gmail.com.

Several messages during the last weeks irritated me and I guess I was not
the only one. Eventually we are all humans but often enough we don’t treat
ourselves like that. Let’s treat machines like machines and humans like
humans - not the other way round.

That’s why I want to say “Thank you Gophers”! Thanks to to Rob, Ken an
Robert for creating an awesome piece of software. Thanks to Russ and Ian
for continuing this work. And thanks to all the contributors no matter for
which company you work.

There will never be a 100% agreement on implementation details and there
will never be a perfect process for decision taking. I believe we are lucky
to have people who can take hard decisions when needed but can also say
“no”. I’d like to express my respect for their work. It’s too easy to blame
others in charge not being in their shoes.

Go is an awesome language with amazing tooling and the latest efforts will
not suddenly morph it into a mess. For some it will further improve, for
others it may become worse. But I believe that essentially Go will remain
awesome.

PS: please excuse me if I couldn’t find proper English terms. It’s already
hard in my mother tongue with Kode and Code and Quellcode and Quelltext :-)

--
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/CALWqRZqjPwkn%3DF7FKUrsvfsUxkJxJkQqjpgOv1joUrbTK%3DJ2FQ%40mail.gmail.com.

[go-nuts] Re: A message from the CoC committee

2021-03-24 Thread ben...@gmail.com

> permanent bans were given to multiple individuals, with no possibility 
for appeal

I don't disagree with the bans, but this part -- the "no possibility for 
appeal" seems very ... totalitarian. What if a mistake was made? (Again, 
not saying it was here, but in general, to err is human.) I'm comparing to 
various legal systems, in which there is almost always the possibility of 
appeal, even for heinous crimes. Another aspect is that sometimes people 
change and realize their mistake later, sometimes even because of an 
excommunication like this. What's the rationale for "no possibility of 
appeal"?

-Ben


On Wednesday, March 24, 2021 at 3:01:37 AM UTC+13 can...@google.com wrote:

> Over the last few days, multiple reports were received at 
> con...@golang.org regarding public conduct on golang-nuts, as well as 
> conduct in private channels.  After review, permanent bans were given to 
> multiple individuals, with no possibility for appeal.  Further corrective 
> actions like temporary bans and final warnings are being deliberated, 
> pending further investigation. 
>
> As stated in our Code of Conduct , we believe 
> that healthy debate and disagreement are essential to a healthy project and 
> community. However, it is never ok to be disrespectful. 
>
> When evaluating a response to a report and making decisions on a 
> corrective action, the Go CoC committee takes into account the
>
> * severity of the conduct violation
> * impact of conduct on individuals who report to con...@golang.org
> * impact of conduct on the community (bystanders, those not directly 
> involved in CoC reports) 
> * conduct history in all Go project spaces, assessing patterns of behavior 
> across multiple sites versus one-off or "most recent only" conduct 
> incidents. 
> * impact to people of marginalized groups
>
> The last two factors also necessitate a public response, to assure those 
> who witness unacceptable behavior, particularly in public places, that 
> appropriate and fair corrective action was taken.  
>  
> We pledge  to make participation 
> in the Go project* and our community a harassment-free experience for 
> everyone. 
>
> Thank You,
> Carmen Andoh
> on behalf of the Go CoC committee
>
> *Go project spaces include all golang-* googlegroups, github/golang/go 
> issue repo, and other online forums where the Go CoC is in effect. 
>

-- 
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/cbda73ba-78a4-4f9a-ad2b-59e6e6ce2c19n%40googlegroups.com.

Re: [go-nuts] Re: A message from the CoC committee

On Wed, Mar 24, 2021 at 12:19 PM ben...@gmail.com  wrote:
>
> > permanent bans were given to multiple individuals, with no possibility for 
> > appeal
>
> I don't disagree with the bans, but this part -- the "no possibility for 
> appeal" seems very ... totalitarian. What if a mistake was made? (Again, not 
> saying it was here, but in general, to err is human.) I'm comparing to 
> various legal systems, in which there is almost always the possibility of 
> appeal, even for heinous crimes. Another aspect is that sometimes people 
> change and realize their mistake later, sometimes even because of an 
> excommunication like this. What's the rationale for "no possibility of 
> appeal"?

My take on this is that if someone has chosen for whatever reason to
attack a project, an appeals process just provides another mechanism
for them to consume project resources.

Also, in practice, we are all pseudonyms here anyhow.  If people
change their ways, they will likely benefit from adopting a new
pseudonym that is free of any toxicity attached to the old one.

Finally, this is a process run by human beings, not computer code or
even a legal system.  There can always be adjustments and exceptions
over time if there are good reasons for them.

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/CAOyqgcV8OnZWJKXbxz4negUipa2Vd3v_%3DF2PNZtdt3WcTuYDVg%40mail.gmail.com.

[go-nuts] unexpected fault address 0xfffffff800000019

2021-03-24 Thread Andrew Werner

A situation has arisen a few times lately where we've seen segfaults that
have strange looking address values. Another thing that makes the situation
confusing is that the memory referenced by the stack trace should have been
allocated at init time. This seems to only be happening on macOS. The code
in question was built using go1.15.5 on x86_64-apple-darwin20.3.0. We don't
have a reliable repro but it has happened more than once. A user did report
seeing an odd message involving `g->` or so they claim. From my sleuthing,
the only code which could throw that message would be:
https://github.com/golang/go/blob/go1.15.5/src/runtime/proc.go#L703.

Anyway, this all smells of memory corruption to me but I would love
somebody to confirm my feeling that that fault address feels bogus. Is
there any non-corruption reason why one might see this sort of fault?

unexpected fault address 0xfff80019
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1
addr=0xfff80019 pc=0x5658770]

goroutine 2093790 [running]:
runtime.throw(0x865aaf3, 0x5)
/usr/local/opt/go/libexec/src/runtime/panic.go:1116 +0x72
fp=0xc0338bdd18 sp=0xc0338bdce8 pc=0x403c7b2
runtime.sigpanic()
/usr/local/opt/go/libexec/src/runtime/signal_unix.go:749 +0x3e5
fp=0xc0338bdd48 sp=0xc0338bdd18 pc=0x40532e5

Cockroach is tracking this in
https://github.com/cockroachdb/cockroach/issues/62283.

--
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/CA%2BvRuzNT1-chwnfje0P5as3QGR7ehtuCikR_Pfb6%3D21LqYaHmA%40mail.gmail.com.

[go-nuts] Re: unexpected fault address 0xfffffff800000019

2021-03-24 Thread awer...@gmail.com

Oh, we've got another confirmed case of the scary runtime error. I guess 
now the question is, does anybody know of any memory corruption bugs in 
macOS and go1.15.5? I didn't see anything obvious.


runtime: gp: gp=0xc000802900, goid=0, gp->atomicstatus=0
runtime: g: g=0xc000602480, goid=0, g->atomicstatus=0
fatal error: bad g->status in ready

https://gist.github.com/awoods187/e9289c706ddc529034368fd3a2a25323

On Wednesday, March 24, 2021 at 10:02:20 PM UTC-4 awer...@gmail.com wrote:

> A situation has arisen a few times lately where we've seen segfaults that 
> have strange looking address values. Another thing that makes the situation 
> confusing is that the memory referenced by the stack trace should have been 
> allocated at init time. This seems to only be happening on macOS. The code 
> in question was built using go1.15.5 on x86_64-apple-darwin20.3.0. We 
> don't have a reliable repro but it has happened more than once. A user did 
> report seeing an odd message involving `g->` or so they claim. From my 
> sleuthing, the only code which could throw that message would be: 
> https://github.com/golang/go/blob/go1.15.5/src/runtime/proc.go#L703. 
>
> Anyway, this all smells of memory corruption to me but I would love 
> somebody to confirm my feeling that that fault address feels bogus. Is 
> there any non-corruption reason why one might see this sort of fault?
>
> unexpected fault address 0xfff80019
> fatal error: fault
> [signal SIGSEGV: segmentation violation code=0x1 addr=0xfff80019 
> pc=0x5658770]
>
> goroutine 2093790 [running]:
> runtime.throw(0x865aaf3, 0x5)
>   /usr/local/opt/go/libexec/src/runtime/panic.go:1116 +0x72 
> fp=0xc0338bdd18 sp=0xc0338bdce8 pc=0x403c7b2
> runtime.sigpanic()
>   /usr/local/opt/go/libexec/src/runtime/signal_unix.go:749 +0x3e5 
> fp=0xc0338bdd48 sp=0xc0338bdd18 pc=0x40532e5
>
> Cockroach is tracking this in 
> https://github.com/cockroachdb/cockroach/issues/62283. 
>

-- 
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/2226ea92-4d9b-4ff9-a441-fa3ac38acb9dn%40googlegroups.com.

Re: [go-nuts] Oopses in standard-library documentation

2021-03-24 Thread 'Dan Kortschak' via golang-nuts

On Wed, 2021-03-24 at 18:31 -0700, Scott Pakin wrote:
> I just noticed that some of the package comments in the standard
> library are coming from the wrong source file.  Here are two examples
> from a golang.org/pkg/ screenshot:
>
>
> In the case of the former, src/os/exec/read3.go appears to be missing
> a newline between the package comment and package, and in the case of
> the latter, src/runtime/mkduff.go appears to be the file at fault.
>
> Do I need to file a bug report, or is this a simple enough issue that
> one of the developers can just make a quick pass through the source
> code, adding the missing blank lines?
>
> — Scott

Some of them appear to be due to godoc ignoring +build directives. For
example, the crypto/x509 package has "Generates root_ios.go." which
it's getting from here
https://golang.org/src/crypto/x509/root_ios_gen.go. go/doc has a
similar problem from https://golang.org/src/go/doc/headscan.go, and
go/types from https://golang.org/src/go/types/gotype.go...

In fact all of the ones I looked at appear to be due to this.

Dan


-- 
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/bbcc80c6fb04a0f371dbfe3144a4c33a322a7dbe.camel%40kortschak.io.

Re: [go-nuts] Thanks

On Wed, Mar 24, 2021 at 5:04 PM 'Axel Wagner' via golang-nuts
 wrote:
>
> I would have thought that by now we've all learned that there is nothing to 
> be gained by having this discussion here.
>
> I can't help it though, to point out that this thread started with an 
> extremely apolitical message, before it got diverted.
> I liked Chris's message and would thus like to amplify it :)

Agreed on all counts.

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/CAOyqgcUuu-J%2BZU2nw2as6OB0abxfXJPPo%2BTVyHrUUZ8fwp1LFA%40mail.gmail.com.

Re: [go-nuts] A message from the CoC committee

2021-03-24 Thread Tyler Compton

Thanks Carmen, and others on the CoC committee. I don't think anyone would
say the work you do is fun, but whenever we get these rashes of toxic
behavior on the mailing list or on GitHub, it makes me glad the CoC exists.

On Tue, Mar 23, 2021 at 7:01 AM 'can...@google.com' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Over the last few days, multiple reports were received at
> cond...@golang.org regarding public conduct on golang-nuts, as well as
> conduct in private channels.  After review, permanent bans were given to
> multiple individuals, with no possibility for appeal.  Further corrective
> actions like temporary bans and final warnings are being deliberated,
> pending further investigation.
>
> As stated in our Code of Conduct , we believe
> that healthy debate and disagreement are essential to a healthy project and
> community. However, it is never ok to be disrespectful.
>
> When evaluating a response to a report and making decisions on a
> corrective action, the Go CoC committee takes into account the
>
> * severity of the conduct violation
> * impact of conduct on individuals who report to cond...@golang.org
> * impact of conduct on the community (bystanders, those not directly
> involved in CoC reports)
> * conduct history in all Go project spaces, assessing patterns of behavior
> across multiple sites versus one-off or "most recent only" conduct
> incidents.
> * impact to people of marginalized groups
>
> The last two factors also necessitate a public response, to assure those
> who witness unacceptable behavior, particularly in public places, that
> appropriate and fair corrective action was taken.
>
> We pledge  to make participation
> in the Go project* and our community a harassment-free experience for
> everyone.
>
> Thank You,
> Carmen Andoh
> on behalf of the Go CoC committee
>
> *Go project spaces include all golang-* googlegroups, github/golang/go
> issue repo, and other online forums where the Go CoC is in effect.
>
> --
> 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/593d282d-5c55-482e-acda-1181850090d4n%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/CAA%3DXfu1FJMgztUsOh47baf%3DWUmUu1N19XnN_B2i5Cc70x7%2BoKQ%40mail.gmail.com.

Re: [go-nuts] golang/mobile: Could we add GitHub Actions for PRs?

2021-03-24 Thread Tyler Compton

I'm not a go-mobile contributor, but since the repository is only mirrored
on GitHub and hosted elsewhere I'm not sure if GitHub Actions would be the
right choice. I think they'd reach a CI tool that can have its results
appear both on GitHub and on googlesource.com.

On Mon, Mar 22, 2021 at 8:48 AM Michael Chong 
wrote:

> GitHub Actions  has been introduced
> for a while.
>
> For PRs of go-mobile , only 
> *google-cla
> *is running on GitHub Actions.
> I wonder whether we can add support like automatic testing?
>
>
> --
> 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/e6194e76-bd34-40d0-995e-dff5110b98afn%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/CAA%3DXfu1QTXtUNVe84YK3m3Fe1To9etQGYvd9j1vX6FCWAOBQZQ%40mail.gmail.com.

Re: [go-nuts] What's the BUG in the flag package?

2021-03-24 Thread Jan Mercl

On Wed, Mar 24, 2021 at 11:25 PM Matt Mueller  wrote:

> I noticed a lonely BUG comment without an explanation in the flag package: 
> https://github.com/golang/go/blob/master/src/flag/flag.go#L955

Looking at the code it seems to me that the comment is saying the
_client_ code has a bug in that it defines the same flag more than
once.

-- 
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/CAA40n-VXJwaLtjViJ0WO3wyAK5HiAz1-XOXNmGZmjwK9rqmNpw%40mail.gmail.com.

Re: [go-nuts] Thanks

2021-03-24 Thread Peter Wilson

I more naturally think of it ('All lives matter)  as an emotional or 
philosophical statement.
I feel it is absurd and harmful for sloganeering - especially 
'language-engineered' sloganeering along the lines of 'have you stopped 
beating your wife yet?'  - to be promoted on a technical page ; I am also 
uncomfortable that an organisation with such an approach to politics is 
promoted on a technical page.

True, 'your gaff, your rules'. But still. 

And the header's still there.

On Wednesday, March 24, 2021 at 5:41:22 PM UTC-5 kortschak wrote:

> On Wed, 2021-03-24 at 22:09 +, alex breadman wrote:
> > Let's keep divisive political BS away from this lovely project.
> >
> > Glad to see the political header removed from the website, at least
> > on mobile.
> >
> > All lives matter.
>
> This too is a political statement.
>
>
>

-- 
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/87929b97-b7b7-4e8b-912b-84a4a04f1719n%40googlegroups.com.

Re: [go-nuts] Thanks

2021-03-24 Thread 'Axel Wagner' via golang-nuts

I would have thought that by now we've *all* learned that there is nothing
to be gained by having this discussion here.

I can't help it though, to point out that this thread started with an
extremely apolitical message, before it got diverted.
I liked Chris's message and would thus like to amplify 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/CAEkBMfGzniTLAubRTJdtcRO9m%3DyKib41aFQ3zXgQ68vuROk%3DyA%40mail.gmail.com.

Re: [go-nuts] Thanks

2021-03-24 Thread alex breadman

Let's keep divisive political BS away from this lovely project.

Glad to see the political header removed from the website, at least on
mobile.

All lives matter.

On Wed, 24 Mar 2021, 8:41 pm Chris Burkert,  wrote:

> Several messages during the last weeks irritated me and I guess I was not
> the only one. Eventually we are all humans but often enough we don’t treat
> ourselves like that. Let’s treat machines like machines and humans like
> humans - not the other way round.
>
> That’s why I want to say “Thank you Gophers”! Thanks to to Rob, Ken an
> Robert for creating an awesome piece of software. Thanks to Russ and Ian
> for continuing this work. And thanks to all the contributors no matter for
> which company you work.
>
> There will never be a 100% agreement on implementation details and there
> will never be a perfect process for decision taking. I believe we are lucky
> to have people who can take hard decisions when needed but can also say
> “no”. I’d like to express my respect for their work. It’s too easy to blame
> others in charge not being in their shoes.
>
> Go is an awesome language with amazing tooling and the latest efforts will
> not suddenly morph it into a mess. For some it will further improve, for
> others it may become worse. But I believe that essentially Go will remain
> awesome.
>
> PS: please excuse me if I couldn’t find proper English terms. It’s already
> hard in my mother tongue with Kode and Code and Quellcode and Quelltext :-)
>
> --
> 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/CALWqRZqjPwkn%3DF7FKUrsvfsUxkJxJkQqjpgOv1joUrbTK%3DJ2FQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANaetAaJq68N5%2BJUMW038CORnm-mn0OKopdBy1qGsQM0Lj7h_Q%40mail.gmail.com.

Re: [go-nuts] Thanks

2021-03-24 Thread 'Dan Kortschak' via golang-nuts

On Wed, 2021-03-24 at 22:09 +, alex breadman wrote:
> Let's keep divisive political BS away from this lovely project.
>
> Glad to see the political header removed from the website, at least
> on mobile.
>
> All lives matter.

This too is a political statement.


-- 
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/9f652ac597da3b0fce061d1090f364af4795de31.camel%40kortschak.io.

[go-nuts] What's the BUG in the flag package?

2021-03-24 Thread Matt Mueller

I noticed a lonely BUG comment without an explanation in the flag 
package: https://github.com/golang/go/blob/master/src/flag/flag.go#L955

I did a quick `git blame` and it goes all the way back to the initial 
commit: 
https://github.com/golang/go/commit/ac0dd5ae525db0d057e94c03c3f506bc30afae31.

Any ideas what the bug could be? Maybe this can be removed and I should 
open a PR?

Thanks!
Matt

-- 
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/0adc9978-7c9b-4de9-a1c5-eba3c477492an%40googlegroups.com.

Re: [go-nuts] Re: unexpected fault address 0xfffffff800000019

On Wed, Mar 24, 2021 at 8:25 PM Kurtis Rader  wrote:

> On Wed, Mar 24, 2021 at 7:05 PM awer...@gmail.com 
> wrote:
>
>> Oh, we've got another confirmed case of the scary runtime error. I guess
>> now the question is, does anybody know of any memory corruption bugs in
>> macOS and go1.15.5? I didn't see anything obvious.
>>
>
> I'm unaware of any memory corruption bugs inimical to Go on macOS. Note
> that you can use the vmmap(1) command to examine the memory map of a
> process on macOS. On my system running that against an Elvish process (a
> shell written in Go) does not show any addresses with a 0xff prefix. So
> the 0xfff80019 address is suspicious on its face. The first half
> would be -8 interpreted as an int32 and the second half would be 25
> (decimal). You say the "memory referenced by the stack trace should have
> been allocated at init time". What do you mean by that? Are you saying you
> explicitly mmap memory at 0xfff8000 (or a base address in the
> general range)? That doesn't seem likely so I don't know how to interpret
> your assertion.
>

Also, values like 8 (and -8, 4, -4) are particularly suspect in problems of
this nature since they suggest invalid pointer arithmetic.

-- 
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/CABx2%3DD-WXKzTJ7wGBhwoywRb2CRyLLNw2XkqGy%3D3kj7MQJF7Fw%40mail.gmail.com.

Re: [go-nuts] upgrade golang to 1.1.5 in vscode not showing

On Wed, Mar 24, 2021 at 9:16 PM Dr. Lincy Jim  wrote:

> Yes I am using Go in WSL(Sorry I forgot to mention it)
> go 1.13 version is in Networks
> \\wsl$\Ubuntu\home\lincy\go
>
> but the 1.15 version is in  Networks  \\wsl$\Ubuntu\user\local (go 1.15
> has been extracted here)
>
> Should i manually copy the go 15 folder and place it where go 13 is?
> In Vscode at the bottom of the  window it shows go 1.13? how do I change
> it to go 1.15
>

This is really a question for your whomever told you to upgrade from Go
1.13 to 1.15. We have no idea why you were told to upgrade. Or who told you
to do the upgrade. Presumably it was the IT department responsible for the
computers you use at your $dayjob.

I'll start by pointing out that you did not show us the output of `which -a
go`. Nonetheless, the information you did provide implies you have the WSL
equivalent of `\\wsl$\Ubuntu\home\lincy\go` (version 1.13) in your PATH
ahead of `\\wsl$\Ubuntu\user\local` (version 1.15). Perhaps you should just
delete your personal copy of the Go toolchain installed in
`\\wsl$\Ubuntu\home\lincy\go`. But, again, not knowing anything about your
$dayjob computer environment it might also be the case that you should have
installed the new version of Go in your personal directory rather than
/usr/local/.

-- 
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/CABx2%3DD-Cke_PrvTaW-47higgjNZpbCfK3otU05BGuxwTiZ58oA%40mail.gmail.com.

[go-nuts] Re: meaning of SSA operation

2021-03-24 Thread Ge

Thank you, looking forward to new Go version with regabi.

在2021年3月25日星期四 UTC+8 上午12:04:39 写道：

> Also, be aware that work that we really hope lands in 1.17 will tinker 
> with all the call operations.
>
> The goal is to switch to an ABI that passes parameters to/from calls in 
> registers, and the way
> that ends up expressed in SSA is that first (and we do this part in 1.16) 
> the parameters to the 
> call will appear as inputs, and the results will be obtained with 
> OpSelectN.  The call will still
> receive and return a memory value, as last input and last element of 
> result.
>
> This is then lowered to a machine-agnostic level where some parameters are 
> stored in memory,
> the others in registers -- where the registers appear as inputs/outputs of 
> the call -- and then
> further lowered (simple OpCode rewrite) to machine-specific call 
> instructions.  The registers themselves
> are bound in the register allocator, by the "trick" of telling it that 
> Calls have only a single appropriate
> register for each of their inputs/outputs.
>
> This might look a little odd the first time you see it.
>
> And, also, the order in which the registers inputs/outputs are encoded is 
> not fixed; for compiler
> efficiency purposes, we *might* reorder them so that all the integer 
> registers come first, etc.
> (This would allow a lot more sharing of register masks.)
>
> This full change is likely only for amd64 in 1.17, then for other 
> architectures once we figure out
> the exact recipe.  It touches many parts of the compiler and runtime.
>
> On Wednesday, March 24, 2021 at 4:01:36 AM UTC-4 Ge wrote:
>
>> Thank you Keith for clarification. It's really of great help.
>>
>> Ge
>>
>> 在2021年3月24日星期三 UTC+8 上午7:45:13 写道：
>>
>>> On Tuesday, March 23, 2021 at 9:11:13 AM UTC-7 Ge wrote:
>>>

 Hi,
 Recently I encountered a problem which seems to be related to SSA 
 optimization 
 and feels hard to figure out what some SSA operation means.

 Code:
 case1:
 func main() {
 var x int
 go func() {
 for {   
 x++  //no matter "-N" compile flags is specified or 
 not, 'x++' will be optimized
 }
 }()
 println(x)
 }

 case2:
 func main() {
 var x int
 go func() {
 for {   
 x++  
 dummy()   // when empty function 'dummy' is added to this 
 infinite loop, ''x++' stays last
 }
 }()
 println(x)
 }

 //go:noinline
 func dummy() {
 }

 I tried 'GOSSAFUNC=main.func1 go tool compile case2.go' and found the 
 key point is
 deadcode phase in SSA. Here is CFG before 'early deadcode' phase:

 ``` *ssaoptx.go*
 5  go func() {
 6  for {
 7  x++
 8  dummy()
 9  }
 10 }()
 ```

 ``` *early copyelim*

- b1:
- 
   - v1 (?) = InitMem 
   - v2 (?) = SP 
   - v3 (?) = SB 
   - v4 (?) = LocalAddr <**int> {} v2 v1
   - v5 (5) = Arg <*int> {} ([*int])
   - v9 (?) = Const64  [1]
- Plain → b2 (*+6*)


- b2: ← b1 b4
- 
   - v14 (7) = Phi  v1 v12
   - v15 (7) = Copy <*int> v5 ([*int])
- Plain → b3 (7)


- b3: ← b2
- 
   - v6 (7) = Copy <*int> v5 ([*int])
   - v7 (7) = Copy  v14
   - v8 (*+7*) = Load  v5 v14
   - v10 (7) = Add64  v8 v9
   - v11 (7) = Store  {int} v5 v10 v14
   - v12 (*+8*) = StaticCall  {"".dummy} v11
- Plain → b4 (8)


- b4: ← b3
- Plain → b2 (7)


- b5:
- 
   - v13 (10) = Unknown 
- Ret v13

 ```
 deadcode phase will traverse all blocks and find out the reachable 
 blocks 
 (In above example is b1,b2,b3,b4, while b5 is isolated block), Second 
 it will
 find out live values based on reachable blocks and eliminate dead 
 values.

 The call of dummy function makes v8,v10,v11 all live so 'x++' isn't 
 optimized.
 I have read ssa/README.md but still had some questions.

 1. The role of InitMem.
  It seems that every function starts with it, are some initialize 
 work like 
  stack space allocation and named return values initialization done 
 by it?


>>> Not really. Stack space and any zeroing required are done when 
>>> generating the preamble. They are not represented in SSA.
>>> InitMem is just the initial state of memory on entry to the function. It 
>>> does not generate any actual code.
>>>  
>>>
 2.  The meaning of 'v14 (7) = Phi  v1 v12'.
   It looks like v14 = Φ(v1, v12), but I don't know why InitMem and 
 dummy function
   call will affect here.

 3.  The meaning of of  StaticCall's argument .
   Some ssa

Re: [go-nuts] Re: unexpected fault address 0xfffffff800000019

On Wed, Mar 24, 2021 at 7:05 PM awer...@gmail.com 
wrote:

> Oh, we've got another confirmed case of the scary runtime error. I guess
> now the question is, does anybody know of any memory corruption bugs in
> macOS and go1.15.5? I didn't see anything obvious.
>

I'm unaware of any memory corruption bugs inimical to Go on macOS. Note
that you can use the vmmap(1) command to examine the memory map of a
process on macOS. On my system running that against an Elvish process (a
shell written in Go) does not show any addresses with a 0xff prefix. So
the 0xfff80019 address is suspicious on its face. The first half
would be -8 interpreted as an int32 and the second half would be 25
(decimal). You say the "memory referenced by the stack trace should have
been allocated at init time". What do you mean by that? Are you saying you
explicitly mmap memory at 0xfff8000 (or a base address in the
general range)? That doesn't seem likely so I don't know how to interpret
your assertion.

Looking at your project it appears you are using CGO which means the most
likely cause of the corruption is the linked C code.

-- 
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/CABx2%3DD98KND2m87R7-VpYqLVWYrceJeciJxR%3DJqu6ytoHd_jzA%40mail.gmail.com.

[go-nuts] upgrade golang to 1.1.5 in vscode not showing

2021-03-24 Thread Dr. Lincy Jim



Hi,

My os is windows 10 on which i have installed golang1.16 andd the version 
of golang on my vscode is1.13
but since I am using my laptop for work ,i have been asked to upgrade from 
1.13 to 1.15
I did the following steps in terminal of vscode-ubuntu
$ sudo wget https://golang.org/dl/go1.15.5.linux-amd64.tar.gz
$ sudo tar -C /usr/local -xzf go1.15.5.linux-amd64.tar.gz
$ export PATH=$PATH:/usr/local/go/bin
$ source ~/.bashrc
$ go version

still it shows version 1.13

kindly guide
thanking in advance

-- 
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/ac8694ce-6a9d-4ae1-9e91-66b283f1ac50n%40googlegroups.com.

Re: [go-nuts] What's the BUG in the flag package?

On Wed, Mar 24, 2021 at 3:30 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 11:25 PM Matt Mueller  wrote:
>
> > I noticed a lonely BUG comment without an explanation in the flag package: 
> > https://github.com/golang/go/blob/master/src/flag/flag.go#L955
>
> Looking at the code it seems to me that the comment is saying the
> _client_ code has a bug in that it defines the same flag more than
> once.

That could be, but BUG usually indicates something that should be
changed in the Go code.

In this case the original (and pretty much still current) code is

   m := flags.formal;
   flag, alreadythere = m[name]; // BUG

I bet that there was a bug in the compiler back in 2008 such that

   flag, alreadythere = flag.formal[name];

didn't work, and the BUG refers to introducing a local variable that
is only used once.

If someone wants to send a CL removing the comment and removing the
local variable m that would be fine.

Thanks.

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/CAOyqgcUnM_QF0REt6AhxTzNd2xNdY%2BP%3D_eWDs5Jht7rk-C%2BwmA%40mail.gmail.com.

Re: [go-nuts] upgrade golang to 1.1.5 in vscode not showing