Re: [go-nuts] Any reason why this type conversion is not allowed?

@lan @Shulhan Thanks. Glad to know the design goal much better. On Tuesday, April 14, 2020 at 1:07:36 PM UTC+8, Ian Lance Taylor wrote: > > On Mon, Apr 13, 2020 at 6:56 PM Glen Huang > > wrote: > > > > Given > > > > type Data []byte > > s := [][]byte{{1},{2}} > > > > I wonder why this con

Re: [go-nuts] Any reason why this type conversion is not allowed?

On Mon, Apr 13, 2020 at 6:56 PM Glen Huang wrote: > > Given > > type Data []byte > s := [][]byte{{1},{2}} > > I wonder why this conversion isn't allowed? > > []Data(s) > > Seems pretty straightforward. Maybe I miss some edge cases where things won't > square? https://golang.org/doc/faq#convert_s

[go-nuts] x/mobile: gomobile bind fails to find cgo library

It seems like "gomobile" bind command cannot find CGO libraries. I enabled CGO, and still, the issue remains the same. I would really appreciate it if someone could help me with this matter. ### What version of Go are you using (`go version`)? $ go version go version go1.14.1 darwin/am

[go-nuts] [ANN] Unik, a Go unikernel capable of running Gio GUI programs

Congrats on building this! What you have done is amazing. I have always wanted to do something like this but never did find the time nor commitment. https://groups.google.com/forum/m/#!topic/gvisor-users/T2WBS7DDehU -- You received this message because you are subscribed to the Google Groups "

Re: [go-nuts] Any reason why this type conversion is not allowed?

> On 14 Apr 2020, at 09.46, Glen Huang wrote: > > With all due respect, I think assigning to interface{} is orthogonal to the > question, which deals with variance. (I asked about it here: > https://groups.google.com/forum/#!topic/golang-nuts/S4p54OpQHGw) > > Here, the type is redefined, so

Re: [go-nuts] Any reason why this type conversion is not allowed?

With all due respect, I think assigning to interface{} is orthogonal to the question, which deals with variance. (I asked about it here: https://groups.google.com/forum/#!topic/golang-nuts/S4p54OpQHGw) Here, the type is redefined, so in the context of conversion, it and the original should be e

Re: [go-nuts] Any reason why this type conversion is not allowed?

Go doesn't do any implicit type conversions, and it's quite consistent about that. The only things which are type "converted" are untyped constants. I would love for this to work too, by the way, since I often come up with something like: var a []interface{} var b []SomethingConcrete I would lov

[go-nuts] Any reason why this type conversion is not allowed?

Given type Data []byte s := [][]byte{{1},{2}} I wonder why this conversion isn't allowed? []Data(s) Seems pretty straightforward. Maybe I miss some edge cases where things won't square? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsu

Re: [go-nuts] New Go API for protobuf

In terms of whether the public API needs to change in light of the new protobuf API, the only place that the old protobuf API leaks to the public grpc API is here: https://pkg.go.dev/google.golang.org/grpc/credentials?tab=doc#OtherChannelzSecurityValue (where it uses the old proto.Message defi

Re: [go-nuts] Re: [ANN] Unik, a Go unikernel capable of running Gio GUI programs

IBM VM/370 and much that followed is exactly this “VM is a hardware abstraction” line of reasoning. Logging into a user session was to “IPL a machine.” (Initial Program Load, imagine an IBM PC bios screen rushing by) On Mon, Apr 13, 2020 at 2:06 PM Brian Candler wrote: > On Monday, 13 April 2020

Re: [go-nuts] New Go API for protobuf

As of right now, grpc is on github.com/golang/protobuf@v1.3.3 . However, nothing stops you in your specific application to upgrade to github.com/golang/protobuf@v1.4.0, which just a thin wrapper over the

Re: [go-nuts] New Go API for protobuf

[ + joetsai ] On Mon, Apr 13, 2020 at 3:41 PM Tharaneedharan Vilwanathan wrote: > > Hi, > > I have a quick question. > > I was going through this: > https://blog.golang.org/protobuf-apiv2 > > I would like to know if grpc is using this new version. To the extent I > tried, it seemed to use the ol

[go-nuts] New Go API for protobuf

Hi, I have a quick question. I was going through this: https://blog.golang.org/protobuf-apiv2 I would like to know if grpc is using this new version. To the extent I tried, it seemed to use the old API. Am I right? If so, how do I make grpc use the new API? Or am I missing something? Please let

Re: [go-nuts] testing code that uses ioutil.ReadDir?

If they end up "littering", then I'll agree.  So far, I just need the one... hold my beer... On 4/13/20 10:40 AM, Robert Engels wrote: I don’t think littering your code with state variable and branches just to test is in anyway a good (or sustainable approach) approach.  I have never seen any

[go-nuts] Re: [ANN] Unik, a Go unikernel capable of running Gio GUI programs

On Monday, 13 April 2020 19:42:17 UTC+1, Elias Naur wrote: > > The project is an experiment in a larger exploration of the question: > "what if the operating > system process abstraction were a virtual machine? > Interesting. BTW, have you seen gVisor ? It takes a diff

Re: [go-nuts] [ANN] Unik, a Go unikernel capable of running Gio GUI programs

Dnia 2020-04-13, o godz. 11:42:16 Elias Naur napisał(a): > https://eliasnaur.com/unik Thank you. Respect! :) > -- elias -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from t

[go-nuts] [ANN] Unik, a Go unikernel capable of running Gio GUI programs

Hi, I just completed the proof-of-concept for a Go unikernel, Unik, which allows Go programs to run without an operating system directly in virtual machines. Unlike similar projects Unik is written in Go (and assembler), and it is compiled into Go programs just like any other Go dependency. Uni

Re: [go-nuts] container/heap, heap interface question

Thanks, Ian. On Sunday, April 12, 2020 at 9:10:25 PM UTC-7, Ian Lance Taylor wrote: > > On Sun, Apr 12, 2020 at 8:28 PM Ram Kumar > wrote: > > > > Documentation for "container/heap" says > > > > Package heap provides heap operations for any type that implements > heap.Interface. > > > > he

Re: [go-nuts] Re: map for readonly access will always remain thread-safe ?

> > I'm not saying that m["foo"] is a > variable (it's not, because it's not addressable). I'm saying that m > is a variable and m["foo"] is a read of that variable m, just as if p > is a variable of pointer type then *p is a read of that variable p. > Ah, ok, this framing makes sense to me! On

Re: [go-nuts] Re: map for readonly access will always remain thread-safe ?

On Mon, Apr 13, 2020 at 10:17 AM wrote: > > Very old thread I know, but: > > > a map is a variable > > This seems clear enough, but what doesn't seem obvious to me is that an > expression like m["foo"] can be treated as "just a variable". Does the spec > also make that clear? > > E.g., if I roll

Re: [go-nuts] testing code that uses ioutil.ReadDir?

I don’t think littering your code with state variable and branches just to test is in anyway a good (or sustainable approach) approach. I have never seen any large scale project that did this - but could be my ignorance. > On Apr 13, 2020, at 12:13 PM, 'K Richard Pixley' via golang-nuts > wr

Re: [go-nuts] Re: map for readonly access will always remain thread-safe ?

Very old thread I know, but: > a map is a variable This seems clear enough, but what doesn't seem obvious to me is that an expression like m["foo"] can be treated as "just a variable". Does the spec also make that clear? E.g., if I roll my own map type, there's no reason to assume m.Get("foo")

Re: [go-nuts] testing code that uses ioutil.ReadDir?

"Coverage is a proxy for testing quality, but not a guarantee of it. Getting to 100% coverage is a better indicator of chasing metrics than of actually writing good tests" Wise words indeed. I'm going to print out this quote and frame it. Thanks Rob! On Monday, 13 April 2020 17:07:25 UTC+1, K

Re: [go-nuts] testing code that uses ioutil.ReadDir?

On 4/10/20 4:15 PM, Ian Lance Taylor wrote: I'm not proud. Here is an example program for which os.Open(dirname) succeeds but ioutil.ReadDir(dirname) fails. You may have to adjust pathMax and nameMax for your system. Whether you actually want to use this technique is left to you. Thank you. 

Re: [go-nuts] testing code that uses ioutil.ReadDir?

I like this solution better than Ian's, thank you. If I can't eliminate an error, or fake it, add a new one.  :). On 4/12/20 4:04 PM, Rob Pike wrote: I am the author of the test coverage tool, and I do not believe that 100% code coverage is the right goal. Coverage is a proxy for testing quali

Re: [go-nuts] testing code that uses ioutil.ReadDir?

On 4/12/20 6:55 AM, Kevin Malachowski wrote: [External Email. Be cautious of content] Is there a particular reason you want 100% code coverage? In this case, I'm writing code that will be the introduction of go to a team of which I am now a fresh member.  100% code coverage opens eyes.  And

[go-nuts] [ANN] The top geek's survival kit - tweet over telephone, news over SMS, browser over Email, and much more! Check out the open source laitos project.

Hello fellow Gophers. With the ongoing global-scale challenge, I present to you the top geek's survival kit - tweet over telephone, news over SMS, browser over Email, and much more! The free and open source laitos software connects to primitive infrastructure such as telephone, SMS, and satel

[go-nuts] Re: godoc (golang.org/x/tools/cmd/godoc) has become module-aware

@Hein Meling Thanks for the pointer, this actually helped. It gets installed into `$GOPATH/bin`, which actually IS in my `$PATH`, but `which godoc` shows `/usr/local/bin/godoc`. My `.profile` explicitly puts `$GOPATH/bin` first, but somehow my $PATH starts with all sorts of crap like `/usr/loca

Re: [go-nuts] correction in make documentation

Cool, thank you for the second pair of eyes :) On Saturday, April 11, 2020 at 9:48:06 PM UTC+1, Rob 'Commander' Pike wrote: > > It's not just the size, though, it's also what kind of thing gets made. I > think it's better as is. > > -rob > > > On Sun, Apr 12, 2020 at 6:02 AM Feroz Jilla > wrote

Re: [go-nuts] Intercepting field access and method call

Thanks for the clarification, Brian! On Monday, April 13, 2020 at 2:56:49 PM UTC+6, Brian Candler wrote: > > On Sunday, 12 April 2020 18:12:16 UTC+1, Tanmay Das wrote: >> >> this is not my first statically typed language, I know a little bit of C >> and Java. I was under the impression that Go is

[go-nuts] Re: Tools for managing licenses of dependencies

GitHub's licensed tool is written in Ruby but supports Go: https://github.com/github/licensed/blob/master/docs/sources/go.md. Another option is https://github.com/frapposelli/wwhrd. Go tooling is designed with programmatic use in mind so you could also easily roll your own

Re: [go-nuts] Intercepting field access and method call

On Sunday, 12 April 2020 18:12:16 UTC+1, Tanmay Das wrote: > > this is not my first statically typed language, I know a little bit of C > and Java. I was under the impression that Go is capable of some dynamic > behavior. Maybe things like Go's type inference, duck typing, empty > interface{} le