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 gol
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 m
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?
>
> // initial
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 UTC-
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
(https://github.com/golang/go/issue
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 t
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 integers
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. W
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 = make(
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 subscrib
Ah, I should update that I don't really maintain this any longer since
there are better tools these days. The best of which I've found is xgo
(which supports cgo): https://github.com/karalabe/xgo
On Mon, Jan 9, 2017 at 1:16 PM, Dave Mazzoni wrote:
> This looked really nice, but I'm having proble
Unless you're using a 64bit atomic on a 32 bit platform, there is nothing to
worry about.
--
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..
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 bool
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 answe
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
> net/timeout_test.go but little
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
https://github.co
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 really really large
On Mon, Jan 9, 2017 at 9:00 AM, wrote:
> 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 packag
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 th
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
p
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 b
Hi,
I've been using the Go fonts (in p9p acme) for a week now, and so far I
kind of like it, so thanks for making it.
Anyway, I've just noticed this error message in the terminal from which I
launched acme, so I assume acme is the one complaining about it, but I
haven't dug any deeper.
"stringwi
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 r
Thanks for your caution. Then is there a way to know that a certain
variable is aligned properly? Will the compiler make the global variable
`var p *int` in my sample code aligned properly?
在 2017年1月9日星期一 UTC+8上午3:17:37，Dave Cheney写道：
>
> What you are talking about is called a torn write, which
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 sync/a
Yes, I think you are right about the case in my sample code. The code
doesn't show exactly what I'm concerned about. I just wanna know whether a
write to a global pointer in 64-bit machine an atomic operation or not.
在 2017年1月9日星期一 UTC+8上午6:22:12，Caleb Doxsey写道：
>
> Shouldn't this particular cas
Yes, the author of that post is also me : )
在 2017年1月9日星期一 UTC+8下午6:30:59，Konstantin Khomoutov写道：
>
> On Sun, 8 Jan 2017 01:22:59 -0800 (PST)
> 陈诚 > wrote:
>
> > Is the size of a pointer value 32 bits or 64 bits in golang when
> > build with `GOARCH=amd64` option specified and running on 64-bit
Thanks for the responses.
I took a look at the generated code and go-bindata does in fact use the
form "var _data = []byte(`my giant string`)".
But there's something strange happening: I can't reproduce the problem
on my Macbook Pro. It compiles just fine here.
On Mon, Jan 9, 2017, at 12:5
On Sun, 8 Jan 2017 01:22:59 -0800 (PST)
陈诚 wrote:
> Is the size of a pointer value 32 bits or 64 bits in golang when
> build with `GOARCH=amd64` option specified and running on 64-bit OS?
[...]
Isn't it http://stackoverflow.com/q/41531337/720999 ?
--
You received this message because you are s
32 matches
Mail list logo
