Re: [go-nuts] multiple-value f1() in single-value context

On Wed, Feb 28, 2018 at 12:23 PM, Alex Dvoretskiy wrote: > Hello Golang-nuts > > Why it is not allowed to pass function result like this to return?: > > https://play.golang.org/p/YPeaeW_4WZ6 > > > Or it is allowed without declaring temporary variables i3, i4? You need to assign the results of the

[go-nuts] multiple-value f1() in single-value context

Hello Golang-nuts Why it is not allowed to pass function result like this to return?: https://play.golang.org/p/YPeaeW_4WZ6 Or it is allowed without declaring temporary variables i3, i4? Thanks Alex -- You received this message because you are subscribed to the Google Groups "golang-nuts" g

[go-nuts] Re: Go += Package Versioning

I read through quite a bit of those docs, but somehow missed that - thanks Daniel. On Tuesday, February 27, 2018 at 4:35:32 PM UTC-7, Daniel Theophanes wrote: > > Hi Robert, you still can do that. Just add a "replace" directive in the > local go.mod. > > Please see https://research.swtch.com/vgo

[go-nuts] Re: Go += Package Versioning

Hi Robert, you still can do that. Just add a "replace" directive in the local go.mod. Please see https://research.swtch.com/vgo-tour for more details. On Tuesday, February 27, 2018 at 1:47:40 PM UTC-8, Robert Carlsen wrote: > > Before with the naive GOPATH workflow and also with vendoring, it wa

[go-nuts] Re: Cannot take the adress of.....

This is a shallow, visual symmetry. Per Go spec, Foo{} and 5 are not related in a meaningful way. Foo{} denotes a runtime operation that creates a new instance of Foo struct, and & takes an address of this instance. 5 is an integer literal https://golang.org/ref/spec#Integer_literals. While i

[go-nuts] Re: Go += Package Versioning

Before with the naive GOPATH workflow and also with vendoring, it was super easy for me to debug problems with and contribute to upstream packages. With vgo, I can't just cd into vendor/github.com/foo/bar to test out fixes for bugs, etc. Without vendoring I could just cd into $GOPATH/src/gith

[go-nuts] Re: Cannot take the adress of.....

> You can't take the address of the return value of a function or a > conversion (which is conceptually just a function) because it doesn't > have a location in memory and thus doesn't have an address. I've never understood the reason for this limitation. I'd expect the compiler to box any value

[go-nuts] Re: [ANN] Loukoum: a simple SQL Query Builder with reusable components

Hi Thomas, I’ve thought about writing something like this. My postgreSQL queries go through database/sql and github.com/lib/pq and are concatenated strings with + and constants in most cases, and sometimes with Sprintf to write an index naming a column. This approach is hard to read. I have thi

[go-nuts] Re: Possible bug in RHEL 7 / CentOS 7 CIFS implementation: workaround in Go core?

Yes, assuming there aren't other odd edge cases. I'm considering 32k to be safe since that's what C does, and every language we use (Python and PHP in particular) seem to rely on the C implementation, and don't have any problems that we've discovered. On Tuesday, February 27, 2018 at 12:32:14

[go-nuts] Possible bug in RHEL 7 / CentOS 7 CIFS implementation: workaround in Go core?

Wouldn't *2 (8k) be enough? -- 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. For more options, visit https://groups.googl

[go-nuts] Possible bug in RHEL 7 / CentOS 7 CIFS implementation: workaround in Go core?

I filed an issue (https://github.com/golang/go/issues/24015) that is looking like a bug in RHEL 7 when running getdents64 with too small a buffer. Brief summary: Go pulls data 4k at a time using the getdents64 system call on Linux. For some reason the response is always a pattern where the fir

[go-nuts] Re: Interface ????

Because then you could do this: func PrintAll(vals []interface{}) { vals[0] = 123 } func main() { names := []string{"stanley", "david", "oscar"} var s string s = names[0] } -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsu

[go-nuts] [ANN] Loukoum: a simple SQL Query Builder with reusable components

Hi, I'd like to announce a new open source project from Ulule: *Loukoum * (https://github.com/ulule/loukoum) *.*It's a simple query builder that will help you to generate complex queries without SQL injection. If you're not using an ORM, you should give it a try. At the moment, we only support

Re: [go-nuts] AES-GCM as stream cipher?

The tag is wrapped inside of the output of seal: - size of the tag: https://golang.org/src/crypto/cipher/gcm.go#L126 - https://golang.org/src/crypto/cipher/gcm.go#L146 You have to pass the tag + encrypted data to open to decrypt. AES-GCM already works like a stream cipher, meaning the result o

[go-nuts] Re: Interface ????

The usual way to do this is a function or method to convert from []string to []interface{}: https://play.golang.org/p/VW-xs6E9xul The correct approach is probably something different than "func PrintAll(vals []interface{})". What are you trying to do? Matt On Tuesday, February 27, 2018 at 9:25

Re: [go-nuts] Interface ????

On Tue, Feb 27, 2018 at 4:25 PM wrote: > Why doesn't work this : Because types []string and []interface{} are different and not assignable to each other. > and Why does it work? : Because type string implements interface{} (as any other type does), string is assignable to a variable of type in

[go-nuts] Interface ????

*Hello* *A beginner question :* *Why doesn't work this :* package main import ( "fmt" ) func PrintAll(vals []interface{}) { for _, val := range vals { fmt.Println(val) } } func main() { names := []string{"stanley", "david", "oscar"} <-error

[go-nuts] Arbitrary Secondary Indexes for boltdb

This package contains implementation for arbitrary secondary indexes for boltdb (the version maintained by coreos ) - currently alpha quality with not enough tests. The selector passed as the definition of the index is a bit lik

[go-nuts] Re: emersion/go-imap - How to retrieve and list unseen messages

teisipäev, 27. veebruar 2018 15:11.58 UTC+2 kirjutas Ivo Freitas: > > Hello > > I'm trying to use this implementation of IMAP protocol mas seems to be > impossible to retrieve unseen messages from the mailbox. > Cross-posted to SO: https://stackoverflow.com/q/49009432/723693 ain -- You recei

[go-nuts] emersion/go-imap - How to retrieve and list unseen messages

Hello I'm trying to use this implementation of IMAP protocol mas seems to be impossible to retrieve unseen messages from the mailbox. Here's my code. package main import ( "emailmonitor/util" "fmt" ) func main() { serverGmail := util.NewServerGmail() serverGmail.Connect() serverGmail.Login()

[go-nuts] Re: [ANN] An IMAP library written in Go. It can be used to build a client and/or a server and supports UTF-7.

Hello Emersion I'm using your library described above. Is there a way that we could talk about it? I have some doubts and sugestions. Thank you Em terça-feira, 28 de junho de 2016 09:43:19 UTC-3, emersion escreveu: > > Hi! > > I've been working for a couple of weeks on yet another IMAP library. I

Re: [go-nuts] Re: Cannot take the adress of.....

On Mon, Feb 26, 2018 at 10:01 PM, wrote: > or similar simpler example : > > this works : > > var j int = 42 > var p *int > p=&j // this works > fmt.Println(*p) > > > > var j int = 42 > var p *int > p=&int(j) //this doesn't work > fmt.Print

[go-nuts] AES-GCM as stream cipher?

Hi all, Is it possible to use go's GCM implementation as a stream cipher? It appears to me that the counter/tag are held private within the AEAD.Seal/Open methods. Thanks! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Tuesday, 27 February 2018 08:17:20 UTC+1, di...@veryhaha.com wrote: > > ok, this is really make gophers worry about whether or not the pointer > atomic functions should be used. > No, probably this is much less worrying as you think. Take a look as the documentation of sync/atomic: "These

Re: [go-nuts] Is there some kind of memory write protection mechanism?

Indeed. The concern here is unfounded. The original question was “why does it break?” and the answer is “because you used dangerous tools in a disallowed way.” That answer was not acknowledged; the subject was changed to “how can I trust anything that uses dangerous tools?” This time the answer