Re: [go-nuts] global goroutine data / thread local storage?

2020-09-26 Thread Alex Besogonov
On Saturday, September 26, 2020 at 12:34:37 PM UTC-7 Ian Lance Taylor wrote:

> > A Go-style goroutine-local system can be thought as a context.Context 
> that is transparently assigned to a goroutine and its children. Thus if you 
> want to change the value, you'd do something like "c := 
> magic.GetCurrentContext(); c = c.WithValue(...); magic.SetContext(c);". 
> > This would affect only the current goroutine going forward, but not its 
> children. 
> In general, Go's attitude is that explicit is better than implicit. 
> If you rigorously stick to the pattern you describe, it's the same as 
> passing the context.Context around explicitly (except that passing the 
> Context around explicitly is more flexible). 
>
Well, I ran a simple regexp grep over my existing code base. Out of 8153 
functions I have 7632 functions that have context.Context as a parameter. 
So basically in my Go code every function has to have about half a line of 
extra fluff (context and the error return).

I'm ambivalent about goroutine-specific variables. Context is not a 
terribly bad solution, I can personally live with it just fine. 
Unfortunately, there are _STILL_ APIs that don't have context. I was bitten 
by JSON marshalling and SQL. And apparently newer APIs are being designed 
by the Golang team that don't accept a context (because it doesn't look 
nice).

-- 
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/0371c088-7056-45ac-8f1f-e45f5b82b4c5n%40googlegroups.com.


Re: [go-nuts] [CGO] How can I convert GoString to wchar_t?

2020-09-26 Thread Jan Mercl
On Sat, Sep 26, 2020 at 10:01 PM Raffaele Sena  wrote:
>
> wchar_t is a 16 bits value representing a UTF16 character so you could 
> convert Go strings to and from UTF16 using the unicode/utf16 package.

FTR: Correct for Windows, may be different on other platforms.

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


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-26 Thread Alex Besogonov
On Saturday, September 26, 2020 at 12:33:40 PM UTC-7 Ian Lance Taylor wrote:

> On Fri, Sep 25, 2020 at 6:29 PM Alex Besogonov  
> wrote: 
> > If you mutate the value, then only the current goroutine is affected 
> (not even its existing children). Basically, the goroutine-local context is 
> copied on new goroutine launch. 
> > That's how pprof labels work right now, btw. 
> Labels are not variables. Variables have values that can be changed. 
>
Most people don't need fully mutable goroutine-specific variables, but 
something like an automatic context carrier. It's immutable, so this would 
mostly solve the mutation problem. 

So in your example you'll have to write:
for _, p := range s { threadCtx = 
threadCtx.WithValue(p.SlowMethod(threadCtx.get()));}
 
This makes it clear that there's causal relationship between the current 
value and the next one, so the loop can't be naïvely parallelized. Of 
course, a very determined programmer can still shoot themselves in the foot 
(by reading and replacing the automatic context inside p.SlowMethod), but 
the footgun here is pretty explicit.

-- 
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/3b7ab9c2-e1d5-4cc4-b5c0-bcac3e96b37dn%40googlegroups.com.


Re: [go-nuts] [CGO] How can I convert GoString to wchar_t?

2020-09-26 Thread Raffaele Sena
wchar_t is a 16 bits value representing a UTF16 character so you could
convert Go strings to and from UTF16 using the unicode/utf16 package.


On Sat, Sep 26, 2020 at 11:39 AM Sean  wrote:

> Hi gophers,
>
> I'm trying to write the Golang wrapper for a dll with CGO.
>
> A wrapper that will only work in windows.
>
> I need to be able to send UTF-8 or unicode strings to c.
>
> This issue was never asked on platforms like stackoverflow.
>
> So I couldn't find a solution.
>
> https://github.com/dkager/tolk/blob/master/src/Tolk.h#l72
> line 72
>
> https://github.com/dkager/tolk/blob/master/src/Tolk.h#l100
> line 100
>
> I am adding the code I tried below:
>
>
> package talker
>
> //#cgo windows  CFLAGS: -DGO_WINDOWS -Iinclude
> //#cgo windows  LDFLAGS: -Llib/x64 -lTolk
> //#include "Tolk.h"
> import "C"
> //  import "unsafe"
>
>
> func Load() {
> C.Tolk_Load()
> }
>
> func IsLoaded() bool {
> if C.Tolk_IsLoaded() == false {
> return false
> }
> return true
> }
>
>
> func Unload() {
> C.Tolk_Unload()
> }
>
>
> // problem: the function I can't find a solution for.
> func DetectScreenReader() string{
> return C.GoString(C.Tolk_DetectScreenReader())
> }
>
> func HasBraille() bool{
> b := C.Tolk_HasBraille()
> if (b == false) {
> return false }
> return true
> }
>
> // problem: the second function I can't find a solution for ..
> func Output(text string, interrupt bool) {
> b := C.bool(bool)
> C.Tolk_Output((*C.wchar_t)(text), b)
> }
>
>
>
> error: .\talker.go:39:28: cannot convert text (type string) to type
> *_Ctype_ushort
>
> Sean
>
>- Email: seantolstoyev...@protonmail.com
>
>- GitHub: SeanTolstoyevski 
>
> ‍羚 I’m a software developer. I coding often Python, sometimes Go and
> rarely (C)/C++.
>
> --
> 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/aeaba06b-bb41-3e3a-3ee4-7993b8bb4596%40gmail.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/CANKfucbP61nRLwsca1UsQSYq6qq-mMC-ZC8i6mHEGKqra72eAQ%40mail.gmail.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-26 Thread Alex Besogonov
On Saturday, September 26, 2020 at 5:41:54 AM UTC-7 rog wrote:

> A Go-style goroutine-local system can be thought as a context.Context that 
>> is transparently assigned to a goroutine and its children. Thus if you want 
>> to change the value, you'd do something like "c := 
>> magic.GetCurrentContext(); c = c.WithValue(...); magic.SetContext(c);".
>>
>> This would affect only the current goroutine going forward, but not its 
>> children.
>>
>
> What happens if you want to invoke an operation by passing its arguments 
> to an existing goroutine that does work on the current goroutine's behalf 
> (aka a worker pool)?
> I don't think this pattern is that uncommon, and it would break the 
> inheritable-variables model. 
>
Worker pools with long-lived goroutines are actually very rare in Go, 
because launching a new goroutine is easy. A worker pool that is created 
in-place (for example, to run parallel processing on data) would work just 
fine.

-- 
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/fddb15ae-876c-48f4-83d2-d9a6e43b73c4n%40googlegroups.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-26 Thread Ian Lance Taylor
On Fri, Sep 25, 2020 at 6:36 PM Alex Besogonov  wrote:
>
> On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
>>  wrote:
>> >
>> > Inheritable goroutine-locals would actually work just fine in Go. 
>> > Moreover, Go actually has them in the form of pprof labels.
>> What should happen if one goroutine changes an inherited
>> goroutine-local variable?
>
> A Go-style goroutine-local system can be thought as a context.Context that is 
> transparently assigned to a goroutine and its children. Thus if you want to 
> change the value, you'd do something like "c := magic.GetCurrentContext(); c 
> = c.WithValue(...); magic.SetContext(c);".
>
> This would affect only the current goroutine going forward, but not its 
> children.

In general, Go's attitude is that explicit is better than implicit.
If you rigorously stick to the pattern you describe, it's the same as
passing the context.Context around explicitly (except that passing the
Context around explicitly is more flexible).

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/CAOyqgcVJws%2BVpnYx%2BPRpRprdhvq_csti_5bwqFOnfesoKLja0A%40mail.gmail.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-26 Thread Ian Lance Taylor
On Fri, Sep 25, 2020 at 6:29 PM Alex Besogonov  wrote:
>
> If you mutate the value, then only the current goroutine is affected (not 
> even its existing children). Basically, the goroutine-local context is copied 
> on new goroutine launch.
>
> That's how pprof labels work right now, btw.

Labels are not variables.  Variables have values that can be changed.

For example, if we had goroutine local variables then code like

goroutine var G int32

func F(s []P) {
 for _, p := range s {
G += p.SlowMethod()
}
}

might get changed to

func F(s []P) {
for _, p := range s {
p := p
go func() {
atomic.Add(, p.SlowMethod())
}()
}
}

but the two functions would work very differently.

Ian




> On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
>>  wrote:
>> >
>> > Inheritable goroutine-locals would actually work just fine in Go. 
>> > Moreover, Go actually has them in the form of pprof labels.
>>
>> What should happen if one goroutine changes an inherited
>> goroutine-local variable?
>>
>> Ian
>>
>>
>> > On Wednesday, September 23, 2020 at 5:55:50 PM UTC-7 Ian Lance Taylor 
>> > wrote:
>> >>
>> >> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills  wrote:
>> >> >
>> >> > There appears to be a way to get a reference on the goroutine id:
>> >> >
>> >> > http://blog.sgmansfield.com/2015/12/goroutine-ids/
>> >>
>> >> But as you can see by reading that blog article, that is almost a joke.
>> >>
>> >> Go considers these things to be better handled explicitly, which is
>> >> why people are telling you to use a context.Context value. And, yes,
>> >> you'll want to use a Context aware logging package.
>> >>
>> >> In Go it's trivial to create new goroutines, and as soon as you do
>> >> that any goroutine-local-variable scheme falls apart. So Go has
>> >> consistently chosen to not provide that capability, and similarly to
>> >> not provide goroutine IDs. It's an intentional choice by the
>> >> language. There have been a number of discussions about this in the
>> >> past on this mailing list.
>> >>
>> >> 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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/golang-nuts/f78f2d12-89d2-494d-983a-a462f0124d82n%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/ee6daca3-6e85-458e-95fd-877e8af4368dn%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/CAOyqgcWyF61EgKxxn3ikokyJi61-9Zqde_WtyPVMO1A6ojnLvg%40mail.gmail.com.


[go-nuts] [CGO] How can I convert GoString to wchar_t?

2020-09-26 Thread Sean

Hi gophers,

I'm trying to write the Golang wrapper for a dll with CGO.

A wrapper that will only work in windows.

I need to be able to send UTF-8 or unicode strings to c.

This issue was never asked on platforms like stackoverflow.

So I couldn't find a solution.

https://github.com/dkager/tolk/blob/master/src/Tolk.h#l72
line 72

https://github.com/dkager/tolk/blob/master/src/Tolk.h#l100
line 100

I am adding the code I tried below:


package talker

//#cgo windows  CFLAGS: -DGO_WINDOWS -Iinclude
//#cgo windows  LDFLAGS: -Llib/x64 -lTolk
//#include "Tolk.h"
import "C"
//  import "unsafe"


func Load() {
    C.Tolk_Load()
}

func IsLoaded() bool {
    if C.Tolk_IsLoaded() == false {
        return false
        }
    return true
}


func Unload() {
    C.Tolk_Unload()
}


// problem: the function I can't find a solution for.
func DetectScreenReader() string{
    return C.GoString(C.Tolk_DetectScreenReader())
}

func HasBraille() bool{
    b := C.Tolk_HasBraille()
    if (b == false) {
        return false }
    return true
}

// problem: the second function I can't find a solution for ..
func Output(text string, interrupt bool) {
    b := C.bool(bool)
    C.Tolk_Output((*C.wchar_t)(text), b)
}



error: .\talker.go:39:28: cannot convert text (type string) to type 
*_Ctype_ushort



Sean

 * Email: seantolstoyev...@protonmail.com
   
 * GitHub: SeanTolstoyevski 

‍羚 I’m a software developer. I coding often Python, sometimes Go and 
rarely (C)/C++.


--
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/aeaba06b-bb41-3e3a-3ee4-7993b8bb4596%40gmail.com.


Re: [go-nuts] global goroutine data / thread local storage?

2020-09-26 Thread roger peppe
On Sat, 26 Sep 2020, 02:36 Alex Besogonov,  wrote:

> On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote:
>
>> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov
>>  wrote:
>> >
>> > Inheritable goroutine-locals would actually work just fine in Go.
>> Moreover, Go actually has them in the form of pprof labels.
>> What should happen if one goroutine changes an inherited
>> goroutine-local variable?
>>
> A Go-style goroutine-local system can be thought as a context.Context that
> is transparently assigned to a goroutine and its children. Thus if you want
> to change the value, you'd do something like "c :=
> magic.GetCurrentContext(); c = c.WithValue(...); magic.SetContext(c);".
>
> This would affect only the current goroutine going forward, but not its
> children.
>

What happens if you want to invoke an operation by passing its arguments to
an existing goroutine that does work on the current goroutine's behalf (aka
a worker pool)?

I don't think this pattern is that uncommon, and it would break the
inheritable-variables model.

>
>
>> > On Wednesday, September 23, 2020 at 5:55:50 PM UTC-7 Ian Lance Taylor
>> wrote:
>> >>
>> >> On Wed, Sep 23, 2020 at 5:46 PM Alex Mills 
>> wrote:
>> >> >
>> >> > There appears to be a way to get a reference on the goroutine id:
>> >> >
>> >> > http://blog.sgmansfield.com/2015/12/goroutine-ids/
>> >>
>> >> But as you can see by reading that blog article, that is almost a
>> joke.
>> >>
>> >> Go considers these things to be better handled explicitly, which is
>> >> why people are telling you to use a context.Context value. And, yes,
>> >> you'll want to use a Context aware logging package.
>> >>
>> >> In Go it's trivial to create new goroutines, and as soon as you do
>> >> that any goroutine-local-variable scheme falls apart. So Go has
>> >> consistently chosen to not provide that capability, and similarly to
>> >> not provide goroutine IDs. It's an intentional choice by the
>> >> language. There have been a number of discussions about this in the
>> >> past on this mailing list.
>> >>
>> >> 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...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/f78f2d12-89d2-494d-983a-a462f0124d82n%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/7bc62278-5cbc-47fe-abd2-36172e4e8520n%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/CAJhgacifKxQVzq%3Dak%2BCzR_5GX-1C5_%3DdV6awwkbaDNrn40MVYA%40mail.gmail.com.


Re: [go-nuts] Build kubernetes with gollvm

2020-09-26 Thread Ivan Serdyuk
Brendan,
could you review this and express your vision against the usage of

https://godoc.org/k8s.io/kubernetes/third_party/forked/golang/reflect

https://golang.org/pkg/reflect/
https://github.com/modern-go/reflect2
packages?

What is required to patch, within the reflect2 package, so Kubernetes could
be compiled via gollvm?

Ivan

On Sat, Jul 20, 2019 at 5:32 AM Yuan Ting  wrote:

> OK, I will check out the reflect2 package and take a look. Thanks a lot
> for your direction!
>
> Best,
> Ting
>
> On Friday, July 19, 2019 at 10:30:32 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Fri, Jul 19, 2019 at 1:11 AM Yuan Ting  wrote:
>> >
>> >  Sorry to have troubled you again, I found that many famous Go projects
>> also import github.com/modern-go/reflect2 , such as kubernetes and moby.
>> According to the second paragraph in your explanation, these popular
>> projects will also failed in compilation. I think this may be a big
>> challenge for gccgo/gollvm's promotion.
>> >
>> > To solve this compiler-sensitive problem, the way I can come up with is
>> replacing all unsafe mechanisms as mentioned above in reflect2 to safe or
>> standard mechanisms (and may go against the purpose of reflect2). I'm not
>> familiar with runtime, but is it possible to support the same symbol in
>> gccgo/gollvm style?
>>
>> Simply supporting runtime.typelinks is not enough.  The reflect
>> package is closely tied to the compiler implementation.  The reflect
>> package is not identical in the gc library and the GoLLVM library.  If
>> people need reflect2 to work with GoLLVM, then the only workable
>> option is for the reflect2 authors to write a version of their package
>> that uses the gccgo build tag to build a version that works with
>> GoLLVM.  Perhaps you could help them with that.  Sorry this isn't very
>> helpful.  I don't really understand why people are using the package.
>>
>> 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/1fd95c73-6e30-4089-bad4-b21c261d788a%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/CANFCsz_Ropfv93%2B_g%3DsPCa_yzrQuQJSQcWTjvLbTB-GcMhBkyw%40mail.gmail.com.