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
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
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?
>
> //
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
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
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
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
>
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
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.
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 =
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
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
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
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
>
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo