Re: [go-nuts] sigTERM not intercepted

[Kurtis Rader]

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?

On Tue, Mar 23, 2021 at 8:47 PM Madscientist Microneil <
madscientist.micron...@gmail.com> wrote:

> Hi,
>
> I've got a REST endpoint coded in go and it communicates with various
> child processes to get it's work done.
>
> I've used
>
> // Set up to handle signals so we can stop when asked
> done := make(chan os.Signal, 3)
> signal.Notify(done, os.Interrupt, syscall.SIGINT, syscall.SIGTERM)
>
> and
>
> <-done
>
> to capture sigTERM and a few others so that when the server is being shut
> down for maintenance it will cleanly finish the requests it is working on
> before it shuts down.
>
> Unfortunately, it seems that the child processes get sigTERM right away
> and as a result they die so the requests that are in flight end up broken.
>
> Did I miss a step?
>
> Thanks,
> _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/b99a53f4-732a-489c-be6e-572354cf7386n%40googlegroups.com
> 
> .
>


-- 
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-wMpjkWzeWFHQFRgY_dJ8cH2LYW9y_04%2B96zUxon-cgA%40mail.gmail.com.

[go-nuts] sigTERM not intercepted

[Madscientist Microneil]

Hi,

I've got a REST endpoint coded in go and it communicates with various child 
processes to get it's work done.

I've used 

// Set up to handle signals so we can stop when asked
done := make(chan os.Signal, 3)
signal.Notify(done, os.Interrupt, syscall.SIGINT, syscall.SIGTERM)

and 

<-done

to capture sigTERM and a few others so that when the server is being shut 
down for maintenance it will cleanly finish the requests it is working on 
before it shuts down.

Unfortunately, it seems that the child processes get sigTERM right away and 
as a result they die so the requests that are in flight end up broken.

Did I miss a step?

Thanks,
_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/b99a53f4-732a-489c-be6e-572354cf7386n%40googlegroups.com.

Re: [go-nuts] Type parameters syntax... Can it be improved?

[atd...@gmail.com]

Nevermind, I forgot about function return values.

Difficult to infer them without specifying them, isn'it?

Sorry... should have thought better.
On Wednesday, March 24, 2021 at 12:23:12 AM UTC+1 atd...@gmail.com wrote:

> Mmmh, :/ depends. What is the type of IntMin for the compiler in your 
> example? The same as Min?
>
> If not, it is basically defining a regular function out of a generic 
> function definition.
> So it is merely about constraining the type parameter further to be of 
> specific type int.
>
> A simple closure would be a sensible way to deal with it easily. In 
> general, one would define a general closure function with new type 
> parameters that have aditional constraints.
>
> Trying to see type parameters more like concrete types and interface 
> types, just with different constraints enforced at compile-time than those 
> of types and interface types.
> Could make brackets redundant.
> On Tuesday, March 23, 2021 at 11:22:51 PM UTC+1 Ian Lance Taylor wrote:
>
>> On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com  
>> wrote: 
>> > 
>> > Since, we also know the type of v, It would be infered from it. 
>> > 
>> > There is no variance, no dependent type... Meaning that the type of a 
>> Go variable does not change. 
>> > So the constraints do not change midway through the program, including 
>> type names/definitions. 
>> > 
>> > It does however require to have something that resemble a type 
>> definition beforehand. 
>> > A type parameter definition. 
>>
>> In some cases it can be inferred. But what about cases where it 
>> can't? And what if I want to write 
>>
>> // IntMin is a function with type func(int, int) int. 
>> var IntMin = Min[int] 
>>
>> ? 
>>
>> The constraints don't change midway through a program, but in your 
>> example the meaning of T does change. 
>>
>> Ian 
>>
>>
>> > On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote: 
>> >> 
>> >> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com  
>> wrote: 
>> >> > 
>> >> > Quick question... 
>> >> > 
>> >> > Why do we need brackets to define a parametered function, struct 
>> etc...? 
>> >> > 
>> >> > Why not change Go kinds to accept either a type (would produce a 
>> regular, function, structs, etc) or a new type parameter object that would 
>> implement the constraints (would produce a generic function definition) 
>> >> > 
>> >> > for instance, 
>> >> > 
>> >> > type parameter T 
>> >> > 
>> >> > // [...] some way to add constraint to T 
>> >> > 
>> >> > func Max(v T) T{...} 
>> >> > 
>> >> > What are the brackets for? Just an idea. 
>> >> 
>> >> Each call to Max can use a different value for T. We can call 
>> >> Max[int] and Max[string]. How would we do that with this notation? 
>> >> 
>> >> A type parameter really is a parameter to the function. Making it 
>> >> syntactically similar to other non-type parameters seems like a good 
>> >> idea to me. 
>> >> 
>> >> 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...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%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/23765669-8548-4977-abd9-fe5b183f4461n%40googlegroups.com.

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

[Anthony Martin]

can...@google.com once said:
> 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.

Where is the moderation log?

  Anthony

-- 
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/YFqDmTorc/glZImf%40alice.

[go-nuts] Re: meaning of SSA operation

['Keith Randall' via golang-nuts]

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 operations like 
> StaticCall
>I can't get enough information. Here is the relevant souce In 
> genericOps.go:
>```
>{name: "StaticCall", argLength: 1, aux: "CallOff", call: true}, 
>   
>  // call function aux.(*obj.LSym), arg0=memory.  auxint=arg size.  Returns 
> memory.
>   ```
>   For 'v12 (*+8*) = StaticCall  {"".dummy} v11' the only 
> argument is v11 but
>   obviously v11 seems not the address of dummy function.
>
>
The address of the target of the call is not stored in a separate SSA value 
- it is encoded directly in the StaticCall Value (in the Aux field).
Other types of calls (the indirect ones whose target must be computed at 
runtime, like InterCall) do take a target as an SSA value.
 

> 4.  As threre are other incomprehensible ssa operations except InitMem, 
> Phi, ... ,
>   Is there any documents which can help understanding？
>  
>

In general these all have to do with the concept of the "memory" type. 
Values in SSA can have such a type, which means "the entire state of 
memory". Function calls, for example, take a memory state as an argument 
(as well as any explicit arguments) and return a new memory state. Same for 
stores. Loads take a memory state as input.

Phi operations are described 
here: https://en.wikipedia.org/wiki/Static_single_assignment_form
Phis of memory mean the merge of two memory states.
 

> 'Thanks for you time.
>

-- 
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/07f3a6f8-c975-4bfe-9227-e6a5e04c9babn%40googlegroups.com.

Re: [go-nuts] Type parameters syntax... Can it be improved?

[atd...@gmail.com]

Mmmh, :/ depends. What is the type of IntMin for the compiler in your 
example? The same as Min?

If not, it is basically defining a regular function out of a generic 
function definition.
So it is merely about constraining the type parameter further to be of 
specific type int.

A simple closure would be a sensible way to deal with it easily. In 
general, one would define a general closure function with new type 
parameters that have aditional constraints.

Trying to see type parameters more like concrete types and interface types, 
just with different constraints enforced at compile-time than those of 
types and interface types.
Could make brackets redundant.
On Tuesday, March 23, 2021 at 11:22:51 PM UTC+1 Ian Lance Taylor wrote:

> On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com  wrote:
> >
> > Since, we also know the type of v, It would be infered from it.
> >
> > There is no variance, no dependent type... Meaning that the type of a Go 
> variable does not change.
> > So the constraints do not change midway through the program, including 
> type names/definitions.
> >
> > It does however require to have something that resemble a type 
> definition beforehand.
> > A type parameter definition.
>
> In some cases it can be inferred. But what about cases where it
> can't? And what if I want to write
>
> // IntMin is a function with type func(int, int) int.
> var IntMin = Min[int]
>
> ?
>
> The constraints don't change midway through a program, but in your
> example the meaning of T does change.
>
> Ian
>
>
> > On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote:
> >>
> >> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com  
> wrote:
> >> >
> >> > Quick question...
> >> >
> >> > Why do we need brackets to define a parametered function, struct 
> etc...?
> >> >
> >> > Why not change Go kinds to accept either a type (would produce a 
> regular, function, structs, etc) or a new type parameter object that would 
> implement the constraints (would produce a generic function definition)
> >> >
> >> > for instance,
> >> >
> >> > type parameter T
> >> >
> >> > // [...] some way to add constraint to T
> >> >
> >> > func Max(v T) T{...}
> >> >
> >> > What are the brackets for? Just an idea.
> >>
> >> Each call to Max can use a different value for T. We can call
> >> Max[int] and Max[string]. How would we do that with this notation?
> >>
> >> A type parameter really is a parameter to the function. Making it
> >> syntactically similar to other non-type parameters seems like a good
> >> idea to me.
> >>
> >> 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%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/5eb1bc1e-49a3-4340-83b2-a375b0ad65b4n%40googlegroups.com.

[go-nuts] Question on module versioning expected behavior

[Marcin Romaszewicz]

I recently hit a little issue with go.mod versioning that's confusing me.
My go.mod is straightforward:
https://github.com/deepmap/oapi-codegen/blob/master/go.mod

One of the packages in there is kin-openapi at v0.47.0:
github.com/getkin/kin-openapi v0.47.0

We briefly had some code in the repo which referred to some files which
weren't present in kin-openapi@v0.47.0, but these files were present in
kin-openapi@0.52.0
https://github.com/deepmap/oapi-codegen/pull/322

I would have expected that files not being present in 0.47.0 would result
in a compiler error, but instead, what happened is that my go.mod had its
kin-openapi requirement increased to 0.52.0 automatically by go build.

It's surprising to me that Go is smart enough to figure out that a
subsequent version of that module contains what I'm looking for, and it
updates go.mod. In my case, this isn't the behavior that I wanted. So, is
there a way disable this automated roll-up? I want my code to break if I
refer to something in a newer package.

Thanks,
-- Marcin

-- 
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%2Bv29LvpzRMOPyEeRzzekwv%3D4EaORuU%2BSp78sW-mm_DmUHyjZQ%40mail.gmail.com.

Re: [go-nuts] Code Review Checklist: Go Concurrency

[Ian Lance Taylor]

On Sun, Mar 21, 2021 at 1:22 PM Roman Leventov  wrote:
>
> I've created a list of possible concurrency-related bugs and gotchas in Go 
> code: https://github.com/code-review-checklists/go-concurrency.
>
> The idea of this list is to accompany 
> https://github.com/golang/go/wiki/CodeReviewComments and 
> https://golang.org/doc/articles/race_detector#Typical_Data_Races (my list 
> actually refers to a couple of data races described in the list of "Typical 
> Data Races").
>
> Comments, corrections, additions are welcome!
>
> If there are some core Go developers reading this, I would also like to know 
> if you think some of the points from my list can be moved to 
> https://github.com/golang/go/wiki/CodeReviewComments.

Thanks.  This seems useful.  It's not quite the kind of thing that we
have on the CodeReviewComments page, which is more about style than
correctness.  I think it would be fine as another wiki page, or where
you already have it.

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/CAOyqgcWBJEYNFo-o5VpaoSFMcx9kfivENcR9Di-dh1-ZhdLg6w%40mail.gmail.com.

Re: [go-nuts] Type parameters syntax... Can it be improved?

[Ian Lance Taylor]

On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com  wrote:
>
> Since, we also know the type of v, It would be infered from it.
>
> There is no variance, no dependent type... Meaning that the type of a Go 
> variable does not change.
> So the constraints do not change midway through the program, including type 
> names/definitions.
>
> It does however require to have something that resemble a type definition 
> beforehand.
> A type parameter definition.

In some cases it can be inferred.  But what about cases where it
can't?  And what if I want to write

// IntMin is a function with type func(int, int) int.
var IntMin = Min[int]

?

The constraints don't change midway through a program, but in your
example the meaning of T does change.

Ian


> On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote:
>>
>> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com  wrote:
>> >
>> > Quick question...
>> >
>> > Why do we need brackets to define a parametered function, struct etc...?
>> >
>> > Why not change Go kinds to accept either a type (would produce a regular, 
>> > function, structs, etc) or a new type parameter object that would 
>> > implement the constraints (would produce a generic function definition)
>> >
>> > for instance,
>> >
>> > type parameter T
>> >
>> > // [...] some way to add constraint to T
>> >
>> > func Max(v T) T{...}
>> >
>> > What are the brackets for? Just an idea.
>>
>> Each call to Max can use a different value for T. We can call
>> Max[int] and Max[string]. How would we do that with this notation?
>>
>> A type parameter really is a parameter to the function. Making it
>> syntactically similar to other non-type parameters seems like a good
>> idea to me.
>>
>> 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/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%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/CAOyqgcUi_Jdh-%2Bbfv_5t03E%3DUV%2BoGHfLum80ARrZaG0mxpZeAQ%40mail.gmail.com.

Re: [go-nuts] Type parameters syntax... Can it be improved?

[atd...@gmail.com]

Since, we also know the type of v, It would be infered from it.

There is no variance, no dependent type... Meaning that the type of a Go 
variable does not change. 
So the constraints do not change midway through the program, including type 
names/definitions.

It does however require to have something that resemble a type definition 
beforehand.
A type parameter definition.


On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote:

> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com  wrote:
> >
> > Quick question...
> >
> > Why do we need brackets to define a parametered function, struct etc...?
> >
> > Why not change Go kinds to accept either a type (would produce a 
> regular, function, structs, etc) or a new type parameter object that would 
> implement the constraints (would produce a generic function definition)
> >
> > for instance,
> >
> > type parameter T
> >
> > // [...] some way to add constraint to T
> >
> > func Max(v T) T{...}
> >
> > What are the brackets for? Just an idea.
>
> Each call to Max can use a different value for T. We can call
> Max[int] and Max[string]. How would we do that with this notation?
>
> A type parameter really is a parameter to the function. Making it
> syntactically similar to other non-type parameters seems like a good
> idea to me.
>
> 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/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%40googlegroups.com.

Re: [go-nuts] Type parameters syntax... Can it be improved?

[Ian Lance Taylor]

On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com  wrote:
>
> Quick question...
>
> Why do we need brackets to define a parametered function, struct etc...?
>
> Why not change Go kinds to accept either a type (would produce a regular, 
> function, structs, etc) or a new type parameter object that would implement 
> the constraints (would produce a generic function definition)
>
> for instance,
>
> type parameter T
>
> // [...]  some way to add constraint to T
>
> func Max(v T) T{...}
>
> What are the brackets for? Just an idea.

Each call to Max can use a different value for T.  We can call
Max[int] and Max[string].  How would we do that with this notation?

A type parameter really is a parameter to the function.  Making it
syntactically similar to other non-type parameters seems like a good
idea to me.

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/CAOyqgcVLgSXG6X1PJqDjy%3D%3DiTjx_y9merLmZfW67qtggnd0sgw%40mail.gmail.com.

[go-nuts] Type parameters syntax... Can it be improved?

[atd...@gmail.com]

Quick question...

Why do we need brackets to define a parametered function, struct etc...?

Why not change Go kinds to accept either a type (would produce a regular, 
function, structs, etc) or a new type parameter object that would implement 
the constraints (would produce a generic function definition)

for instance,

type parameter T

// [...]  some way to add constraint to T

func Max(v T) T{...} 

What are the brackets for? Just an idea.

-- 
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/f7f85bc8-667e-4d75-81e2-76bb70828fcbn%40googlegroups.com.

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

[Ian Lance Taylor]

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 compile it (with bootstarp.sh) setting GOOS=nsx 
>> >> >> >>> for cross compiling. Something like this:
>> >> >> >>>
>> >> >> >>> GOOS=nsx GOARCH=ppc64 bootstrap.bash
>> >> >> >>>
>> >> >> >>> That will not work at first. Now you have to make it work, which 
>> >> >> >>> *IS* the porting process.
>> >> >> >>>
>> >> >> >>> Eventually you will be able to compile everything and generate a 
>> >> >> >>> go toolchain for your platform. At that point you will copy the 
>> >> >> >>> generated files to the target platform and test it.
>> >> >> >>>
>> >> >> >>> That will 

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

[Shiva]

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? 

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 compile it 
> (with bootstarp.sh) setting GOOS=nsx for cross compiling. Something like 
> this:
> >> >> >>>
> >> >> >>> GOOS=nsx GOARCH=ppc64 bootstrap.bash
> >> >> >>>
> >> >> >>> That will not work at first. Now you have to make it work, which 
> *IS* the porting process.
> >> >> >>>
> >> >> >>> Eventually you will be able to compile everything and generate a 
> go toolchain for your platform. At that point you will copy the generated 
> files to the target platform and test it.
> >> >> >>>
> >> >> >>> That will most likely fail in your first attempt. Then go back, 
> fix what you think is broken and try again.
> >> >> >>>
> >> >> >>> On Wed, May 13, 2020 at 8:11 AM Randall Becker <
> the@gmail.com> wrote:
> >> >> 
> >> >> 
> >> >> 
> >> >>  On Tuesday, 12 May 2020 20:02:01 UTC-4, Ian Lance Taylor wrote:
> >> >> >
> >> >> > On Tue, May 12, 2020 at 2:17 PM Randall Becker <
> the@gmail.com> wrote:
> >> >> > >
> >> >> > > On Tuesday, 12 May 2020 16:55:54 UTC-4, Ian Lance Taylor 
> 

[go-nuts] meaning of SSA operation

[Ge]

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?

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 operations like 
StaticCall
   I can't get enough information. Here is the relevant souce In 
genericOps.go:
   ```
   {name: "StaticCall", argLength: 1, aux: "CallOff", call: true}, 
  
 // call function aux.(*obj.LSym), arg0=memory.  auxint=arg size.  Returns 
memory.
  ```
  For 'v12 (*+8*) = StaticCall  {"".dummy} v11' the only argument 
is v11 but
  obviously v11 seems not the address of dummy function.

4.  As threre are other incomprehensible ssa operations except InitMem, 
Phi, ... ,
  Is there any documents which can help understanding？
 
'Thanks for you time.

-- 
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/2d078627-62d6-4885-9c53-9bc9f5629d90n%40googlegroups.com.

[go-nuts] getting-started page instructions unclear

[fgergo]

On page https://golang.org/doc/tutorial/getting-started#call :
step 1.3. : visit https://pkg.go.dev/rsc.io/quote#pkg-index
step 1.4. instructs "At the top of this page, note that package quote
is included in the rsc.io/quote module."

How can I "note that package quote is included in the rsc.io/quote module." ?
Which part of "the top of this page" on page
ttps://pkg.go.dev/rsc.io/quote#pkg-index describes the "included"
relation?

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%2Bctqrpk0gznYXO8WqWp%3D1sxGnJNVz8v8KAWCSSZFFcuT-_WmQ%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

On Tue, Mar 23, 2021 at 3:02 PM 'can...@google.com' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> 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 :)

-- 
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/CAEkBMfEPHboBjretjX3MQ_%3D6--ezbpo%2B%2BtjZ3MO7QbnBeOwezw%40mail.gmail.com.

[go-nuts] A message from the CoC committee

['can...@google.com' via golang-nuts]

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.