[go-nuts] Go compiler - questions about escape analysis.

[messi...@gmail.com]

Hi,

I'm reading the go compiler source code and now come to the escape analysis 
part,  I just can't figured out the following question so I want to get 
some help from the community:

What's the meaning of location.transient 
?
  I 
can't fully understand the comment of this field, could someone please give 
me an example to explain the meaning of "the represented expression's 
address does not outlive the statement; that is, whether its storage can be 
immediately reused"?  

Thanks for any help and tips.

-- 
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/5b8c56ed-e20e-43b4-ab53-9acfd505240dn%40googlegroups.com.

Re: [go-nuts] Go compiler - syntax tree vs AST?

[messi...@gmail.com]

>  I don't know of a way to dump the former, but perhaps there is one.

It seems there's no way to dump the former tree through any compiler flag 
by now. The dumper entry point is Fdum 
p
 
but one can only use it through UT. Maybe it's only for internal use for 
compiler developers.

>  As far as I know the most likely next evolutionary step in this area 
will be to replace the Node tree with the cmd/compile/internal/syntax tree.

Really? I see in master branch, all the Node tree related code has been 
moved to a separated package* ir(cmd/compile/internal/ir/)*, and a lot of 
work has been done for this change. Do you mean the compiler will use only 
one kind of Syntax Tree and this part of code will be eliminated in the end?

Thanks.
On Monday, May 17, 2021 at 10:49:28 AM UTC+8 spencer...@gmail.com wrote:

> > As far as I know the most likely next evolutionary step in this area 
> will be to replace the Node tree with the cmd/compile/internal/syntax tree.
> hello All, 
>   I have a question. As far as I know, the AST transformation phase has 
> been in existence for several years now. So I want to know the reason why the 
> AST transformation phase has not been eliminated now? 
>
>   Thanks in advance.
> 在2019年9月3日星期二 UTC+8 下午11:37:58 写道：
>
>> Hello Ian,
>>
>> Thank you for your answer.
>>
>> Why do you ask? 
>>
>>
>> Just out of curiosity, I was working with the SSA package for a tool, and 
>> since the compiler uses this package as well I wanted to go a bit deeper on 
>> that and write a small article on it. That's quite an interesting part but 
>> the usage of two different syntax tree was a bit confusing.
>>
>> Hope this helps
>>
>>
>> Yes, a lot. Thanks again!
>>
>> Le mardi 3 septembre 2019 17:54:38 UTC+4, Ian Lance Taylor a écrit :
>>>
>>> On Tue, Sep 3, 2019 at 6:23 AM Vincent Blanchon 
>>>  wrote: 
>>> > 
>>> > The compiler documentation mentions a syntax tree in the parsing phase 
>>> when the AST transformation phase mentions a conversion from the syntax 
>>> tree to the compiler's AST representation. 
>>> > If I do not misunderstand, the command "go tool compile -W" will 
>>> display the AST. 
>>> > 
>>> > I was wondering how far is different the syntax tree from the AST? 
>>> Where could I get documentation or an example of this syntax tree? 
>>>
>>> Note that AST just means Abstract Syntax Tree, so it's a little 
>>> confusing to talk converting a syntax tree to an AST.  What we really 
>>> have is two different ASTs. 
>>>
>>> Unfortunately none of this stuff is well documented.  The parser 
>>> generates a syntax tree as defined in cmd/compile/internal/syntax. 
>>> That is then converted to the Node tree defined in 
>>> cmd/compile/internal/gc/syntax.go.  The -W option dumps the latter.  I 
>>> don't know of a way to dump the former, but perhaps there is one. 
>>>
>>> > Also, is this syntax tree mandatory? Is it not possible to build the 
>>> AST directly from the lexer+parser? 
>>>
>>> The use of two different syntax trees is entirely historical due to 
>>> the evolution of the compiler.  The original code base was a C 
>>> compiler written in C which became a Go compiler written in C which 
>>> was machine translated from C to Go.  There has been a lot of cleanup 
>>> but there is still a lot of historical cruft.  As far as I know the 
>>> most likely next evolutionary step in this area will be to replace the 
>>> Node tree with the cmd/compile/internal/syntax tree. 
>>>
>>> Hope this helps, and I hope someone will correct me if I made a mistake. 
>>>
>>> Why do you ask? 
>>>
>>> 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/2e2c488c-1cc3-4072-b01c-e0c11a09eb13n%40googlegroups.com.

Re: [go-nuts] Is it possible to produce coverage profiles for *_test.go files?

[Rob Pike]

You could run go tool cover yourself, but getting the details right can be
difficult. Instead, I suggest moving the test code into the main package,
but protected by a build tag and called from the real test.

foo_test.go:

func TestFoo(t *testing.T) { mainTestFoo(t) }

foo.go:

func mainTestFoo(t *testing.T) { t.Helper(); ... }

The disadvantage is that you'd need to pass the build tag when you run the
test, but that is easy to do in a script.

-rob


On Wed, May 19, 2021 at 8:23 PM Piers Powlesland 
wrote:

> I'm working on a project with some quite complex test code and I'd like to
> be able to understand what parts of it are executing for certain tests. I
> generated coverage using the go test -coverprofile=coverage.out 
> command but the coverage file only seems to contain information for non
> test files. Is it possible to extend the coverage to cover *_test.go files
> as well?
>
> Thanks,
>
> Piers
>
> --
> 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/8b8ebbac-10fe-4fde-9f54-30cf53e2321dn%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/CAOXNBZQpccCoC6ubO9auHC66SfEVfPe%2BHfGo4e6f50Z6wDXbog%40mail.gmail.com.

[go-nuts] A little love for x/oauth2

[cpu...@gmail.com]

I've recently worked a bit with oauth2 and noticed that issue tracker and 
PRs could use a little love. Quite a number of PRs have gone through Gerrit 
review without merging and the issues contain some imho valid points.

Is there a policy for maintaining x/oauth2 or putting it into slower 
maintenance-only mode?

Cheers,
Andi

-- 
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/d026d6f0-d493-400e-8c6f-c254d9a8b703n%40googlegroups.com.

[go-nuts] Delve v1.6.1 released

[Derek Parker]

Hello Gophers!

New Delve release day! 

Delve v1.6.1 is released today!

This release contains 2 new commands, new options for existing commands, 
bug fixes and more! Check out the changelog for more details: 
https://github.com/go-delve/delve/blob/master/CHANGELOG.md#161-2021-05-18.

-- 
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/46c56a73-993b-4934-b601-c7620cd73d06n%40googlegroups.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

[Ian Lance Taylor]

On Fri, May 14, 2021 at 7:28 AM 'Michael Pratt' via golang-nuts
 wrote:
>
> Go has a non-moving GC [1], so that is not an issue. That said, 
> unsafe.Pointer states "the referenced allocated object, if any, is retained 
> and not moved until the call completes". It doesn't say that this recursively 
> applies to objects referenced by the converted object, though I perhaps it 
> should.

To date we have explicitly decided that it shouldn't.  See the
discussion at 
https://go.googlesource.com/proposal/+/refs/heads/master/design/12416-cgo-pointers.md.

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

Re: [go-nuts] cancel method of timerCtx of context package

[Ian Lance Taylor]

On Wed, May 12, 2021 at 6:43 PM qinggeer Bao  wrote:
>
> In the cancel method of timerCtx type:
>
> func (c *timerCtx) cancel(removeFromParent bool, err error) {
> c.cancelCtx.cancel(false, err)
> if removeFromParent {
> // Remove this timerCtx from its parent cancelCtx's children.
> removeChild(c.cancelCtx.Context, c)
> }
> c.mu.Lock()
> if c.timer != nil {
> c.timer.Stop()
> c.timer = nil
> }
> c.mu.Unlock()
> }
>
> why it use the following:
> c.cancelCtx.cancel(false, err)
> if removeFromParent {
> // Remove this timerCtx from its parent cancelCtx's children.
> removeChild(c.cancelCtx.Context, c)
> }
>
> instead, direclty call
> c.cancelCtx.cancel(removeFromParent, err)
>
> Is there any reason?

The two calls look the same but they are not the same.  The c passed
to removeChild by cancelCtx.cancel is not the same as the c passed to
removeChild by timerCtx.cancel.

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/CAOyqgcVKZ4H4Hm%2B-qe85GLa8yA%2BO6vV%3DGdSb7Pc3ovVTze8quA%40mail.gmail.com.

Re: [go-nuts] Guarantee tcp pkt delivery

[Perry Couprie]

Op wo 19 mei 2021 13:37 schreef Amarjeet Anand :

> Hi
>
> Consider a sequence of events---
>
> 1. Tcp server started on port 8080 using *net.Listen("tcp", ":8080")*
>
> 2. Tcp client established a connection using *net.Dial("tcp", ":8080") *and
> received a *conn* object.
>
> 3. Tcp server is force killed.
>
> 4. Now when the tcp client performs *conn.Write()*, this operation *pass*
> with no error.
>
>
>
> *Question*-
> What should be a reliable way of writing to a tcp connection so that in
> step 4, client knows that it was writing to nothing and the write was not
> successful.
>
> Since this is an expected tcp behaviour (*thanks Ian for letting me know*)
> am sure there must be some way to guarantee the tcp packet delivery (*one
> way can be of ACK, but that will need server change, which is not very
> desirable in my situation*).
> Could you please point me to some relevant documents?
>
> --
> 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/CAORUUQVwioZTuH3Q9xTG-c-EUguiqt6C9CbLG2jeHWUf-QrWNQ%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/CABvoXdEV6cYt_frz1s%2BM-K%3DcKTvbSrxp9u65ph14sHEqjq3MbQ%40mail.gmail.com.

Re: [go-nuts] Guarantee tcp pkt delivery

[Jesper Louis Andersen]

On Wed, May 19, 2021 at 1:37 PM Amarjeet Anand  wrote:

> Consider a sequence of events---
>
> 1. Tcp server started on port 8080 using *net.Listen("tcp", ":8080")*
>
> 2. Tcp client established a connection using *net.Dial("tcp", ":8080") *and
> received a *conn* object.
>
> 3. Tcp server is force killed.
>
> 4. Now when the tcp client performs *conn.Write()*, this operation *pass*
> with no error.
>
>
There's no way to know, really. Suppose your server is on a Robot on Mars.
At 3, in the sequence above, it takes several minutes for the signal to
arrive on earth, and you may easily execute 4 in between. This buffers the
write in the OS kernel, and it transmits in the other direction, expecting
an ACK back. This takes up to something like 45 minutes round-trip. On
earth, the window is in milliseconds, but computers work on the nanosecond
scale, so it can still occur, and does so commonly. To hide the network
latency, we thus allow for the write to the kernel buffer instantly, and we
use the next write to handle the network error.

*Question*-
> What should be a reliable way of writing to a tcp connection so that in
> step 4, client knows that it was writing to nothing and the write was not
> successful.
>
> Since this is an expected tcp behaviour (*thanks Ian for letting me know*)
> am sure there must be some way to guarantee the tcp packet delivery (*one
> way can be of ACK, but that will need server change, which is not very
> desirable in my situation*).
> Could you please point me to some relevant documents?
>
> The key impossibility result is [The Two Generals Problem](
https://en.wikipedia.org/wiki/Two_Generals%27_Problem), which we have to
factor into the solution. It leads to the idea of best-effort delivery of
idempotent messages. Construct your protocol such that you can keep sending
the same message again and again, usually by tagging the message with a
unique identifier. The server responds with an ACK of that message
identifier, but at the application layer rather than at the TCP layer. The
server only processes messages once, and if it receives a message twice, it
responds as if it had just processed the message.

This scheme has another advantage: the unique tags allow you to process
messages out-of-order. This will allow the server to process in any order
it wants, which can improve latency.

Another important point is that if you are at the server side, it is
usually good to define a protocol which allows you to send large data sets
as a stream of chunks rather than building a complete data set and then
transmit it in one go. The reason is that it might take a while to build up
the large data set response and the client might be gone in the meantime.
If you stream the data as you go, the writes will give you errors faster,
so you can abort. And if the client can't keep up, the TCP window will
provide feedback pressure on your server to avoid a lot of up-front
processing.


-- 
J.

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

[go-nuts] Re: Guarantee tcp pkt delivery

[Brian Candler]

For detailed explanation from a TCP and sockets point of view, 
see: 
https://stackoverflow.com/questions/11436013/writing-to-a-closed-local-tcp-socket-not-failing
 
(This is described the opposite way round, where the client closes the 
socket then the server tries to write, but it's the same: once the sockets 
are connected, it doesn't matter which is "client" or "server")

In short, if your application wants to know that the message was received 
by the other end, then you need an application-level acknowledgement sent 
by the other end.

You will need this anyway, because in general you don't care that the 
message was received by the TCP stack at the other side; what you care is 
that the application has received *and processed* the message.

Otherwise, the message could have been successfully sent to the remote TCP 
stack, and the even received by the application, but the application killed 
or the power plug yanked before the application has had time to process 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/d84a9269-99b2-4680-bc0d-5642bf29d749n%40googlegroups.com.

[go-nuts] Guarantee tcp pkt delivery

[Amarjeet Anand]

Hi

Consider a sequence of events---

1. Tcp server started on port 8080 using *net.Listen("tcp", ":8080")*

2. Tcp client established a connection using *net.Dial("tcp", ":8080") *and
received a *conn* object.

3. Tcp server is force killed.

4. Now when the tcp client performs *conn.Write()*, this operation *pass*
with no error.



*Question*-
What should be a reliable way of writing to a tcp connection so that in
step 4, client knows that it was writing to nothing and the write was not
successful.

Since this is an expected tcp behaviour (*thanks Ian for letting me know*)
am sure there must be some way to guarantee the tcp packet delivery (*one
way can be of ACK, but that will need server change, which is not very
desirable in my situation*).
Could you please point me to some relevant documents?

-- 
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/CAORUUQVwioZTuH3Q9xTG-c-EUguiqt6C9CbLG2jeHWUf-QrWNQ%40mail.gmail.com.

Re: [go-nuts] How can I check error types of gRPC calls?

[burak serdar]

Here is something I did to pass custom error information:

Based on the grpc code, if an error type has GRPCStatus()
*status.Status function, then grpc gets the status information using
that method. For the error types that can go through grpc, I have this
method below:

func (e MyError) GRPCStatus() *status.Status {
var code codes.Code
switch e.HTTPStatus {
  case http.StatusBadRequest:
code = codes.InvalidArgument
  case http.StatusUnauthorized:
 code = codes.Unauthenticated
  default:
 code = codes.Unknown
 }
 x, _ := json.Marshal(e)
 return status.New(code, string(x))
}


In this example, the error type includes an HTTP status code, and the
grpc status is decided based on that. The grpc error contains a JSON
marshaled error information.

On the receiving end, I have this function:

func FromGRPCError(err error) (MyError, bool) {
  if x, ok := status.FromError(err); ok {
var e MyError
if json.Unmarshal([]byte(x.Message()), ) == nil {
return e, true
   }
  }
  return MyError{}, false
}

This decodes the error information from the incoming error.

This scheme can be extended to deal with multiple error types.

On Tue, May 18, 2021 at 8:45 AM 'Axel Wagner' via golang-nuts
 wrote:
>
> You cant to use status.Code(err), which gives you the gRPC status code.
>
>
> On Tue, May 18, 2021 at 3:08 PM cpu...@gmail.com  wrote:
>>
>>
>> Thank you for the pointer. After looking at the API, I'm still confused how 
>> to use it. I can status.Convert(err) to get a status object but couldn't 
>> really figure how how to use that to extract the actual underlying base 
>> error?
>> On Saturday, May 15, 2021 at 2:12:28 PM UTC+2 kortschak wrote:
>>>
>>> On Sat, 2021-05-15 at 04:47 -0700, cpu...@gmail.com wrote:
>>> > In my local code, I'm using things like
>>> >
>>> > if errors.Is(err, api.ErrMustRetry) { ... }
>>> >
>>> > How would I achieve the same on errors returned by the gRCP
>>> > interface? I've noticed these are wrapped:
>>> >
>>> > rpc error: code = Unknown desc = must retry rpc error: code = Unknown
>>> > desc = must retry
>>> >
>>> > I assume the errors package won't work here as type information is
>>> > not carried across gRPC: What is the best practice here: unwrap the
>>> > root error from the RPC result (how) and perform string comparison?
>>> >
>>>
>>> There is the status package which provides tools for examining the gRPC
>>> errors, https://pkg.go.dev/google.golang.org/grpc/status.
>>>
>>>
>> --
>> 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/8ecd4024-a846-4657-8e61-15c16289ccd2n%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/CAEkBMfERsv28%2BJV-EVYqhZraHbyYmPftQV6V0i55zVaK1R13HQ%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/CAMV2RqrL%3DkqGH2_RSpKuF8ppT-JCfGL9XSFkE63WRX8Eraw3OQ%40mail.gmail.com.

[go-nuts] Is it possible to produce coverage profiles for *_test.go files?

[Piers Powlesland]

I'm working on a project with some quite complex test code and I'd like to 
be able to understand what parts of it are executing for certain tests. I 
generated coverage using the go test -coverprofile=coverage.out  
command but the coverage file only seems to contain information for non 
test files. Is it possible to extend the coverage to cover *_test.go files 
as well?

Thanks,

Piers

-- 
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/8b8ebbac-10fe-4fde-9f54-30cf53e2321dn%40googlegroups.com.

Re: [go-nuts] How to cast a multi-value?

[Brian Candler]

On Tuesday, 18 May 2021 at 21:09:18 UTC+1 Amnon wrote:

> My understanding was that a string had a pointer and a length
>

Yes indeed - sorry my brain was disengaged :-)

>

-- 
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/907c7dd7-54f7-4ec4-8cee-4263c114da24n%40googlegroups.com.

Re: [go-nuts] How to cast a multi-value?

[Martin Leiser]

Assigning string values to string values or byte[] to byte[] does not 
require additional memory allocation.
But conversion between string and byte[] does so most of the time, because 
the underlying array of a string is immutable, versus the mutable of a 
byte[].

Encapsulating the type cast encapsulates exactly this potentially costly 
operation.
Whether this has a negativ or positive impact on potential compiler 
optimisation in respect to the need of a copy
in this special case, is hard to determine.

Amnon schrieb am Dienstag, 18. Mai 2021 um 22:09:18 UTC+2:

> My understanding was that a string had a pointer and a length,
> whereas a slice had a pointer and a length and a capacity.
>
> https://golang.org/src/reflect/value.go?s=59515:59567#L1973
>
>
> On Tuesday, 18 May 2021 at 20:32:39 UTC+1 Brian Candler wrote:
>
>> Assigning a string value to another variable doesn't double the memory 
>> usage.
>>
>> A value of type string consists of a pointer, a length, and a capacity, 
>> and only these are copied - so you get another copy of the pointer, 
>> pointing to the same data buffer.
>>
>>>

-- 
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/188a70df-4dff-40d7-a2d2-4ea64902aa28n%40googlegroups.com.