Re: [go-nuts] error types/strings and errors.Is

2020-09-28 Thread Ian Lance Taylor
On Mon, Sep 28, 2020 at 3:46 AM Kevin Chadwick  wrote:
>
> Are there any thoughts on how to handle error types. Will the user create 
> custom
> error types from strings for use with errors.Is like for their own code or are
> some error strings in the stdlib likely to change. In which case an "import
> errors/types" managed by the stdlib might make sense?
>
> proposal: Go 2 error values
>
> https://github.com/golang/go/issues/29934#issuecomment-546896170

I don't think there is any one solution that will be used in all
cases.  Where the standard library can reasonably provide a shared
error type, it should, as it already does for types like os.PathError
and os.SyscallError.  For a user package, whether it returns a
specific error type is part of that package's API.  Often there is no
need for special error types for a user package.  Where there is a
need, the error types should be documented like any other part of the
API.

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/CAOyqgcUHw0uLfDwDYzv8E7%3DCKhjz%2BX_sB8r0UmWg%3DSTaNj6wiw%40mail.gmail.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-26 Thread Ian Lance Taylor
On Fri, Sep 25, 2020 at 6:36 PM Alex Besogonov  wrote:
>
> On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
>>  wrote:
>> >
>> > Inheritable goroutine-locals would actually work just fine in Go. 
>> > Moreover, Go actually has them in the form of pprof labels.
>> What should happen if one goroutine changes an inherited
>> goroutine-local variable?
>
> A Go-style goroutine-local system can be thought as a context.Context that is 
> transparently assigned to a goroutine and its children. Thus if you want to 
> change the value, you'd do something like "c := magic.GetCurrentContext(); c 
> = c.WithValue(...); magic.SetContext(c);".
>
> This would affect only the current goroutine going forward, but not its 
> children.

In general, Go's attitude is that explicit is better than implicit.
If you rigorously stick to the pattern you describe, it's the same as
passing the context.Context around explicitly (except that passing the
Context around explicitly is more flexible).

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/CAOyqgcVJws%2BVpnYx%2BPRpRprdhvq_csti_5bwqFOnfesoKLja0A%40mail.gmail.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-26 Thread Ian Lance Taylor
On Fri, Sep 25, 2020 at 6:29 PM Alex Besogonov  wrote:
>
> If you mutate the value, then only the current goroutine is affected (not 
> even its existing children). Basically, the goroutine-local context is copied 
> on new goroutine launch.
>
> That's how pprof labels work right now, btw.

Labels are not variables.  Variables have values that can be changed.

For example, if we had goroutine local variables then code like

goroutine var G int32

func F(s []P) {
 for _, p := range s {
G += p.SlowMethod()
}
}

might get changed to

func F(s []P) {
for _, p := range s {
p := p
go func() {
atomic.Add(, p.SlowMethod())
}()
}
}

but the two functions would work very differently.

Ian




> On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
>>  wrote:
>> >
>> > Inheritable goroutine-locals would actually work just fine in Go. 
>> > Moreover, Go actually has them in the form of pprof labels.
>>
>> What should happen if one goroutine changes an inherited
>> goroutine-local variable?
>>
>> Ian
>>
>>
>> > On Wednesday, September 23, 2020 at 5:55:50 PM UTC-7 Ian Lance Taylor 
>> > wrote:
>> >>
>> >> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills  wrote:
>> >> >
>> >> > There appears to be a way to get a reference on the goroutine id:
>> >> >
>> >> > http://blog.sgmansfield.com/2015/12/goroutine-ids/
>> >>
>> >> But as you can see by reading that blog article, that is almost a joke.
>> >>
>> >> Go considers these things to be better handled explicitly, which is
>> >> why people are telling you to use a context.Context value. And, yes,
>> >> you'll want to use a Context aware logging package.
>> >>
>> >> In Go it's trivial to create new goroutines, and as soon as you do
>> >> that any goroutine-local-variable scheme falls apart. So Go has
>> >> consistently chosen to not provide that capability, and similarly to
>> >> not provide goroutine IDs. It's an intentional choice by the
>> >> language. There have been a number of discussions about this in the
>> >> past on this mailing list.
>> >>
>> >> 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/f78f2d12-89d2-494d-983a-a462f0124d82n%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/ee6daca3-6e85-458e-95fd-877e8af4368dn%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/CAOyqgcWyF61EgKxxn3ikokyJi61-9Zqde_WtyPVMO1A6ojnLvg%40mail.gmail.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-25 Thread Ian Lance Taylor
On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
 wrote:
>
> Inheritable goroutine-locals would actually work just fine in Go. Moreover, 
> Go actually has them in the form of pprof labels.

What should happen if one goroutine changes an inherited
goroutine-local variable?

Ian


> On Wednesday, September 23, 2020 at 5:55:50 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills  wrote:
>> >
>> > There appears to be a way to get a reference on the goroutine id:
>> >
>> > http://blog.sgmansfield.com/2015/12/goroutine-ids/
>>
>> But as you can see by reading that blog article, that is almost a joke.
>>
>> Go considers these things to be better handled explicitly, which is
>> why people are telling you to use a context.Context value. And, yes,
>> you'll want to use a Context aware logging package.
>>
>> In Go it's trivial to create new goroutines, and as soon as you do
>> that any goroutine-local-variable scheme falls apart. So Go has
>> consistently chosen to not provide that capability, and similarly to
>> not provide goroutine IDs. It's an intentional choice by the
>> language. There have been a number of discussions about this in the
>> past on this mailing list.
>>
>> 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/f78f2d12-89d2-494d-983a-a462f0124d82n%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/CAOyqgcXA77jaLGEuUVHOpkKPu3GqrF3orK5dte01nOTMK%3DfL2g%40mail.gmail.com.


Re: [go-nuts] Are float64 and float32 exact in Golang (like strictfp in Java)

2020-09-25 Thread Ian Lance Taylor
On Fri, Sep 25, 2020 at 4:03 PM Ryan Keppel  wrote:
>
> Does golang generate the SSE2 over the x87 floating point instructions on 
> x64? In Java terms, it's always using strictfp? You could check the assembly 
> I suppose.

On amd64 the Go compiler uses SSE2.  It does not use x87.

However, the Go compiler is not quite like Java strictfp, as the Go
compiler will use instructions like fma that do not round precisely as
strictfp requires.

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/CAOyqgcXVUhQzhtz7zb-gR4%3DL9v4mzOv%2Brif6bS%2Bep3NV8r3fSA%40mail.gmail.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-24 Thread Ian Lance Taylor
On Wed, Sep 23, 2020 at 6:02 PM Alex Mills  wrote:
>
> Not a joke, in terms of performance, if you access the goroutine id via the C 
> library call?

I'm not sure what C library call you mean.

> My only concern would be if goroutine id's were reused, if not it would work.

Goroutine IDs are not reused.  (Well, a goroutine ID is just a 64-bit
integer so it could technically wrap around and be reused in that way,
but it seems unlikely.)

Ian


> On Wed, Sep 23, 2020 at 5:54 PM Ian Lance Taylor  wrote:
>>
>> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills  wrote:
>> >
>> > There appears to be a way to get a reference on the goroutine id:
>> >
>> > http://blog.sgmansfield.com/2015/12/goroutine-ids/
>>
>> But as you can see by reading that blog article, that is almost a joke.
>>
>> Go considers these things to be better handled explicitly, which is
>> why people are telling you to use a context.Context value.  And, yes,
>> you'll want to use a Context aware logging package.
>>
>> In Go it's trivial to create new goroutines, and as soon as you do
>> that any goroutine-local-variable scheme falls apart.  So Go has
>> consistently chosen to not provide that capability, and similarly to
>> not provide goroutine IDs.  It's an intentional choice by the
>> language.  There have been a number of discussions about this in the
>> past on this mailing list.
>>
>> 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/CAOyqgcUsLyVurqXqt6GDgMBQYcoVK%2BP4%2Bdm14ju-VKiA%3Dh1jYg%40mail.gmail.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-23 Thread Ian Lance Taylor
On Wed, Sep 23, 2020 at 5:46 PM Alex Mills  wrote:
>
> There appears to be a way to get a reference on the goroutine id:
>
> http://blog.sgmansfield.com/2015/12/goroutine-ids/

But as you can see by reading that blog article, that is almost a joke.

Go considers these things to be better handled explicitly, which is
why people are telling you to use a context.Context value.  And, yes,
you'll want to use a Context aware logging package.

In Go it's trivial to create new goroutines, and as soon as you do
that any goroutine-local-variable scheme falls apart.  So Go has
consistently chosen to not provide that capability, and similarly to
not provide goroutine IDs.  It's an intentional choice by the
language.  There have been a number of discussions about this in the
past on this mailing list.

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


Re: [go-nuts] Evaluation order of return

2020-09-23 Thread Ian Lance Taylor
On Wed, Sep 23, 2020 at 1:10 AM cs.ali...@gmail.com
 wrote:
>
> I am not actually questioning the current design, as you both said it is not 
> a good practice to call a return statement as I wrote above, I am trying to 
> understand the relation between memory, interface and order of evaluation. It 
> is clear that the compiler takes account of whether a return statement is an 
> interface or a struct and  the memory size of the returned value, If I return 
> a struct rather than an interface, it changes the order, If I add fields to 
> the structs it changes the order. Is there a paper that I can find why the 
> compiler considers them for ordering, why it is important for performance or 
> anything else?

I'm not aware of any paper specific to the Go compiler.

I find it most useful to consider a compiler as creating a set of
constraints derived from the input based on the language semantics.
These are constraints like in "a = b; b = c" the read of b in the
first assignment must be completed before the store to b in the second
assignment.  Once the set of constraints is created, the compiler must
solve those constraints given an instruction architecture including a
set of registers.  The goal is to optimize execution time while
minimizing compilation time without violating any constraints.
Because compilation time matters, compilers do not fully analyze all
possible solutions; instead, when it comes to things like memory
load/store order, instruction selection, and register allocation, they
are full of heuristics that tend to give good results in practice.

When you view a compiler in that way, a question like "why does adding
fields to a struct change the order of memory loads and stores"
becomes uninteresting.  The reason has to do with the details of all
the constraints that applied while compiling that particular package.
There is no rule that says "if the struct has more fields, do this."
It's just that the set of heuristics happened to produce a particular
result.  Changing some other piece of code in some other part of the
package might produce a different result.  Or a different version of
the compiler might apply different heuristics and get different
results.

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/CAOyqgcX__%2BKDDnzQ2LjuYm-1gMdrQy%3DLoNB0MmMj%3DaTGJPAF1A%40mail.gmail.com.


Re: [go-nuts] Windows Write Call Error when Writing to Network mapped Folder.

2020-09-23 Thread Ian Lance Taylor
On Wed, Sep 23, 2020 at 10:25 AM Hesham Elhadad  wrote:
>
> Thanks Ian,
> The root cause of this issue is not the hard drive, it is something with 
> overlapped offset and high offset values, need to be set to 0 to have a 
> smooth APPEND to the file.
> I need to use /x/sys/windows package to call this function WriteFile(handle 
> Handle, buf []byte, done *uint32, overlapped *Overlapped) (err error).
> However, there is neither examples nor clarification on how to use or call 
> the function. Also, most of the function in this package using *int16/*int32 
> for file names which is not clear to me if I want to use a string file name.
> Appreciate any support you can provide, or guidance on a material which could 
> help.

Given a *os.File f that you can get using os.OpenFile, you can use
f.SyscallConn to get a syscall.RawConn rc, and you can call rc.Write
with a function literal that calls unix.WriteFile with the handle.

Ian



> On Tue, Sep 22, 2020 at 9:04 PM Ian Lance Taylor  wrote:
>>
>> On Tue, Sep 22, 2020 at 11:14 AM helhadad  wrote:
>> >
>> > Hi Folks,
>> > I am trying to create file and write to it on a network mapped drive, 
>> > which I can access, create, delete and edit files using windows explorer 
>> > or CMD (Windows 10/Server 2016).
>> >
>> > You can find all details of the issue and response from other Go-Expert 
>> > below:
>> >
>> > https://stackoverflow.com/questions/63960049/writing-to-networked-mapped-drive-empty-files-or-failure
>> >
>> > I would appreciate if you enlighten me about the issue and how to solve it.
>>
>> According to Stack Overflow you are getting errors that say "the
>> parameter is incorrect."  If I search for "Windows the parameter is
>> incorrect" all the top links are about reformatting the disk.  So
>> perhaps you should give that a try.
>>
>> 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/CAOyqgcXpQrAMaDKMRw1tPWjVMgdhR_OWgc9-aLf5kHHru_dttw%40mail.gmail.com.


Re: [go-nuts] Windows Write Call Error when Writing to Network mapped Folder.

2020-09-22 Thread Ian Lance Taylor
On Tue, Sep 22, 2020 at 11:14 AM helhadad  wrote:
>
> Hi Folks,
> I am trying to create file and write to it on a network mapped drive, which I 
> can access, create, delete and edit files using windows explorer or CMD 
> (Windows 10/Server 2016).
>
> You can find all details of the issue and response from other Go-Expert below:
>
> https://stackoverflow.com/questions/63960049/writing-to-networked-mapped-drive-empty-files-or-failure
>
> I would appreciate if you enlighten me about the issue and how to solve it.

According to Stack Overflow you are getting errors that say "the
parameter is incorrect."  If I search for "Windows the parameter is
incorrect" all the top links are about reformatting the disk.  So
perhaps you should give that a try.

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


Re: [go-nuts] [generics] Typo for type with type argument

2020-09-21 Thread Ian Lance Taylor
On Mon, Sep 21, 2020 at 9:08 AM Christian Persson  wrote:
>
> I have found a small typo in the current draft for generics. In the section 
> "Function argument type inference" 
> (https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#function-argument-type-inference),
>  there is a function NewPair:
>
> func NewPair[F any](f1, f2 F) *Pair(F) { ... }
>
> The return type should be *Pair[F] (brackets instead of parentheses), right?

Thanks for catching this.  Sent https://golang.org/cl/256303 to fix 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/CAOyqgcWTLALcR%2BGrvciH1g0gqJ3t02pLAdUwB65Hcyd-w0zsuA%40mail.gmail.com.


Re: [go-nuts] Evaluation order of return

2020-09-21 Thread Ian Lance Taylor
On Mon, Sep 21, 2020 at 9:34 AM 'Axel Wagner' via golang-nuts
 wrote:
>
> The evaluation order is defined here:
> https://golang.org/ref/spec#Order_of_evaluation
> The important part is that the order of evaluation in a return statement is 
> only defined for function calls, method calls and communication statements, 
> but not in relation to other operations. So, in
> return intNumber, setInteger()
> It is not defined whether `intNumber` or `setInteger()` is 
> evaluated first, as the former is none of those. I can't really tell you why, 
> but it has been discussed a couple of times, you might find something using 
> the search function on golang-nuts.
>
> If you want reliable behavior, you should assign the result first
> var intNumber Integer
> err := setInteger()
> return intNumber, err

This flexibility is in the language to permit better code
optimization.  The compiler can choose how to order memory loads and
function calls.  It is not required to do a memory load, save it
somewhere, and then do the function call.

Of course, this does have the downside that different compilers will
produce different behavior for the same code.  So far we've decided
that that is OK.

My personal attitude is if a single statement writes to a variable
other than by assigning to it directly, and the statement also reads
from that same variable, then the program is already confusing.  While
we could lock down a specific order of evaluation, that won't help the
fact that the program is hard to read and hard to understand.  So I
don't see a good argument for forcing many well written programs to
run very slightly slower in order to make poorly written programs
behave consistently.  But I understand that other people feel
differently.

Ian



> On Mon, Sep 21, 2020 at 6:09 PM cs.ali...@gmail.com  
> wrote:
>>
>> Why does the compiler change evaluation order of return when adding a new 
>> field to a struct?  I didn't check the compiler output, I only guess it 
>> somehow changes the order.
>> play
>> package main
>> import (
>> "fmt"
>> )
>> type Number interface {
>> Value() int
>> }
>> type Integer struct {
>> value int
>> additional int // remove this for different result
>> }
>> func (integer Integer) Value() int {
>> return integer.value
>> }
>> func main() {
>> number, _ := getNumber()
>> fmt.Printf("number val: %d\n", number.Value())
>> }
>> func getNumber() (Number, error) {
>> var intNumber Integer
>> return intNumber, setInteger()
>> }
>> func setInteger(num *Integer) error {
>> num.value = 2
>> return nil
>> }
>>
>> --
>> 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/b7077f03-b0f4-454a-a587-ab9757164409n%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/CAEkBMfHsSFfjPzoOTVz7Q4fE%3DziCXhA5mbUWzSkQ5DADMyzWFw%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/CAOyqgcUAEwdMHrNaLKvDyiPEBdXNH8uQ4Uq2WY77s2QFOR8-uA%40mail.gmail.com.


Re: [go-nuts] flag: bug with shared values?

2020-09-18 Thread Ian Lance Taylor
On Fri, Sep 18, 2020 at 12:50 AM Manfred Touron  wrote:
>
> 1. if I need to open an issue or not on the go repo, if the fix is not about 
> code, it can be about doc maybe?

Documentation fixes are always welcome.  You can open an issue or just
send a change.

> 2. if other gophers has ideas of workaround?

I don't understand why it is important for these two different flags
to share the same variable.

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/CAOyqgcU9cMZnf4PaozoBEa4kL7DJgK1PDmnkibDmQ%2BLhbgm%3DJw%40mail.gmail.com.


Re: [go-nuts] Why does interface type carries pointer to basic types but not values itself?

2020-09-18 Thread Ian Lance Taylor
On Fri, Sep 18, 2020 at 10:31 AM Никифор Серяков  wrote:
>
> Lets imagine this code.
>
> ```go
> var i int
>
> func main() {
> i = 3
>
> F(i)
> }
>
> var q interface{}
>
> //go:noinline
> func F(a interface{}) {
> q = a
> }
> ```
>
> then run `go tool compile -S ~/a.go`
>
> Skipping all not related, in main function we'll see
>
> ```
> 0x001d 00029 (/home/nik/a.go:6) MOVQ $3, "".i(SB)
> 0x0028 00040 (/home/nik/a.go:8) MOVQ $3, (SP)
> 0x0030 00048 (/home/nik/a.go:8) PCDATA $1, $0
> 0x0030 00048 (/home/nik/a.go:8) CALL runtime.convT64(SB)
> 0x0035 00053 (/home/nik/a.go:8) LEAQ type.int(SB), AX
> 0x003c 00060 (/home/nik/a.go:8) MOVQ AX, (SP)
> 0x0040 00064 (/home/nik/a.go:8) CALL "".F(SB)
> ```
>
> Where `runtime.convT64` is 
> https://github.com/golang/go/blob/master/src/runtime/iface.go#L364,
> which allocates (except some small optimization) new `*int` variable instead 
> of just copying value itself.
>
> So for interface declared (here 
> https://github.com/golang/go/blob/master/src/runtime/runtime2.go#L208) as
> ```go
> type eface struct {
> _type *_type
> data  unsafe.Pointer
> }
> ```
>
> `int` to `interface{}` conversion looks like
> ```go
> v := new(int)
> *v = value
> return eface{
> _type: ,
> data: unsafe.Pointer(),
> }
> ```
> instead of
> ```go
> return eface{
> _type: ,
> data: unsafe.Pointer(value),
> }
> ```
>
> I have some guess, that it is connected with garbage collection and 
> requirement to know in advance if some piece of memory is pointer or not. But 
> isn't it worth it to add some `if` in gc and do not make such allocations, 
> reducing gc pressure?

Interface values used to work more or less as you describe.  As you
guessed, it was changed to support a more efficient concurent garbage
collector.  The garbage collector has to know whether a value is a
pointer or not.  With the implementation the gc compiler uses today,
both fields of an interface value are always pointers.  If the second
word in an interface is sometimes a pointer and sometimes not, then
the garbage collector has to look at the first word to decide.  And
that is a race condition for a concurrent garbage collector.  It might
be possible to handle it, but it would significantly complicate the
write barrier.

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/CAOyqgcWO%2BuzVj9qR0O9%3Drz_VuvymPjw2JD8AJ-45vTQ-4RE%3DqQ%40mail.gmail.com.


Re: [go-nuts] Cloud the current generic draft constraint a type parameter must be exactly some types

2020-09-18 Thread Ian Lance Taylor
On Fri, Sep 18, 2020 at 10:07 AM tapi...@gmail.com  wrote:
>
> instead of sharing the same underlying types with some types?

In the current design draft, the answer is yes, but only for
non-predeclared defined types.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types

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/CAOyqgcUsDVKtTV70LVqRy2kjZZUGt0x%2BbyLGSZteeqxXP76O%3Dg%40mail.gmail.com.


Re: [go-nuts] flag: bug with shared values?

2020-09-17 Thread Ian Lance Taylor
On Thu, Sep 17, 2020 at 5:04 PM Manfred Touron  wrote:
>
> I think that I discovered a bug in the stdlib flag package:
>
> sharedFlag := "init-value"
> fooFs := flag.NewFlagSet("foo", flag.ContinueOnError)
> barFs := flag.NewFlagSet("bar", flag.ContinueOnError)
> fooFs.StringVar(, "baz", "foo-default", "testing")
> barFs.StringVar(, "baz", "bar-default", "testing")
> _ = fooFs.Parse([]string{""}) // no error
> fmt.Println(*sharedFlag) // bar-default, instead of foo-default
>
> To quote @peterbourgon on this issue:
>
> > Haha! This is a bug (?) with stdlib flag.FlagSet.
> > The default value provided to e.g. fs.StringVar isn't kept as metadata 
> > associated with the flag in the corresponding flagset, but is rather 
> > assigned to the associated variable. And that assignment happens at 
> > declaration time, when you call fs.StringVar, and not when you call 
> > fs.Parse. So the default value you see in any flag set will be the default 
> > value provided to whichever StringVar declaration happens to occur last — 
> > in your test, it's this one.
> > This sucks.
> > I think the only fix here would be, somehow, avoiding assigning a default 
> > value in the declaration, and populating it later. Or defining a separate 
> > e.g. DeferredFlagVar type that encapsulated this behavior? I don't know 
> > offhand what's best. Ugh.
>
> I never contributed to the go repo yet, so I prefer to ask here your opinion 
> about this strange behavior, what you suggest in term of fix that does not 
> require to touch the stdlib, and if you think that I need to issue a bug on 
> the go repo and try to contribute a fix?

What you say is true and I can see how it would be surprising but I
don't personally consider this to be a bug.  It's a design decision.
Perhaps it should be documented more clearly: don't use the same
variable for more than one XXXVar calls.

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


Re: [go-nuts] Catch/handle cgo SIGSEGV

2020-09-17 Thread Ian Lance Taylor
On Thu, Sep 17, 2020 at 12:09 PM Tamás Gulácsi  wrote:
>
> Can you provide some skim of a C-side signal handler that could induce a Go 
> panic?
> All I want is to have an error on Go side, instead of a crash (though it may 
> be safer to have a crash...).

I can't think of any safe way that a C signal handler could cause a
panic in the goroutine that called the C code that made the invalid
memory reference.

You could in principle have a C signal handler call a Go function that
sends a message on a buffered channel that tells some other goroutine
to panic.  I think that could be safe.  But it would not be safe for a
C signal handler to call a Go function that calls panic.  That would
leave the program with most signals blocked.

Ian




> Ian Lance Taylor a következőt írta (2020. szeptember 17., csütörtök, 21:00:52 
> UTC+2):
>>
>> On Thu, Sep 17, 2020 at 8:52 AM Tamás Gulácsi  wrote:
>> >
>> > I'm searching for help in https://github.com/godror/godror/issues/100 - 
>> > I've added a recover, called debug.SetPanicOnFault, without success: the 
>> > extra free still panics with SIGSEGV, and the recover does not catch it 
>> > (or I coded it wrongly): 
>> > https://github.com/godror/godror/blob/2dab250ab19e158ba97699841f40c9de9d061f29/stmt.go#L306
>> >
>> > panic: https://github.com/godror/godror/issues/100#issuecomment-694192603
>>
>> When a SIGSEGV occurs while running C code called via cgo, that
>> SIGSEGV is not turned into a Go panic.
>>
>> It works this way both because 1) C is not a memory-safe language, and
>> if the C code has not installed a signal handler there is no reason to
>> think that the C code is prepared to carry on after a segmentation
>> violation; 2) the mechanism that Go uses to turn a memory error into a
>> panic can only work for Go code, not for C code.
>>
>> 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/30ca05ec-255b-4d67-b45f-89fde5396bb6n%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/CAOyqgcU-fYa2Eg7WCxM97OjZW_rPkTF1H_C4wyieXKguY%2Bkcaw%40mail.gmail.com.


Re: [go-nuts] Catch/handle cgo SIGSEGV

2020-09-17 Thread Ian Lance Taylor
On Thu, Sep 17, 2020 at 8:52 AM Tamás Gulácsi  wrote:
>
> I'm searching for help in https://github.com/godror/godror/issues/100 - I've 
> added a recover, called debug.SetPanicOnFault, without success: the extra 
> free still panics with SIGSEGV, and the recover does not catch it (or I coded 
> it wrongly): 
> https://github.com/godror/godror/blob/2dab250ab19e158ba97699841f40c9de9d061f29/stmt.go#L306
>
> panic: https://github.com/godror/godror/issues/100#issuecomment-694192603

When a SIGSEGV occurs while running C code called via cgo, that
SIGSEGV is not turned into a Go panic.

It works this way both because 1) C is not a memory-safe language, and
if the C code has not installed a signal handler there is no reason to
think that the C code is prepared to carry on after a segmentation
violation; 2) the mechanism that Go uses to turn a memory error into a
panic can only work for Go code, not for C code.

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/CAOyqgcVTYfoEmR0wy_Ka31nwMG0cr2sP45i6gZZWtT%2BEQUOkPw%40mail.gmail.com.


Re: [go-nuts] RISCV & Golang custom-compilations ahead?

2020-09-13 Thread Ian Lance Taylor
On Sun, Sep 13, 2020 at 1:50 AM josvazg  wrote:
>
> This is not a proposal, just a curiosity question to check if anyone in the 
> Go ecosystem has already thought on this issue and have some solutions in 
> mind.
>
> I might be late to this realization, but nowadays is pretty clear Intel 
> monolithic ISA dominance is threatened. ARM is taking over Macs and Amazon is 
> doubling their offer of ARM based Cloud instances. In the end, you can't 
> ignore chips with comparable performance but lower power consumption and heat 
> dissipation issues.
>
> This is not yet disruptive for Go. Go already produces ARM binaries, so I'd 
> expect it might just mean more compilations to ARM will happen and be 
> offered. Maybe also ARM optimizations might see higher demand.
>
> RISCV is a different story.
>
> If server/laptop grade RISCV SoCs achieve a similar performance/power 
> consumption ratio to their ARM counterparts, as they have no licensing costs 
> &  are extensible, I expect they are going to spread very quickly. ARM 
> already saw this recently and is opening up a few of their licenses.
>
> And RISCV is not like the others for Go. RISCV is a modular extensible ISA, 
> including standard and custom extensions.
>
> The standard extensions may already require some compiler architecture 
> rework. Go might chose not to do anything and just support a handful of the 
> most common RISCV ISA combinations... or add ISA modularity support. Starting 
> from the mandatory core ISA, prefer specific module instructions to generic 
> ones when the module letters are present in the GOARCH=riscvxxx passed in.
>
> The custom extensions may be even more disruptive. Go could chose to ignore 
> them altogether so that Go compiled programs are always generic and can never 
> use the custom extensions. But if RISCV takes off, that would mean Go 
> programs will be slower and not really suitable for custom workloads some 
> companies may have preferred to run on Go on their chosen chipset.
>
> On way around could be to provide compiler plugins so that some Go end users 
> can extend the go compiler to use the custom extensions where they make 
> sense. So they can customize their Go binaries for their workloads as they 
> see fit. I expect having a plugin like this that has a simple & usable API to 
> be tricky, to say the least. But I am not an expert so I might be wrong.
>
> Another way could be to provide even more generic compilations, and leave the 
> final custom compilation step to the targets.
>
> For instance, the Go way could advise to just compile to GOARCH=wasm and 
> leave the optimizations to a custom WASM runtime available at the target. 
> That runtime is extended from the generic RISCV WASM runtime to use that 
> particular chipset custom ISA extensions when appropriate. But Go is not 
> involved in any way on that runtime, it might be even written in Rust or 
> something else or be a Go program not provided as part of the Go language or 
> tooling.
>
> Or Go could chose to ship unfinished compilations for this, not unlike JVM 
> bytecodes. It could still be WASM or maybe the intermediate SSA 
> representation of the program, and then provide an extensible transpiler that 
> Go developers using particular custom ISA extensions can extend and use to 
> produce the final custom static binary. It might be even embedded into  the 
> go tool so that when you "go get" you already get the custom executable 
> locally. That would be very cool, but probably as tricky as the compiler 
> plugins mentioned above. In fact, this and the compiler plugins option might 
> end up being the same.
>
> I'd expect Go will not evolve to provide an extensible VM runner or JIT 
> compiler environment. It seems too far a departure from the go runtime model 
> and also will bring many known nuisances that plague these systems like JVM 
> (big runtime env needed in the target, higher memory consumption, etc)
>
> So just curiosity, has any one have a thought on this or can point to 
> literature on this matter?


The way we've historically approached this kind of thing is to use a
fixed GOARCH value and to use a separate environment variable, which
for RISCV would be GORISCV and, perhaps, GORISCV64.  That separate
environment variable would be the set of specific architecture
variants that matter.  For example, see the variables GOARM, GO386,
etc., at https://golang.org/cmd/go/#hdr-Environment_variables .

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/CAOyqgcUZ3VCiJwp1WpMCZ-rq4OMdxwSYx-xH_BKr0EX01SXDLw%40mail.gmail.com.


Re: [go-nuts] alloc vs totalalloc in memory

2020-09-11 Thread Ian Lance Taylor
On Fri, Sep 11, 2020 at 5:01 PM Alex Mills  wrote:
>
> The explanations I find online arent very clear to me :(

Well, OK, but I don't know what I can say other than to repeat the
information from that link.

Alloc is bytes of allocated heap objects.

TotalAlloc is cumulative bytes allocated for heap objects.

If that is not clear, what is not clear about it?

Ian


> On Thursday, September 10, 2020 at 6:40:34 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Thu, Sep 10, 2020 at 4:39 PM Alexander Mills
>>  wrote:
>> >
>> > I have this helper func to print memory usage (detect a memory leak?)
>> >
>> >
>> > func PrintMemUsage() {
>> > var m runtime.MemStats
>> > runtime.ReadMemStats()
>> > // For info on each, see: https://golang.org/pkg/runtime/#MemStats
>> > fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))
>> > fmt.Printf("\tTotalAlloc = %v MiB", bToMb(m.TotalAlloc))
>> > fmt.Printf("\tSys = %v MiB", bToMb(m.Sys))
>> > fmt.Printf("\tNumGC = %v\n", m.NumGC)
>> > }
>> >
>> > I am seeing output like this:
>> > Alloc = 2481 MiB TotalAlloc = 24038 MiB Sys = 2752 MiB NumGC = 114
>> >
>> > what is the difference between Alloc and TotalAlloc .. ?
>>
>> The link above, after "For info on each", explains the difference. If
>> the explanation is unclear, tell us more.
>>
>> 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/6c889d9b-e2f1-4583-b310-8954ce456852n%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/CAOyqgcXQ4eedgwwnxT0Hg_3%2BWmjexX1NriT26U1AksEVmrW8sg%40mail.gmail.com.


Re: [go-nuts] Proposal: auto return String instead of []byte if requested

2020-09-11 Thread Ian Lance Taylor
On Fri, Sep 11, 2020 at 9:45 AM Kevin Chadwick  wrote:
>
> I apologise if this has already been discussed. Google didn't turn up anything
> directly related.
>
> If you read a file using the following that returns a byte slice.
>
> tlsCertb, err := ioutil.ReadFile("/etc/ssl/mycert")
> if err != nil {
>log.Fatal(err)
> }
> tlsCert = string(tlsCertb)
>
> Is there a way to get a string without the cast.
>
> Otherwise couldn't the language automatically return a string rather than a 
> byte
> slice in these cases if the receiving var is already a string?
>
> e.g.
>
> var string tlsCert
> tlsCert, err = ioutil.ReadFile("/etc/ssl/mycert")
> if err != nil {
>log.Fatal(err)
> }

The way Go works, ioutil.ReadFile is compiled with the io/ioutil
package.  It can't change based on how it is called.  So it is always
going to return []byte.

The only way to implement what you suggest would be to add an implicit
conversion from []byte to string.  But that seems problematic.  In
general Go avoids implicit conversions except to interface types.  And
a conversion to string does require a copy, so it doesn't seem like a
great idea to do that implicitly.

If this happens a lot in your code, it seems easy enough to use a tiny
helper function.

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


Re: [go-nuts] zombie parent scenario with golang

2020-09-10 Thread Ian Lance Taylor
On Thu, Sep 10, 2020 at 5:09 PM Kurtis Rader  wrote:
>
> A defunct process is a process that has terminated but whose parent process 
> has not called wait() or one of its variants. I don't know why lsof still 
> reports open files. It shouldn't since a dead process should have its 
> resources, such as its file descriptor table, freed by the kernel even if the 
> parent hasn't called wait(). You didn't tell us the details of the OS you're 
> using so I would simply assume it's a quirk of your OS. It might be more 
> productive to look into why your program is panicing at map_faststr.go:275. A 
> likely explanation is you have a race in your program that is causing it to 
> attempt to mutate a map concurrently or you're trying to insert into a nil 
> map.

That's a good point.  What OS are you using?  I don't think you said.

Ian


> On Thu, Sep 10, 2020 at 4:43 PM Uday Kiran Jonnala  
> wrote:
>>
>> Hi Ian,
>>
>> Again. Thanks for the reply. Problem here is we see go process is in defunt 
>> process and sure parent process did not get SIGCHILD and looking deeper,
>> I see a thread in  futex_wait_queue_me. If we think we are just getting the 
>> stack trace and the go process actually got killed, why would I see
>> associated fd's in file table and fd table is still intact (see lsof 
>> information)
>>
>> Process which is in defunt state which got panic is <87548>, checking for 
>> threads in this which is 87548
>>
>> bash-4.2# cat /proc/87548/status
>>  Name: replicator
>>  State: Z (zombie)
>>
>> bash-4.2# ls -Fl /proc/87548/task/87561/fd | grep 606649
>> l-wx--. 1 root root 64 Aug 25 10:59 1 -> pipe:[606649]
>> l-wx--. 1 root root 64 Aug 25 10:59 2 -> pipe:[606649]
>>
>> Listing the threads
>>
>> bash-4.2# ps -aefT | grep 87548
>> root 87548 87548 87507 0 Aug23 ? 00:00:00 [replicator] 
>> root 87548 87561 87507 0 Aug23 ? 00:00:00 [replicator] 
>> root 112448 112448 42566 0 17:13 pts/0 00:00:00 grep 87548
>>
>> bash-4.2# lsof | grep 606649
>> replicato  87548  87561root1w FIFO   0,11   0t0  
>>606649 pipe
>> replicato  87548  87561root2w FIFO   0,11   0t0  
>>606649 pipe
>>
>> Why does lsof show the entry for the FIFO file of this process?
>>
>> So I feel we have a scenario the thread which is sleeping on 
>> futex_wait_queue_me is not cleanup during panic() and causing the main
>> thread to be exited leaving detached thread which waiting in 
>> futex_wait_queue_me is still present.
>>
>> The main issue is I am not able to reproduce this, since this go process is 
>> very big.
>>
>> Any way to verify this OR  take it further.
>>
>> Thanks & Regards,
>> Uday Kiran
>> On Monday, September 7, 2020 at 12:05:05 PM UTC-7 Ian Lance Taylor wrote:
>>>
>>> On Mon, Sep 7, 2020 at 12:03 AM Uday Kiran Jonnala  
>>> wrote:
>>> >
>>> > Thanks for the reply, I get the point on zombie, I do not think the issue 
>>> > here is parent not reaping child, seems like go process has not finished 
>>> > execution of some
>>> > internal threads (waiting on some futex) and causing SIGCHILD not to be 
>>> > sent to parent.
>>> >
>>> > go process named  hit with panic and I see this went into 
>>> > zombie state
>>> >
>>> > $ ps -ef | grep replicator
>>> > root 87548 87507 0 Aug23 ? 00:00:00 [replicator] 
>>> >
>>> > Now looking at the tasks within the process
>>> >
>>> > I see the stack trace of the threads within the process still stuck on 
>>> > following
>>> >
>>> > bash-4.2# cat /proc/87548/task/87561/stack
>>> > [] futex_wait_queue_me+0xc4/0x120
>>> > [] futex_wait+0x10a/0x250
>>> > [] do_futex+0x35e/0x5b0
>>> > [] SyS_futex+0x13b/0x180
>>> > [] do_syscall_64+0x79/0x1b0
>>> > [] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>>> > [] 0x
>>> >
>>> > From the above example if we are creating some internal threads and main 
>>> > thread is excited due to panic and left some detached threads, process 
>>> > will be in zombie state until the threads
>>> > within the process completes.
>>> >
>>> > It appears there is some run away threads hung state scenario causing 
>>> > this. I am not able to reproduce it with main go routine explict panic 
>>> > and some go ro

Re: [go-nuts] alloc vs totalalloc in memory

2020-09-10 Thread Ian Lance Taylor
On Thu, Sep 10, 2020 at 4:39 PM Alexander Mills
 wrote:
>
> I have this helper func to print memory usage (detect a memory leak?)
>
>
> func PrintMemUsage() {
> var m runtime.MemStats
> runtime.ReadMemStats()
> // For info on each, see: https://golang.org/pkg/runtime/#MemStats
> fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))
> fmt.Printf("\tTotalAlloc = %v MiB", bToMb(m.TotalAlloc))
> fmt.Printf("\tSys = %v MiB", bToMb(m.Sys))
> fmt.Printf("\tNumGC = %v\n", m.NumGC)
> }
>
> I am seeing output like this:
> Alloc = 2481 MiB TotalAlloc = 24038 MiB Sys = 2752 MiB NumGC = 114
>
> what is the difference between Alloc and TotalAlloc .. ?

The link above, after "For info on each", explains the difference.  If
the explanation is unclear, tell us more.

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/CAOyqgcVsLoMxgnHbf%2BizcB27f-jfwqxsL80p4ya%2Bb_bp1Wp5AQ%40mail.gmail.com.


Re: [go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.

2020-09-10 Thread Ian Lance Taylor
On Wed, Sep 9, 2020 at 11:58 PM Yonatan Gizachew  wrote:
>
> Also, is there a way to print the values of runtime.g?

In what sense?  Code running the runtime package can just print it.
Or if you run the program under gdb, you should be able to "print
'runtime.g'" (you need the quotes because otherwise gdb will think it
is a structure field reference).  At least, gdb works that way on
GNU/Linux, not sure about your operating system.

Ian

> On Thursday, September 10, 2020 at 12:15:04 PM UTC+9 Ian Lance Taylor wrote:
>>
>> On Wed, Sep 9, 2020 at 7:39 PM Yonatan Gizachew  wrote:
>> >
>> > This might be trivial, but could you explain me the relationship between 
>> > the following?
>> > 1. value returned by __tls_get_addr
>>
>> This is the address of the TLS control block. The exact definition
>> depends on the architecture. All TLS variables are at some offset
>> from this value.
>>
>> > 2. runtime.g
>>
>> A TLS variable that holds the current goroutine, a pointer to a g struct.
>>
>> > 3. runtime.g0
>>
>> A global variable that holds the g struct used for the initial goroutine.
>>
>> > 4. runtime.m0
>>
>> A global variable that holds the m struct used for the initial thread.
>>
>> > 5. runtime.m
>>
>> gccgo no longer uses this. In earlier releases it was a TLS variable
>> that holds the current thread, a pointer to an m struct. In current
>> releases gccgo uses g->m for this.
>>
>> 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/0935d7c3-d2de-49cd-8d25-196b276c5ca9n%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/CAOyqgcW1KzAdxYxfv4Ge5zFoioO3XTmDwVLeCxaC5dxobavkDw%40mail.gmail.com.


Re: [go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.

2020-09-10 Thread Ian Lance Taylor
On Wed, Sep 9, 2020 at 11:55 PM Yonatan Gizachew  wrote:
>
> Thank you for the explanation. For example, please have a look at the this bt.
> __tls_get_addr is called after runtime.getg. So, what does __tls_get_addr 
> return at this time, a pointer to runtime.g or runtime.g itself?

If I recall correctly, __tls_get_addr (which is of course a general
utility that has nothing particularly to do with Go) will return the
address of runtime.g for the thread that calls it.

Ian



> On Thursday, September 10, 2020 at 12:15:04 PM UTC+9 Ian Lance Taylor wrote:
>>
>> On Wed, Sep 9, 2020 at 7:39 PM Yonatan Gizachew  wrote:
>> >
>> > This might be trivial, but could you explain me the relationship between 
>> > the following?
>> > 1. value returned by __tls_get_addr
>>
>> This is the address of the TLS control block. The exact definition
>> depends on the architecture. All TLS variables are at some offset
>> from this value.
>>
>> > 2. runtime.g
>>
>> A TLS variable that holds the current goroutine, a pointer to a g struct.
>>
>> > 3. runtime.g0
>>
>> A global variable that holds the g struct used for the initial goroutine.
>>
>> > 4. runtime.m0
>>
>> A global variable that holds the m struct used for the initial thread.
>>
>> > 5. runtime.m
>>
>> gccgo no longer uses this. In earlier releases it was a TLS variable
>> that holds the current thread, a pointer to an m struct. In current
>> releases gccgo uses g->m for this.
>>
>> 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/20dd490b-f972-4af7-bf4c-f2ab8188c5c1n%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/CAOyqgcXTEX8i6j6qdcr4jEdOo%2Beix8zoepn4by8nuO%2BirqXF8w%40mail.gmail.com.


Re: [go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.

2020-09-09 Thread Ian Lance Taylor
On Wed, Sep 9, 2020 at 7:39 PM Yonatan Gizachew  wrote:
>
> This might be trivial, but could you explain me the relationship between the 
> following?
> 1. value returned by __tls_get_addr

This is the address of the TLS control block.  The exact definition
depends on the architecture.  All TLS variables are at some offset
from this value.

> 2. runtime.g

A TLS variable that holds the current goroutine, a pointer to a g struct.

> 3. runtime.g0

A global variable that holds the g struct used for the initial goroutine.

> 4. runtime.m0

A global variable that holds the m struct used for the initial thread.

> 5. runtime.m

gccgo no longer uses this.  In earlier releases it was a TLS variable
that holds the current thread, a pointer to an m struct.  In current
releases gccgo uses g->m for this.

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/CAOyqgcXZPrfi1i1vR_bYCkrSOkUd9NWp2YoCQMrBF-0Zj%3DDazQ%40mail.gmail.com.


Re: [go-nuts] Running golang C-shared library in an OS that uses cooperative scheduling.

2020-09-09 Thread Ian Lance Taylor
On Wed, Sep 9, 2020 at 7:26 PM Yonatan Gizachew  wrote:
>
> Is there any known problems that could appear when we run golang C-shared 
> libraries in an OS that uses a non-preemptive scheduling mechanism. I am 
> experiencing some problems related to TLS (more specifically runtime.m0 and 
> runtime.g0).
> FYI - the C-shared library was built suing the gccgo compiler as:
>  go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go

Note that runtime.m0 and runtime.g0 are not themselves TLS variables.
runtime.g is a TLS variable.

As gccgo has not been tested on your platform, any number of problems
are possible.  How does your OS handle scheduling non-preemptively?
Only schedule on system calls?  I think that could work with typical
Go programs, although it could longer GC pauses with gccgo.

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/CAOyqgcVO01_SaUxG9GZettfYNcqBxiey-B7Fjo9JTk7KeD7%2Bqg%40mail.gmail.com.


Re: [go-nuts] linux/arm struct alignment seems wrong

2020-09-09 Thread Ian Lance Taylor
On Wed, Sep 9, 2020 at 4:59 AM Jan Mercl <0xj...@gmail.com> wrote:
>
> If the intent is to have Go alignments/offsets of types compatible
> with the C ABI then I think it's safe to say this is a bug.
>
> And the existence of the syscall package, in some cases passing
> Go-defined structs to the kernel that must be binary compatible with
> their C definitions, IMO suggests that the intent is indeed there.

Exact alignment/offset compatibility with the C ABI is not a goal.
Sorry.  (It's actually harder than one might think to maintain that
kind of compatibility.  For example, on x86, the C ABI uses one
alignment for double variables and a different alignment for double
variables that appear as a field in a struct.  Unless, of course, you
use the -malign-double option.  And more generally some platforms have
multiple C ABIs, including x86 if you count the MCU psABI.)

The Go structs in the syscall package that need to match C structs are
carefully written to work correctly.

You may find the cgo -godefs option to be helpful, as it provides Go
structs that exactly match C structs, given a particular set of
compiler options.

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/CAOyqgcW%2ByA%2BzE4afZ81GJHCXm%3De9tfz-8gD99EQiEe%2Bk7xOKRw%40mail.gmail.com.


Re: [go-nuts] Re: why the binary generated by go test has no symbol table

2020-09-08 Thread Ian Lance Taylor
On Tue, Sep 8, 2020 at 7:04 PM buaa...@gmail.com  wrote:
>
> I wrote a tool to get binary file's symbol table during initialization, and 
> do some special tests, but it fails on Linux, so I get the log like:
>
> $ go test
> 2020/09/09 10:02:44 reading /tmp/go-build334351549/b001/xxx.test: no symbol 
> section
> 2020/09/09 10:02:44 reading /tmp/go-build334351549/b001/xxx.test: no symbols

One approach you can use is to have the test build a program using "go build".

Or you can run your tests using "go test -c".

Ian


> 在2020年9月9日星期三 UTC+8 上午6:01:18 写道:
>>
>> On Mon, Sep 7, 2020 at 7:07 PM buaa...@gmail.com  wrote:
>> >
>> > There is no ldflags provided, so why the symbol table is stripped
>>
>> Because if you run "go test" without the -c option, the executable is
>> built, run, and then thrown away. There no reason to spend time
>> generating debugging information that nobody will ever use.
>>
>> Which leads to the question: how did you notice? What is the real problem 
>> here?
>>
>> Ian
>>
>>
>> > 在2020年9月8日星期二 UTC+8 上午10:05:33 写道:
>> >>
>> >> And only on Linux, there is no symbol section in test binary unless I 
>> >> generate it by go test -c
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to golang-nuts...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/golang-nuts/d8840e17-63c6-4f32-af1d-5d73d12dfbd4n%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/93fd8c75-6e2d-4449-8912-a86fc70dee06n%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/CAOyqgcUA%3DZDMa1X7pH1JCkr_XxMgWS-LRBdrsXLcbqiahPW28g%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-09-08 Thread Ian Lance Taylor
On Tue, Sep 8, 2020 at 5:47 PM Steven Blenkinsop  wrote:
>
> Reading over the pointer method example, I noticed that a derived type cannot 
> be inferred in a nested call while leaving method constraints intact:
>
> type DerivedTypeConstraint[T any] interface {
> type *T
> Method()
> }
>
> func Foo[T any, PT DerivedTypeConstraint[T]](_ T) {}
>
> func Bar[T any, PT DerivedTypeConstraint[T]](t T) {
> Foo(t) // Error: *T has no methods
> }
>
> type S struct{}
>
> func (S) Method() {}
>
> func main() {
> Bar(S{}) // This is fine, PT gets inferred as *S, which implements Method
> }
>
>
> https://go2goplay.golang.org/p/9GMdhTbcMDs
>
> Obviously, you can work around this by passing PT explicitly rather than 
> letting *T be inferred. It's just unfortunate that, even though *T must have 
> any methods in the constraint on PT (any other type with the same underlying 
> type would have no methods), the compiler isn't, and most likely shouldn't 
> be, smart enough to figure that out. I'm not sure how to solve this, but I 
> think it makes the design feel a little less polished.

I think that it's really crucial for type inference rules to be as
simple and clear as possible.  There must never be any confusion as to
what an inferred type might be.  In complicated cases, it's fine to
explicitly list the type arguments.  In fact, it's more than fine:
it's desirable.

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/CAOyqgcWrPLkq61GZBYQ%3Dt5zhnd%3DY%3DbtBhSEBT9XNmBnpfvVY3g%40mail.gmail.com.


Re: [go-nuts] Re: why the binary generated by go test has no symbol table

2020-09-08 Thread Ian Lance Taylor
On Mon, Sep 7, 2020 at 7:07 PM buaa...@gmail.com  wrote:
>
> There is no ldflags provided, so why the symbol table is stripped

Because if you run "go test" without the -c option, the executable is
built, run, and then thrown away.  There no reason to spend time
generating debugging information that nobody will ever use.

Which leads to the question: how did you notice?  What is the real problem here?

Ian


> 在2020年9月8日星期二 UTC+8 上午10:05:33 写道:
>>
>> And only on Linux, there is no symbol section in test binary unless I 
>> generate it by go test -c
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d8840e17-63c6-4f32-af1d-5d73d12dfbd4n%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/CAOyqgcVKFp%3DMv-h%2BzdY%2B5VcHhSrs9McxhHLUX_O9dyAzm2GhFw%40mail.gmail.com.


Re: [go-nuts] Syntactic analysis with Gocc

2020-09-08 Thread Ian Lance Taylor
On Tue, Sep 8, 2020 at 11:56 AM Abraham  wrote:
>
> Hi, I am trying to implement a parser with Gocc. This is the file with the 
> definition of the grammar.

...

> However the parse input, I am not able to correctly read the latest 
> production of Opc (MLinea) and a syntax error. I think the definition is 
> correct, but I don't get the desired result.
> What am I doing wrong?

You might need to reach out to the gocc maintainers directly.

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/CAOyqgcUEEok0xz8uy7PJJoFYRRsy%2Bna3CCGRxQgGY8GD0L46Bg%40mail.gmail.com.


Re: [go-nuts] cgo cross compilation to arm failed

2020-09-07 Thread Ian Lance Taylor
On Sun, Sep 6, 2020 at 1:53 PM 'Hubert Hirtz' via golang-nuts
 wrote:
>
> I am trying to cross-compile a project that depends on sqlite3 on a
> amd64 machine (host) for an armhf machine (target), using clang with the
> appropriate "--target" flag.
>
> The build fails on runtime/cgo with the following errors:
>
> ```
> # runtime/cgo
> In file included from gcc_libinit.c:8:
> /usr/include/pthread.h:672:6: error: 'regparm' is not valid on this platform
> /usr/include/bits/pthreadtypes-arch.h:52:50: note: expanded from macro
> '__cleanup_fct_attribute'
> In file included from gcc_libinit.c:8:
> /usr/include/pthread.h:684:3: error: 'regparm' is not valid on this platform
> /usr/include/bits/pthreadtypes-arch.h:52:50: note: expanded from macro
> '__cleanup_fct_attribute'
> In file included from gcc_libinit.c:8:
> /usr/include/pthread.h:725:6: error: 'regparm' is not valid on this platform
> /usr/include/bits/pthreadtypes-arch.h:52:50: note: expanded from macro
> '__cleanup_fct_attribute'
> ```
>
> Here is the `go env` and the full build output (run with `-x`):
> 
>
> Do you have any idea why it fails or if I missed something?

In order to cross-compile a Go program that uses cgo, you need a
complete C cross-compiler.  In this case your C cross-compiler appears
to be using the native header files, which can't work.  It needs to
use the cross-compiler header files.

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/CAOyqgcUf-oJQGRcs%3D_kwVRATD4%2B6jRS1hsJUZdPu%2BnznKYLHRA%40mail.gmail.com.


Re: [go-nuts] zombie parent scenario with golang

2020-09-07 Thread Ian Lance Taylor
On Mon, Sep 7, 2020 at 12:03 AM Uday Kiran Jonnala  wrote:
>
> Thanks for the reply, I get the point on zombie, I do not think the issue 
> here is parent not reaping child, seems like go process has not finished 
> execution of some
> internal threads (waiting on some futex) and causing SIGCHILD not to be sent 
> to parent.
>
> go process named  hit with panic and I see this went into zombie 
> state
>
> $ ps -ef | grep replicator
> root  87548  87507  0 Aug23 ?00:00:00 [replicator] 
>
> Now looking at the tasks within the process
>
> I see the stack trace of the threads within the process still stuck on 
> following
>
> bash-4.2# cat /proc/87548/task/87561/stack
> [] futex_wait_queue_me+0xc4/0x120
> [] futex_wait+0x10a/0x250
> [] do_futex+0x35e/0x5b0
> [] SyS_futex+0x13b/0x180
> [] do_syscall_64+0x79/0x1b0
> [] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [] 0x
>
> From the above example if we are creating some internal threads and main 
> thread is excited due to panic and left some detached threads, process will 
> be in zombie state until the threads
> within the process completes.
>
> It appears there is some run away threads hung state scenario causing this. I 
> am not able to reproduce it with main go routine explict panic and some go 
> routine still executing.
>
> Does the above stack trace sound familiar wrt internal threads of Go runtime ?

If the process is defunct, then none of the thread stacks matter.
They are just where the thread happened to be when the process exited.

What is the real problem you are seeing?

Ian




> On Thursday, August 27, 2020 at 1:43:39 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Thu, Aug 27, 2020 at 10:01 AM Uday Kiran Jonnala
>>  wrote:
>> >
>> > I have a situation on zombie parent scenario with golang
>> >
>> > A process (in the case replicator) has many goroutines internally
>> >
>> > We hit into panic() and I see the replicator process is in Zombie state
>> >
>> > <<>>>:~$ ps -ef | grep replicator
>> >
>> > root 87548 87507 0 Aug23 ? 00:00:00 [replicator] 
>> >
>> >
>> >
>> > Main go routine (or the supporting P) excited, but panic left the other P 
>> > thread to be still in executing state (main P could be 87548 and 
>> > supporting P thread 87561 is still there) in blocked state
>> >
>> > bash-4.2# ls -Fl /proc/87548/task/87561/fd | grep 606649l-wx--. 1 root 
>> > root 64 Aug 25 10:59 1 -> pipe:[606649]l-wx--. 1 root root 64 Aug 25 
>> > 10:59 2 -> pipe:[606649]
>> >
>> > Stack trace
>> >
>> > bash-4.2# cat /proc/87548/task/87561/stack[] 
>> > futex_wait_queue_me+0xc4/0x120[] 
>> > futex_wait+0x10a/0x250[] 
>> > do_futex+0x35e/0x5b0[] 
>> > SyS_futex+0x13b/0x180[] 
>> > do_syscall_64+0x79/0x1b0[] 
>> > entry_SYSCALL_64_after_hwframe+0x3d/0xa2[] 
>> > 0x
>> >
>> >
>> >
>> > We have panic internally from main go routine
>> >
>> > fatal error: concurrent map writes
>> >
>> > goroutine 666359 [running]:
>> > runtime.throw(0x101d6ae, 0x15)
>> > /home/ll/ntnx/toolchain-builds/78ae837ba07c8ef8f0ea782407d8d4626815552b.x86_64/go/src/runtime/panic.go:608
>> >  +0x72 fp=0xc00374b6f0 sp=0xc00374b6c0 pc=0x42da62
>> > runtime.mapassign_faststr(0xdb71c0, 0xc00023f5f0, 0xc000aca990, 0x83, 
>> > 0xc0009d03c8)
>> > /home/ll/ntnx/toolchain-builds/78ae837ba07c8ef8f0ea782407d8d4626815552b.x86_64/go/src/runtime/map_faststr.go:275
>> >  +0x3bf fp=0xc00374b758 sp=0xc00374b6f0 pc=0x41527f
>> > github.eng.nutanix.com/xyz/abc/metadata.UpdateRecvInProgressFlag(0xc000aca990,
>> >  0x83, 0x0)
>> >
>> > ...
>> >
>> > goroutine 665516 [chan receive, 2 minutes]:
>> > zeus.(*Leadership).LeaderValue.func1(0xc003d5c120, 0x0, 0xc002e906c0, 
>> > 0x52, 0xc00302ec60, 0x29)
>> > /home/ll/ntnx/main/build/.go/src/zeus/leadership.go:244 +0x34
>> > created by zeus.(*Leadership).LeaderValue
>> > /home/ll/ntnx/main/build/.go/src/zeus/leadership.go:243 +0x277
>> > 2020-08-03 00:35:04 rolled over log file
>> > ERROR: logging before flag.Parse: I0803 00:35:04.426906 196123 
>> > dataset.go:26] initialize zfs linking
>> > ERROR: logging before flag.Parse: I0803 00:35:04.433296 196123 
>> > dataset.go:34] completed zfs linking successfully
>> > I0803 00:35:04.433447 196123 main.go:86] Gflags passed NodeUuid: 
>> > c238e584-0eeb

Re: [go-nuts] Asynchronous preemption

2020-09-04 Thread Ian Lance Taylor
On Wed, Sep 2, 2020 at 9:11 PM Yonatan Gizachew  wrote:
>
> I see. If that is so, what is the job of sysmon thread?

The sysmon thread is not related to asynchronous preemption.  The
sysmon thread does a few different things.  One of the things it does
is notice threads that have been stuck in a system call for a while,
and detach them from their P, and start running a new thread
associated with that P.  This is scheduler activity, and it permits
additional parallelism in the program, but it's not preemption.

Ian

> On Thursday, September 3, 2020 at 12:35:26 PM UTC+9 Ian Lance Taylor wrote:
>>
>> On Wed, Sep 2, 2020 at 7:14 PM Yonatan Gizachew  wrote:
>> >
>> > Is it possible to stop the asynchronous preemption like:
>> > GODEBUG=asyncpreemptoff=1 go build -o libgotest.so -buildmode=c-shared 
>> > -compiler=gccgo test.go
>> >
>> > I am using gccgo compiler.
>>
>> Note that executables built by the gccgo compiler don't use
>> asynchronous preemption.
>>
>> 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/2b865dc9-7992-4239-9d5f-09c0ba1fa369n%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/CAOyqgcX4dCF_NBEnLLK75mT%3DUh1kczeHfV7FVnWRQf5e%2BM-PoQ%40mail.gmail.com.


Re: [go-nuts] Deep printing in the reflect package

2020-09-04 Thread Ian Lance Taylor
On Fri, Sep 4, 2020 at 2:57 PM aind...@gmail.com  wrote:
>
> I agree that this functionality can be implemented outside the standard 
> library. However, traversing nested data structures does seem to fall into 
> reflect's domain. In particular, one would have to deal with unexported 
> fields and pointer cycles.
>
> I can also see how a newcomer would think the standard library would be able 
> to print any value in the language.
>
> > there will inevitably be a lot of desire for customization of the printed 
> > output, which will lead to a complex API.
>
> This is a fair. Maybe the goal should be to provide a general mechanism to 
> walk data structures, rather than format them?

Well, that too can live outside of the reflect package.  Probably the
right approach would be write a third party package, see whether it
seems popular, and then consider whether to bring it into the standard
library.

You suggest that traversing nested data structure is reflect's domain,
but I'm not sure I agree.  The only current case is reflect.DeepEqual.

Ian


> On Friday, September 4, 2020 at 4:24:23 PM UTC-4 Ian Lance Taylor wrote:
>>
>> On Fri, Sep 4, 2020 at 1:11 PM aind...@gmail.com  wrote:
>> >
>> > Often on my team, Go programmers (particularly new ones) simply want full 
>> > visibility into a data structure when debugging. For those who aren't 
>> > familiar with pointers, seeing a hexadecimal number show up in a log can 
>> > be really frustrating. I usually point them to 
>> > https://github.com/davecgh/go-spew or https://github.com/sanity-io/litter. 
>> > Although they can be heavy-handed with their unsafe package dependency and 
>> > fancy formatting, they are indispensable when debugging data structures 
>> > like syntax trees.
>> >
>> > I wonder it's worthwhile to add this functionality to the reflect package, 
>> > and take advantage of the functionality that DeepEquals uses. I'm not a 
>> > fan of Dump functions that just take an io.Writer. Why not add a named 
>> > type for interface{} or reflect.Value called reflect.Deep, which 
>> > implements fmt.Formatter? Then, packages that use fmt will have more 
>> > precise control over formatting, and we can maybe add special formatting 
>> > directives for reflect.Deep.
>> >
>> > What do you think?
>>
>> Well, we already have fmt.Printf("%#v", value).
>>
>> I don't see any obvious reason to add printing to the reflect package.
>> It doesn't require any internal information, and can be written
>> entirely separately. And, there will inevitably be a lot of desire
>> for customization of the printed output, which will lead to a complex
>> API.
>>
>> Basically: https://golang.org/doc/faq#x_in_std .
>>
>> 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/beda96b2-9f41-41f8-a501-3090b15ed37bn%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/CAOyqgcUNK2jn0q%2B3xttWuyBDDxEtAKJ0%2BMOc4LMn5apScgmQcQ%40mail.gmail.com.


Re: [go-nuts] What is The compiler's -json optimization logging

2020-09-04 Thread Ian Lance Taylor
[ + drchase ]

On Fri, Sep 4, 2020 at 1:16 PM Falco Wockenfuß  wrote:
>
> sorry if this is a dumb question, but the Release Notes for go 1.15 have the 
> Note:
> The compiler's -json optimization logging now reports large (>= 128 byte) 
> copies and includes explanations of escape analysis decisions.
>
> But I didn't find anything about "-json" as a flag for go build or similar 
> and google dind't yield anything for go compiler json optimization logging or 
> similar.
>
> Can anyone clarify what this json optimiziation logging is and how it can be 
> used/invoked ?

It does seem that this option should be mentioned in cmd/compile/doc.go.

To use it, try "go build -gcflags=json=0,/my/json/dir".

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/CAOyqgcVB-pJUf6AxSDsAqoEJbzBm_h7Qt4%2BTJyUg0mE63RyDcQ%40mail.gmail.com.


Re: [go-nuts] Deep printing in the reflect package

2020-09-04 Thread Ian Lance Taylor
On Fri, Sep 4, 2020 at 1:11 PM aind...@gmail.com  wrote:
>
> Often on my team, Go programmers (particularly new ones) simply want full 
> visibility into a data structure when debugging. For those who aren't 
> familiar with pointers, seeing a hexadecimal number show up in a log can be 
> really frustrating. I usually point them to 
> https://github.com/davecgh/go-spew or https://github.com/sanity-io/litter. 
> Although they can be heavy-handed with their unsafe package dependency and 
> fancy formatting, they are indispensable when debugging data structures like 
> syntax trees.
>
> I wonder it's worthwhile to add this functionality to the reflect package, 
> and take advantage of the functionality that DeepEquals uses. I'm not a fan 
> of Dump functions that just take an io.Writer. Why not add a named type for 
> interface{} or reflect.Value called reflect.Deep, which implements 
> fmt.Formatter? Then, packages that use fmt will have more precise control 
> over formatting, and we can maybe add special formatting directives for 
> reflect.Deep.
>
> What do you think?

Well, we already have fmt.Printf("%#v", value).

I don't see any obvious reason to add printing to the reflect package.
It doesn't require any internal information, and can be written
entirely separately.  And, there will inevitably be a lot of desire
for customization of the printed output, which will lead to a complex
API.

Basically: https://golang.org/doc/faq#x_in_std .

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/CAOyqgcW48Y%3DXz51daYM4qkrrDdj2wuCm6dBOa%3DR9vgBMVZatig%40mail.gmail.com.


Re: [go-nuts] Asynchronous preemption

2020-09-02 Thread Ian Lance Taylor
On Wed, Sep 2, 2020 at 7:14 PM Yonatan Gizachew  wrote:
>
> Is it possible to stop the asynchronous preemption like:
> GODEBUG=asyncpreemptoff=1 go build -o libgotest.so -buildmode=c-shared 
> -compiler=gccgo test.go
>
> I am using gccgo compiler.

Note that executables built by the gccgo compiler don't use
asynchronous preemption.

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/CAOyqgcUyOoBe%2BcV7MqL5crCHbUHuuYEXu%2BhPe1gQwmMokN75Tg%40mail.gmail.com.


Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-09-02 Thread Ian Lance Taylor
On Wed, Sep 2, 2020 at 3:45 AM targe...@gmail.com  wrote:
>
> > Other people have said this too, but I want to emphasize that there
> are not 4 potential states of an interface value. There are 2
> potential states: 1) interface does not hold any value, and is == nil;
> 2) interface holds a value, and is != nil.
>
> Indeed, there are 2 states of interface observable from outside. Although one 
> of these observable states gets expressed through 2 states invisible to outer 
> world. Which isn't a problem on its own.
>
> > When you start talking about an interface as a fat pointer you are
> talking about how those 2 states are implemented. There are other
> possible implementations
>
> Yes. And that's not an issue on its own. The issue is, such implementation 
> detail kind of "leaks" sometimes and bites you when you don't expect. And it 
> does so because the way it gets constructed omits one specific detail of 
> conversion from pointer to interface.

I don't think that is correct.  The implementation detail never leaks.
An interface always either holds a valid value (is != nil) or does not
hold a valid value (is == nil).

I believe the confusion is due to the overloading of "nil".  It means
both an invalid interface and an invalid pointer, but you are
permitted to store an invalid pointer in a valid interface.

Ian

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


Re: [go-nuts] cgo godefs questions

2020-09-01 Thread Ian Lance Taylor
On Tue, Sep 1, 2020 at 12:10 AM 'Dan Kortschak' via golang-nuts
 wrote:
>
> I am working on some C/Go interop code that includes this horror on the
> C side (TYPE_BITS is 5 and NAMED_BITS is 16):
>
> ```
> struct sxpinfo_struct {
> SEXPTYPE type  :  TYPE_BITS;
> /* ==> (FUNSXP == 99) %% 2^5 == 3 == CLOSXP
>  * -> warning: `type' is narrower than values
>  *  of its type
>  * when SEXPTYPE was an enum */
> unsigned int scalar:  1;
> unsigned int obj   :  1;
> unsigned int alt   :  1;
> unsigned int gp: 16;
> unsigned int mark  :  1;
> unsigned int debug :  1;
> unsigned int trace :  1;  /* functions and memory tracing */
> unsigned int spare :  1;  /* used on closures and when REFCNT is defined 
> */
> unsigned int gcgen :  1;  /* old generation number */
> unsigned int gccls :  3;  /* node class */
> unsigned int named : NAMED_BITS;
> unsigned int extra : 32 - NAMED_BITS; /* used for immediate bindings */
> }; /*   Tot: 64 */
> ```
>
> This gets converted to this Go struct:
>
> ```
> type sxpinfo struct {
> Gpuint16
> Pad_cgo_0 [2]byte
> Named uint16
> Pad_cgo_1 [2]byte
> }
> ```
>
> I don't expect that Cgo will cope with the bitfields, but I am
> surprised that it makes any effort at all beyond getting to alignment.
> In particular the Go sxpinfo gives misleading field, Gp that although
> the correct size, is not aligned at all with the bits in the C gp field
> (one byte too far forward).
>
> Is this behaviour expected? Would it not be more sensible to do with
> bitfields what Cgo does with unions, and just give back a struct {
> [8]byte }?
>
>
> The second question is whether `#cgo pkg-config:` is expected to work
> with -I flags?
>
> I can generate the Go definitions with
>
> ```
> go tool cgo -godefs -- $(pkg-config --cflags libR) generate.go
> ```
>
> but including `#cgo pkg-config: R` or `#cgo pkg-config: libR` fails to
> find the R headers.

This is a bug.  Sent https://golang.org/cl/252378.


> The second question is whether `#cgo pkg-config:` is expected to work
> with -I flags?
>
> I can generate the Go definitions with
>
> ```
> go tool cgo -godefs -- $(pkg-config --cflags libR) generate.go
> ```
>
> but including `#cgo pkg-config: R` or `#cgo pkg-config: libR` fails to
> find the R headers.

I think that currently cgo -godefs ignores #cgo lines.  This was
recently reported at https://golang.org/issue/41072.

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/CAOyqgcVAM2-%3DJjffe1qpznozeBXZHGf302d-fJ9wE90ADUBWLw%40mail.gmail.com.


Re: [go-nuts] [generics] Bugs + something else

2020-08-31 Thread Ian Lance Taylor
On Mon, Aug 31, 2020 at 5:49 PM p...@pjebs.com.au  wrote:
>
> 1.
> For this Go 2 snippet: https://go2goplay.golang.org/p/vbfBBmjxaMi
>
> Why can't I use square brackets when calling the constructor?

Sorry, the Go 2 playground isn't fully up to date.


> 2. Variadic `any` types + allowing a called function() to be used as an 
> argument + return arguments types and numbers based on input arguments
>
> I want to implement a `must` function which I proposed here: 
> https://github.com/golang/go/issues/32219
>
> Based on the current generics proposal, I don't seem to be able to do so.
> Am I missing something or is must outside its ambit?

The current design draft does not support variadic type parameters.
Maybe someday.

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/CAOyqgcUFPaZoU46rPsS-RpXA2eAM2Xnr1dEXi_b%3DtHXNGm55MA%40mail.gmail.com.


Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

2020-08-31 Thread Ian Lance Taylor
On Mon, Aug 31, 2020 at 10:25 AM samir.el...@gmail.com
 wrote:
>
> Great improvements. Well done.
>
> Any intentions to make methods accept additional type arguments ?

See 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods
.

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/CAOyqgcVNjM1jzLQH6isUJyvh8oVj4Ciw-5FxMXfgnWeiOj2yjw%40mail.gmail.com.


Re: [go-nuts] rin: return if nil syntactic sugar

2020-08-30 Thread Ian Lance Taylor
On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris  wrote:
>
> Idk if this has been proposed or discussed before.
>
> Given the last error handling abbreviation proposal is rejected. How about 
> some simple syntactic sugar like this:
>
>   rin Something()
>
> Which is just a sugar for:
>
>   if err := Something(); err != nil {
> return err
>   }
>
> To make it worth the new keyword make it so that:
>
>   rin v := Something()
>
> equals to:
>
>   v, err := Something()
>   if err != nil {
> return err
>   }

This is similar to the check/handle design draft, without the handle.
You may want to take a look at https://golang.org/issue/40432.
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/CAOyqgcU5C4F-m_YPsPtxuPmt5TQrJnXN2QK4dGBONkYD1iKyww%40mail.gmail.com.


Re: [go-nuts] Memory Leak in bytes.Buffer String() method

2020-08-30 Thread Ian Lance Taylor
On Sun, Aug 30, 2020 at 8:25 AM Sarath Prabath Redlapalli Jaya
 wrote:
>
> Hi, we've been observing high memory usage in the following code
> https://github.com/Masterminds/squirrel/blob/master/placeholder.go#L113
>
> We measured from pprof of heap
>
> (pprof) top20
>
> Showing nodes accounting for 360.07MB, 91.31% of 394.32MB total
>
> Dropped 142 nodes (cum <= 1.97MB)
>
> Showing top 20 nodes out of 139
>
>   flat  flat%   sum%cum   cum%
>
>   101.21MB 25.67% 25.67%   101.21MB 25.67%  bytes.(*Buffer).String

This tells you where the memory was allocated.  If you are trying to
track down a memory leak, you need to look into what is keeping this
memory live in the heap.  The fact that it was allocated here is a
start.  But your next step is to look at what calls to this function
are allocating memory, and what is happening to that memory to keep it
alive.  The pprof program can help tell you where the calls are coming
from, but then you'll have to look at what happens to those strings
and why they are being kept live.

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/CAOyqgcUc2fK50YyBJRSuirvR%3DOioTtg%3DC6fL2ovHKNKAVCwB8g%40mail.gmail.com.


Re: [go-nuts] Re: Memory Leak in bytes.Buffer String() method

2020-08-30 Thread Ian Lance Taylor
On Sun, Aug 30, 2020 at 8:28 AM Sarath Prabath Redlapalli Jaya
 wrote:
>
> The memory usage of containers are ever increasing and has grown from 100 MB 
> to ~ 1 GB in couple of hours. Not able to understand where the gap is, even 
> though the the builder is being reset. Would keeping a sync.Pool of builders 
> help here?

No, because the problem is not the builders.  It's what is happening
to the strings after they have been built.

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/CAOyqgcWfivhCZj1MmAfSg_JBZVxr_hE9K%2Bj%3Dr-NvZrr3nUHeSw%40mail.gmail.com.


Re: [go-nuts] about go tool link, where link get code(text segment) from *.o files and write it to executable files?

2020-08-30 Thread Ian Lance Taylor
On Sun, Aug 30, 2020 at 7:32 AM xie cui  wrote:
>
> i am trying to understand code of cmd/link,  i need to know where linker get 
> instructions(text segment in executable file) from *o file, and where linker 
> write the binary data (.text segment) to excutable file(in linux it 's a elf 
> file).

The linker was recently rewritten, so I'm describing tip and to some
extent Go 1.15, not earlier releases.

Object files are read by the cmd/link/internal/loader package.  The Go
object file format is read by code in cmd/internal/goobj.

All the loadable segments are written out by the asmb function in
cmd/link/internal/asmb.go.

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/CAOyqgcUpTwG8PPCeENXcdTHG-G0DS%3DDbq2RdQJNWzQFiFpVVag%40mail.gmail.com.


Re: [go-nuts] How to correctly run test in Golang source code directory runtime?

2020-08-28 Thread Ian Lance Taylor
On Fri, Aug 28, 2020 at 9:35 AM Chai Baoyang <88304...@qq.com> wrote:
>
> Hi All,
>  I tried to run "go test -timeout 30s -run ^TestMemStats$" in the source 
> directory runtime. But failed with error infomation below:
> "error.go:7:8: use of internal package internal/bytealg not allowed
> alg.go:8:2: use of internal package internal/cpu not allowed
> atomic_pointer.go:8:2: use of internal package runtime/internal/atomic not 
> allowed
> chan.go:22:2: use of internal package runtime/internal/math not allowed
> alg.go:9:2: use of internal package runtime/internal/sys not allowed"

This normally means that the "go" binary on your PATH had a GOROOT
that was not the same as the directory in which you ran "go test".

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/CAOyqgcX%3Dz3PRNn%3D1fXi46FdnSe%3DGCdTmOQZHQSPZy_491cjWiw%40mail.gmail.com.


Re: [go-nuts] zombie parent scenario with golang

2020-08-27 Thread Ian Lance Taylor
On Thu, Aug 27, 2020 at 10:01 AM Uday Kiran Jonnala
 wrote:
>
> I have a situation on zombie parent scenario with golang
>
>  A process (in the case replicator) has many goroutines internally
>
> We hit into panic() and I see the replicator process is in Zombie state
>
> <<>>>:~$ ps -ef | grep replicator
>
> root  87548  87507  0 Aug23 ?00:00:00 [replicator] 
>
>
>
> Main go routine (or the supporting P) excited, but panic left the other P 
> thread to be still in executing state (main P could be 87548 and supporting P 
> thread 87561 is still there) in blocked state
>
> bash-4.2# ls -Fl /proc/87548/task/87561/fd | grep 606649l-wx--. 1 root 
> root 64 Aug 25 10:59 1 -> pipe:[606649]l-wx--. 1 root root 64 Aug 25 
> 10:59 2 -> pipe:[606649]
>
> Stack trace
>
> bash-4.2# cat /proc/87548/task/87561/stack[] 
> futex_wait_queue_me+0xc4/0x120[] 
> futex_wait+0x10a/0x250[] 
> do_futex+0x35e/0x5b0[] 
> SyS_futex+0x13b/0x180[] 
> do_syscall_64+0x79/0x1b0[] 
> entry_SYSCALL_64_after_hwframe+0x3d/0xa2[] 
> 0x
>
>
>
> We have panic internally from main go routine
>
> fatal error: concurrent map writes
>
> goroutine 666359 [running]:
> runtime.throw(0x101d6ae, 0x15)
> /home/ll/ntnx/toolchain-builds/78ae837ba07c8ef8f0ea782407d8d4626815552b.x86_64/go/src/runtime/panic.go:608
>  +0x72 fp=0xc00374b6f0 sp=0xc00374b6c0 pc=0x42da62
> runtime.mapassign_faststr(0xdb71c0, 0xc00023f5f0, 0xc000aca990, 0x83, 
> 0xc0009d03c8)
> /home/ll/ntnx/toolchain-builds/78ae837ba07c8ef8f0ea782407d8d4626815552b.x86_64/go/src/runtime/map_faststr.go:275
>  +0x3bf fp=0xc00374b758 sp=0xc00374b6f0 pc=0x41527f
> github.eng.nutanix.com/xyz/abc/metadata.UpdateRecvInProgressFlag(0xc000aca990,
>  0x83, 0x0)
>
> ...
>
> goroutine 665516 [chan receive, 2 minutes]:
> zeus.(*Leadership).LeaderValue.func1(0xc003d5c120, 0x0, 0xc002e906c0, 0x52, 
> 0xc00302ec60, 0x29)
> /home/ll/ntnx/main/build/.go/src/zeus/leadership.go:244 +0x34
> created by zeus.(*Leadership).LeaderValue
> /home/ll/ntnx/main/build/.go/src/zeus/leadership.go:243 +0x277
> 2020-08-03 00:35:04 rolled over log file
> ERROR: logging before flag.Parse: I0803 00:35:04.426906 196123 dataset.go:26] 
> initialize zfs linking
> ERROR: logging before flag.Parse: I0803 00:35:04.433296 196123 dataset.go:34] 
> completed zfs linking successfully
> I0803 00:35:04.433447 196123 main.go:86] Gflags passed NodeUuid: 
> c238e584-0eeb-48bd-b299-2a25b13602f1, External Ip: 10.15.96.163
> I0803 00:35:04.433460 196123 main.go:99] Component name using for this 
> process : abc-c238e584-0eeb-48bd-b299-2a25b13602f1
> I0803 00:35:04.433467 196123 main.go:120] Trying to initialize DB
>
>  If there is panic() from main P thread, as I understand we exit() and 
> cleanup all P threads of the process.
>
>  Are we hitting into the following scenario, I did not look into M-P-G 
> implantation in detail.
>
>  Example:
>
> #include 
> #include 
> #include 
> #include 
>
> void *thread_function(void *args)
> {
> printf("The is new thread! Sleep 20 seconds...\n");
> sleep(100);
> printf("Exit from thread\n");
> pthread_exit(0);
> }
>
> int main(int argc, char **argv)
> {
> pthread_t thrd;
> pthread_attr_t attr;
> int res = 0;
> res = pthread_attr_init();
> res = pthread_attr_setdetachstate(, PTHREAD_CREATE_DETACHED);
> res = pthread_create(, , thread_function, NULL);
> res = pthread_attr_destroy();
> printf("Main thread. Sleep 5 seconds\n");
> sleep(5);
> printf("Exit from main process\n");
> pthread_exit(0);
> }
>
> kkk@ ~/mycode/go () $ ./a.out &
> [1] 108418Main thread. Sleep 5 secondsThe is new thread! Sleep 20 seconds...
> kkk@ ~/mycode/go () $
> Exit from main processs
> PID TTY  TIME CMD
> 49313 pts/26   00:00:01 bash108418 pts/26   00:00:00 [a.out] 108449 
> pts/26   00:00:00 ps
>
>  See the main process is  and child is still hanging around
>
> kkk@ ~/mycode/go () $ sudo cat 
> /proc/108418/task/108420/stack[] 
> hrtimer_nanosleep+0xbd/0x1d0[] 
> SyS_nanosleep+0x7e/0x90[] 
> system_call_fastpath+0x16/0x1b[] 
> 0xujonnala@ ~/mycode/go () $ Exit from thread
>
>  Any help in this regard is appreciated.


I think you are misreading something somewhere.  Zombie status is a
feature of a process, not a thread.  It means that the child process
has exited but that the parent process, the one which started the
child process via the fork system call (or, on GNU/Linux, the clone
system call), has not called the wait (or waitpid or wait3 or wait4)
system call to collect its status.

So don't look at threads or P's.  Look at the parent process that
started the process that became a zombie.

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/CAOyqgcXCc05jyP6OzKt0vRJ7nUod%3DFT9JTAivU3ACfDHxGg%3Djw%40mail.gmail.com.

Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-08-27 Thread Ian Lance Taylor
On Thu, Aug 27, 2020 at 3:53 AM targe...@gmail.com  wrote:
>
> Please don't forget that interface pointer isn't simple. It's a so-called 
> "fat pointer" which consists of pointer to data and pointer to methods table. 
> Thus, we have 4 potential states - (nil, nil), (nil, pointer), (pointer, nil) 
> and (pointer,pointer). First one is just ordinary nil interface. Last one is 
> just ordinary interface pointer with all operations callable without issue 
> (as long as they're properly implemented, of course). Third one with valid 
> data pointer and nil table pointer can be AFAIK created only through 
> reflection and is safely considered "invalid state". We're left with second 
> state with nil data pointer and valid table pointer, making interface methods 
> callable on it. It wouldn't be a problem - if such state couldn't be created 
> by merely casting typed nil pointer (typed pointer variable with nil value) 
> to interface. Why is this an issue? Because most interface implementations 
> require valid data pointer. "Static" (i.e. not needing data) implementations 
> can be considered corner case.

Other people have said this too, but I want to emphasize that there
are not 4 potential states of an interface value.  There are 2
potential states: 1) interface does not hold any value, and is == nil;
2) interface holds a value, and is != nil.

When you start talking about an interface as a fat pointer you are
talking about how those 2 states are implemented.  There are other
possible implementations, and in fact the implementation in gccgo used
to be different.  And even the implementation in the gc compiler has
changed; at one time ints and other small values were stored directly
in the interface value, but now we instead store a pointer to the
data.

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


Re: [go-nuts] Naming environment variables

2020-08-26 Thread Ian Lance Taylor
On Wed, Aug 26, 2020 at 8:03 AM Siddhesh Divekar
 wrote:
>
> What is the convention to name an environment variable if the program is 
> going to set it and use it.
> I have seen both ABC_DEF & AbcDef forms of it.

Do you mean the name used for the environment variable, or the name
used in the Go program?

Most environment variables use names in all caps with underscores, so ABC_DEF.

Most Go variables use mixed caps, so AbcDef.

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


Re: [go-nuts] Re: Generics and parentheses

2020-08-25 Thread Ian Lance Taylor
Thanks for the note.  Please see the discussion at
https://groups.google.com/d/msg/golang-nuts/iAD0NBz3DYw/VcXSK55XAwAJ .

Ian

On Tue, Aug 25, 2020 at 1:21 PM Kaveh Shahbazian
 wrote:
>
> After playing in generics playground with a dozen of cases that came to my 
> mind, IMHO brackets seem to be more clear than parentheses for declaring type 
> parameters. Also using the type keyword before the type parameter reduces the 
> cognitive load drastically.
>
> type StateFn[type T] func(T) StateFn[T] // Good
>
> vs:
>
> type StateFn(type T) func(T) StateFn(T) // Not as clear as the previous one
>
> It's hard to say if there are any practical alternatives to brackets - 
> according to the proposal. But angle brackets are not that ugly by themselves.
>
> (I'm not sure if this approach is actually possible)
>
> The hash/number signs appear in the language specifications just once:
>
> type StateFn<#T> func(T) StateFn<#T>
>
> And the %T syntax is used to print types:
>
> type StateFn<%T> func(T) StateFn<%T>
>
> Then, that problematic example would become:
>
> a, b = w<#x,y>(z)
>
> or:
>
> a, b = w<%x,y>(z)
>
> On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote:
>>
>> We have received a variety of feedback on the generics draft design (blog). 
>> Thanks to everyone who took the time to read it, play with generics code in 
>> the playground, file issues, and send us their thoughts.
>>
>>
>> Not unexpectedly, many people raised concerns about the syntax, specifically 
>> the choice of parentheses for type parameter declarations and generic type 
>> and function instantiations.
>>
>>
>> A typical computer keyboard provides four easily accessible pairs of 
>> single-character symmetrical "brackets": parentheses ( and ), square 
>> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
>> curly braces to delineate code blocks, composite literals, and some 
>> composite types, making it virtually impossible to use them for generics 
>> without severe syntactic problems. Angle brackets require unbounded parser 
>> look-ahead or type information in certain situations (see the end of this 
>> e-mail for an example). This leaves us with parentheses and square brackets. 
>> Unadorned square brackets cause ambiguities in type declarations of arrays 
>> and slices, and to a lesser extent when parsing index expressions. Thus, 
>> early on in the design, we settled on parentheses as they seemed to provide 
>> a Go-like feel and appeared to have the fewest problems.
>>
>>
>> As it turned out, to make parentheses work well and for 
>> backward-compatibility, we had to introduce the type keyword in type 
>> parameter lists. Eventually, we found additional parsing ambiguities in 
>> parameter lists, composite literals, and embedded types which required more 
>> parentheses to resolve them. Still, we decided to proceed with parentheses 
>> in order to focus on the bigger design issues.
>>
>>
>> The time has come to revisit this early decision. If square brackets alone 
>> are used to declare type parameters, the array declaration
>>
>>
>> type A [N]E
>>
>>
>> cannot be distinguished from the generic type declaration
>>
>>
>> type A[N] E
>>
>>
>> But if we are comfortable with the extra type keyword, the ambiguity 
>> disappears:
>>
>>
>> type A[type N] E
>>
>>
>> (When we originally dismissed square brackets, the type keyword was not yet 
>> on the table.)
>>
>>
>> Furthermore, the ambiguities that arise with parentheses appear not to arise 
>> with square brackets. Here are some examples where extra parentheses are not 
>> needed with square brackets:
>>
>>
>> using () using []
>>
>> func f((T(int))  func f(T[int])
>>
>> struct{ (T(int)) }   struct{ T[int] }
>>
>> interface{ (T(int)) }interface{ T[int] }
>>
>> [](T(int)){} []T[int]{}
>>
>>
>> To test this better understanding, and to get a feel for this alternative 
>> notation, we will begin to make changes to our prototype implementation such 
>> that it accepts either parentheses or square brackets (only one or the 
>> other) in a generic Go package. Those changes will first appear as commits 
>> to the dev.go2go branch, and eventually in the playground.
>>
>>
>> If square brackets don't lead to unforeseen issues, we have another fully 
>> explored notation to choose from, which will allow us to make a more 
>> informed decision.
>>
>>
>> - gri, iant
>>
>>
>> PS: For ambiguities with angle brackets consider the assignment
>>
>>
>> a, b = w < x, y > (z)
>>
>>
>> Without type information, it is impossible to decide whether the right-hand 
>> side of the assignment is a pair of expressions
>>
>>
>> (w < x), (y > (z))
>>
>>
>> or whether it is a generic function invocation that returns two result values
>>
>>
>> (w)(z)
>>
>>
>> In Go, type information is not available at compile time. For instance, in 
>> this case, any of the identifiers may be declared in another file that has 
>> not even been parsed yet.
>>
>>

Re: [go-nuts] Possible reasons for a segmentation fault inside mallocgc during package importing

2020-08-24 Thread Ian Lance Taylor
On Mon, Aug 24, 2020 at 7:05 PM Yonatan Gizachew  wrote:
>
> We were trying to run a go c-shared library on a emulator (Written in C/C++). 
> We use gccgo compiler to create .so file from test.go file, so that the 
> runtime could be liked dynamically. Currently we are facing a problem while 
> packages were imported in main.init.
> Here is a disassembly of the main.init function which was called from 
> runtime.main
> https://github.com/Emegua/golang_nuts/blob/master/main_init.S
> We tried to debug the issue, and until now, it seems the problem is related 
> to TLS.
> We made breakpoint using b ../../../src/libgo/go/runtime/malloc.go:660.
> When the c:= gomcache() is executed, a __tls_get_addr function retrieves some 
> address from TLS.
> Refer to the following bt.
> https://github.com/Emegua/golang_nuts/blob/master/gdb_bt_1
>
> From runtime.gomcache function here:
> https://github.com/Emegua/golang_nuts/blob/663517937f34580288c2d07249ade515a7bf4c44/runtime1.go#L490
>
> From the retrieved address (i.e, getg()), now it tries to retrieve its member 
> variable (called mcache) by accessing to specific index using pointer 
> dereferencing.
> Please see here the disassembled
> https://github.com/Emegua/golang_nuts/blob/master/disas_1.S
>
> After a few steps, it retrieves the correct values c.
>  
> https://github.com/Emegua/golang_nuts/blob/6a246ae7715823688a74581649c77da4369f8717/malloc.go#L661
> But while importing some packages, say runtime package, the same process 
> (i.e., dereferencing the pointer obtained by __tls_get_addr) retrieves 0x0 
> which is nullptr.
>
> From the following line, we inspected the all dereferenced value of pointer, 
> step by step.
>
> The results are as follows. Left column is before the import of runtime, 
> right column is while importing runtime. As it shows, retrieved pointer is 
> same for both situation (i.e., 0x7f7ae76d7b18), but it contains different 
> value so the resulting dereferenced pointer(i.e., c) is also different. 
> Please refer to the following image.
>
> gccgo --version
> gccgo (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
>
> What would be any possible explanation for the segfault?

I don't know what is happening.  It appears that somehow you are on a
thread that wasn't properly initialized.

Could you take a step back and show the steps you took to get to this
point?  How exactly did you create the .so file?  How exactly are you
running 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/CAOyqgcVx7Bffqo5goWBV1HcAQd0HQsN0qSi5VgUOwP4mYSoxjQ%40mail.gmail.com.


Re: [go-nuts] Generics - type inference - which type parameters?

2020-08-24 Thread Ian Lance Taylor
On Mon, Aug 24, 2020 at 4:34 PM Patrick Smith  wrote:
>
> I may be missing something, but it seems to me that one point in the draft's 
> discussion of type inference could usefully be clarified 
> (https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference).
>
> The term "type parameter" there should be restricted to the type parameters 
> in the specific use of a generic type or function for which we are trying to 
> infer type arguments. For example (https://go2goplay.golang.org/p/pWis3rlJElu)
>
> func Min[type T interface{ type int, uint }](a, b T) T {
>
> if b < a {
>
> return b
>
> }
> return a
>
> }
>
> func Min3[type U interface{ type int }](a, b, c U) U {
>
> return Min(a, Min(b, c))
>
> }
>
> func BadMin3[type V interface{ type int, uint, string }](a, b, c V) V {
>
> return Min(a, Min(b, c))
>
> }
>
> Here, U and V are type parameters, but when inferring type arguments for the 
> calls to Min, we must consider U and V as fixed types, not subject to type 
> unification. This seems needed in order for the compiler to reject BadMin3.

Thanks.  That seems fairly clear to me, but I'm probably too close to
the problem.  Any suggestions for exactly where we should add a
sentence, and what that sentence should be?  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/CAOyqgcVOWb_snspcZ_mu8sBPSKV9jUHMp%2BGxVO1Q8E0PxQgcZQ%40mail.gmail.com.


Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-24 Thread Ian Lance Taylor
On Thu, Aug 20, 2020 at 9:54 PM Ian Lance Taylor  wrote:
>
> Our intent here is that "any" will be available for all code.  Yes, we
> wouldn't do it if it weren't for its use as a type constraint.  But if
> we are going to do it for type constraints, there seems to be little
> benefit to restricting it to only work as a type constraint.
>
> This is not, of course, a new idea, even in the absence of generics.
> For example, https://golang.org/issue/33232.  (My comment there was
> that we would use interface{} less if we had generics, but of course
> when we require type constraints then we actually wind up using it
> somewhat more.)

I've seen objections that a language change for generics should not
implicitly pull in a change to non-generic code.  That seems fair.  It
may be the right thing to do, but it should be justified separately.
So we're going to start with "any" only being accepted as a type
constraint, and we can discuss making the name available for all uses
separately, probably on issue 33232.  Clearly adding "any" as a name
accepted in type constraints is a step toward defining "any" for all
code, but doing so isn't a requirement for generics.

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/CAOyqgcWr%2BrnZ7znmUe1MSMy1%2B%3DsXFxYbP1qt7%3DqnVXVVXXBE%3Dw%40mail.gmail.com.


Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?

2020-08-23 Thread Ian Lance Taylor
On Sun, Aug 23, 2020 at 1:16 PM Denis Cheremisov
 wrote:
>
> You may use something like this
>
> value2 := *(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer()) + 
> 8))
> if value2 == 0 {
> return true
> }
>
> on AMD64, should work also for any 64 bit architecture (at least I believe 
> so). Remember though this is hacky and may stop working once.

You could do that, but please don't.

Ian


> воскресенье, 23 августа 2020 г. в 22:58:51 UTC+3, Aviv Eyal:
>>
>> I was trying to show that the current behavior is confusing and that 
>> fmt.Print() needing to resort to panic-and-recover is kinda code smell, but 
>> I sorts-of convinced myself that the current behavior is right, or at least 
>> consistent.
>>
>> In my code, I got bit because I sometimes use v *Type to denote "I may or 
>> may not have a value here" (where Type is a value-type).
>> This is probably a bad practice on my behalf, because I break the Liskov 
>> substitution principle: there is a value of `*Type` that is not a valid 
>> value of `Type`, and I let this value slip by.
>>
>> In this case, `v Type` implements Stringer (i.e. valid callee for 
>> `v.String()`, but `v *Type`, in the strictest sense, does not.
>> The only reason we can write:
>>
>> func (Type) String() string {...}
>> v *Type = {...}
>> _ = v.String()
>>
>> and have it compile, is syntactic sugar: `v` gets implicitly de-referenced, 
>> and there's an implicit assumption that it's not nil.
>> And there's a matching syntactic sugar for converting `Type` to a `*Type`.
>>
>> So, In the code:
>>
>> func (Type) String() string {...}
>>
>> v *Type = nil
>> r interface{} = v
>> _, ok = r.(Stringer)
>>
>> What I really want to ask is "Can I, at runtime, call r.String()?", whereas 
>> the question Go answers is "Is any of `r`, `*r`, or `` defines .String()?" 
>> - which matches the static semantics of `r.String()`.
>>
>> So, while I should probably not use *Type as a replacement for 
>> Optional, I think it might make sense to have some operator that can 
>> determine, at run-time, if a call `r.String()` is valid (including a 
>> nil-check).
>>
>>
>> -- Aviv
>>
>> On Saturday, April 11, 2020 at 4:48:28 PM UTC+3 ren...@ix.netcom.com wrote:
>>>
>>> I agree with the OP. The usefulness of nil interfaces is pretty limited. 
>>> Show me a useful case that cant easily be implemented with non-nil 
>>> interfaces.
>>>
>>> I would argue that allowing nil interfaces causes more subtle latent bugs 
>>> and makes it harder to reason about the correctness of code when reviewing 
>>> it.
>>>
>>> It just feels wrong. I realize I’m probably in the minority here but the OP 
>>> is not alone.
>>>
>>> On Apr 11, 2020, at 8:20 AM, 'Axel Wagner' via golang-nuts 
>>>  wrote:
>>>
>>> On Fri, Apr 10, 2020 at 7:17 PM  wrote:

 I realize I'm reviving an age-old discussion here and apologize for 
 bringing up the undead. I happend to run into this when my application 
 panicked when some interfaces where initialized with nil mock objects 
 instead of being left uninitialized as in production mode.
>>>
>>>
>>> Let's imagine a world in which `foo == nil` also is true if `foo` is an 
>>> interface-value containing a nil-pointer. Let's say in this world, someone 
>>> sends a message to golang-nuts. They wrote a mock for the same code. And 
>>> since it's just a mock, they just returned static value from its methods 
>>> and didn't need to care if the pointer was nil or not. They are confused, 
>>> because the passed in this mock, but the code just assumed the field was 
>>> uninitialized and never called into their mock. What would you tell them? 
>>> Why is their confusion less valid?
>>>
 This would be an example where a nil implementing fooer is never caught:

 type fooer interface {
  foo()
 }

 type other struct{}

 func (o *other) foo() {} // implement fooer

 func main() {
  var f fooer

  var p *other // nil
  f = p // it is a fooer so I can assign it

  if f == nil {
 // will not get here
  }
 }


 My confusion comes from the point that the nil interface is apparently not 
 "a nil-pointer with the correct method set" while *other is even if nil.
>>>
>>>
>>> In the code you posted, even a nil *other is a perfectly fine 
>>> implementation of fooer. You can call `(*other)(nil).foo()` without any 
>>> problems.
>>> So, as you illustrated, calling methods on a nil-pointer can be totally 
>>> fine. A nil-interface, OTOH, doesn't have any methods to call, as it 
>>> doesn't contain a dynamic value. If you write `(*other)(nil).foo()`, it is 
>>> completely clear what code gets called - even if that code *might* panic. 
>>> If you write `fooer(nil).foo()`, what code should be called in your opinion?
>>>
>>> I think it's easy to see that a nil-interface and a nil-pointer stored in 
>>> an interface are very different things. Even 

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

2020-08-23 Thread Ian Lance Taylor
On Sun, Aug 23, 2020 at 3:00 PM Juliusz Chroboczek  wrote:
>
> > We’re going to permit type switches on type parameters that have type
> > lists, without the “.(type)” syntax.  The “(.type)” syntax exists to
> > clarify code like “switch v := x.(type)”.
>
> Could you please give an example of the proposed syntax?

func F[T constraints.Integer]() {
switch T {
case int:
case int8:
}
}

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


Re: [go-nuts] how golang choose instructions?

2020-08-23 Thread Ian Lance Taylor
On Sat, Aug 22, 2020 at 10:31 PM xie cui  wrote:
>
> we can find same dynamic programming algorithm(like BURS bottom rewriting 
> system), to choose instructions in book about compiler technique. but as far 
> as i know, it seems that golang just transform ast to ssa IR, then lower to 
> machine instruction. how i find the min cost of instructions?

I believe that instruction cost is implicitly encoded in the rules
that appear in the cmd/compile/internal/ssa/gen directory.  The rules
only list the instruction choices that seem best.  As far as I know
the gc compiler does not trade off between register allocation and
instruction selection, but I don't know everything that it does.

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


Re: [go-nuts] Go routines stuck in runtime_pollwait

2020-08-22 Thread Ian Lance Taylor
On Sat, Aug 22, 2020 at 12:06 PM Siddhesh Divekar
 wrote:
>
> We saw an issue with our process running in k8s on ubuntu 18.04.
> Most of the go routines are stuck for several minutes in http/http2 net code.
>
> Have you seen similar issues ?
>
> goroutine 2800143 [select, 324 minutes]: 
> net/http.(*persistConn).readLoop(0xc00187d440) 
> /usr/local/go/src/net/http/transport.go:2032 +0x999 created by 
> net/http.(*Transport).dialConn /usr/local/go/src/net/http/transport.go:1580 
> +0xb0d goroutine 2738894 [IO wait, 352 minutes]: 
> internal/poll.runtime_pollWait(0x7f5b61b280c0, 0x72, 0x) 
> /usr/local/go/src/runtime/netpoll.go:184 +0x55 
> internal/poll.(*pollDesc).wait(0xc0017e7e18, 0x72, 0x1000, 0x1000, 
> 0x) /usr/local/go/src/internal/poll/fd_poll_runtime.go:87 
> +0x45 internal/poll.(*pollDesc).waitRead(...) 
> /usr/local/go/src/internal/poll/fd_poll_runtime.go:92 
> internal/poll.(*FD).Read(0xc0017e7e00, 0xc0044a9000, 0x1000, 0x1000, 0x0, 
> 0x0, 0x0) /usr/local/go/src/internal/poll/fd_unix.go:169 +0x1cf 
> net.(*netFD).Read(0xc0017e7e00, 0xc0044a9000, 0x1000, 0x1000, 0xc0026359e8, 
> 0x49d7fd, 0xc0017e7e00) /usr/local/go/src/net/fd_unix.go:202 +0x4f 
> net.(*conn).Read(0xcdb8b8, 0xc0044a9000, 0x1000, 0x1000, 0x0, 0x0, 0x0) 
> /usr/local/go/src/net/net.go:184 +0x68 
> net/http.(*connReader).Read(0xc004a4fec0, 0xc0044a9000, 0x1000, 0x1000, 0x0, 
> 0x0, 0x0) /usr/local/go/src/net/http/server.go:785 +0xf4 
> bufio.(*Reader).fill(0xc003f1a360) /usr/local/go/src/bufio/bufio.go:100 
> +0x103 bufio.(*Reader).Peek(0xc003f1a360, 0x4, 0x0, 0x0, 0x0, 0x0, 
> 0xc002635ad0) /usr/local/go/src/bufio/bufio.go:138 +0x4f 
> net/http.(*conn).readRequest(0xc0028e1d60, 0x393ed20, 0xc0024e9780, 0x0, 0x0, 
> 0x0) /usr/local/go/src/net/http/server.go:962 +0xb3b 
> net/http.(*conn).serve(0xc0028e1d60, 0x393ed20, 0xc0024e9780) 
> /usr/local/go/src/net/http/server.go:1817 +0x6d4 created by 
> net/http.(*Server).Serve /usr/local/go/src/net/http/server.go:2928 +0x384
>
> Is there a know issue or something obvious from the backtrace here.

It's entirely normal for goroutines to sit in pollWait if they are
waiting for network I/O.  There may be reasons why this is incorrect
for your program, but you'll have to tell us those reasons.

Also, along with those reasons, please tell us the version of Go and
the exact environment that you are running.  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/CAOyqgcXQyDF_WV8JQRQop_9ffO%3D37jWXUto61jB%3DMiobtrLbDg%40mail.gmail.com.


Re: [go-nuts] obtaining the original type from a named alias type with go/types?

2020-08-21 Thread Ian Lance Taylor
On Fri, Aug 21, 2020, 9:16 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Sat, 2020-08-15 at 21:44 -0700, Ian Lance Taylor wrote:
> > On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts
> >  wrote:
> > >
> > > I would like to be able to obtain the original type for an alias
> > > given
> > > a source input. I can see in "go/types" that it's possible to know
> > > whether a named type is an alias by `typ.Obj().IsAlias()`, but I
> > > cannot
> > > see how to obtain the actual original type unless it is an alias
> > > for a
> > > basic type.
> > >
> > > Can someone point me to a way to get this information? From the
> > > source
> > > it looks something like
> > > `typ.Obj().Type().(*types.Named).Obj().Type()`.
> > > Is this correct assuming that the original type is a named type?
> >
> > I haven't tested it but I *think* you can just write
> > typ.Underlying().
> >
> > Ian
>
> Thanks, Ian.
>
> No that doesn't work. For example with type byte, you get back the byte
> name.
>
> https://play.golang.org/p/PPjHBotsIsw


The underlying type of byte is indeed byte.  What are you hoping for?

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/CAOyqgcX6Dwe1-YduJ_kvAGj%2B6N0uVYAiqK0-NJo3-yDukkuWXA%40mail.gmail.com.


Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-21 Thread Ian Lance Taylor
On Fri, Aug 21, 2020 at 3:03 PM Axel Wagner
 wrote:
>
> On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor  wrote:
>>
>> Yes, there are various such possibilities.
>>
>> What jimmy frasche said above is correct: nothing changes in the case
>> of a type switch of a type parameter.  The code now knows the type
>> list element that the type argument matched, but it can't do anything
>> that it couldn't do anyhow.
>
>
> I think there are two reasonable things that it could be allowed to do in the 
> case, that aren't allowed outside:
> 1. Convert to the matched type. We have a guarantee that the matched type is 
> either identical or has the same underlying type, both of which would allow a 
> conversion in the language as-is. I feel allowing this conversion would be 
> sufficiently useful (e.g. passing things to `strconv.Itoa` or functions from 
> `math` can be very useful).
> 2. If the type is not a predeclared type, we could even take this a step 
> further, as the types must be identical - so we might allow treating them as 
> such. This feels natural when viewed from the "type lists are essentially sum 
> types" POV. However, it would treat predeclared types more special than other 
> declared types and so it may be too elaborate to put into the spec. It would 
> also allow what rog suggest - but only in certain corner cases, which feels 
> weird.
>
> The more I think about it, the less I understand the intention behind the 
> type-switch construct introduced. I tend to agree that 1. at least should be 
> possible to make it useful. But even then, it seems like kind of a big change 
> for relatively limited use. What was the motivation behind that change? Is 
> there discussion somewhere, of interesting use-cases this enables?

Given a type parameter, there are two interesting pieces of
information.  One is what the actual type argument is; we can already
determine that by writing code like "var x T; switch
(interface{})(x).(type) { ... }".  The other is which type in the type
list was matched by the type argument.  The latter is the purpose of
the type switch suggested here.  Without something like that type
switch, there is no straightforward way for a generic function to
determine which type in a type list is matched by a type argument.

See also 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#identifying-the-matched-predeclared-type
.

I'm not at all wedded to this.  We can continue to omit it.  It just
seems like adding a capability that does not otherwise exist.

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/CAOyqgcWt25q-oboPW%3Dky4gr9GDyrTDewO8NiLjr%2Bb1MrSXMeUg%40mail.gmail.com.


Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-21 Thread Ian Lance Taylor
Yes, there are various such possibilities.

What jimmy frasche said above is correct: nothing changes in the case
of a type switch of a type parameter.  The code now knows the type
list element that the type argument matched, but it can't do anything
that it couldn't do anyhow.

Ian

On Fri, Aug 21, 2020 at 2:43 PM Axel Wagner
 wrote:
>
> also, of course, you could still use operators with them, while now also 
> knowing the exact semantics of those operators (e.g. in regards to overflow), 
> which might also be useful.
>
> On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner  
> wrote:
>>
>>
>>
>> On Fri, Aug 21, 2020 at 11:30 PM roger peppe  wrote:
>>>
>>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche  wrote:
>>>>
>>>> I'd assume that would fail to compile as you're returning a []T not a []int
>>>
>>>
>>> If that's the case, then I'm not sure that such a type switch would be very 
>>> useful. It would tell you what type the values are, but you can't do 
>>> anything with them because all the values would still be of the original 
>>> type.
>>
>>
>> You can reasonably convert them to their underlying type and *then* use them 
>> as such.
>> That would make it useful while not allowing what you posit.
>>
>>> I had assumed that the intention was that within the arm of the type 
>>> switch, the switched type would take on the specified type.
>>> That would allow (for example) specialising to use underlying machine 
>>> operations on []T when T is a known type such as byte.
>>
>>
>> It would, however, prevent you from calling methods on the type or pass it 
>> to a function taking an interface compatible with the constraint.
>> Also, I shudder to even imagine how this could be put into a spec.
>>
>>>
>>>
>>>
>>>> On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
>>>> >
>>>> >
>>>> > On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor  wrote:
>>>> >>
>>>> >> After many discussions and reading many comments, we plan to move
>>>> >> forward with some changes and clarifications to the generics design
>>>> >> draft.
>>>> >>
>>>> >> 1.
>>>> >>
>>>> >> We’re going to settle on square brackets for the generics syntax.
>>>> >> We’re going to drop the “type” keyword before type parameters, as
>>>> >> using square brackets is sufficient to distinguish the type parameter
>>>> >> list from the ordinary parameter list.  To avoid the ambiguity with
>>>> >> array declarations, we will require that all type parameters provide a
>>>> >> constraint.  This has the advantage of giving type parameter lists the
>>>> >> exact same syntax as ordinary parameter lists (other than using square
>>>> >> brackets).  To simplify the common case of a type parameter that has
>>>> >> no constraints, we will introduce a new predeclared identifier “any”
>>>> >> as an alias for “interface{}”.
>>>> >>
>>>> >> The result is declarations that look like this:
>>>> >>
>>>> >> type Vector[T any] []T
>>>> >> func Print[T any](s []T) { … }
>>>> >> func Index[T comparable](s []T, e T) { … }
>>>> >>
>>>> >> We feel that the cost of the new predeclared identifier “any” is
>>>> >> outweighed by the simplification achieved by making all parameter
>>>> >> lists syntactically the same: as each regular parameter always has a
>>>> >> type, each type parameter always has a constraint (its meta-type).
>>>> >>
>>>> >> Changing “[type T]” to “[T any]” seems about equally readable and
>>>> >> saves one character.  We’ll be able to streamline a lot of existing
>>>> >> code in the standard library and elsewhere by replacing “interface{}”
>>>> >> with “any”.
>>>> >>
>>>> >> 2.
>>>> >>
>>>> >> We’re going to simplify the rule for type list satisfaction.  The type
>>>> >> argument will satisfy the constraint if the type argument is identical
>>>> >> to any type in the type list, or if the underlying type of the type
>>>> >> argument is identical to any type in the type list.  What we are
>>>> >> removing here is any use of the under

Re: [go-nuts] Unique GO language features

2020-08-21 Thread Ian Lance Taylor
On Fri, Aug 21, 2020 at 10:16 AM joseph.p...@gmail.com
 wrote:
>
> I really like the 'defer' statement and think it would be a useful addition 
> to other programming languages.

I believe that Swift has also added a defer statement, which I assume
was based on the idea in Go.

> The feature where GO performs escape analysis and promotes stack variables to 
> the heap: Did that originate with GO or was it first implemented elsewhere?

That has been implemented in other languages, notably Java.

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/CAOyqgcWqcy01WBwyt4Y9be968nW2kE-90%2BBs0ETYmuSeaXDEsQ%40mail.gmail.com.


Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-21 Thread Ian Lance Taylor
On Thu, Aug 20, 2020, 11:22 PM Bakul Shah  wrote:

> On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor  wrote:
>
> > 3.
> >
> > We’re going to clarify that when considering the operations permitted
> > for a value whose type is a type parameter, we will ignore the methods
> > of any types in the type list.  The general rule is that the generic
> > function can use any operation permitted by every type in the type
> > list.  However, this will only apply to operators and predeclared
> > functions (such as "len" and "cap").  It won’t apply to methods, for
> > the case where the type list includes a list of types that all define
> > some method.  Any methods must be listed separately in the interface
> > type, not inherited from the type list.
> >
> > This rule seems generally clear, and avoids some complex reasoning
> > involving type lists that include structs with embedded type
> > parameters.
>
> You seem to be saying a generic function can use operator X only if
> if *every* type in the type list implements it. Thus if I have
>
> type foo interface { int; someSLice }
>
> I can't use + and I can't use len(), right?


Right.  And, to be clear, that is how the current design draft works before
this change.

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


Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-21 Thread Ian Lance Taylor
On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Just to clarify, the intent is to make the declaration in the spec `type
> any = interface{}`, not `type any interface{}`, correct? The latter would
> be more analogous to `error`. Either has certain advantages and
> disadvantages, I'm not sure which I prefer, but I just want to make sure I
> understand the plan :)
>

I've been thinking of a type alias rather than a defined type, but I'm not
sure which is best.  It would be interesting to hear whether anybody has a
clear preference, and why.

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/CAOyqgcUFU_Lz0c%3D-6V6N9X2Ku2Hx-9%2BDeHequ0oLX9Soyo_3GQ%40mail.gmail.com.


Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-20 Thread Ian Lance Taylor
On Thu, Aug 20, 2020 at 8:28 PM jimmy frasche  wrote:
>
> To clarify on the type switches, would it have to be used like this:
>
> type C interface {
>   type X, Y
> }
>
> func f(x X) X {
>   return x
> }
>
> func g[T C](v T) T {
>   switch v {
>   case X:
> // to use v as an X
> // we must convert
> x0 := X(v)
> x1 := f(x0)
> // to use x1 as a T
> // we must convert back
> t := T(x1)
> return t
>   case Y:
> return v
>   }
> }
>
> And that the lack of a dedicated syntax to distinguish the case like
> .[type] also means that you could no longer write
>
> func h[T comparable](x, a, b T) {
>   switch x {
>   case a:
>   case b:
>   }
> }
>
> Regardless, all of these changes are fantastic!

No, the intent is that you would switch on the type parameter itself,
not a value.

func g[T C](v T) T {
  switch T {
// the rest is the same
  }
}

Thanks for asking.

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/CAOyqgcVd%3DaSttfOBgriPPkPMAhymdGw-v2RSb3OXM1zomuv7yA%40mail.gmail.com.


Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-20 Thread Ian Lance Taylor
On Thu, Aug 20, 2020 at 8:52 PM burak serdar  wrote:
>
> On Thu, Aug 20, 2020 at 8:22 PM Jan Mercl <0xj...@gmail.com> wrote:
> >
> > On Fri, Aug 21, 2020 at 2:28 AM Ian Lance Taylor  wrote:
> >
> > > To simplify the common case of a type parameter that has
> > > no constraints, we will introduce a new predeclared identifier “any”
> > > as an alias for “interface{}”.
> >
> > Anyone can write the declaration
> >
> > type any = interface{}
> >
> > today and possibly some people already do that. But in my opinion that
> > would, so far, not pass a code review within the Go project per se.
> > (It would definitely not pass my code review.)
> >
> > I don't like it and It makes me sad it is being proposed to become
> > officially blessed.
>
> Is "any" truly an alias for interface{}, or is it only a constraint? I
> agree with Jan's point that replacing interface{} with "any" might
> unintentionally encourage its use.

Our intent here is that "any" will be available for all code.  Yes, we
wouldn't do it if it weren't for its use as a type constraint.  But if
we are going to do it for type constraints, there seems to be little
benefit to restricting it to only work as a type constraint.

This is not, of course, a new idea, even in the absence of generics.
For example, https://golang.org/issue/33232.  (My comment there was
that we would use interface{} less if we had generics, but of course
when we require type constraints then we actually wind up using it
somewhat more.)

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/CAOyqgcWubUzPNmLs_aPF%2BjjyOfr6Pz_czWF5EqLM2vLWdTsZ4Q%40mail.gmail.com.


[go-nuts] [ generics] Moving forward with the generics design draft

2020-08-20 Thread Ian Lance Taylor
After many discussions and reading many comments, we plan to move
forward with some changes and clarifications to the generics design
draft.

1.

We’re going to settle on square brackets for the generics syntax.
We’re going to drop the “type” keyword before type parameters, as
using square brackets is sufficient to distinguish the type parameter
list from the ordinary parameter list.  To avoid the ambiguity with
array declarations, we will require that all type parameters provide a
constraint.  This has the advantage of giving type parameter lists the
exact same syntax as ordinary parameter lists (other than using square
brackets).  To simplify the common case of a type parameter that has
no constraints, we will introduce a new predeclared identifier “any”
as an alias for “interface{}”.

The result is declarations that look like this:

type Vector[T any] []T
func Print[T any](s []T) { … }
func Index[T comparable](s []T, e T) { … }

We feel that the cost of the new predeclared identifier “any” is
outweighed by the simplification achieved by making all parameter
lists syntactically the same: as each regular parameter always has a
type, each type parameter always has a constraint (its meta-type).

Changing “[type T]” to “[T any]” seems about equally readable and
saves one character.  We’ll be able to streamline a lot of existing
code in the standard library and elsewhere by replacing “interface{}”
with “any”.

2.

We’re going to simplify the rule for type list satisfaction.  The type
argument will satisfy the constraint if the type argument is identical
to any type in the type list, or if the underlying type of the type
argument is identical to any type in the type list.  What we are
removing here is any use of the underlying types of the types in the
type list.  This tweaked rule means that the type list can decide
whether to accept an exact defined type, other than a predeclared
type, or whether to accept any type with a matching underlying type.

This is a subtle change that we don’t expect to affect any existing
experimental code.

We think that this definition might work if we permit interface types
with type lists to be used outside of type constraints.  Such
interfaces would effectively act like sum types. That is not part of
this design draft, but it’s an obvious thing to consider for the
future.

Note that a type list can mention type parameters (that is, other type
parameters in the same type parameter list).  These will be checked by
first replacing the type parameter(s) with the corresponding type
argument(s), and then using the rule described above.

3.

We’re going to clarify that when considering the operations permitted
for a value whose type is a type parameter, we will ignore the methods
of any types in the type list.  The general rule is that the generic
function can use any operation permitted by every type in the type
list.  However, this will only apply to operators and predeclared
functions (such as "len" and "cap").  It won’t apply to methods, for
the case where the type list includes a list of types that all define
some method.  Any methods must be listed separately in the interface
type, not inherited from the type list.

This rule seems generally clear, and avoids some complex reasoning
involving type lists that include structs with embedded type
parameters.

4.

We’re going to permit type switches on type parameters that have type
lists, without the “.(type)” syntax.  The “(.type)” syntax exists to
clarify code like “switch v := x.(type)”.  A type switch on a type
parameter won’t be able to use the “:=” syntax anyhow, so there is no
reason to require “.(type)”.  In a type switch on a type parameter
with a type list, every case listed must be a type that appears in the
type list (“default” is also permitted, of course).  A case will be
chosen if it is the type matched by the type argument, although as
discussed above it may not be the exact type argument: it may be the
underlying type of the type argument.  To make that rule very clear,
type switches will not be permitted for type parameters that do not
have type lists.  It is already possible to switch on a value “x”
whose type is a type parameter without a type list by writing code
like “switch (interface{})(x).(type)” (which may now be written as
“switch any(x).(type)”).  That construct is not the simplest, but it
uses only features already present in the language, and we don’t
expect it to be widely needed.


These changes will soon be implemented in the experimental design on
the dev.generics branch, and in the go2go playground.  Some of them
already work.  We will update the design draft accordingly.


We welcome any comments.  Thanks for all the help that so many people
have provided so far.

Ian & Robert

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

Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler

2020-08-18 Thread Ian Lance Taylor
On Tue, Aug 18, 2020 at 6:20 PM Yonatan Gizachew  wrote:
>
> But may I know what gccgo's runtime package?

https://go.googlesource.com/gofrontend/+/refs/heads/master/libgo/go/runtime/
https://go.googlesource.com/gofrontend/+/refs/heads/master/libgo/runtime/

Ian


> On Wednesday, August 19, 2020 at 8:52:48 AM UTC+9 Ian Lance Taylor wrote:
>>
>> On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew  wrote:
>> >
>> > Sorry I couldn't provide code to reproduce the case, but I just wanted to 
>> > know if there are known cases for my issue.
>> > From the golang source code, in the runtime library proc.go file there is 
>> > this code snippet
>> > https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199
>> > In my case, I build my go program with -buildmode=c-shared mode and I 
>> > loaded it dynamically to my program written in C. So as to load the 
>> > runtime go libraries dynamically, I preferred to use the gccgo compiler 
>> > instead of gc compiler. Here is how I built my go code.
>> >
>> > $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go
>> >
>> > I was hoping the linker would set the islibrary flag to True and as a 
>> > result the main function in proc.go would return at line 202. But it 
>> > wasn't the case.
>> >
>> > I was wondering why islibrary was set false.
>>
>> Note that gccgo uses a different runtime package. Your link is to the
>> gc runtime package, not the gccgo runtime package.
>>
>> gccgo sets isarchive for both c-archive and c-shared. As this is an
>> internal runtime variable, it shouldn't make any difference. Does it
>> ever make a difference to your code that gccgo sets isarchive rather
>> than islibrary?
>>
>> 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/39b98200-4b70-4c1e-8604-b98e2cad43f4n%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/CAOyqgcVDT06L3RDmwChTJkXmQC5OkR5KkO%3DwH%3DTcjdJrYY5sRA%40mail.gmail.com.


Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler

2020-08-18 Thread Ian Lance Taylor
On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew  wrote:
>
> Sorry I couldn't provide code to reproduce the case, but I just wanted to 
> know if there are known cases for my issue.
> From the golang source code, in the runtime library proc.go file there is 
> this code snippet
> https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199
> In my case, I build my go program with -buildmode=c-shared mode and I loaded 
> it dynamically to my program written in C. So as to load the runtime go 
> libraries dynamically, I preferred to use the gccgo compiler instead of gc 
> compiler. Here is how I built my go code.
>
> $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go
>
> I was hoping the linker would set the islibrary flag to True and as a result 
> the main function in proc.go would return at line 202. But it wasn't the case.
>
> I was wondering why islibrary was set false.

Note that gccgo uses a different runtime package.  Your link is to the
gc runtime package, not the gccgo runtime package.

gccgo sets isarchive for both c-archive and c-shared.  As this is an
internal runtime variable, it shouldn't make any difference.  Does it
ever make a difference to your code that gccgo sets isarchive rather
than islibrary?

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/CAOyqgcWXwH4CQE65LcqCwXYXeViSs5-9GexBNH0C%2B2ktAVntmA%40mail.gmail.com.


Re: [go-nuts] [generics] Type list syntax

2020-08-18 Thread Ian Lance Taylor
On Tue, Aug 18, 2020 at 1:48 PM Frederik Zipp  wrote:
>
> Ian Lance Taylor schrieb am Dienstag, 18. August 2020 um 21:26:23 UTC+2:
>>
>> What would it mean to permit any type as a constraint?
>
>
> Each type would match exactly the same types it would match in a plain old 
> function parameter list:

Well, that's assignability.


>> I actually looked into this, to see if we could say that any type
>> could be used as a constraint, and say that a type parameter
>> constraint would permit any type argument that is assignable to the
>> constraint type. Unfortunately that leads to some odd behavior. If
>> we use a named type as the constraint, it may have methods. But we
>> can use a corresponding type literal as a type argument. That would
>> add methods to a type literal with no explicit type conversion.
>
>
> But isn't that already the case with normal function parameters?
>
> package main
>
> type S struct{}
>
> func (s S) M() {}
>
> func F(s S) {
> s.M()
> }
>
> func main() {
> // no explicit type conversion from struct{} to S
> F(struct{}{})
> }

Yes, but here you are assigning the value struct{}{} to the type S.
That's not how type arguments work: type arguments are not assigned to
type parameters.  Instead, the body of a generic function or type is
instantiated with the type argument.  In a generic function, rather
than assigning a value struct{}{} to type S, we are replacing
instances of S in F with struct{}.  But struct{} has no methods.  So
can you call method M on an argument whose type is the type parameter?
 Why or why not?


>> Similarly, if we use a type literal as a type, we can use a defined
>> type as a type argument. But the generic function could assign the
>> type parameter to some other defined type, and now we have a generic
>> function that could not be compiled if we simply substituted the type
>> argument for any instance of the type parameter.
>
>
> Same here:
>
> package main
>
> type S struct{}
>
> func (s S) M() {}
>
> func F(s struct{}) {
> var x S = s
> _ = x
> }
>
> func main() {
> // no explicit type conversion from S to struct{}
> F(S{})
> }

Same answer.  Instantiation is not assignment, so is assignability the
right rule for constraint satisfaction?


>> And I don't see what we gain by following that path.
>
>
> It would mostly be for the sake of consistency, and as a justification for a 
> hypothetical sum type like `anyof` (as a replacement for type lists in 
> interfaces) to be usable as a constraint.

Fair enough.

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/CAOyqgcUVOm6UJgbKwC-dc_jnoAn3ku-MjvrRSyXnOH7kPVCx2w%40mail.gmail.com.


Re: [go-nuts] New linker

2020-08-18 Thread Ian Lance Taylor
On Sat, Aug 15, 2020 at 11:49 PM Amnon  wrote:
>
> Austin's doc refers to your idea of a new object format for the 21st century.
> Has anyone developed that?

No, that is still just a thought.


> As someone who has been writing linkers since 1988, (most famously the Gold 
> linker), and who has a fair
> number of commits on the dev.linker branch,  do you have any insights into 
> the new linker project
> which would be interesting to share with the world?

Thanks for the praise.  Sorry to say that I don't have any particular
insights.  I think the new linker has been great work, but I
personally was only peripherally involved.  I read the design doc, and
that's about 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/CAOyqgcWztg7DiYtAGpnaDA25%3DNecFEUpNSks5TxznfLs6eoygg%40mail.gmail.com.


Re: [go-nuts] [generics] Type list syntax

2020-08-18 Thread Ian Lance Taylor
On Tue, Aug 18, 2020 at 11:29 AM Frederik Zipp  wrote:
>
> The more I think about it the less I understand why type list should reside 
> inside interfaces. I can only think of two reasons:
>
> 1) Avoid a new keyword for type lists.
> 2) The idea that only interfaces should be able to act as constraints.
>
> Regarding 2): Why this artificial limitation? Why not allow all types as 
> constraints? Even int. It's nonsensical, but it would be like "interface{ 
> type int }" in the current draft, which is nonsensical, too. The rule would 
> be simple: Any type can act both as normal type and as constraint. With the 
> possible exception of `anyof`s, until there is a solution to use them as 
> regular types as well.

Thanks for the comment.

What would it mean to permit any type as a constraint?

I actually looked into this, to see if we could say that any type
could be used as a constraint, and say that a type parameter
constraint would permit any type argument that is assignable to the
constraint type.  Unfortunately that leads to some odd behavior.  If
we use a named type as the constraint, it may have methods.  But we
can use a corresponding type literal as a type argument.  That would
add methods to a type literal with no explicit type conversion.
Similarly, if we use a type literal as a type, we can use a defined
type as a type argument.  But the generic function could assign the
type parameter to some other defined type, and now we have a generic
function that could not be compiled if we simply substituted the type
argument for any instance of the type parameter.

I know my descriptions are rather sketchy, but the point is that we
need a really clear definition of when a type argument satisfies a
type constraint, and of what operations a type constraint permits in
the generic function.  I think we have a fairly clear understanding of
this when we permit interface types, with optional type lists, as type
constraints.  I don't think we know what it means when we allow other
kinds of types as type constraints, and I don't see an obvious path
forward.  And I don't see what we gain by following that path.

Thanks again.

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/CAOyqgcUFQEo-HJvaxfrP%2B6_iSojRXZ-qzfuqYaoj6ewiUX%2BCtw%40mail.gmail.com.


Re: [go-nuts] [generics] Type list syntax

2020-08-18 Thread Ian Lance Taylor
On Tue, Aug 18, 2020 at 7:38 AM Frederik Zipp  wrote:
>
> The draft syntax for type lists is a comma separated list:
>
> type SignedInteger interface {
> type int, int8, int16, int32, int64
> }
>
> Wouldn't it be more consistent with existing Go syntax regarding types if it 
> was a semicolon separated list in curly braces?
>
> type SignedInteger interface {
> type {int; int8; int16; int32; int64}
> }

Adding to what others have said, I don't see why this syntax is more
consistent with existing syntax.  Both struct fields and interface
methods, which are separated using semicolons, are an example of
concatenation: the fields and methods are concatenated together, and
all the concatenated elements are present in the final type.  Type
lists as used in constraints are an example of alternation: exactly
one of the types is chosen.  I can't think of any other example of
alternation in Go, so there isn't any syntax to be consistent with.


> If some day, somehow, type lists should emerge from 'interface' as 
> non-nilable sum types, the natural syntax would be:
>
> type MySum type {
> A
> B
> }
>
> var mySum type{A; B}
>
> Even if this will never happen, this thought experiment suggests that curly 
> braces and semicolons are the more Go-like syntax choice for type lists.

If we were to introduce non-nilable sum types, I think it would be
quite unlikely that the syntax would be "type MySum type { ... }".
That seems fairly obscure.  Admittedly, that might be a reason to use
a different syntax in type constraints.  But it's not a convincing
argument for using "type { A; B }" in a type constraint.

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/CAOyqgcUg2oHhLy9YL1xxC0PDZyw9awBwhe_Hzb2_F%2BQj2gZ6WQ%40mail.gmail.com.


Re: [go-nuts] [generics] Constraint type inference not working

2020-08-17 Thread Ian Lance Taylor
On Sun, Aug 16, 2020 at 7:42 AM jake...@gmail.com  wrote:
>
> When I try the example from the "Constraint type inference" section of the 
> Draft Design: 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>  it does not seem to actually work:
>
> https://go2goplay.golang.org/p/pfq3QV6gdgf
>
> What am I missing?

I'm not sure.  Can you open a bug report?  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/CAOyqgcXCAMYzsafxAnkWhmP0KQMc07yrWVu%3DTtEhk0T_-c20iA%40mail.gmail.com.


Re: [go-nuts] How to build an object file for a specific GOOS and GOARCH with external linker?

2020-08-17 Thread Ian Lance Taylor
On Sun, Aug 16, 2020 at 12:53 AM rotusm...@gmail.com
 wrote:
>
> i took your suggestions, tried the '-work' option it showed me the temporary 
> directory where the build files are stored, but they didn't contain the 
> object file. After exploring that a little, i found out out that the 'go 
> build' command also makes a temporary link directory with the build directory 
> but the link directory gets deleted even with the '-work' option.

Sorry, I forgot about that.  I guess you don't need the -work flag.
Instead, add another flag to -ldflags: "-tmpdir=/my/tmp/dir".  The
go.o file will be put into that directory.  I see you figured that
out.  Sorry for the confusion.


> i watched a video of gopher-os and looked through it's github repository for 
> ways to extract the object files needed and tried his command as follows, but 
> i'm getting these errors which i can't resolve:
>
> GOARCH=386 GOOS=linux go build -n 2>&1 | sed -e "1s|^|set -e\n|" -e 
> "1s|^|export GOOS=linux\n|" -e "1s|^|export GOARCH=386\n|" -e "1s|^|export 
> CGO_ENABLED=0\n|" -e "1s|^|WORK='./build'\n|" -e "1s|^|alias pack='go tool 
> pack'\n|" -e "/^mv/d" -e "s|-extld|-tmpdir='./build' -linkmode=external 
> -extldflags='-nostdlib' -extld|g" | sh 2>&1 | sed -e "s/^/ | /g"
>
> Errors/Warnings:
>
>  | loadinternal: cannot find runtime/cgo
>  | /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 
> 08049000
>
> The above command is able to produce an object file in the ./build directory 
> i specified, i can link it without any errors, but when i try to run the 
> executable it doesn't work.
>
> i know there is nothing wrong with the linker script because i have created 
> object files using the gccgo cross-compiler, and they work.
> i wish to use the extra set of features the 'go build' cross-compiler is able 
> to provide that gccgo cross-compiler cannot.

I'm not sure what's going on here.  There are many possibilities.  In
particular note that Go makes direct system calls; it does not use
libc.  So your system has to provide a compatible system call
interface.

Ian

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


Re: [go-nuts] Re: What does "ex-wait-release" mean?

2020-08-17 Thread Ian Lance Taylor
On Mon, Aug 17, 2020 at 8:56 AM jake...@gmail.com  wrote:
>
> See https://groups.google.com/g/golang-dev/c/qtxOW0x4Rrw/m/WqepX5V6AQAJ on 
> the golang-dev forum. It mean that it was wait-release but the tree is now 
> open for development.

And the new tag helps us find CLs that were postponed during the release freeze.

Ian


> On Monday, August 17, 2020 at 3:23:55 AM UTC-4 lziq...@gmail.com wrote:
>>
>> Some of my CLs are tagged with this, and I don't know why? Can someone 
>> please tell me?
>>
>> https://go-review.googlesource.com/c/go/+/244778
>
> --
> 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/b47fc560-836c-4fd6-8336-1e3d9f99ac6fn%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/CAOyqgcWGHojptesS2Rvpq%3D%2BequeGo-kny2fK6cjcCYQC3ru%3DsA%40mail.gmail.com.


Re: [go-nuts] Generics and parentheses

2020-08-17 Thread Ian Lance Taylor
On Mon, Aug 17, 2020 at 10:13 AM Jonathan Gerber  wrote:
>
> 1) Of the enumerated omissions, the ones that I think are really unfortunate 
> are, in order of importance, from my perspective:
>
> No operator methods & no adapters - Doesn't this make generic types sort of 
> second class?. I think these features would be an elegant addition to the 
> language but I assume that there is a reason for their omission.

To me this is kind of separate from generics.  It's true that the lack
of operator methods means that user defined types are never as capable
as the types predefined by the language.  But that limitation seems to
apply to all types, not just generic types.


> No support covariance or contravariance. Maybe I am on shaky ground in terms 
> of my understanding but doesn't this mean, for instance, that if I have two 
> interfaces, Foo and Bar, and a third composite interface, FooBar, which 
> consists of Foo and Bar, that a function with a generic parameter T 
> constrained by Foo would not accept a type that implements FooBar? If i am 
> incorrect, where does this come into play?

Go in general does not support covariance and contravariance because
those are complex concepts and Go has a very simple type system.
https://golang.org/doc/faq#covariant_types .  That said, I don't think
that your example uses covariance.  If FooBar is composed of Foo and
Bar (type FooBar interface { Foo; Bar }) then any type that implements
FooBar also implements Foo.


> No support for variadic type parameters. Rust gets around this with hygienic 
> macros and meta-programming. I am not a big fan of the level of 
> complexity/quirkiness involved with working around the lack of variadics in 
> Rust. I hope to see them in Generics in Go one day. Otherwise, you will 
> probably end up api bloat full of functions differing only in the number of 
> parameters supported.

We may get variadic type parameters some day, if we can figure out a
way to make them work.  I don't think that's a priority for the first
version, though.  And it's not easy to see how to make them work;
their support in C++ seems to rely heavily on SFINAE, which I don't
think we particularly we want in Go.

> 2) I don't see syntax for directly applying multiple constraints to a generic 
> type. Is this achievable only via interface composition?

Yes.


> 3) And something I glossed over during the first reading, but is a bit sad - 
> Methods may not take additional type arguments.

Yes.  I think we'd all like them if we can figure out how to implement
them, but it's not obvious.  See the example at
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods
.


> Also, in the area of ergonomics, here are some thoughts:
> 1) Allow for separating out generic type declarations from constraints. Rust 
> allows you to split type parameter declaration from type constraints via an 
> optional `where` keyword which comes right before the body of the entity. 
> This is very helpful for readability, especially given complex constraints.

The current design draft lets you move complex constraints into their
own separately defined type, so I don't see a clear need for further
separation.

> 2) I personally don't think allowing multiple types to share a constraint is 
> worth not allowing unbounded types without the bulky "interface{}" type. Is 
> there some other simpler syntax that could be considered? Would a simple {} 
> be a parsing nightmare? What about '_' ?  Something like `func Something 
> (type T _, U SuperUseful ) (a T, b U){...}` ?

Most likely we would support using "any" as an alias for "interface{}".

Thanks for the note.

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/CAOyqgcXjHwq%3Dep0uD%2BYvntLmETfJFEJ9MytJrW7Egvs5tkT2mw%40mail.gmail.com.


Re: [go-nuts] Memory synchronization by channel operations and mutexes

2020-08-17 Thread Ian Lance Taylor
On Mon, Aug 17, 2020 at 9:06 AM jake...@gmail.com  wrote:
>
> My understanding is that atomic does not 'synchronize memory' in general.  If 
> you use a Mutex, then everything that happened before is 'synchronized'. If 
> you use atomic then only the atomic variable is 'synchronized'. That is kind 
> of the point of using atomic.
>
> If I am wrong, please point me at the part of the Go Memory Model that says 
> otherwise. Personally, I have always felt that the go memory model, and 
> specifically the guarantees of the atomic package are not as rigorously 
> defined as I would like. But in this case, I'm pretty sure I am correct.

The behavior of the sync/atomic package is not specified at all by the
Go memory model.  See https://golang.org/issue/5045.

I'm not sure I agree that using sync/atomic means that only that
memory location is synchronized (assuming I understand what that
means, which I may not).  There are other meaningful patterns for
sync/atomic.

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/CAOyqgcXKCSHb4-g7uHvf-RMsky8veC52OFDjmguUQCxHDXbShA%40mail.gmail.com.


Re: [go-nuts] [generics]: Pointer methods in interfaces used as constraints?

2020-08-15 Thread Ian Lance Taylor
On Fri, Aug 14, 2020 at 9:31 PM Patrick Smith  wrote:
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#pointer-method-example
>  has this example:
>
> // Setter2 is a type constraint that requires that the type
> // implement a Set method that sets the value from a string,
> // and also requires that the type be a pointer to its type parameter.
> type Setter2(type B) interface {
>
> Set(string)
>
> type *B
>
> }
> // FromStrings2 takes a slice of strings and returns a slice of T,
> // calling the Set method to set each returned value.
> //
> // We use two different type parameters so that we can return
> // a slice of type T but call methods on *T aka PT.
> // The Setter2 constraint ensures that PT is a pointer to T.
> func FromStrings2(type T interface{}, PT Setter2(T))(s []string) []T {
>
> result := make([]T, len(s))
>
> for i, v := range s {
>
> // The type of [i] is *T which is in the type list
>
> // of Setter2, so we can convert it to PT.
>
> p := PT([i])
>
> // PT has a Set method.
>
> p.Set(v)
>
> }
>
> return result
>
> }
>
>
> I wonder if it might be worthwhile to allow specifying pointer methods in 
> interfaces, so that we could write instead
>
> type Setter3 interface {
>
> // For type T to implement Setter3, *T must have a Set method.
>
> * Set(string)
>
> }
>
> func FromStrings3(type T Setter3(T))(s []string) []T {
>
> result := make([]T, len(s))
>
> for i, v := range s {
>
> result[i].Set(v)
>
> }
>
> }
>
>
> This is simpler in two ways: FromStrings3 only needs one interface 
> constraint, and it does not need to convert [i] to a type parameter, 
> but can call result[i].Set(v) directly.
>
> I imagine interfaces containing pointer methods should be used only as 
> constraints on type parameters, not as normal interfaces.
>
> I have no idea if such cases arise often enough to make this idea worthwhile.

This suggestion is a little bit like the pointer methods we had in an
earlier version of the design draft
(https://go.googlesource.com/proposal/+/572fea69936c3f25a99860fce22aeb23a3263ca3/design/go2draft-type-parameters.md#pointer-methods).

I'm not sure how that would work if such an interface type were used
other than as a type constraint (of course we could forbid that case).
An interface currently holds either a pointer or a value.  If the
interface says that the method must be on the pointer type, then
presumably the interface will hold a value.  But then what address do
we take to call the method?  Taking the address of the value stored
inside the interface would mean that an interface was a reference type
rather than a value type.  I think that would be a subtle distinction
that might increase confusion when using the language.  Though
admittedly the points in this area are already rather subtle (e.g.,
the FAQ answer https://golang.org/doc/faq#pointer_to_interface).

That side, at the moment I think that the constraint type inference
idea is more versatile, as it works for types other than pointers.

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/CAOyqgcWxTFPM_fmL%3DyE9VNgob1_UZYufyz94F%3D5rov1YcJU72Q%40mail.gmail.com.


Re: [go-nuts] New linker

2020-08-15 Thread Ian Lance Taylor
On Sat, Aug 15, 2020 at 11:49 AM Amnon  wrote:
>
> What is the best place to read about the ongoing work on the new linker?
> With the Go 1.15 release, how far along are we with the plans?
> What has been achieved?
> And what is still to come?

The work on the new linker is close to complete and has been merged
into tip for the future 1.16 release (although 1.16 won't be released
until next February).  The work is as described at
https://golang.org/s/better-linker.

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


Re: [go-nuts] obtaining the original type from a named alias type with go/types?

2020-08-15 Thread Ian Lance Taylor
On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts
 wrote:
>
> I would like to be able to obtain the original type for an alias given
> a source input. I can see in "go/types" that it's possible to know
> whether a named type is an alias by `typ.Obj().IsAlias()`, but I cannot
> see how to obtain the actual original type unless it is an alias for a
> basic type.
>
> Can someone point me to a way to get this information? From the source
> it looks something like `typ.Obj().Type().(*types.Named).Obj().Type()`.
> Is this correct assuming that the original type is a named type?

I haven't tested it but I *think* you can just write typ.Underlying().

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


Re: [go-nuts] [ generics ] Concrete example of comparables and generic function types

2020-08-14 Thread Ian Lance Taylor
On Thu, Aug 13, 2020 at 8:37 PM Beka Westberg  wrote:
>
> Hello! I just ran into a problem that is solved really nicely with the new 
> generics proposal and I thought someone might find it interesting :D
>
> I was trying to implement a library for doing ascii art programmatically. The 
> main struct is basically an image.Image except it works with bytes instead of 
> colors. As such you /should/ be able to create functions (like a flood fill 
> algorithm) that are abstracted over both of these types, but without 
> "generics" this cannot be done (with compile time type safety).
>
> I sketched a little project in the go2go playground that implements generic 
> functions for doing Porter-Duff compositions on any types that fulfill the 
> following constraint:
>
> ```
> type Rect(type T comparable) interface {
> At(x, y int) T
> Set(x, y int, t T)
> }
> ```
>
> Type defs on lines [8, 13]. Porter-Duff implementation [15, 99] Main [101, 
> 108] ByteImg implementation [110, 185]
>
> I liked this example because it requires passing a generic function (the 
> Porter-Duff func) to another generic function (Merge) :D I hope someone else 
> finds it interesting as well!

Thanks for the example.

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/CAOyqgcUWF7c3kvJa-c%3DTTw9Cdccbcz%3D9A%2BKDxpdSBaWgjrtymw%40mail.gmail.com.


Re: [go-nuts] How to build an object file for a specific GOOS and GOARCH with external linker?

2020-08-14 Thread Ian Lance Taylor
On Fri, Aug 14, 2020 at 8:29 AM  wrote:
>
> i'm trying to create an object file by using "go build" for GOOS=linux 
> GOARCH=386.
> My current go environment has GOOS=linux GOARCH=amd64.
>
> i know that go build directly builds and links the files, but i want to link 
> files using an external linker file, so i need only the object file to be 
> created.
>
> i have tried to look up ways to do so, but i could not find any solution to 
> this.
>
> The files i'm trying to compile can be .go files that have a main function or 
> just a non-main-package.

There is no way to do this for a non-main package.  I'm not sure how
that makes sense.  There wouldn't be any way for you to use such an
object.

For a main package, one trick to get you started is to use to use go
build -ldflags="-linkmode=external -extld=/bin/echo".  That will show
you how the external linker is invoked, including the objects that are
passed to it.  If you also use the go build -work option, it will save
the temporary directory, and you can grab the objects.  Then in
principle you can copy those objects to the target system and run the
linker command there.

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


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Ian Lance Taylor
On Thu, Aug 13, 2020 at 3:09 PM roger peppe  wrote:
>
> I do feel that the "all or nothing" nature of type parameter lists (if you 
> specify one type parameter, you must explicitly specify all of the others 
> too, even if they could otherwise be inferred) is likely to get in the way 
> here. I'd like to see a way to specify some type parameters and not others, 
> so that constraint type inference can work even when, for example, there's a 
> generic return type parameter that can't be inferred from the arguments. We 
> could potentially use an underscore for that.

If I understand you correctly, we changed that when we added the
constraint type inference section.  See the updated
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference
section.

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/CAOyqgcVvLvuAVy%3DWVA2n4wCcpEKNfbxTN-d_K%3Dz8kz1oiK9Z3g%40mail.gmail.com.


Re: [go-nuts] [generics] Was "no type contracts" considered?

2020-08-13 Thread Ian Lance Taylor
On Wed, Aug 12, 2020 at 9:58 AM Markus Heukelom
 wrote:
>
>
>
> On Mon, Aug 10, 2020 at 8:30 PM Ian Lance Taylor  wrote:
>>
>> Go is a strictly typed languages, and constraints are the meta-types
>> of type parameters.
>
>
> I just realised there might be a distinction between strictly typed and 
> strongly typed languages. Would it be correct to say C++ is strongly typed, 
> but not strictly typed wrt templates (up C++20 at least)? Did you mean it in 
> that sense?

I'm not sure about the exact terminology here.  I would agree that C++
is only weakly typed at the template meta level.  As I understand it
(and I may not), C++20 introduces optional strict typing at the
template meta level.

In the current generics design draft we are requiring strict
meta-types at the generic level.

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/CAOyqgcU%3DZcZ1SmUa-uqn1QrdvMZE3yTjptCUNRVePx6%2BHHZ4gw%40mail.gmail.com.


Re: [go-nuts] Go1.15 + SQLite Driver + Windows + Ld.exe results in ld error "unrecognized option --high-entropy-va"

2020-08-13 Thread Ian Lance Taylor
On Thu, Aug 13, 2020 at 12:01 PM Corey Gilmore  wrote:
>
> Setup:
> - Go 1.15
> - https://github.com/mattn/go-sqlite3 SQL driver
> - Windows 10 (2004)
> - Ld.exe (via MingW via TDM-GCC), version 2.25
>
> Prior to go1.15, running "go run main.go" or "go build" would work without 
> issue.  With go1.15, the error "ld.exe: unrecognized option 
> '--high-entropy-va'" occurs.  This seems to be due to go1.15 changing the 
> default buildmode from exe to pie (https://golang.org/doc/go1.15#windows) as 
> setting the buildmode (-buildmode=exe) when running "go run" or "go build" 
> resolves the issue.
>
> Looking into ld.exe, I do see that the "--high-entropy-va" flag is available 
> although the error says it is unrecognized.  Odd...but this is also outside 
> of my wheelhouse.
>
> Running/building on WSL or Ubuntu using go1.15 works without issue.  This is 
> strictly a Windows issue and specifically because of SQLite since it requires 
> cgo.

The --high-entropy-va option was added to the MingW linker in the GNU
binutils 2.26 release.  You are using 2.25, which was released in
2014.  The current version is 2.35.  Is it possible for you to upgrade
to a newer version?

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/CAOyqgcWRW0ZhHtwsi9asbZDw%3D1dQ%2Bui9JiRgqkk41ZdtjYgMbw%40mail.gmail.com.


Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Ian Lance Taylor
On Thu, Aug 13, 2020 at 9:22 AM jimmy frasche  wrote:
>
> Would the constraints package have Pointer[E], Slice[E], and so on?

Good question.  I don't know.  We can certainly add them if we see
people using them.


> What happens if you have
>   type SC(type E I) interface {
> type []E
>   }
> for some I? Generally it seems like something to avoid, but it would
> be needed for
>   type Map[type K comparable, V interface{}] interface {
> type map[K]V
>   }
> at least. Are those checked at the same time as methods?

Yes.  Constraints are used for constraint type inference, which gives
us the final set of type arguments.  Only once the type arguments are
fully known do we check that the constraints are satisfied.  So, yes,
this happens at the same time that we verify that the type arguments
have any required methods.


> Do chains of constraints like
>  func F[type T interface{}, PT Setter2[T], SPT SC[PT]](xs SPT) SPT
>  func G[type T interface{}, PT Setter2[T], S0 SC[T], S1[PT]](xs S0) S1
> work?

Yes.  The algorithm loops until there is nothing left to do.


Thanks for the feedback.

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/CAOyqgcU_aD8%3Dw12-FPeiUNKcCe1DSOWLiH203ay6ZPikvO5U0Q%40mail.gmail.com.


Re: [go-nuts] Is there any plan for go plugin .so can be used by different version of go from compiled?

2020-08-13 Thread Ian Lance Taylor
On Thu, Aug 13, 2020 at 9:21 AM zhizhao wang  wrote:
>
> If go plugin .so used by different version of go from compiled, the different 
> package error will occur.
> So is there any plan to fix this problem?

I am not aware of anybody working on this.

It's a very hard problem.

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/CAOyqgcVb08OPXJ-JjA5B9h86bwjnZ1WgfDFzUw%3DCM6922BnT_w%40mail.gmail.com.


[go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-12 Thread Ian Lance Taylor
I just added a new section to the generics design draft describing
constraint type inference.  This is a generalization and
simplification of the earlier pointer method approach, which has now
been removed.  I would be happy to hear any comments.  Thanks.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference

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/CAOyqgcX6AcGUt4e6JTMrxXkAtMRq%2Bo6zSVnjqchEroheYBP%2BBw%40mail.gmail.com.


Re: [go-nuts] Seperate debuginfo?

2020-08-12 Thread Ian Lance Taylor
On Wed, Aug 12, 2020 at 8:43 AM ethan.pailes via golang-nuts
 wrote:
>
> The C ecosystem allows one to generate a separate file containing debug info 
> so that you can initially install a stripped library or binary and then only 
> pull in the debug info as needed. I'm interested in doing the same for go, 
> but I have not been able to find an equivalent to the -gsplit-dwarf compiler 
> flag. I've tried using `objcopy --only-keep-debug` to generate a .debug file, 
> but it didn't seem to take.
>
> Has anyone else gone down this road? I would also be glad to hear that this 
> is just known not to be possible at this point so that I can stop digging.
>
> For a little context as to why I want to do this, we are using go on embedded 
> devices and we would like to keep our payload size down for OTA updates so we 
> would rather avoid shipping debug info that will only be used rarely.

I would expect the objcopy approach to work.

go build x
objcopy --only-keep-debug x x.debug
objcopy --strip-debug --add-gnu-debuglink=x.debug x x.stripped

Where does that go wrong?

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/CAOyqgcU-_Jw_Zk%2BWksxNB9T2t02hTzNQuURwSzuxi97TLknLPw%40mail.gmail.com.


Re: [go-nuts] Generics: after type lists

2020-08-11 Thread Ian Lance Taylor
On Tue, Aug 11, 2020 at 8:47 PM robert engels  wrote:
>
> Isn’t the example with big.Float only a problem because of the pointer based 
> design - which is much harder to write code with than a immutable value based 
> one.
>
> Then you have
>
> D = A.Add(B).Add(C)
>
> with
>
> (Number n) func Add(a Number) Number
>
> Which is straightforward, and the compiler creates the temp storage on the 
> stack for intermediate results.
>
> To perform similar math using pointer based methods you have to use 
> ‘accumulator’ math, and most likely lots of temp variables - and the 
> resulting number of allocations on the stack is probably the same.

Sure, but my point is that there is a chain of hypotheticals here.
You are describing a possible type that as far as I know does not
exist in the wild.  I think that the overall argument that Patrick is
presenting only holds if at least one such type does exist, and if
that type is used widely enough that it's worth writing algorithms
that work both for that type and for builtin types.  It's definitely
possible.  But as far as I know at present it's an entirely
hypothetical situation.  That doesn't mean we shouldn't consider it.
But it does mean that we should also consider how likely it is to
arise.

Ian



> > On Aug 11, 2020, at 10:31 PM, Ian Lance Taylor  wrote:
> >
> > On Tue, Aug 11, 2020 at 4:19 PM Patrick Smith  wrote:
> >>
> >> On Sun, Aug 9, 2020 at 6:29 PM Ian Lance Taylor  wrote:
> >>> If we accept this argument, then in Go it wouldn't be appropriate to
> >>> write a single function that works on both builtin and user-defined
> >>> types.
> >>
> >> This I disagree with; what you regard as inappropriate, I see as a
> >> desirable goal. The question is whether there is a reasonable way to
> >> achieve it, one for which the benefits outweigh the costs.
> >>
> >> Before I explain why I disagree, let me mention that sorting was
> >> perhaps not the best example for me to have used. It is very common to
> >> sort things in an order different than the default (e.g. integers in
> >> reverse order), or to sort things that don't have a default order
> >> (e.g. countries by area, population, or date of formation). For this
> >> reason, sort functions in any language very often accept a comparison
> >> function.
> >>
> >> A better example might be a function that finds the roots of a
> >> polynomial with real-valued coefficients, where the coefficients are
> >> taken from a type F that might be float32, float64, or a user-defined
> >> type such as one based on big.Float. In this function, we want to use
> >> the default arithmetic operations provided by F. It would be very
> >> unusual to override those with a different choice of operations.
> >>
> >> But in the type lists approach, unless we write two distinct versions
> >> of the function, we must use an adaptor type or object (or multiple
> >> adaptor functions) to indicate to the function what arithmetic
> >> operations to use. There is no way for the function to access these
> >> operations otherwise (except reflection).
> >
> > Thanks, it's an interesting example.  big.Float isn't really the same
> > as float32 or float64.  For example, big.Float doesn't provide any way
> > to write "a = b + c + d".  You can only write, in effect, "a = b + c;
> > a += d".  And big.Float doesn't have == != < <= >= >.  Instead it has
> > expressions like "a.Cmp(b) == 0".  So if you want to write a generic
> > function that works on float32/float64/big.Float, you're going to need
> > adaptors no matter what.  You can't avoid them.
> >
> > So in practice I don't think we're going to write the root-finding
> > function using parametric polymorphism at all.  I think we're going to
> > write it using an interface type.  And I think we're going to base
> > that interface type on big.Float.  Then we need to write an
> > implementation of that interface for float32/float64.  And that
> > implementation is likely to use parametric polymorphism so that we
> > only have to write it once to handle both float32 and float64.  And
> > for that implementation, type lists work fine.
> >
> >
> > What you're looking for here, I think, is a case where there is a type
> > A that implements methods that are isomorphic to the basic arithmetic
> > and/or comparison operators.  And then you want an algorithm that can
> > be used with that type, as well as with the builtin types.  For such a
> > case, it might be nice to be abl

Re: [go-nuts] Generics: after type lists

2020-08-11 Thread Ian Lance Taylor
On Tue, Aug 11, 2020 at 4:19 PM Patrick Smith  wrote:
>
> On Sun, Aug 9, 2020 at 6:29 PM Ian Lance Taylor  wrote:
> > If we accept this argument, then in Go it wouldn't be appropriate to
> > write a single function that works on both builtin and user-defined
> > types.
>
> This I disagree with; what you regard as inappropriate, I see as a
> desirable goal. The question is whether there is a reasonable way to
> achieve it, one for which the benefits outweigh the costs.
>
> Before I explain why I disagree, let me mention that sorting was
> perhaps not the best example for me to have used. It is very common to
> sort things in an order different than the default (e.g. integers in
> reverse order), or to sort things that don't have a default order
> (e.g. countries by area, population, or date of formation). For this
> reason, sort functions in any language very often accept a comparison
> function.
>
> A better example might be a function that finds the roots of a
> polynomial with real-valued coefficients, where the coefficients are
> taken from a type F that might be float32, float64, or a user-defined
> type such as one based on big.Float. In this function, we want to use
> the default arithmetic operations provided by F. It would be very
> unusual to override those with a different choice of operations.
>
> But in the type lists approach, unless we write two distinct versions
> of the function, we must use an adaptor type or object (or multiple
> adaptor functions) to indicate to the function what arithmetic
> operations to use. There is no way for the function to access these
> operations otherwise (except reflection).

Thanks, it's an interesting example.  big.Float isn't really the same
as float32 or float64.  For example, big.Float doesn't provide any way
to write "a = b + c + d".  You can only write, in effect, "a = b + c;
a += d".  And big.Float doesn't have == != < <= >= >.  Instead it has
expressions like "a.Cmp(b) == 0".  So if you want to write a generic
function that works on float32/float64/big.Float, you're going to need
adaptors no matter what.  You can't avoid them.

So in practice I don't think we're going to write the root-finding
function using parametric polymorphism at all.  I think we're going to
write it using an interface type.  And I think we're going to base
that interface type on big.Float.  Then we need to write an
implementation of that interface for float32/float64.  And that
implementation is likely to use parametric polymorphism so that we
only have to write it once to handle both float32 and float64.  And
for that implementation, type lists work fine.


What you're looking for here, I think, is a case where there is a type
A that implements methods that are isomorphic to the basic arithmetic
and/or comparison operators.  And then you want an algorithm that can
be used with that type, as well as with the builtin types.  For such a
case, it might be nice to be able to write that algorithm only once.

And, of course, with the current design draft, we can write the
algorithm only once, provided we write it using methods.  We will use
the methods defined by the type A.  And we will need an adapter for
builtin types to implement those methods.  And that adaptor can be
written using type lists.

Now, I think your original argument is that in the future we might
decide to introduce operator methods.  And we might add those operator
methods to A.  And then we can write our algorithm using operators.
But we might have a chain of functions already built using (regular)
methods, and we won't be able to use those with operator methods, so
we will be discouraged from using operator methods.

So first let me observe that that seems to me like a pretty long chain
of hypotheticals.  Is there any type out there today that has methods
that correspond exactly to operators?  There is a reason that
big.Float and friends don't have such methods: for any type that uses
pointers, they are inefficient.  Is this possibility going to be a
real problem, or will it always be a hypothetical one?

Second, let me observe that in this example it seems to me that we
will already have the adapter types that add methods to the builtin
types.  So the question would be: if we add operator methods, can we
very easily shift those adaptor types from using type lists to using
operator methods instead?  And it seems to me that the answer is yes.
If we have operator methods, we will be able to write interface types
with operator methods.  And if we do that it would be very natural to
let the builtin types implement those interfaces.  And, of course, we
can use those interface types as constraints.  So we just have to
change the constraints that our adapter types use from type lists to
interface types with operator methods.  And everything else will work.
So, sure, operator

Re: [go-nuts] How do disable vDSO for i386 and use linker script?

2020-08-11 Thread Ian Lance Taylor
On Tue, Aug 11, 2020 at 12:26 PM  wrote:
>
> I also have a quick follow up question based on #1 here:
>
> >> 1. Is it possible to completely disable use of the vDSO for i386/Linux 
> >> programs? If so, is this done at build time, or automatically by the go 
> >> runtime?
>
> >There is no way to disable use of the VDSO if it is present on the system.
>
> The VDSO is not present on my target OS, but it is present on the OS building 
> the binary, which is amd64 Linux compiling for i386 Linux. To your knowledge, 
> is there anything that I need to do so that VDSO is not used by a pure go 
> program compiled with the standard toolchain? Will the go runtime detect the 
> absence of AT_SYSINFO_EHDR in the aux vector at runtime and use INT 0x80 
> instead?

Yes: if there is no AT_SYSINFO_EDHR at runtime, the Go runtime will
use int 0x80 for all system calls.  This is independent of whether the
VDSO exists at build time.

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/CAOyqgcVAkUQoyCqSxXHVJ32Kf-%2BtpSWcEVw%2BqpLibtE1Z5%3D5Pw%40mail.gmail.com.


Re: [go-nuts] How do disable vDSO for i386 and use linker script?

2020-08-11 Thread Ian Lance Taylor
On Tue, Aug 11, 2020 at 8:12 AM  wrote:
>
> I am attempting to build a simple hello-world go program for a custom 
> operating system that provides compatibility with a subset of Linux syscalls 
> through the INT 0x80 syscall inferface.
>
> My understanding is that go uses the Linux vDSO for time functions, but that 
> otherwise it uses INT 0x80 for syscalls. What I am not 100% sure of is 
> whether go automatically uses INT 0x80 on i386 if the kernel does not provide 
> a pointer to the vDSO in the aux vector. I found this issue on the tracker, 
> but it addresses amd64 instead of i386.

The same thing happens on 386 GNU/Linux.  If the VDSO is not found at
program startup time, because there is no AT_SYSINFO_EHDR aux value,
then the runtime will fall back to using int 0x80.


> 1. Is it possible to completely disable use of the vDSO for i386/Linux 
> programs? If so, is this done at build time, or automatically by the go 
> runtime?

There is no way to disable use of the VDSO if it is present on the system.


> Secondly, I need to use a custom linking script to build my program so that 
> it can be loaded into the user address space designated by the OS. I tried 
> doing this with the following command, but this seems to have linked my 
> hello-world program with glibc code and introduced gratuitous usage of the 
> vDSO via CALL *%gs:0x10.
>
>
> CGO_ENABLED=0 GOARCH=386 go tool link -v -linkmode external -extldflags 
> "-static -Ti386.ld" hello.o

This will link against libc, but I wouldn't expect it to actually use
anything from libc.  Where are the VDSO references coming from?


> 2. Is it possible to feed a linker script into the default go linker similar 
> to gcc's "-T" option?

No.  You can use the -T option to set the text segment address, but
there is no support for general linker scripts.


> 3. Is it possible to link go programs using gcc without also linking in glibc 
> code? The command above generates the host link command below, which seems to 
> link lpthread.

I don't think so, at least not easily.  Once you invoke the external
linker, it's going to expect to use the glibc startup code.


> One idea I had for this is to use the gccgo front end to compile the program 
> under the assumption that I will be able to have more control over the linker 
> flags since the assembler will output a standard object file instead of go's 
> proprietary format. Is there merit to this approach?

Yes, that is likely true.

> I am also curious why lpthread is linked at all when using -linkmode 
> external. I thought that the go runtime provided its own threading 
> implementation, making lpthread unnecessary. It's also unclear to my why 
> glibc code would be linked in considering that CGO_ENABLED=0 is set. Am I 
> misunderstanding what the linker is doing here?

The external linker normally expects that you are using cgo.  When
using cgo, threads are created using pthread_create.  Only when not
using cgo, and not using glibc, does the Go runtime use the clone
system call directly.

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/CAOyqgcX%3DOTp%3D2DJK2jZJL37YCZSzUZ55wW-6Zn3Q1GE_Vgteyw%40mail.gmail.com.


Re: [go-nuts] [proposal] Make go compiler work with different syntax versions in same project to support adaptivity

2020-08-10 Thread Ian Lance Taylor
On Mon, Aug 10, 2020 at 1:30 AM Ivan Ivanyuk  wrote:
>
> Thank you for answering
>
> Why does it take so long to implement generics then? There is already an 
> instrument in playground that works fine. Why not just roll it out and 
> improve design, if needed, in next version?
>
> Having generics in 2021 means many projects will choose other languages in 
> 2020, which will effectively mean 1 year of work in other language

Besides what other people have said, we believe, rightly or wrongly,
that language stability and backward compatibility are important
features for Go programmers.  We don't want to roll out a version of
generics that we then have to change in some incompatible way.  That
would force people to rewrite programs over time, which is painful,
and will decrease people's perception of Go as a stable and reliable
language.

Ian



> On Mon, Aug 10, 2020, 04:13 Ian Lance Taylor  wrote:
>>
>> On Sat, Aug 8, 2020 at 7:51 PM  wrote:
>> >
>> > Add support of optional syntax_version to file beginning, allow compiler 
>> > to tokenize/compile file by the compiler of syntax_version, using any 
>> > number of syntax_version-s in same project
>> >
>> > Why? Because go takes ridiculously long to implement generics, and 
>> > implementation is very likely to not be perfect or to become not perfect 
>> > when world changes. Having support of several syntaxes/compilers in same 
>> > project will allow to adapt syntax faster
>>
>> We already support something like this on a per-module basis via the
>> "go" line in a go.mod file
>> (https://golang.org/cmd/go/#hdr-The_go_mod_file).  See also
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.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/CAOyqgcW6ZQM%2BbNWgmvpaf6sAfbXt0OZmUrEm6mtS%2BDBaEMeegA%40mail.gmail.com.


Re: [go-nuts] [generics] Was "no type contracts" considered?

2020-08-10 Thread Ian Lance Taylor
On Mon, Aug 10, 2020 at 6:07 AM Markus Heukelom
 wrote:
>
> For what it is worth: for non-exported functions/types all operations could 
> be allowed, possibly leading to infamous C++-level error messages but as you 
> are the author of the package, those error messages would make sense to you 
> anyway.
>
> For example, I could really use to be able to write things like this:
>
> func sibling[type t](node *t) *t {
> if node.parent == nil {
> return nil
> }
> if node.parent.left == node {
> return node.parent.right
>   }
>   return node.parent.left
> }
>
> This is not really possible with the current design. Of course I could 
> specify an interface with getters/setters, but that feels a bit silly and 
> cumbersome as everything is local to the package anyway.
>
> I don't have better a solution, but all contracts/constraints do is prevent 
> long, unreadable error messages while inside a package there's no real 
> problem with those error messages to begin with.

Go is a strictly typed languages, and constraints are the meta-types
of type parameters.  You are suggesting that we should have an escape
hatch for that meta-type system when using unexported types.  I
suppose that is possible.  It seems like something we could add later
if it brings a big benefit.

I'm not sure when your example would really arise.  It looks like you
have a tree type; why not make that a parameterized type and make
sibling a method on the type?

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


Re: [go-nuts] Re: [generics] How to use maps in generic structs?

2020-08-10 Thread Ian Lance Taylor
On Mon, Aug 10, 2020 at 7:08 AM Markus Heukelom
 wrote:
>
> Just a quick thought, instead of "comparable" (and type lists) maybe we could 
> use a single operator to specify the required "operators" interface:
>
> type BiMap[type V, K ==] struct {
> forward map[K]V
> reverse map[V]K
> }
>
> func Max[type T <](a, b T) T {
>
> }
>
> func ScanRowStruct[type T .](rows sql.Rows, dest *T) error {  // operator . 
> ensures T is a struct
>
> }

It could probably work, but we wind up with a bunch of special purpose
syntax with only a tenuous connection to the way constraints work in
general.  And you have to define connections between operators.  That
is, comparable supports both == and !=, but you only mentioned ==;
does == imply !=?

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/CAOyqgcXDuwR87UBpPCXsViqN5grg8hB3y_YRbEpBsz-uYJ0%2BRg%40mail.gmail.com.


Re: [go-nuts] Re: [generics] How to use maps in generic structs?

2020-08-10 Thread Ian Lance Taylor
On Mon, Aug 10, 2020 at 7:08 AM Alvadron  wrote:
>
> The type of map keys in Go should be comparable. As you haven't specified any 
> restriction to the type parameters, it doesn't compile because Go doesn't 
> know whether K and V are comparable.
>
> If you add the restriction  "comparable", then it compiles:
>
> type BiMap[type V, K comparable] struct {
> forward map[K]V
> reverse map[V]K
> }
>
> PD: It is true that the error could be more informative. Right now we get:
>
> type checking failed for main
> prog.go2:13:14: invalid map key type K
> prog.go2:14:14: invalid map key type V
>
> Not sure if it is possible but, ideally, the message should say something 
> like "Invalid mp key type K: it is not comparable"

Getting a better error message is https://golang.org/issue/40551.

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


Re: [go-nuts] Generics: after type lists

2020-08-09 Thread Ian Lance Taylor
On Fri, Aug 7, 2020 at 4:33 PM Patrick Smith  wrote:
>
> I like the second draft for generics. It seems to me a large
> simplification and improvement over the first draft. Considering just
> the state of Go today, I would be quite happy with this, even if it's
> not perfect. Thanks to Ian, Robert, and everyone else for their work
> on this.
>
> Also, I would vote for square brackets over parentheses.
>
> But I do have concerns related to the future development of Go. In
> particular, if we think it likely that a future version of Go will
> allow operator overloading, then perhaps type lists are not the best
> choice.
>
> To my mind, the biggest defect in the design draft is that we can't
> write generic functions and types that work transparently with both
> builtin and user-defined types (that do not inherit appropriate
> behavior from an underlying builtin type). For example, we can't write
> a
>
> func Min[type T ...](a, b T) T { ... }
>
> that works both when T is int and when T is
>
> type BigInt struct { i *big.Int }
>
> Instead, we would use workarounds such as writing two versions of Min,
> or passing in an adaptor function or object; in the case of Min, a
> comparison function. And that's OK, especially in an initial version
> of generics.
>
> But generics would be significantly easier to use if we could write
> functions that work on both builtin and user-defined types. The two
> most likely candidates for allowing this seem to be operator
> overloading (where BigInt might have a method named "<", "operator<",
> or some such, that allows it to be used with the < operator) and
> methods on builtin types (where int might be given a method named Less
> with the same behavior as the < operator). Of course, other solutions
> could be imagined, but I'll confine my speculations to those two.
>
> Now let's try to imagine how sorting slices might be implemented in
> the standard library in various futures.  Of course, the current sort
> package would have to be kept and maintained for a long time.
>
> If Go2 implements the current draft with type lists, then we might add
> a sort2 package containing something to:
>
> func SliceBy[type T](s []T, less(T, T) bool) { ... }
>
> type Ordered interface {   // Copied from the draft
> type int, int8, int16, int32, int64,
> uint, uint8, uint16, uint32, uint64, uintptr,
> float32, float64,
> string
> }
>
> func Slice(type T Ordered)(s []T) {
> SliceBy(s, func(a, b T) bool { return a < b })
> }
>
> type Lesser[type T] interface { Less(T) bool }
>
> func SliceByLess(type T Lesser[T])(s []T) {
> SliceBy(s, T.Less)
> }
>
> All well and good. Now say time goes by and Go3 adds operator methods.
> Nothing in the sort2 package expresses a unified sort using operator
> methods, so we need a new package sort3:
>
> func SliceBy[type T](s []T, less(T, T) bool) { ... }
>
> type Lesser[type T] interface { <(T) bool }   // Or whatever the syntax is.
>
> func Slice(type T Lesser)(s []T) {
> SliceBy(s, func(a, b T) bool { return a < b })
> }
>
> (We might just add sort3.Lesser and sort3.Slice into the sort2 package
> under different names, but I suspect the aim would be to eventually
> deprecate sort2.)
>
> The effects will ripple through other code, both in and outside the
> standard library. Suppose some Go2 code has a chain of generic
> functions A calls B calls C calls D, where each exists in two
> versions, one for builtin types and one for user-defined types, and
> the two versions of D call sort2.Slice or sort2.SliceByLess. When Go3
> with operator methods arrives, if we want to unify these, we have to
> write a third version of each of A, B, C, and D, where D calls
> sort3.Slice.
>
> On the other hand, suppose Go2 has type lists and Go3 gives builtin
> types methods corresponding to operators. Assuming the name Less is
> used for <, sort2.SliceByLess now handles both builtin and
> user-defined types, so we don't need a sort3 package. And in the ABCD
> scenario, we can just keep the SliceByLess version of each, and
> quietly let the sort2.Slice versions vanish as they become unused.
>
> [Important point===>] This means that if Go2 has type lists in
> interfaces, there will be a strong incentive for Go3 to give builtin
> types methods, even if we think that operator overloading is otherwise
> a superior solution, because operator overloading will require much
> more new code to be written.
>
> Instead of using type lists, suppose Go2 allowed interfaces to require
> the presence of specific operators. Then the sort2 header might look
> like this:
>
> func SliceBy[type T](s []T, less(T, T) bool) { ... }
>
> type Lesser[type T] interface { <(T) bool }
>
> func Slice(type T Lesser)(s []T) {
> SliceBy(s, func(a, b T) bool { return a < b })
> }
>
> type MLesser[type T] interface { Less(T) bool }
>
> func SliceM(type T MLesser[T])(s []T) {
> SliceBy(s, T.Less)
> }
>
> (Note that the first part is identical to the previous sort3 header.
> But in 

  1   2   3   4   5   6   7   8   9   10   >