Re: [go-nuts] What's the recommended way to determine if a type.Type is exported?

Ah sorry, I apparently didn't pay close attention then. The correct way is to type-assert to *types.Named and then use it's Obj() method, I guess. :) BTW: It's not "casting", but "type-asserting". "casting" (go calls it "converting") is, when you have something with concrete type T1 and convert

[go-nuts] Re: Question about type information for map and slice

On Sunday, April 30, 2017 at 10:54:07 AM UTC+8, feilengcui008 wrote: > > So, if i do this: > //assign some var to interface type > var i io.Reader = readerImpl > i.Read(buf) > > the interface i's dynamic type infomation is filled by type deduction in > compiling phase? > yes > >

[go-nuts] how to get process pid through port on which the process listened?

hi, i want to find process pid through port, such as through 3306 got PID 2052 # netstat -nlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 0.0.0.0:33060.0.0.0:*

[go-nuts] Re: Question about type information for map and slice

So, if i do this: //assign some var to interface type var i io.Reader = readerImpl i.Read(buf) the interface i's dynamic type infomation is filled by type deduction in compiling phase? also the function table in itab field of interface implementation filling with the actually methods

Re: [go-nuts] Errors from Gob

On Thu, Apr 27, 2017 at 08:55:36AM -0700, Chris Hopkins wrote: > What's the current thinking on this sort of error handling? It's hard to > say "Handle errors properly" when the standard library is butchering the > original error message. This most likely *is* the original error, as returned by

Re: [go-nuts] What's the recommended way to determine if a type.Type is exported?

What exactly would you cast to *types.TypeName, btw? Looks like *types.TypeName is not a types.Type (missing Underlying() method). On Sunday, April 23, 2017 at 11:11:13 PM UTC-7, Axel Wagner wrote: > > I'd say, probably type-asserting to a *types.TypeName >

Re: [go-nuts] Strange Go runtime behavior related to xml.Unmarshal

On Sat, Apr 29, 2017 at 3:09 AM, Nikos Anastopoulos wrote: > Τη Σάββατο, 29 Απριλίου 2017 - 7:33:00 π.μ. UTC+3, ο χρήστης Nikos > Anastopoulos έγραψε: >> >> Either through the /proc/PID/tasks entries, or using >> GODEBUG=schedtrace=1000.I get consistent results with both ways

Re: [go-nuts] strange benchmark result: inline is slower than function calls

On Sat, Apr 29, 2017 at 1:43 AM, T L wrote: > > package main > > import ( > "testing" > ) > > const N = 4096 > type T int64 > var a [N]T > > var globalSum T > > func sumByLoopArray_a(p *[N]T) T { > var sum T > for i := 0; i < len(p); i++ { > sum += T(p[i])

Re: [go-nuts] // go:generate won t work, //go:generate will

Yup. On Sat, Apr 29, 2017 at 1:38 PM, Michael Jones wrote: > [NOTE: an unofficial answer on Rob Pike's behalf] > > ...no, not organic growth, not oversight, not antique JCL inflexibility, > rather, a design choice. Use of the "//tag:stuff" structure comes as a > benefit

Re: [go-nuts] GC problem

Your program completes without any trouble on my machine, but do note if we enter the following in an emacs scratch buffer and hit C-j to use it as a glorified calculator: (/ (* 3e8 8) (* 1024 1024 1024)) 2.2351741790771484 If each element in your array takes up 8 bytes, which is the case for a

[go-nuts] benchmark orders matter?

https://play.golang.org/p/pims1WwvlV https://play.golang.org/p/RfeVwF5jHL https://play.golang.org/p/1-A-uoUTjR The benchmarks in the above three files are same, except the orders. The results are different. The middle benchmark is always the most inefficient. Is there any problem in the

[go-nuts] Re: Question about type information for map and slice

On Saturday, April 29, 2017 at 9:56:20 PM UTC+8, feilengcui008 wrote: > > Hey, All > > I'm curious about what happened when map or slice is assigned to interface > variables. > > I know the interface implementation in go runtime is: > type iface struct{ > tab *itab > data

[go-nuts] Re: [ANN] listser/mutexer/channeler: generators.

i forgot to say at the end, id love to be able to do cat mystruct.go | lister Tomates | mutexer Tomatex | That d be awesome! :D On Saturday, April 29, 2017 at 5:06:27 PM UTC+2, mhh...@gmail.com wrote: > > Hi, > > several generators i made to avoid some duplication. > >

[go-nuts] [ANN] listser/mutexer/channeler: generators.

Hi, several generators i made to avoid some duplication. https://github.com/mh-cbon/lister Package lister is a generator to generate typed slice. https://github.com/mh-cbon/channeler Package channeler is a cli generator to generate channeled version of a type.

Re: [go-nuts] // go:generate won t work, //go:generate will

So the question is, if it was intentionally made like this, was it made to make sure a s/beginner/anyone/ will fail at least once ? But i m sure it is just organic growth. On Saturday, April 29, 2017 at 4:25:16 PM UTC+2, Konstantin Khomoutov wrote: > > On Sat, 29 Apr 2017 04:33:19 -0700 (PDT)

Re: [go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)

More often than not the obsessed creator will have the last say and will discard what the trained designer and results of the focus groups tests have to say unless they agree with him/her :D Hence the need for a more flexible solution. But you have a good point. However I still see at least 2

Re: [go-nuts] // go:generate won t work, //go:generate will

On Sat, 29 Apr 2017 04:33:19 -0700 (PDT) mhhc...@gmail.com wrote: > just a note about the //go:gen comment. > > If there is a space in front of go:gen, it won t work, this, > // go:gen... [...] Let's cite the output of running `go help generate`: | Go generate scans the file for directives,

Re: [go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)

On Sat, 29 Apr 2017 01:49:49 -0700 (PDT) Asticode wrote: > - https://github.com/therecipe/qt: like https://github.com/andlabs/ui > it forces you to have a native look [...] It may be just me, but actually a virtue of "having a native look" is one of the best selling points

[go-nuts] Re: go tls doesn't support certificates signed with SHA512 and RSA

I have a very dumb patch to SHA512 with RSA that I can confirm actually works with our server, but the tests are all failing. I'll try to get it cleaned up and submitted to the right place. In the meantime if anyone has any knowledge of why this isn't already done, I'd love to hear about it.

[go-nuts] go tls doesn't support certificates signed with SHA512 and RSA

I have a root CA cert signed with with the aforementioned sigs and I can't get tls with go to work with it. This seems logical given https://github.com/golang/go/blob/11eaf428867417b9d5fab4deadd0ef03c9fd9773/src/crypto/tls/common.go#L151 Would it be reasonable to open an issue about this?

[go-nuts] Question about type information for map and slice

Hey, All I'm curious about what happened when map or slice is assigned to interface variables. I know the interface implementation in go runtime is: type iface struct{ tab *itab data unsafe.Pointer } and the interface static and dynamic type infomation are stored in itab, when we use

[go-nuts] Re: // go:generate won t work, //go:generate will

Tee same behavior happen for a comment placed in a func body, the comment is ignored, without warning. On Saturday, April 29, 2017 at 1:33:20 PM UTC+2, mhh...@gmail.com wrote: > > Hi, > > just a note about the //go:gen comment. > > If there is a space in front of go:gen, it won t work, this, > //

Re: [go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)

Awesome, will definitely check it out. On Sat, Apr 29, 2017 at 12:46 PM, wrote: > Hey thanks for this detailed answer. > > We are in line about what we d like to get from such package, > lightness, efficiency, handy. > > I ll just fix a misunderstanding, about my previous

[go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)

Hey thanks for this detailed answer. We are in line about what we d like to get from such package, lightness, efficiency, handy. I ll just fix a misunderstanding, about my previous question, I m totally adept of html based technologies for the GUI, until electron came out, there were no other

[go-nuts] // go:generate won t work, //go:generate will

Hi, just a note about the //go:gen comment. If there is a space in front of go:gen, it won t work, this, // go:gen... I did not check, but i bet 100 boxes there s already a rule about that. Clear crystal. Still, there is no warning about that in vet/lint, so for a beginner, assuming he got

[go-nuts] GC problem

Hi, I have a gc.go: package main import ( "fmt" "runtime/debug" ) const N = 3e8 func f(x int) { ls := make([]uint64, N) for i := N - 1; i >= 0; i-- { ls[i] = uint64(i) } fmt.Println(ls[x]) } func main() { debug.SetGCPercent(10) f(8) f(9) } 1st call

Re: [go-nuts] Strange Go runtime behavior related to xml.Unmarshal

Τη Σάββατο, 29 Απριλίου 2017 - 7:33:00 π.μ. UTC+3, ο χρήστης Nikos Anastopoulos έγραψε: > > Either through the /proc/PID/tasks entries, or using > GODEBUG=schedtrace=1000.I get consistent results with both ways With some experimentation more I did, I tend to believe this behavior has somehow

[go-nuts] Re: [ANN] astilectron - Build cross platform GUI apps with GO and Electron (HTML/JS/CSS)

Let me add one more project to the list: - https://github.com/therecipe/qt: like https://github.com/andlabs/ui it forces you to have a native look and it seems overly complicated to embed the QT library in the binary Le jeudi 27 avril 2017 14:12:31 UTC+2, Asticode a écrit : > > I do agree

[go-nuts] strange benchmark result: inline is slower than function calls

package main import ( "testing" ) const N = 4096 type T int64 var a [N]T var globalSum T func sumByLoopArray_a(p *[N]T) T { var sum T for i := 0; i < len(p); i++ { sum += T(p[i]) } return sum } func sumByLoopArray_b(p *[N]T) T { var sum T for i := 0; i <