Re: [go-nuts] macos file provider handling with golang

2021-09-25 Thread Vasiliy Tolstov
may be, but i don't understand how to connect it to swift based api and run on m1 macbook пт, 24 сент. 2021 г. в 19:38, Ian Lance Taylor : > > On Fri, Sep 24, 2021 at 9:00 AM Vasiliy Tolstov wrote: > > > > Hi. Does anybody knows how to call macos functions from go? > > Mostly my question about

Re: [go-nuts] Re: macos file provider handling with golang

2021-09-25 Thread Vasiliy Tolstov
thanks, macdriver does not support m1 =) so i can't use it сб, 25 сент. 2021 г. в 08:23, 'Carla Pfaff' via golang-nuts : > > On Friday, 24 September 2021 at 18:00:21 UTC+2 va...@selfip.ru wrote: >> >> Hi. Does anybody knows how to call macos functions from go? >> Mostly my question about file

[go-nuts] Re: cgo question

2021-09-25 Thread Elemer Pixard
Using unsafe.Pointer instead of the C type: C.device_t solved the problem: func Open() { var dev unsafe.Pointer C.open() } On Saturday, September 25, 2021 at 12:13:04 PM UTC-3 Elemer Pixard wrote: > Correction: The Go function is: > func Open() { > var dev *C.device_t > C.open() > }

[go-nuts] Re: cgo question

2021-09-25 Thread Elemer Pixard
Correction: The Go function is: func Open() { var dev *C.device_t C.open() } On Saturday, September 25, 2021 at 10:59:45 AM UTC-3 Elemer Pixard wrote: > I am trying to call the following C function (simplified version from a C > library) from Go, > and I got compiler errors: > typedef void

[go-nuts] cgo question

2021-09-25 Thread Elemer Pixard
I am trying to call the following C function (simplified version from a C library) from Go, and I got compiler errors: typedef void device_t; void open(device_t **dev) { } *Go Function*: func Open() { var dev C.device_t C.open(&) } *Compiler (v1.17) error:* cannot use _cgo0 (type

Re: [go-nuts] Type Parameters Proposal, few unimportant questions

2021-09-25 Thread Kamil Ziemian
> It's a detail of Go scoping. If we write "f := func(...)" then f goes into scope after that statement. As a consequence, > if we used :=, the recursive call to f in the function literal would not refer to the f declared with the := statement, > but to the f that is in scope before the :=