Re: [go-nuts] Reset Slice with Make Every Time?

2017-01-09 Thread Chetan Gowda
Old data remains as it is in the existing allocation. It will be overwritten as you fill up the slice again. -- 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

Re: [go-nuts] Reset Slice with Make Every Time?

2017-01-09 Thread Tomi Häsä
By the way, what happens to the old data I used with the previous make command? On Tuesday, January 10, 2017 at 1:49:37 AM UTC+2, kortschak wrote: > > On Mon, 2017-01-09 at 15:12 -0800, Tomi Häsä wrote: > > Is this the correct way of resetting a slice? I mean do I always need > > to > > use

[go-nuts] Re: Reset Slice with Make Every Time?

2017-01-09 Thread Craig Donnelly
Quick search of the group would help you out.. https://groups.google.com/d/msg/golang-nuts/KLpMGMmO_xw/m0Lpgd8ZzQQJ On Monday, 9 January 2017 23:12:35 UTC, Tomi Häsä wrote: > > Is this the correct way of resetting a slice? I mean do I always need to > use make to reset a slice? > > //

[go-nuts] Re: bit twiddling API survey

2017-01-09 Thread mark
I haven't personally experienced a need for a bit twiddling API, but if you're looking for other interesting operations, you might want to check out the awesome-bits curated list of bitwise operations [1]. [1] https://github.com/keonkim/awesome-bits On Monday, January 9, 2017 at 3:46:45 PM

Re: [go-nuts] bit twiddling API survey

2017-01-09 Thread Caleb Spare
Hi! This is great stuff. I've written a few asm loops in order to use bit-twiddling instructions. The ones you listed cover all of those. One other thing to consider is rotate. The compiler does a good job of recognizing constant rotates and it's getting better

Re: [go-nuts] Documenting Interfaces

2017-01-09 Thread 'Chris Manghane' via golang-nuts
It seems like you would need to do both, at least eventually. I'm not sure why you're saying that you will end up copy-pasting the comments; it seems like each implementation would have something particular about it that would change the documentation. For example, io.Reader must be documented at

Re: [go-nuts] Reset Slice with Make Every Time?

2017-01-09 Thread Dan Kortschak
On Mon, 2017-01-09 at 15:12 -0800, Tomi Häsä wrote: > Is this the correct way of resetting a slice? I mean do I always need > to  > use make to reset a slice? > > // initialize slice > > onearea Area = Area{} > > group []Area = make( []Area, 0, MAX ) > > // add stuff to slice >

[go-nuts] bit twiddling API survey

2017-01-09 Thread mosoi via golang-nuts
Hello! I'm working on a proposal for a compiler/hardware supported bittwidling API. See discussion at https://github.com/golang/go/issues/17373. The current set of functions I have in mind are: count trailing zeros, count leading zeros, byte swap and population count for 32 and 64 bits

[go-nuts] Documenting Interfaces

2017-01-09 Thread Nathan Morley
Hey all, I have a brief question on the "best practices" for documenting Go code. I did a quick sweep through the official blog as well as the Effective Go article, but found no answer as of yet... Let's say I have an interface like a database driver that gets implemented in multiple places.

[go-nuts] Reset Slice with Make Every Time?

2017-01-09 Thread Tomi Häsä
Is this the correct way of resetting a slice? I mean do I always need to use make to reset a slice? // initialize slice onearea Area = Area{} group []Area = make( []Area, 0, MAX ) // add stuff to slice group = append( group, onearea ) // reset slice group =

[go-nuts] Client-side support for HTTP/2 Push?

2017-01-09 Thread David Glasser
I'm aware that Go 1.8 will support server-side support for HTTP/2 server push. Is there any support for reacting to server push in the HTTP/2 client? I'm specifically curious about proxying them with net/http/httputil's ReverseProxy. --dave -- You received this message because you are

Re: [go-nuts] Cross-linking cgo

2017-01-09 Thread Dave Mazzoni
This looked really nice, but I'm having problems with it: go get github.com/mitchellh/gox (no problem) go get github.com/inconshreveable/gonative # github.com/inconshreveable/gonative Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:67: cannot use "" (type string) as type

[go-nuts] Re: error message with Go fonts

2017-01-09 Thread Rob Pike
That's a sign that your .font file is wrong, for instance that it contains a loop or hole in its definition. In particular it's about the textual Plan 9 font file, not the subfont images. But it should be easy to figure out: where does rune U+ map to, according to the font? I suspect the

Re: [go-nuts] When should (or shouldn't) I use (*testing.T).Parallel()?

2017-01-09 Thread Ian Lance Taylor
On Mon, Jan 9, 2017 at 8:22 AM, wrote: > The godoc for (*testing.T).Parallel() only says: > >> Parallel signals that this test is to be run in parallel with (and only >> with) other parallel tests. > > Searching for "t.Parallel()" on golang.org shows some usage in >

Re: [go-nuts] Compiling a really really large package

2017-01-09 Thread chad . retz
In my case, many of the functions are very small (many only a single line that I'm hoping will be inlined). This is a transpiler from another language (Java) akin to Grumpy (Python) and many of the functions are single-line dispatch methods to support OOP. The transpiler is at

Re: [go-nuts] Compiling a really really large package

2017-01-09 Thread 'Than McIntosh' via golang-nuts
One thing to keep in mind: generated-code compilation time issues can sometimes be due to a large function (or functions) as opposed just the total volume of code in the package. For example, https://github.com/golang/go/issues/16407 demonstrates a compile-time problem that sounds a bit like what

Re: [go-nuts] Compiling a really really large package

2017-01-09 Thread chad . retz
It does matter for my use case, but not for these first steps. Thanks. I think still, practically, I need to reduce the code size unfortunately. On Monday, January 9, 2017 at 12:24:36 PM UTC-6, Ian Lance Taylor wrote: > > On Mon, Jan 9, 2017 at 9:00 AM, wrote: > > I have a

[go-nuts] Re: Any parsers exist for go 1.5 heap dumps?

2017-01-09 Thread happyfeet . sak
I am also in same position. Did you find or wrote anything? On Wednesday, September 16, 2015 at 6:05:49 PM UTC+5:30, Jack wrote: > > Hi, > > I'm trying to debug a memory leak. While pprof can tell me where the > memory was allocated, it cannot tell me who owns the pointer to the memory. > I

Re: [go-nuts] Google Grumpy (Python->Go)

2017-01-09 Thread trotterdylan
Cross posting to grumpy-users On Thursday, 5 January 2017 00:42:31 UTC-8, Justin Israel wrote: > > I just gave this a play since I was really curious what it could do. But > it seems like of your python module has imports for other python modules, > they get transpiled into Go import statements

[go-nuts] Compiling a really really large package

2017-01-09 Thread chad . retz
I have a really really large package of code that was generated via a code generator. Granted the main code that references it I expect to remove a lot via DCE or something so the binaries wouldn't be extreme. The code is > 140MB in the single package which I know sounds extreme. Let's ignore

[go-nuts] When should (or shouldn't) I use (*testing.T).Parallel()?

2017-01-09 Thread mark
The godoc for (*testing.T).Parallel() only says: > Parallel signals that this test is to be run in parallel with (and only with) other parallel tests. Searching for "t.Parallel()" on golang.org shows some usage in net/timeout_test.go but little use elsewhere. I would guess t.Parallel() would

Re: [go-nuts] Re: A question about the atomic operations in golang

2017-01-09 Thread 'Axel Wagner' via golang-nuts
The only guarantees made in regards to alignment are the ones outlined here: https://golang.org/ref/spec#Size_and_alignment_guarantees >From what I can tell, there is no such guarantee. But why do you care, specifically? Using the sync/atomic package will handle this correctly in every case. This

Re: [go-nuts] Re: A question about the atomic operations in golang

2017-01-09 Thread 'Axel Wagner' via golang-nuts
The answer (like with virtually all questions like this on golang-nuts) is: Possibly, but you can not rely on it. Assuming that it is might break your program now or at a non-specific future date or on a non-specific current or future processor. If you need atomic operations, please use the