Re: [go-nuts] go runtime/stubs.go noescape

[Kevin Malachowski]

I believe the question was about the specific implementation of noescape, 
specifically the "exclusive or" in that unsafe expression.

To the original poster: are you just curious why, or is there a more specific 
question you have? I'm assuming that function looks like that to correctly 
trick the compiler; perhaps escape analysis gives up if you start xor-ing 
uintptr values or something like that.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2f2b4f8d-1218-4a12-adf1-34e8b4d63648%40googlegroups.com.

Re: [go-nuts] go runtime/stubs.go noescape

[Ian Lance Taylor]

On Sat, Oct 12, 2019 at 1:47 AM tokers  wrote:
>
> Recently I read some go source code and when I read the noescape function in 
> runtime/stubs.go, I have a doubt about it.
>
> // noescape hides a pointer from escape analysis.  noescape is
> // the identity function but escape analysis doesn't think the
> // output depends on the input.  noescape is inlined and currently
> // compiles down to zero instructions.
> // USE CAREFULLY!
> //go:nosplit
> func noescape(p unsafe.Pointer) unsafe.Pointer {
>x := uintptr(p)
>return unsafe.Pointer(x ^ 0)
> }
>
>
>
> I don't know what's the purpose of the exclusive or operation? Does it 
> necessary?

The function comment seems clear.  Can you be more specific about your question?

This is necessary because sometimes the runtime needs to not allocate
a value that would otherwise be allocated.  For example, the runtime
includes the implementation of the heap allocator, and clearly that
implementation cannot itself allocate anything.  The noescape function
is used where allocation would otherwise occur, to ensure that it does
not actually allocate.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXf9mUbXfHrOa%2BmORh0pZ%3DOGmKsRsE8edze%2B19tcWh_kA%40mail.gmail.com.

[go-nuts] Re: [security] Go 1.13.2 and Go 1.12.11 pre-announcement

[Katie Hockman]

Hello gophers,

As an update, the security releases of Go 1.13.2 and Go 1.12.11 have been
moved to *Thursday, October 17*.
We will use the extra time to ensure the fixes are complete and correct.
Sorry for the inconvenience.

Cheers,
Katie on behalf of the Go team

On Fri, Oct 11, 2019 at 5:21 PM Katie Hockman  wrote:

> Hello gophers,
>
> We plan to issue Go 1.13.2 and Go 1.12.11 on Wednesday, October 16.
> These are minor releases to fix security issues.
>
> Following our policy at https://golang.org/security,
> this is the pre-announcement of those releases.
>
> Cheers,
> Katie on behalf of the Go team
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALvTBvdQ3J0E9CyGm8Nv4wmXPOAspgp22VpdMTsWo1_jiOAMsw%40mail.gmail.com.

[go-nuts] Re: Compile Go application with multiple versions of C library

[Igor Maznitsa]

thats possible use preprocessing with golang too, but through some 
extra-tools, like maven-golang, example 


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fcf53518-3357-48b1-a399-67e803314ca9%40googlegroups.com.

[go-nuts] Re: go module & local package

[Igor Maznitsa]

mvn-golang  also allows make 
multi-module go projects with locally situated modules, but it works 
through maven 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dfcfca7c-6196-4e3b-96b9-915b07f5ab19%40googlegroups.com.

Re: [go-nuts] Re: random errors after upgrade to Go1.12 + MacOS High Sierra

[Ulderico Cirello]

the following minor released had this problem fixed. consider upgrading to
the latest version, please.

https://dl.google.com/go/go1.13.1.darwin-amd64.pkg

- ccf


On Tue, Oct 15, 2019 at 7:36 AM  wrote:

> I also have this problem, has you solved?
>
> 在 2019年2月27日星期三 UTC+8上午5:10:21，Ulderico写道：
>>
>> Hi,
>>
>>
>> A colleague of mine is getting random errors after upgrading to Go 1.12
>> in High Sierra, he would see among the errors these:
>>
>> svc.0   : fatal error: sync: inconsistent mutex state
>> svc.0   :
>> svc.0   : goroutine 138 [running]:
>> svc.0   : runtime.throw(0x5862926, 0x1e)
>> svc.0   : /usr/local/go/src/runtime/panic.go:617 +0x72
>> fp=0xc001079fa8 sp=0xc001079f78 pc=0x402f422
>> svc.0   : sync.throw(0x5862926, 0x1e)
>> svc.0   : /usr/local/go/src/runtime/panic.go:603 +0x35
>> fp=0xc001079fc8 sp=0xc001079fa8 pc=0x402f3a5
>> svc.0   : sync.(*Mutex).Lock(0xc00045ace0)
>> svc.0   : /usr/local/go/src/sync/mutex.go:143 +0x15b
>> fp=0xc00107a008 sp=0xc001079fc8 pc=0x40740db
>> svc.0   : sync.(*Once).Do(0xc00045ace0, 0xc00107a048)
>> svc.0   : /usr/local/go/src/sync/once.go:40 +0x3b
>> fp=0xc00107a038 sp=0xc00107a008 pc=0x407435b
>> (this first seems to be a encapsulated sync.Once
>> var releaseOnce sync.Once
>> lockRelease := func() { releaseOnce.Do(func() { lock.Release() })
>> }
>> defer lockRelease()
>> )
>>
>> And
>>
>> svc.0   : runtime: nelems=170 nalloc=86 previous
>> allocCount=85 nfreed=65535
>> svc.0   : fatal error: sweep increased allocation count
>> svc.0   :
>> svc.0   : goroutine 18 [running]:
>> svc.0   : runtime.throw(0x58677ea, 0x20)
>> svc.0   : /usr/local/go/src/runtime/panic.go:617 +0x72
>> fp=0xc68660 sp=0xc68630 pc=0x402f422
>> svc.0   : runtime.(*mspan).sweep(0xb2a5190, 0xca2000,
>> 0x4059200)
>> svc.0   : /usr/local/go/src/runtime/mgcsweep.go:329
>> +0x8da fp=0xc68740 sp=0xc68660 pc=0x402427a
>> svc.0   : runtime.sweepone(0x5909220)
>> svc.0   : /usr/local/go/src/runtime/mgcsweep.go:136
>> +0x26e fp=0xc687a8 sp=0xc68740 pc=0x402374e
>> svc.0   : runtime.bgsweep(0xca2000)
>> svc.0   : /usr/local/go/src/runtime/mgcsweep.go:73 +0xbb
>> fp=0xc687d8 sp=0xc687a8 pc=0x402342b
>> svc.0   : runtime.goexit()
>> svc.0   : /usr/local/go/src/runtime/asm_amd64.s:1337 +0x1
>> fp=0xc687e0 sp=0xc687d8 pc=0x405e671
>> svc.0   : created by runtime.gcenable
>> svc.0   : /usr/local/go/src/runtime/mgc.go:208 +0x58
>>
>> (we couldn't trace this one to any particular part of the code)
>>
>> Has anyone been affected by these problems too?
>>
>>
>> Thanks
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/Cw-bG87Fvyc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5ae38210-bdf0-4331-922d-80bb3a4416c4%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALe9M7kcf1DBfXv-tLeY12FwaPsfHb1ap%3DusSULgtXKEMZwLqA%40mail.gmail.com.

[go-nuts] Re: random errors after upgrade to Go1.12 + MacOS High Sierra

[minxinping0105]

I also have this problem, has you solved? 

在 2019年2月27日星期三 UTC+8上午5:10:21，Ulderico写道：
>
> Hi,
>
>
> A colleague of mine is getting random errors after upgrading to Go 1.12 in 
> High Sierra, he would see among the errors these:
>
> svc.0   : fatal error: sync: inconsistent mutex state
> svc.0   : 
> svc.0   : goroutine 138 [running]:
> svc.0   : runtime.throw(0x5862926, 0x1e)
> svc.0   : /usr/local/go/src/runtime/panic.go:617 +0x72 
> fp=0xc001079fa8 sp=0xc001079f78 pc=0x402f422
> svc.0   : sync.throw(0x5862926, 0x1e)
> svc.0   : /usr/local/go/src/runtime/panic.go:603 +0x35 
> fp=0xc001079fc8 sp=0xc001079fa8 pc=0x402f3a5
> svc.0   : sync.(*Mutex).Lock(0xc00045ace0)
> svc.0   : /usr/local/go/src/sync/mutex.go:143 +0x15b 
> fp=0xc00107a008 sp=0xc001079fc8 pc=0x40740db
> svc.0   : sync.(*Once).Do(0xc00045ace0, 0xc00107a048)
> svc.0   : /usr/local/go/src/sync/once.go:40 +0x3b 
> fp=0xc00107a038 sp=0xc00107a008 pc=0x407435b
> (this first seems to be a encapsulated sync.Once
> var releaseOnce sync.Once
> lockRelease := func() { releaseOnce.Do(func() { lock.Release() }) }
> defer lockRelease()
> )
>
> And
>
> svc.0   : runtime: nelems=170 nalloc=86 previous allocCount=85 
> nfreed=65535
> svc.0   : fatal error: sweep increased allocation count
> svc.0   : 
> svc.0   : goroutine 18 [running]:
> svc.0   : runtime.throw(0x58677ea, 0x20)
> svc.0   : /usr/local/go/src/runtime/panic.go:617 +0x72 
> fp=0xc68660 sp=0xc68630 pc=0x402f422
> svc.0   : runtime.(*mspan).sweep(0xb2a5190, 0xca2000, 
> 0x4059200)
> svc.0   : /usr/local/go/src/runtime/mgcsweep.go:329 +0x8da 
> fp=0xc68740 sp=0xc68660 pc=0x402427a
> svc.0   : runtime.sweepone(0x5909220)
> svc.0   : /usr/local/go/src/runtime/mgcsweep.go:136 +0x26e 
> fp=0xc687a8 sp=0xc68740 pc=0x402374e
> svc.0   : runtime.bgsweep(0xca2000)
> svc.0   : /usr/local/go/src/runtime/mgcsweep.go:73 +0xbb 
> fp=0xc687d8 sp=0xc687a8 pc=0x402342b
> svc.0   : runtime.goexit()
> svc.0   : /usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 
> fp=0xc687e0 sp=0xc687d8 pc=0x405e671
> svc.0   : created by runtime.gcenable
> svc.0   : /usr/local/go/src/runtime/mgc.go:208 +0x58
>
> (we couldn't trace this one to any particular part of the code)
>
> Has anyone been affected by these problems too?
>
>
> Thanks
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5ae38210-bdf0-4331-922d-80bb3a4416c4%40googlegroups.com.

Re: [go-nuts] [syscall_linux,go] doesn't have Ptrace API support for ARM64 architecture

[Ian Lance Taylor]

On Tue, Oct 15, 2019 at 5:53 AM  wrote:
>
> I am working on delve (go debugger)  to provide support for ARM64 platform 
> but  syscall_linux,go doesn't support ARM64 platform.
> for getting reg values through Ptrace, we added following code in 
> syscall_linux,go ..
>
> ptrace(PTRACE_GETREGSET, pid, uintptr(elf.NT_PRSTATUS), 
> uintptr(unsafe.Pointer(&iovec)))
>
>
> can anyone suggest if i need to add support for ARM64 or is there any other 
> method to get DWARF values on ARM64 platform ..

The syscall package is more or less frozen.  Look at
golang.org/x/sys/unix instead, which does have the function
PtraceGetRegsArm64.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU1_UUCPcyUewR5bmtxaGDGZcwCusO8HXAtSbiOh0j65A%40mail.gmail.com.

[go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Stuart Davies]

Thanks.

The copy command was the thing I missed. It does exactly what I need and I 
can control the extension of the backing array with fine detail.

I assume the copy command is implemented efficiently but even if it just 
loops it is a packaged process and will have been optomised by the Go devs 
so it is as good as I am likly to get.

Thanks all for your help :-)

On Tuesday, 15 October 2019 11:16:35 UTC+1, Stuart Davies wrote:
>
> Hi 
>
> I have a slice backed by an array. 
>
> My understanding is that I can extend the slice (append)  up to the 
> capacity of the array. 
>
> After that I do not understand the correct procedure. Append fails when 
> the backing array indexes are exceeded.
>
> So I have this temporary piece of code:
> if p.LineCount >= len(p.Offsets) {
> newLen := p.LineCount + 50
> sb := make([]int64, newLen)
> for i := 0; i < p.LineCount; i++ {
> sb[i] = p.Offsets[i]
> }
> p.Offsets = sb
> }
>
> I know there must be an array copy function that will do this more 
> efficiently but I failed to find it!
>
> Please help.
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f9d99d10-fca2-48c7-ae83-f42595206dbd%40googlegroups.com.

[go-nuts] Re: go 1.13.1 (linux x64): Build and Test is slower.

[Stuart Davies]

Ok I will just get on with it. I am not is a position to compare 
performance when there are so many variables.

I thought others might have had the same issue and there might be a simple 
explanation. 

We can close this discussion.

On Tuesday, 15 October 2019 12:07:11 UTC+1, Stuart Davies wrote:
>
> Hi. 
>
> I use a low spec laptop that I take with me so I can work/play in the 
> coffee shop!
>
> Since upgrading go to 1.13 I have noticed a significant slow down (2 to 3 
> times) in build and build for test especially when debugging. 
>
> It is still fast compared to other languages I use but I was sooo 
> impressed by the build times previously that I am very concious of the 
> slower performance. 
>
> I am using VSCode ar an IDE and have made sure I am up to date with all 
> the tools.
>
> I am using modules as well so perhaps this is the issue but all my code is 
> local and I have a 'replace' in the go.mod file. 
>
> My project is outside GOPATH directory but GOPATH is still defined.
>
> Is ther esomthing I can do to restore the performance of is this 
> 'Progress' and I will just have to et usd to it.
>
> Please keep up the good work. Go is the first language for years that I 
> felt I could invest time in. As a Java dev for many years and the 
> frustrations that brings, Go is a refreshing change. 
> Please keep the language simple and dont get dragged in to the me-too 
> feature debate. Go is a really great language already..
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/74160604-9847-469c-b0e2-eaf23e7071a3%40googlegroups.com.

Re: [go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Marvin Renich]

* thatipelli santhosh  [191015 08:07]:
> Hi Marvin,
> 
> I am curious to know if we approx 10 ( we don't know exact amount of
> slice entries)  add to slice.  Slice will grow based on our size of data
> and underlying array size but doing this create multiple underlying arrays
> (more memory resource utilization, processing). In such case,  what is the
> optimum solution?

The built-in append function does not simply allocate a new backing
array with the exact size needed for the new slice; it allocates a slice
with extra capacity.  It uses some heuristics to give a reasonable
speed/memory-usage trade-off for "typical" cases.  The current algorithm
can be found in src/runtime/slice.go in the function growslice.  Note
that the specific algorithm is not covered by the Go compatibility
guarantee.

If you are trying to be practical, you should start by implementing the
obvious and straight-forward algorithm first (i.e. use append as it was
intended), and then profile your code (the whole application, not just
the code that grows the slice) to determine where optimization will be
useful.  It is very unlikely that the calls to append will be worth
spending time improving.

If this is an academic question, start the same way, but how you decide
where to spend time analyzing the results may be different.

In an application that is only going to have a slice of about 100,000
integers, the cost of append is unlikely to be of any concern at all on
any real production machine.

If it turns out that the append is a bottleneck (memory or speed), you
can write your own Append function by starting with the AppendByte
function from the go-slices-usage-and-internals blog that I linked to in
my previous message.  Do the obvious fix-ups for byte to int (or
whatever your data type is), and modify the algorithm that determines
the capacity of the new slice (the (n+1)*2 in that function).  Then use
your Append function instead of the built-in append.  (Again, note that
this simple (n+1)*2 is _not_ what the built-in append function uses.)

A very simple first optimization (without resorting to your own Append
function) is to initially create the slice using make([]int, 0,
initialCapacity) where you choose initialCapacity to be larger than the
expected maximum size by some arbitrary percentage (e.g. 25%).

This playground link «https://play.golang.org/p/qtfHaoK-6Hy» shows
exactly where the allocations will occur.  It took exactly 28
allocations to reach 100,000 elements.  To show how insignificant that
is, on my laptop it took only 11ms to run that program.  Is that 11ms
really significant in your program?

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191015141236.rldnk7dscbio6pfs%40basil.wdw.

[go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Stuart Davies]

Ok I will have a rethink. 

Is there a way I can control the expansion. I do not want to double the 
storage each time. I want to be able to control and limit the growth if 
necessary.

Thanks for the assistance. I will re-read the article.

On Tuesday, 15 October 2019 11:16:35 UTC+1, Stuart Davies wrote:
>
> Hi 
>
> I have a slice backed by an array. 
>
> My understanding is that I can extend the slice (append)  up to the 
> capacity of the array. 
>
> After that I do not understand the correct procedure. Append fails when 
> the backing array indexes are exceeded.
>
> So I have this temporary piece of code:
> if p.LineCount >= len(p.Offsets) {
> newLen := p.LineCount + 50
> sb := make([]int64, newLen)
> for i := 0; i < p.LineCount; i++ {
> sb[i] = p.Offsets[i]
> }
> p.Offsets = sb
> }
>
> I know there must be an array copy function that will do this more 
> efficiently but I failed to find it!
>
> Please help.
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f4c93ab7-2024-4bd8-8768-2f3744836cc3%40googlegroups.com.

[go-nuts] [syscall_linux,go] doesn't have Ptrace API support for ARM64 architecture

[ossdev]

Hi,

I am working on* delve (go debugger)*  to provide support for ARM64 
platform but  syscall_linux,go doesn't support ARM64 platform.
for getting reg values through Ptrace, we added following code 
in syscall_linux,go ..

ptrace(PTRACE_GETREGSET, pid, uintptr(elf.NT_PRSTATUS), 
uintptr(unsafe.Pointer(&iovec)))


can anyone suggest if i need to add support for ARM64 or is there any other 
method to get DWARF values on ARM64 platform ..


-- 


*Disclaimer* -The information transmitted is intended solely for the 
individual
or entity to which it is addressed and may contain confidential 
and/or
privileged material. Any review, re-transmission, dissemination or 
other use of
or taking action in reliance upon this information by persons 
or entities other
than the intended recipient is prohibited. If you have 
received this email in
error please contact the sender and delete the 
material from any computer. In
such instances you are further prohibited 
from reproducing, disclosing,
distributing or taking any action in reliance 
on it.As a recipient of this email,
you are responsible for screening its 
contents and the contents of any
attachments for the presence of viruses. 
No liability is accepted for any
damages caused by any virus transmitted by 
this email.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8a2a8cb9-2be8-42d8-9cb3-1e85600aa6fe%40googlegroups.com.

Re: [go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[thatipelli santhosh]

Hi Marvin,

I am curious to know if we approx 10 ( we don't know exact amount of
slice entries)  add to slice.  Slice will grow based on our size of data
and underlying array size but doing this create multiple underlying arrays
(more memory resource utilization, processing). In such case,  what is the
optimum solution?

On Tue, Oct 15, 2019, 17:22 Marvin Renich  wrote:

> [When you are replying to someone else's message, reply to that message,
> not your original message.  Your reply lost the context of the message
> to which you were replying (Jan Mercl's).]
>
> * Stuart Davies  [191015 07:24]:
> > My goal is to contain a list of integers that may extend to possibly a
> > couple of thousand entries. Initial size is 100. Extensions add 50
> entries
> > at a time.
> >
> > I declared the array initially with:
> >
> > make([]int64, 100).
> >
> > I tried using the Append function but could not Append past the 100
> > entries. The 101 entry threw a panic so I detirmined to extend the array
> > myself.
> >
> > I would have thought Append should extend if required but it did not (or
> am
> > I using it incorrectly). I looked at some other code examples but could
> not
> > find a solution.
> >
> > In C there is an array copy function that is implemented by the
> processor
> > directly, it's been a long time since I used C and assembler but I
> rememer
> > there were non overlapping mem copy instructions that would make an
> array
> > copy very fast.
> >
> > Is there somthing similar in GO.
> >
> > This is a general question, it is not really specific to my application.
> I
> > just want to know the best practices for 'extending' an array of
> arbitrary
> > type.
>
> The append function should do exactly what you want, but you must use it
> properly.  There is a good explanation of slices on the Go blog at
> «https://blog.golang.org/go-slices-usage-and-internals».  The builtin
> append function will append to the existing backing array if there is
> enough capacity, but will allocate a new backing array if necessary.
> Because of this, it always returns the new slice, and you must use the
> returned slice, rather than the original.  Here is a playground link
> demonstrating the use of append:
> «https://play.golang.org/p/5Pl16hN-T5u».
>
> ...Marvin
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20191015115219.dca3mjcdj54qxslq%40basil.wdw
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN1Sb7w%2BXKLXmRrzS4biZTvZJ-eTbtWR8DOGfzdfp13S2%3Dx%3D3w%40mail.gmail.com.

Re: [go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Marvin Renich]

P.S. If you are still having trouble after reading the responses to your
query, use the go playground (https://play.golang.org/) to create a
simple program that demonstrates what you are trying, and post the link
you get from clicking the "Share" button, and explain what you would
like the output to be.  People can then modify your playground entry to
help you.

Note that when passing slices to other functions that might modify the
slice, you either need to return the modified slice or pass a pointer to
the slice.  This is why the append function is the way it is.

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191015120406.532esrartpryiw6k%40basil.wdw.

[go-nuts] Re: question about runtime design

[awh6al]

Thank's ian.

On Monday, October 14, 2019 at 1:53:23 PM UTC+1, Awhb Bal wrote:
>
> salam. Hi gophers can any one take a look at at this snippet of code 
> https://play.golang.org/p/qv0N0EN81tX 
> and answer me why should this panic at runtime, and why the compiler 
> does not catch this kind of mistakes.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ebf0dcb4-db05-4169-9488-3b065d2be3a7%40googlegroups.com.

Re: [go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Marvin Renich]

[When you are replying to someone else's message, reply to that message,
not your original message.  Your reply lost the context of the message
to which you were replying (Jan Mercl's).]

* Stuart Davies  [191015 07:24]:
> My goal is to contain a list of integers that may extend to possibly a 
> couple of thousand entries. Initial size is 100. Extensions add 50 entries 
> at a time.
> 
> I declared the array initially with:
> 
> make([]int64, 100).
> 
> I tried using the Append function but could not Append past the 100 
> entries. The 101 entry threw a panic so I detirmined to extend the array 
> myself. 
> 
> I would have thought Append should extend if required but it did not (or am 
> I using it incorrectly). I looked at some other code examples but could not 
> find a solution.
> 
> In C there is an array copy function that is implemented by the processor 
> directly, it's been a long time since I used C and assembler but I rememer 
> there were non overlapping mem copy instructions that would make an array 
> copy very fast. 
> 
> Is there somthing similar in GO.
> 
> This is a general question, it is not really specific to my application. I 
> just want to know the best practices for 'extending' an array of arbitrary 
> type.

The append function should do exactly what you want, but you must use it
properly.  There is a good explanation of slices on the Go blog at
«https://blog.golang.org/go-slices-usage-and-internals».  The builtin
append function will append to the existing backing array if there is
enough capacity, but will allocate a new backing array if necessary.
Because of this, it always returns the new slice, and you must use the
returned slice, rather than the original.  Here is a playground link
demonstrating the use of append:
«https://play.golang.org/p/5Pl16hN-T5u».

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191015115219.dca3mjcdj54qxslq%40basil.wdw.

Re: [go-nuts] go 1.13.1 (linux x64): Build and Test is slower.

[Miguel Angel Rivera Notararigo]

Hello :) I think you need to give some samples of what you are doing
because without that the people that know about how to solve that problem
cant help you. Remember, there are a lot of factors that may increase the
building time, could you share at least something like time go build with
both versions (1.13 and 1.12)?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAF9DLCnGvi%3DT-Dkhe30Hhp8_evxvMYN5UYkAcVycn8xVY3%3Dduw%40mail.gmail.com.

Re: [go-nuts] Extending an array 'The right way'. Guidence needed!

[Wojciech S. Czarnecki]

On Tue, 15 Oct 2019 03:16:35 -0700 (PDT)
Stuart Davies  wrote:

Uh, the important citation got deleted somehow:
[...]

https://golang.org/ref/spec#Appending_and_copying_slices

"If the capacity of s is not large enough to fit the additional values,
append allocates a new, sufficiently large underlying array that fits both the
existing slice elements and the additional values.
Otherwise, append re-uses the underlying array. "

Correct use of append is to reassign the target array: 

target = append(target, toappend)

then append will take care of resizing/copying for you.

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191015134349.6148fb74%40zuzia.

Re: [go-nuts] Extending an array 'The right way'. Guidence needed!

[Wojciech S. Czarnecki]

On Tue, 15 Oct 2019 03:16:35 -0700 (PDT)
Stuart Davies  wrote:

> Hi 
> 
> I have a slice backed by an array. 
> 
> My understanding is that I can extend the slice (append)  up to the 
> capacity of the array.

Its good understanding.

> Append fails when the backing array indexes are exceeded.
"exceeded" means "over the capacity"  

> I know there must be an array copy function that will do this more 
> efficiently but I failed to find it!

It is a built-in function and is aptly named "copy": 

https://golang.org/ref/spec#Appending_and_copying_slices

> Please help.

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20191015133246.111bd096%40zuzia.

[go-nuts] Re: Extending an array 'The right way'. Guidence needed!

[Stuart Davies]

My goal is to contain a list of integers that may extend to possibly a 
couple of thousand entries. Initial size is 100. Extensions add 50 entries 
at a time.

I declared the array initially with:

make([]int64, 100).

I tried using the Append function but could not Append past the 100 
entries. The 101 entry threw a panic so I detirmined to extend the array 
myself. 

I would have thought Append should extend if required but it did not (or am 
I using it incorrectly). I looked at some other code examples but could not 
find a solution.

In C there is an array copy function that is implemented by the processor 
directly, it's been a long time since I used C and assembler but I rememer 
there were non overlapping mem copy instructions that would make an array 
copy very fast. 

Is there somthing similar in GO.

This is a general question, it is not really specific to my application. I 
just want to know the best practices for 'extending' an array of arbitrary 
type.

On Tuesday, 15 October 2019 11:16:35 UTC+1, Stuart Davies wrote:
>
> Hi 
>
> I have a slice backed by an array. 
>
> My understanding is that I can extend the slice (append)  up to the 
> capacity of the array. 
>
> After that I do not understand the correct procedure. Append fails when 
> the backing array indexes are exceeded.
>
> So I have this temporary piece of code:
> if p.LineCount >= len(p.Offsets) {
> newLen := p.LineCount + 50
> sb := make([]int64, newLen)
> for i := 0; i < p.LineCount; i++ {
> sb[i] = p.Offsets[i]
> }
> p.Offsets = sb
> }
>
> I know there must be an array copy function that will do this more 
> efficiently but I failed to find it!
>
> Please help.
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d50b9df8-121f-4f92-811d-463ec92776b0%40googlegroups.com.

[go-nuts] go 1.13.1 (linux x64): Build and Test is slower.

[Stuart Davies]

Hi. 

I use a low spec laptop that I take with me so I can work/play in the 
coffee shop!

Since upgrading go to 1.13 I have noticed a significant slow down (2 to 3 
times) in build and build for test especially when debugging. 

It is still fast compared to other languages I use but I was sooo impressed 
by the build times previously that I am very concious of the slower 
performance. 

I am using VSCode ar an IDE and have made sure I am up to date with all the 
tools.

I am using modules as well so perhaps this is the issue but all my code is 
local and I have a 'replace' in the go.mod file. 

My project is outside GOPATH directory but GOPATH is still defined.

Is ther esomthing I can do to restore the performance of is this 'Progress' 
and I will just have to et usd to it.

Please keep up the good work. Go is the first language for years that I 
felt I could invest time in. As a Java dev for many years and the 
frustrations that brings, Go is a refreshing change. 
Please keep the language simple and dont get dragged in to the me-too 
feature debate. Go is a really great language already..


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/14260cf5-2ccc-4fb3-9748-ada1939a9fa6%40googlegroups.com.

Re: [go-nuts] Extending an array 'The right way'. Guidence needed!

[Jan Mercl]

On Tue, Oct 15, 2019 at 12:16 PM Stuart Davies  wrote:

> I have a slice backed by an array.
>
> My understanding is that I can extend the slice (append)  up to the capacity 
> of the array.

I guess that by 'extend the slice' you mean reslicing. Yes, that can
be done while len <= cap. However, appending is a different operation,
performed by the predeclared function `append`.

Please let us know what is the ultimate goal you need to achieve. Best
is to share the minimal, compilable code you have already at the Go
playground: https://play.golang.org

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-ViG7%2Bk1UdDJ_mqCfw0_-fA%3DiDRvenHbajES65NjxGgdA%40mail.gmail.com.

[go-nuts] Extending an array 'The right way'. Guidence needed!

[Stuart Davies]

Hi 

I have a slice backed by an array. 

My understanding is that I can extend the slice (append)  up to the 
capacity of the array. 

After that I do not understand the correct procedure. Append fails when the 
backing array indexes are exceeded.

So I have this temporary piece of code:
if p.LineCount >= len(p.Offsets) {
newLen := p.LineCount + 50
sb := make([]int64, newLen)
for i := 0; i < p.LineCount; i++ {
sb[i] = p.Offsets[i]
}
p.Offsets = sb
}

I know there must be an array copy function that will do this more 
efficiently but I failed to find it!

Please help.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/626edeb6-db16-4549-ad4b-d086f9c4%40googlegroups.com.