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
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
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
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
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
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
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
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
>
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'
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
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,
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:
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
> 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.
> ...
>
> 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
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,
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
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
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
19 matches
Mail list logo
