Re: [go-nuts] Any non-split 'print' functions available?

[Aram Hăvărneanu]

For this type of thing I'd recommend a debugger.

-- 
Aram Hăvărneanu

-- 
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/CAEAzY38F9C1%3DYM-xnvOo9h9%2Bn8SQqyO52im%2BYWdsU4mvhCUYJw%40mail.gmail.com.

Re: [go-nuts] Automatically releasing memory resources allocated in cgo?

[Tom Payne]

Thank you very much for the fast, clear, and detailed answer :)

On Fri, 1 Nov 2019 at 15:08, Ian Lance Taylor  wrote:

> On Fri, Nov 1, 2019 at 6:31 AM Tom Payne  wrote:
> >
> > cgo is often used to provide bindings to C libraries. Any memory
> allocated in the C library is not visible to Go, so Go does not have an
> accurate view of the program's memory usage and does not run the garbage
> collector or any finalizers often enough. Consequently, memory usage for a
> Go server that uses cgo heavily can grow very large, with Go itself being
> utterly unaware of it.
> >
> > If the C functions allocate memory, historically you could set a
> finalizer to free the memory sometime after there are no remaining
> references to it in Go, as, for example, described in this blog post.
> However, the current Go docs on runtime.SetFinalizer state:
> >
> > > There is no guarantee that finalizers will run before a program exits,
> so typically they are useful only for releasing non-memory resources
> associated with an object during a long-running program.
> >
> > Are there any other ways to automatically release memory resources
> associated with an object? Or telling Go's memory manager that the small
> object it sees in the Go world is but the tip of an iceberg of memory
> allocated in the C world and therefore should be finalized?
> >
> > Not-good options include:
> > - Requiring the programmer to make explicit calls to free the memory
> resources when they believe the object is no longer needed, but this takes
> us back to the painful world of C's manual memory management and is easy to
> get wrong.
> > - Padding Go objects associated with C memory resources with large,
> unused fields (e.g. an [1024]byte) in the hope that the Go garbage
> collector will be more likely to finalize and free them when they are
> unused.
> > - Avoiding cgo in any server code.
> >
> > Are there any good options?
>
>
> If you are using C code, you are using C's memory resource policy.  So
> the best approach is to use explicit calls to free.  I agree that that
> takes you back to the painful world of C's manual memory management,
> but, after all, if you are using C then you can't pretend that you are
> not using C.
>
> That said, although Go is careful not to promise that it will actually
> execute finalizers, in practice it does run them.  Padding the Go
> object won't make any difference as to when a finalizer is run.  It
> will be run in the next full GC cycle after the Go value is no longer
> referenced.  If there are times when the program knows that there is a
> lot of C memory that is no longer required, it can help by calling
> runtime.GC itself.
>
> In practice I think the best approach is a hybrid: free the C memory
> explicitly, but also add a finalizer.  In the finalizer, free the C
> memory, and log the fact that you are doing so, along with any
> information that will help identify where the C memory was allocated.
> Then periodically check your logs for cases where the finalizer ran,
> and add the necessary calls to explicitly free the C memory manually.
> Of course, when you free the C memory manually, don't forget to clear
> the finalizer.
>
> 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/CAHY_QbR2NB1FFobtTW6dkXN9h-Zj5uw3bfodVnFzghL_1%3DdUJg%40mail.gmail.com.

[go-nuts] Go servers should return 308 for non-GET methods

[rfgrimm]

Hi all,

Apologies if this has been discussed before.  I searched and didn't find 
anything.  There are a few places in http/server.go that will redirect with 
301s and that could cause clients, including Go's client, to change the 
method to a GET.  One place/condition when it does this kind of redirect is 
in ServeMux.Handler if the request has a double-slash in the path.  This 
could be problematic if the request is doing a non-GET request such as a 
POST.

Here's an easy way to reproduce what I'm talking about:

package main


import (

"fmt"

"net/http"

)

 

func main() {

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {

fmt.Fprintf(w, "Hello, World!")

})

http.ListenAndServe(":8080", nil)

}


Then "curl -X POST http://localhost//; which result result in a 301.  I 
propose that this should result in a 308 instead of a 301 so clients 
(including Go's http client) won't change the method to GET when handling 
the redirect.  I encountered this in the project I'm working on because we 
accidentally were making a request like "POST http:api/" 
using a Go client and talking to a Go server.  I was going to file a bug on 
this but wanted to consult this list first.


Regards,

-Rob

-- 
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/d8cd6c54-33f0-45bc-b368-eb336e12e3e5%40googlegroups.com.

Re: [go-nuts] How to kill running function from core golang libraries

[burak sarac]

Thank you all for your response
Jake - thank you for clarification and yes you are correct. Application 
works like checksum validation server,client. Terminate is only useful if 
user triggered server to download a very large file but figured wrong 
setting present and i.e. does ctrl+c on client yet still it is matter of 
seconds. For the exact same reason I have postponed but I wanted to 
investigate if there is a way. I will give a shot this weekend for the 
io.Reader

Burak

On Friday, November 1, 2019 at 4:54:00 PM UTC+1, Jake Montgomery wrote:
>
> On Friday, November 1, 2019 at 10:30:50 AM UTC-4, Shulhan wrote:
>>
>>
>> On Fri, 1 Nov 2019, 21:07 burak sarac,  wrote:
>>
>>>  I have a go routine running something like 'hash.sum(data)' using import 
>>> "hash" that I want to terminate immediately in case of user wants to 
>>> kill, I can not send channel to notify. 
>>>
>>
>>
>> I have not tried this, but you can use a combination of defer, panic and 
>> recover to unroll the process.
>>
>> The recover function is inside calculate, and the for-loop is running in 
>> goroutine before calculate.
>>
>>defer func() { recover() }
>>go loop()
>>calculate()
>>
>> Inside the loop() you will call panic("terminate").
>>
>> -- Shulhan
>>
>
> Shulhan - I think the point was that Burak does not have control over the 
> code for the function that we want to interrupt. So he has no ability to 
> insert a panic. 
>
> Burak - I do not believe there is a generic way to interrupt a function or 
> goroutine which does not take a Context, or have some other interruption 
> method baked in. I know the idea of being able to "kill" a goroutine has 
> been discussed before, and has generally gone nowhere. 
>
> It might be useful to have more details of the call, and to understand why 
> you need to interrupt this function. Assuming the hash.sum() you refer to 
> takes a []byte, then how long could it reasonably take? The best bet might 
> be to simply let it finish and ignore the result. Of course, if the 
> function is being sourced off an io.Reader(), or something like that, then 
> you might be able to interrupt the stream by wrapping the interface with 
> some of your own code.
>
>

-- 
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/6e941dc9-2cca-4050-ae6b-1a3066337a8a%40googlegroups.com.

Re: [go-nuts] How to kill running function from core golang libraries

[burak serdar]

On Fri, Nov 1, 2019 at 8:07 AM burak sarac  wrote:
>
>  I have a go routine running something like 'hash.sum(data)' using import 
> "hash" that I want to terminate immediately in case of user wants to kill, I 
> can not send channel to notify. I only can think of copying implementation 
> but then I have to watch each update on library which I really dont want to 
> mess with. Do you have any suggestions? Code is here
>
> https://github.com/getsumio/getsum/blob/master/internal/supplier/gosupplier.go#L115

Can you provide a customized hash implementation that will panic based
on a flag?

>
> Thank you too much for help:)
> Burak
>
> --
> 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/716c9b47-e84b-4aea-b061-45604fd1561e%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/CAMV2RqpZ3OnA4rtvYHvuE5Juuof1HT4hv%2B4weOnk%2B%2BvcYAHd9g%40mail.gmail.com.

Re: [go-nuts] How to kill running function from core golang libraries

[Jake Montgomery]

On Friday, November 1, 2019 at 10:30:50 AM UTC-4, Shulhan wrote:
>
>
> On Fri, 1 Nov 2019, 21:07 burak sarac, > 
> wrote:
>
>>  I have a go routine running something like 'hash.sum(data)' using import 
>> "hash" that I want to terminate immediately in case of user wants to 
>> kill, I can not send channel to notify. 
>>
>
>
> I have not tried this, but you can use a combination of defer, panic and 
> recover to unroll the process.
>
> The recover function is inside calculate, and the for-loop is running in 
> goroutine before calculate.
>
>defer func() { recover() }
>go loop()
>calculate()
>
> Inside the loop() you will call panic("terminate").
>
> -- Shulhan
>

Shulhan - I think the point was that Burak does not have control over the 
code for the function that we want to interrupt. So he has no ability to 
insert a panic. 

Burak - I do not believe there is a generic way to interrupt a function or 
goroutine which does not take a Context, or have some other interruption 
method baked in. I know the idea of being able to "kill" a goroutine has 
been discussed before, and has generally gone nowhere. 

It might be useful to have more details of the call, and to understand why 
you need to interrupt this function. Assuming the hash.sum() you refer to 
takes a []byte, then how long could it reasonably take? The best bet might 
be to simply let it finish and ignore the result. Of course, if the 
function is being sourced off an io.Reader(), or something like that, then 
you might be able to interrupt the stream by wrapping the interface with 
some of your own code.

-- 
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/e9464b1d-f753-4df4-9d29-e6d19cf870d2%40googlegroups.com.

[go-nuts] Re: Automatically releasing memory resources allocated in cgo?

[Jake Montgomery]

Ian's advice seems sound. But there is one other option to consider. When 
practical, I like to simply copy C allocated memory to Go allocated memory 
in the wrapper for the cgo call, and free the C memory immediately. This 
removes the insanity of keeping track of C memory in Go. Obviously there 
are myriad reasons why this might not be possible, or might impose to great 
a penalty. But where it is possible, it makes life easy again. 

On Friday, November 1, 2019 at 9:28:36 AM UTC-4, Tom Payne wrote:
>
> cgo is often used to provide bindings to C libraries. Any memory allocated 
> in the C library is not visible to Go, so Go does not have an accurate view 
> of the program's memory usage and does not run the garbage collector or any 
> finalizers often enough. Consequently, memory usage for a Go server that 
> uses cgo heavily can grow very large, with Go itself being utterly unaware 
> of it.
>
> If the C functions allocate memory, historically you could set a finalizer 
> to free the memory sometime after there are no remaining references to it 
> in Go, as, for example, described in this blog post 
> .
>  
> However, the current Go docs on runtime.SetFinalizer 
>  state:
>
> > There is no guarantee that finalizers will run before a program exits, 
> so typically they are useful only for releasing non-memory resources 
> associated with an object during a long-running program.
>
> Are there any other ways to automatically release memory resources 
> associated with an object? Or telling Go's memory manager that the small 
> object it sees in the Go world is but the tip of an iceberg of memory 
> allocated in the C world and therefore should be finalized?
>
> Not-good options include:
> - Requiring the programmer to make explicit calls to free the memory 
> resources when they believe the object is no longer needed, but this takes 
> us back to the painful world of C's manual memory management and is easy to 
> get wrong.
> - Padding Go objects associated with C memory resources with large, unused 
> fields (e.g. an [1024]byte) in the hope that the Go garbage collector will 
> be more likely to finalize and free them when they are unused.
> - Avoiding cgo in any server code.
>
> Are there any good options?
>
> Cheers,
> Tom
>

-- 
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/682feb70-e5de-400c-a14b-06e8af6140ae%40googlegroups.com.

Re: [go-nuts] http: superfluous response.WriteHeader call

[Mhd Shulhan]

On Fri, 1 Nov 2019, 00:13 ,  wrote:

> help me!
>
> web connect database and show view. when press f5 repeatedly
> command line show http: superfluous response.WriteHeader
> call...
>

My guess is that you call response.WriteHeader in your code.  Check again,
and make sure its only call once.

--  shuLhan

>

-- 
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/CAMh9%2BYDXYFnPKwLHqiSVbZWcL_3TjcJdO%3Dcc8Bd3fjAtJurYnQ%40mail.gmail.com.

Re: [go-nuts] How to kill running function from core golang libraries

[Mhd Shulhan]

On Fri, 1 Nov 2019, 21:07 burak sarac,  wrote:

>  I have a go routine running something like 'hash.sum(data)' using import
> "hash" that I want to terminate immediately in case of user wants to
> kill, I can not send channel to notify.
>


I have not tried this, but you can use a combination of defer, panic and
recover to unroll the process.

The recover function is inside calculate, and the for-loop is running in
goroutine before calculate.

   defer func() { recover() }
   go loop()
   calculate()

Inside the loop() you will call panic("terminate").

-- Shulhan

>

-- 
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/CAMh9%2BYA%3DYW9gp6gtduRMyh_Zu567CJ97r8PcR-Wzp9HEz2%2BxHg%40mail.gmail.com.

Re: [go-nuts] Automatically releasing memory resources allocated in cgo?

[Ian Lance Taylor]

On Fri, Nov 1, 2019 at 6:31 AM Tom Payne  wrote:
>
> cgo is often used to provide bindings to C libraries. Any memory allocated in 
> the C library is not visible to Go, so Go does not have an accurate view of 
> the program's memory usage and does not run the garbage collector or any 
> finalizers often enough. Consequently, memory usage for a Go server that uses 
> cgo heavily can grow very large, with Go itself being utterly unaware of it.
>
> If the C functions allocate memory, historically you could set a finalizer to 
> free the memory sometime after there are no remaining references to it in Go, 
> as, for example, described in this blog post. However, the current Go docs on 
> runtime.SetFinalizer state:
>
> > There is no guarantee that finalizers will run before a program exits, so 
> > typically they are useful only for releasing non-memory resources 
> > associated with an object during a long-running program.
>
> Are there any other ways to automatically release memory resources associated 
> with an object? Or telling Go's memory manager that the small object it sees 
> in the Go world is but the tip of an iceberg of memory allocated in the C 
> world and therefore should be finalized?
>
> Not-good options include:
> - Requiring the programmer to make explicit calls to free the memory 
> resources when they believe the object is no longer needed, but this takes us 
> back to the painful world of C's manual memory management and is easy to get 
> wrong.
> - Padding Go objects associated with C memory resources with large, unused 
> fields (e.g. an [1024]byte) in the hope that the Go garbage collector will be 
> more likely to finalize and free them when they are unused.
> - Avoiding cgo in any server code.
>
> Are there any good options?


If you are using C code, you are using C's memory resource policy.  So
the best approach is to use explicit calls to free.  I agree that that
takes you back to the painful world of C's manual memory management,
but, after all, if you are using C then you can't pretend that you are
not using C.

That said, although Go is careful not to promise that it will actually
execute finalizers, in practice it does run them.  Padding the Go
object won't make any difference as to when a finalizer is run.  It
will be run in the next full GC cycle after the Go value is no longer
referenced.  If there are times when the program knows that there is a
lot of C memory that is no longer required, it can help by calling
runtime.GC itself.

In practice I think the best approach is a hybrid: free the C memory
explicitly, but also add a finalizer.  In the finalizer, free the C
memory, and log the fact that you are doing so, along with any
information that will help identify where the C memory was allocated.
Then periodically check your logs for cases where the finalizer ran,
and add the necessary calls to explicitly free the C memory manually.
Of course, when you free the C memory manually, don't forget to clear
the finalizer.

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/CAOyqgcUpD9d59Hk7CZECwBd87QN5uyyunWxwKGSpMqnrCSAuLA%40mail.gmail.com.

[go-nuts] How to kill running function from core golang libraries

[burak sarac]

 I have a go routine running something like 'hash.sum(data)' using import "
hash" that I want to terminate immediately in case of user wants to kill, I 
can not send channel to notify. I only can think of copying implementation 
but then I have to watch each update on library which I really dont want to 
mess with. Do you have any suggestions? Code is here 

https://github.com/getsumio/getsum/blob/master/internal/supplier/gosupplier.go#L115

Thank you too much for help:)
Burak

-- 
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/716c9b47-e84b-4aea-b061-45604fd1561e%40googlegroups.com.

Re: [go-nuts] Any non-split 'print' functions available?

[Ian Lance Taylor]

On Thu, Oct 31, 2019 at 11:44 PM Xiangdong JI  wrote:
>
> Thanks Ian, having difficulty figuring out how to print a pointer using 
> write1, could you please shed a light? Thanks.

You have to do something like (untested)

var buf [20]byte
b := itoa(buf[:], uint64(uintptr(ptrToPrint)))
write1(2, [0], len(b))

Ian

> On Friday, November 1, 2019 at 2:00:04 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Thu, Oct 31, 2019 at 5:10 AM Xiangdong JI  wrote:
>> >
>> > seeking utilities for diagnosing some 'nosplit' runtime functions. Thanks 
>> > a lot.
>>
>> b := []byte("my debug message\n")
>> write1(2, [0], len(b))
>>
>> 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/d097f1f1-7127-49d3-834c-e22c8b7ecb26%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/CAOyqgcX3LKNjAF6dmcW3tiDc4XzjyLvHF-fgHbU49QPvXY4Xdw%40mail.gmail.com.

[go-nuts] Automatically releasing memory resources allocated in cgo?

[Tom Payne]

cgo is often used to provide bindings to C libraries. Any memory allocated 
in the C library is not visible to Go, so Go does not have an accurate view 
of the program's memory usage and does not run the garbage collector or any 
finalizers often enough. Consequently, memory usage for a Go server that 
uses cgo heavily can grow very large, with Go itself being utterly unaware 
of it.

If the C functions allocate memory, historically you could set a finalizer 
to free the memory sometime after there are no remaining references to it 
in Go, as, for example, described in this blog post 
.
 
However, the current Go docs on runtime.SetFinalizer 
 state:

> There is no guarantee that finalizers will run before a program exits, so 
typically they are useful only for releasing non-memory resources 
associated with an object during a long-running program.

Are there any other ways to automatically release memory resources 
associated with an object? Or telling Go's memory manager that the small 
object it sees in the Go world is but the tip of an iceberg of memory 
allocated in the C world and therefore should be finalized?

Not-good options include:
- Requiring the programmer to make explicit calls to free the memory 
resources when they believe the object is no longer needed, but this takes 
us back to the painful world of C's manual memory management and is easy to 
get wrong.
- Padding Go objects associated with C memory resources with large, unused 
fields (e.g. an [1024]byte) in the hope that the Go garbage collector will 
be more likely to finalize and free them when they are unused.
- Avoiding cgo in any server code.

Are there any good options?

Cheers,
Tom

-- 
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/e15adc2e-5d41-4413-b8ed-84c63dbbb8c7%40googlegroups.com.

[go-nuts] Re: Go 1.13.4 and Go 1.12.13 are released

[Stephen Illingworth]

Build fails here. Using v1.13 to build:

go test proxy running at GOPROXY=http://127.0.0.1:41805/mod
go proxy: no archive rsc.io v1.5.2: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.1.0: file does not exist
go proxy: no archive rsc.io v1.5.1: file does not exist
go proxy: no archive example.com/newcycle v1.0.0: file does not exist
--- FAIL: TestScript (0.00s)
--- FAIL: TestScript/vendor_complex (0.57s)
script_test.go:191: 
# smoke test for complex build configuration (0.571s)
> go build -o complex.exe complex
> [exec:gccgo] go build -compiler=gccgo -o complex.exe complex
[stderr]
package complex
imports runtime: cannot find package "runtime" in any of:
$WORK/gopath/src/complex/vendor/runtime (vendor tree)
/home/steve/Go/go1.13.4/src/runtime (from $GOROOT)
$WORK/gopath/src/runtime (from $GOPATH)
[exit status 1]
FAIL: testdata/script/vendor_complex.txt:5: unexpected command 
failure

--- FAIL: TestIssue7573 (0.01s)
go_test.go:3048: running testgo [build -n -compiler gccgo cgoref]
go_test.go:3048: standard error:
go_test.go:3048: package cgoref
imports runtime: cannot find package "runtime" in any of:
/home/steve/Go/go1.13.4/src/runtime (from $GOROOT)
/tmp/cmd-go-test-589579455/gotest023101038/src/runtime (from 
$GOPATH)
package cgoref
imports syscall: cannot find package "syscall" in any of:
/home/steve/Go/go1.13.4/src/syscall (from $GOROOT)
/tmp/cmd-go-test-589579455/gotest023101038/src/syscall (from 
$GOPATH)

go_test.go:3048: go [build -n -compiler gccgo cgoref] failed 
unexpectedly in /home/steve/Go/go1.13.4/src/cmd/go: exit status 1
FAIL
FAILcmd/go91.345s

-- 
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/d43f9dd9-9cdf-4234-8ab2-0bf8085ba090%40googlegroups.com.

[go-nuts] Re: Roadblock for user-implemented JIT compiler

[Sokolov Yura]

Don't forget about calling to write barriers. 

-- 
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/0cee4894-0c9d-4088-a36c-c8178cee3f49%40googlegroups.com.

Re: [go-nuts] Any non-split 'print' functions available?

[Xiangdong JI]

Thanks Ian, having difficulty figuring out how to print a pointer using 
write1, could you please shed a light? Thanks.

On Friday, November 1, 2019 at 2:00:04 PM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Oct 31, 2019 at 5:10 AM Xiangdong JI  > wrote: 
> > 
> > seeking utilities for diagnosing some 'nosplit' runtime functions. 
> Thanks a lot. 
>
> b := []byte("my debug message\n") 
> write1(2, [0], len(b)) 
>
> 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/d097f1f1-7127-49d3-834c-e22c8b7ecb26%40googlegroups.com.

Re: [go-nuts] Any non-split 'print' functions available?

[Ian Lance Taylor]

On Thu, Oct 31, 2019 at 5:10 AM Xiangdong JI  wrote:
>
> seeking utilities for diagnosing some 'nosplit' runtime functions. Thanks a 
> lot.

b := []byte("my debug message\n")
write1(2, [0], len(b))

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/CAOyqgcVB983v7K3mfgb5GY4cojN0b9es6mXDdz6iZ8j15mts9Q%40mail.gmail.com.