[go-nuts] Re: not available from my location when I run git mail to submit a patch.
Use a proxy fix it. On Wednesday, September 28, 2016 at 11:25:31 PM UTC+8, Peng Gao wrote: > > I just make a path and want to push it, I got this error > > git mail > fatal: remote error: Access Denied (not available from your location) > (running: git push -q origin HEAD:refs/for/master) > git-codereview: exit status 128 > > what's the reason? > -- 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.google.com/d/optout.
[go-nuts] not available from my location when I run git mail to submit a patch.
I just make a path and want to push it, I got this error git mail fatal: remote error: Access Denied (not available from your location) (running: git push -q origin HEAD:refs/for/master) git-codereview: exit status 128 what's the reason? -- 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.google.com/d/optout.
[go-nuts] Re: Calling a Go function from asm ("fatal error: missing stackmap")
On Tuesday, September 20, 2016 at 11:00:34 AM UTC+8, Peng Gao wrote: > > BTW in your test file, you can directly append your bytes slice. > b1 = append(b1, vs...) > and slicesEqual is redundant, bytes.Equal does test the length of two > arguments > I mix up cap and len, just ignore it. > > On Tuesday, September 20, 2016 at 6:56:55 AM UTC+8, Caleb Spare wrote: >> >> I'm trying to call a Go function from asm and I'm having trouble figuring >> out the details. >> >> (In the past I've always endeavored to avoid this situation and make all >> my asm functions be leaf functions, but in my current use case it would be >> most helpful to be able to call a Go helper.) >> >> See the demo code at >> https://github.com/cespare/misc/tree/master/asm/stackmap or go get >> github.com/cespare/misc/asm/stackmap. >> >> For >> the >> demo, I have a small function with an append-style API: >> >> func X(b []byte) []byte >> >> This calls a Go helper growSlice. >> >> This code sometimes works, but if I run `go test -count 1000` I'll >> quickly see >> >> runtime: frame github.com/cespare/misc/asm/stackmap.X untyped locals >> 0xc420042bf8+0x30 >> fatal error: missing stackmap >> ... >> >> I've read through the Runtime Coordination section of the >> asm >> walkthrough (https://golang.org/doc/asm#runtime) several times, but I >> don't see the problem. >> >> Here is my understanding of a few relevant bits of that section (which >> might be incorrect): >> >> If the results will hold live pointers during a call instruction, the >>> function should start by zeroing the results and then executing the >>> pseudo-instruction GO_RESULTS_INITIALIZED. >> >> >> This doesn't seem to apply to my code because the results aren't >> populated until after the CALL. >> >> If a function has no local stack frame, the pointer information can be >>> omitted. This is indicated by a local frame size annotation of $0-n on the >>> TEXT instruction. The pointer information can also be omitted if the >>> function contains no call instructions. Otherwise, the local stack frame >>> must not contain pointers, and the assembly must confirm this fact by >>> executing the pseudo-instruction NO_LOCAL_POINTERS. >> >> >> My function makes a CALL with arguments. But it has to have a pointer >> (the slice) on the local stack frame in order to pass to that helper. I >> don't really understand what this section means. >> >> `go vet` doesn't say anything about my code. >> >> Any ideas? >> >> Thanks! >> Caleb >> > -- 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.google.com/d/optout.
[go-nuts] Re: Calling a Go function from asm ("fatal error: missing stackmap")
BTW in your test file, you can directly append your bytes slice. b1 = append(b1, vs...) and slicesEqual is redundant, bytes.Equal does test the length of two arguments. On Tuesday, September 20, 2016 at 6:56:55 AM UTC+8, Caleb Spare wrote: > > I'm trying to call a Go function from asm and I'm having trouble figuring > out the details. > > (In the past I've always endeavored to avoid this situation and make all > my asm functions be leaf functions, but in my current use case it would be > most helpful to be able to call a Go helper.) > > See the demo code at > https://github.com/cespare/misc/tree/master/asm/stackmap or go get > github.com/cespare/misc/asm/stackmap. > > For > the > demo, I have a small function with an append-style API: > > func X(b []byte) []byte > > This calls a Go helper growSlice. > > This code sometimes works, but if I run `go test -count 1000` I'll quickly > see > > runtime: frame github.com/cespare/misc/asm/stackmap.X untyped locals > 0xc420042bf8+0x30 > fatal error: missing stackmap > ... > > I've read through the Runtime Coordination section of the > asm > walkthrough (https://golang.org/doc/asm#runtime) several times, but I > don't see the problem. > > Here is my understanding of a few relevant bits of that section (which > might be incorrect): > > If the results will hold live pointers during a call instruction, the >> function should start by zeroing the results and then executing the >> pseudo-instruction GO_RESULTS_INITIALIZED. > > > This doesn't seem to apply to my code because the results aren't populated > until after the CALL. > > If a function has no local stack frame, the pointer information can be >> omitted. This is indicated by a local frame size annotation of $0-n on the >> TEXT instruction. The pointer information can also be omitted if the >> function contains no call instructions. Otherwise, the local stack frame >> must not contain pointers, and the assembly must confirm this fact by >> executing the pseudo-instruction NO_LOCAL_POINTERS. > > > My function makes a CALL with arguments. But it has to have a pointer > (the slice) on the local stack frame in order to pass to that helper. I > don't really understand what this section means. > > `go vet` doesn't say anything about my code. > > Any ideas? > > Thanks! > Caleb > -- 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.google.com/d/optout.