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

[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] Re: why the binary generated by go test has no symbol table

[buaa...@gmail.com]

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

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

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

[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] [ generics ] Added constraint type inference to the design draft

[Steven Blenkinsop]

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.

On Fri, Aug 14, 2020 at 5:40 AM roger peppe  wrote:

>
>
> On Thu, 13 Aug 2020 at 23:30, Ian Lance Taylor  wrote:
>
>> 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.
>>
>
> Ah, that's useful and interesting, thanks. I suspect that being able to
> selectively omit type parameters could be useful though - for when there's
> no obvious ordering to the parameters and you want to infer some of the
> earlier types in the list while specifying some later ones. Maybe in
> practice it'll always be possible to use an explicit type conversion in a
> value parameter to do this though, especially if Steven
> Blenkinsop's ordering suggestions are followed (perhaps that could be a `go
> vet` checki).
>
>   cheers,
> rog.
>
>>
>>
>> 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/CAJhgacjPfoUp%2Bkhb4csuF%2Bz%3DTEWchZuSri94yTP4%2BtRvtnK5Ng%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/CANjmGJvgk%2BRgAgUwfgDutCGNiqZHzH0KCCh2aZ0Gp_UeG%2BHnjA%40mail.gmail.com.

Re: [go-nuts] Syntactic analysis with Gocc

[LEN P]

Thanks, was my mistake.

El mar., 8 de septiembre de 2020 15:43, Ian Lance Taylor 
escribió:

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

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

[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

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

[go-nuts] Re: Unable to represent a file data type

[Ronny Bangsund]

On Tuesday, September 8, 2020 at 7:44:33 PM UTC+2, Qali Fah wrote:
>
> The problems i'm having are how i would represent the artwork(picture 
> file) and song (music file) in gorm (Golang ORM library) and in what format 
> do i return it to the client after being stored and are there external 
> packages i can use to simplify things?
>
I'd use filenames locally and return URLs to media. Reference the music and 
image files rather than stuffing them into the database. Store names, 
filenames and all the metadata you think makes sense (artist, album, genre 
and all sorts of extra tags) in the music file table.

If presenting a web API, JSON is perfectly fine (and most common). Any web 
frontends are likely to be JS anyway, so use a natively easy to use format. 
The built-in packages in the Go distribution can get you all the way, but 
if you like a little extra help with routing, Chi is a decent option:
https://github.com/go-chi/chi


-- 
You received this message because you are subscribed to the Google 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/eb1a0231-c95f-4443-8f33-a273039bff50o%40googlegroups.com.

[go-nuts] Syntactic analysis with Gocc

[Abraham]

Hi, I am trying to implement a parser with Gocc. This is the file with the 
definition of the grammar.

/* *** LEXER  */

!espacio_en_blanco: '\t' | '\n' | '\r' | ' ' ;
!comentario:'#' { . } '\n' ;

_letra: 'A'-'Z' | 'a'-'z' | '_' ;
_digito:'0'-'9' ;
_alfa:  _letra | _digito ;

cadena: '"' {_alfa | ' ' | '!' | '.' } '"' ;
entero: '0' | '1'-'9' {_digito} ;

multi:  '/' '*' ;

mkdisk: 'm' 'k' 'd' 'i' 's' 'k' ;
rmdisk: 'r' 'm' 'd' 'i' 's' 'k' ;
fdisk:  'f' 'd' 'i' 's' 'k' ;
mount:  'm' 'o' 'u' 'n' 't' ;
unmount:'u' 'n' 'm' 'o' 'u' 'n' 't' ;
rep:'r' 'e' 'p' ;
 
size:   's' 'i' 'z' 'e' ;
fit:'f' 'i' 't' ;
unit:   'u' 'n' 'i' 't' ;
path:   'p' 'a' 't' 'h' ;
type:   't' 'y' 'p' 'e' ;
delete: 'd' 'e' 'l' 'e' 't' 'e' ;
name:   'n' 'a' 'm' 'e' ;
add:'a' 'd' 'd' ;
id: 'i' 'd' ;

mbr:'m' 'b' 'r' ;
disk:   'd' 'i' 's' 'k' ;

identificador:  _letra {_alfa} ;

gn: '-' ;
igl:'=' ;

/* *** */

/* * PARSER ** */

<<
import(
"fmt"
)
>>

Cmd:Mkdisk <<  fmt.Println("Axioma") >> ;

Mkdisk: mkdisk OpcMkdisk << fmt.Println("Instrucción reconocida.") 
>> ;

OpcMkdisk:  OpcMkdisk Opc << fmt.Println("Producción recursiva.") >>
|   Opc << fmt.Println("Se ejecuta primero.") >> ;

Opc:Size
|   Path
|   Unit
|   MLinea ;

Size:   gn size << fmt.Println("SIZE") >> ;

Path:   gn path << fmt.Println("PATH") >> ;

Unit:   gn unit << fmt.Println("UNIT") >> ;

MLinea: gn fit << fmt.Println("ML") >> ;

/* *** */

The test method is as follows:

func main() {
texto := "mkdisk -size -path -unit -fit"
p := parser.NewParser()
s := lexer.NewLexer([]byte(texto))
res, err := p.Parse(s)
if err != nil {
fmt.Println("Se produjo un error.")
} else if res != nil {
fmt.Println("Se reconoció la instrucción.")
}
}

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c0f2ea89-827e-4df5-9a20-7d6d340f4d36n%40googlegroups.com.

[go-nuts] Unable to represent a file data type

[Qali Fah]

Hello everyone, i'm trying to create a music store API, where you can 
basically listen and buy songs. The problems i'm having are how i would 
represent the artwork(picture file) and song (music file) in gorm (Golang 
ORM library) and in what format do i return it to the client after being 
stored and are there external packages i can use to simplify things? Thank 
you.  

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/140eb0e9-85a0-4a90-871b-b1880d732f30n%40googlegroups.com.

Re: [go-nuts] Why does race detector only throw out warning rather than fatal error?

[Robert Engels]

The reason is so that you can detect multiple race conditions per run. Race 
detector is not designed for production runs. 

> On Sep 8, 2020, at 7:48 AM, Cholerae Hu  wrote:
> 
> Code with data races is invalid code, we shouldn't let it run once we find a 
> data race. Actually, since Go 1.5, when runtime finds concurrent read and 
> write to a map, it does throw a fatal error rather than just warning. Maybe 
> it's not consistent that race detector only print out warning message.
> -- 
> You received this message because you are subscribed to the Google 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/6c615a58-721e-4de0-ae8d-c4119c367b8dn%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/45C1C2FC-170E-48D6-983D-F3F85FCF6B57%40ix.netcom.com.

[go-nuts] [ANN] Use Twitter over satellite, send Emails over telephone, watch YouTube on Windows 98 - what more can a geek desire? (laitos v4.1)

[Houzuo Guo]

Hey fellow Gophers!

As a professional geek 邏, you need Internet access whenever and wherever! 
That's what laitos grants you - Internet access and features using 
primitive communication infrastructure such as telephone, SMS, and 
satellite terminal.

Check out the latest version 4.1: https://github.com/HouzuoGuo/laitos

Kind regards,
Howard

-- 
You received this message because you are subscribed to the Google 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/385bc333-1241-46d6-8cf5-717eee4e19f3n%40googlegroups.com.

[go-nuts] Why does race detector only throw out warning rather than fatal error?

[Cholerae Hu]

Code with data races is invalid code, we shouldn't let it run once we find 
a data race. Actually, since Go 1.5, when runtime finds concurrent read and 
write to a map, it does throw a fatal error rather than just warning. Maybe 
it's not consistent that race detector only print out warning message.

-- 
You received this message because you are subscribed to the Google 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/6c615a58-721e-4de0-ae8d-c4119c367b8dn%40googlegroups.com.

[go-nuts] Re: Interface definition as type alias

['Javier Zunzunegui' via golang-nuts]

> The only real downsides, I think, are that compiler errors gets harder to 
read:
> https://github.com/golang/go/issues/21866
> And likewise, that the name won't appear at runtime, so if you print 
things using `reflect`, the result will be less readable.
> ...
> https://github.com/golang/go/issues/8082

Yeah, those are the downsides I am familiar with. The reflect I have no 
issue with, the compiler errors is a bit more unfortunate. I wasn't aware 
of those proposals, though looking at their dates they are not being 
actively considered.

Does it have performance implications? Is there any difference in type 
resolution for typed interfaces vs untyped ones?

On Tuesday, September 8, 2020 at 12:15:42 PM UTC+2 Javier Zunzunegui wrote:

> > So yes: Using a type alias has advantages, but no, this advantage is 
> never realized because neither the alias nor the plain type decl are used 
> in practice.
>
> The ResonseWriter is a bad example because it has a method `Header() 
> http.Header`, for which you must import net/http regardless. 
> Take fmt.Stringer, `type Stringer interface { String() string }`. I could 
> perfectly well define `type MyStringer interface { String() string }` and 
> use that instead of fmt.Stringer (if fmt.Stringer were an alias, with much 
> more flexibility), and avoid importing fmt altogether. And even this 
> scenario is trivial (I have nothing agaist importing fmt!), but for my own 
> interfaces having the interface defined in separate places can help avoid 
> import cycles, make packages more locally contained, keep compilation 
> faster, etc.
>
> Hence why I'm asking for reasons against it. I have used this before and 
> it has served me well, so I know there are advantages.
>
> On Tuesday, September 8, 2020 at 11:41:25 AM UTC+2 Volker Dobler wrote:
>
>> In practice you never declare the same interface twice 
>> switch from one to the other. Why would anybody declare
>> his own ResonseWriter interface if net/http.ResponseWriter
>> exists?
>>
>> So yes: Using a type alias has advantages, but no, this
>> advantage is never realized because neither the alias nor
>> the plain type decl are used in practice.
>>
>> V.
>>
>> On Tuesday, 8 September 2020 at 10:13:23 UTC+2 Javier Zunzunegui wrote:
>>
>>> TLDR: Why should I NOT the alias form `type ... = interface {...}` 
>>> instead of the standard `type ... interface {...}` for interface 
>>> declarations?
>>>
>>> The extended question:
>>>
>>> The normal type definition for an interface in go would be `type 
>>> TypeName interface {...}`. This results in a new type, which is assignable 
>>> to other types of the similar interfacce, such that this is valid:
>>> ```
>>> type I1 interface{ Foo() }
>>> type I2 interface{ Foo() }
>>> var _ I1 = I2(nil)
>>> ```
>>> But these are different types, such that any function with one of these 
>>> in the signature can't be converted to a similar function with the other, 
>>> such that this is NOT valid:
>>> ```
>>> var _ func(I1) = (func(I2))(nil)
>>> ```
>>>
>>> Declare the types as aliases  
>>> however, 
>>> and the limitation dissapears:
>>> ```
>>> type I1 interface{ Foo() }
>>> type I2 interface{ Foo() }
>>> var _ I1 = I2(nil) // still valid
>>> var _ func(I1) = (func(I2))(nil) // now valid
>>> ```
>>>
>>> A runnable example of the below using `http.ResponseWriter`:
>>>
>>>- without alias 
>>>- with alias 
>>>
>>> My point being using aliases offers an advantage (more flexible 
>>> assignment and interface implementation) and to my knowledge no meaningful 
>>> drawback. So why not use it everywhere?
>>>
>>

-- 
You received this message because you are subscribed to the Google 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/51fa50f1-afcc-4694-ae80-254c4630b89an%40googlegroups.com.

[go-nuts] Re: Interface definition as type alias

['Javier Zunzunegui' via golang-nuts]

> So yes: Using a type alias has advantages, but no, this advantage is 
never realized because neither the alias nor the plain type decl are used 
in practice.

The ResonseWriter is a bad example because it has a method `Header() 
http.Header`, for which you must import net/http regardless. 
Take fmt.Stringer, `type Stringer interface { String() string }`. I could 
perfectly well define `type MyStringer interface { String() string }` and 
use that instead of fmt.Stringer (if fmt.Stringer were an alias, with much 
more flexibility), and avoid importing fmt altogether. And even this 
scenario is trivial (I have nothing agaist importing fmt!), but for my own 
interfaces having the interface defined in separate places can help avoid 
import cycles, make packages more locally contained, keep compilation 
faster, etc.

Hence why I'm asking for reasons against it. I have used this before and it 
has served me well, so I know there are advantages.

On Tuesday, September 8, 2020 at 11:41:25 AM UTC+2 Volker Dobler wrote:

> In practice you never declare the same interface twice 
> switch from one to the other. Why would anybody declare
> his own ResonseWriter interface if net/http.ResponseWriter
> exists?
>
> So yes: Using a type alias has advantages, but no, this
> advantage is never realized because neither the alias nor
> the plain type decl are used in practice.
>
> V.
>
> On Tuesday, 8 September 2020 at 10:13:23 UTC+2 Javier Zunzunegui wrote:
>
>> TLDR: Why should I NOT the alias form `type ... = interface {...}` 
>> instead of the standard `type ... interface {...}` for interface 
>> declarations?
>>
>> The extended question:
>>
>> The normal type definition for an interface in go would be `type TypeName 
>> interface {...}`. This results in a new type, which is assignable to other 
>> types of the similar interfacce, such that this is valid:
>> ```
>> type I1 interface{ Foo() }
>> type I2 interface{ Foo() }
>> var _ I1 = I2(nil)
>> ```
>> But these are different types, such that any function with one of these 
>> in the signature can't be converted to a similar function with the other, 
>> such that this is NOT valid:
>> ```
>> var _ func(I1) = (func(I2))(nil)
>> ```
>>
>> Declare the types as aliases  
>> however, 
>> and the limitation dissapears:
>> ```
>> type I1 interface{ Foo() }
>> type I2 interface{ Foo() }
>> var _ I1 = I2(nil) // still valid
>> var _ func(I1) = (func(I2))(nil) // now valid
>> ```
>>
>> A runnable example of the below using `http.ResponseWriter`:
>>
>>- without alias 
>>- with alias 
>>
>> My point being using aliases offers an advantage (more flexible 
>> assignment and interface implementation) and to my knowledge no meaningful 
>> drawback. So why not use it everywhere?
>>
>

-- 
You received this message because you are subscribed to the Google 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/8580a406-f24b-4475-819d-1a4e08ed5e38n%40googlegroups.com.

Re: [go-nuts] Interface definition as type alias

['Axel Wagner' via golang-nuts]

The only real downsides, I think, are that compiler errors gets harder to
read:
https://github.com/golang/go/issues/21866
And likewise, that the name won't appear at runtime, so if you print things
using `reflect`, the result will be less readable.

I think there are cases where it has advantages, such as breaking import
cycles. They probably can be solved in other ways too, though.

IMO, if the conclusion would be "always use type-aliases", I'd prefer "Go
should make parameters and returns contra- and covariant respectively".
Because we'd essentially saying that interfaces should be represented by
their method set, not their type-name:
https://github.com/golang/go/issues/8082
Which is a fine position to take, but full contra- and covariance is both
cleaner and more powerful - again, IMHO.

On Tue, Sep 8, 2020 at 10:14 AM 'Javier Zunzunegui' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> TLDR: Why should I NOT the alias form `type ... = interface {...}` instead
> of the standard `type ... interface {...}` for interface declarations?
>
> The extended question:
>
> The normal type definition for an interface in go would be `type TypeName
> interface {...}`. This results in a new type, which is assignable to other
> types of the similar interfacce, such that this is valid:
> ```
> type I1 interface{ Foo() }
> type I2 interface{ Foo() }
> var _ I1 = I2(nil)
> ```
> But these are different types, such that any function with one of these in
> the signature can't be converted to a similar function with the other, such
> that this is NOT valid:
> ```
> var _ func(I1) = (func(I2))(nil)
> ```
>
> Declare the types as aliases  
> however,
> and the limitation dissapears:
> ```
> type I1 interface{ Foo() }
> type I2 interface{ Foo() }
> var _ I1 = I2(nil) // still valid
> var _ func(I1) = (func(I2))(nil) // now valid
> ```
>
> A runnable example of the below using `http.ResponseWriter`:
>
>- without alias 
>- with alias 
>
> My point being using aliases offers an advantage (more flexible assignment
> and interface implementation) and to my knowledge no meaningful drawback.
> So why not use it everywhere?
>
> --
> You received this message because you are subscribed to the Google 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/d9595614-ce72-4602-8ead-67e9a1427181n%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/CAEkBMfHmJeriqzsbYrhyuX%3DNzeMvJ3GcAAoXBwL_TKgkBkPUtg%40mail.gmail.com.

[go-nuts] Re: Interface definition as type alias

[Volker Dobler]

In practice you never declare the same interface twice 
switch from one to the other. Why would anybody declare
his own ResonseWriter interface if net/http.ResponseWriter
exists?

So yes: Using a type alias has advantages, but no, this
advantage is never realized because neither the alias nor
the plain type decl are used in practice.

V.

On Tuesday, 8 September 2020 at 10:13:23 UTC+2 Javier Zunzunegui wrote:

> TLDR: Why should I NOT the alias form `type ... = interface {...}` instead 
> of the standard `type ... interface {...}` for interface declarations?
>
> The extended question:
>
> The normal type definition for an interface in go would be `type TypeName 
> interface {...}`. This results in a new type, which is assignable to other 
> types of the similar interfacce, such that this is valid:
> ```
> type I1 interface{ Foo() }
> type I2 interface{ Foo() }
> var _ I1 = I2(nil)
> ```
> But these are different types, such that any function with one of these in 
> the signature can't be converted to a similar function with the other, such 
> that this is NOT valid:
> ```
> var _ func(I1) = (func(I2))(nil)
> ```
>
> Declare the types as aliases  
> however, 
> and the limitation dissapears:
> ```
> type I1 interface{ Foo() }
> type I2 interface{ Foo() }
> var _ I1 = I2(nil) // still valid
> var _ func(I1) = (func(I2))(nil) // now valid
> ```
>
> A runnable example of the below using `http.ResponseWriter`:
>
>- without alias 
>- with alias 
>
> My point being using aliases offers an advantage (more flexible assignment 
> and interface implementation) and to my knowledge no meaningful drawback. 
> So why not use it everywhere?
>

-- 
You received this message because you are subscribed to the Google 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/d3fd66bc-6732-451f-b563-e780ab9570c0n%40googlegroups.com.

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

[Amnon]

Cross compilation of CGO stuff requires a lot of faff.

I spend several years doing embedded development, and messing about 
with GCC build-chains. So I was absolutely astounded that the Go build tools
do everything with two env vars.

Once you branch out to CGO, you are back in the hairy world of GCC cross
compilation tool chains. I say turn back if you can!

My advice, if you need sqlite, is to switch 
to https://gitlab.com/cznic/sqlite
which is a pure Go version. I haven't tried it. But if it spared people 
the pain of CGO, then it is worth its weight in gold.

On Monday, 7 September 2020 20:27:39 UTC+1, Ian Lance Taylor wrote:
>
> 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/4400a583-de03-402e-a7f3-b1d2cc8eb0feo%40googlegroups.com.

[go-nuts] Interface definition as type alias

['Javier Zunzunegui' via golang-nuts]

TLDR: Why should I NOT the alias form `type ... = interface {...}` instead 
of the standard `type ... interface {...}` for interface declarations?

The extended question:

The normal type definition for an interface in go would be `type TypeName 
interface {...}`. This results in a new type, which is assignable to other 
types of the similar interfacce, such that this is valid:
```
type I1 interface{ Foo() }
type I2 interface{ Foo() }
var _ I1 = I2(nil)
```
But these are different types, such that any function with one of these in 
the signature can't be converted to a similar function with the other, such 
that this is NOT valid:
```
var _ func(I1) = (func(I2))(nil)
```

Declare the types as aliases  
however, 
and the limitation dissapears:
```
type I1 interface{ Foo() }
type I2 interface{ Foo() }
var _ I1 = I2(nil) // still valid
var _ func(I1) = (func(I2))(nil) // now valid
```

A runnable example of the below using `http.ResponseWriter`:

   - without alias 
   - with alias 

My point being using aliases offers an advantage (more flexible assignment 
and interface implementation) and to my knowledge no meaningful drawback. 
So why not use it everywhere?

-- 
You received this message because you are subscribed to the Google 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/d9595614-ce72-4602-8ead-67e9a1427181n%40googlegroups.com.