Re: [go-nuts] macos file provider handling with golang
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 file provider methods, i want to write > > something that works as file provider for macos > > Are you looking for https://golang.org/cmd/cgo? See also > https://go.dev/blog/cgo. > > Ian -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- 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/CACaajQtQiw4AOM8a%3DkWZb8CtC1xM6Xt2SA8LZBYhLU8%2B5sHmGA%40mail.gmail.com.
Re: [go-nuts] Re: macos file provider handling with golang
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 provider methods, i want to write >> something that works as file provider for macos > > > https://github.com/progrium/macdriver > "MacDriver is a toolkit for working with Apple/Mac APIs and frameworks in Go." > > > -- > 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/c9321e1c-2999-4590-a94b-57de6e3e3c59n%40googlegroups.com. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- 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/CACaajQuJr1WCP_v8UskKFb4W70QrHOL%3DnNgMO9jDorS7fDuhcg%40mail.gmail.com.
[go-nuts] Re: cgo question
Using unsafe.Pointer instead of the C type: C.device_t solved the problem:
func Open() {
var dev unsafe.Pointer
C.open(&dev)
}
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(&dev)
> }
>
>
> 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 device_t;
>> void open(device_t **dev) {
>> }
>>
>> *Go Function*:
>> func Open() {
>>var dev C.device_t
>>C.open(&&dev)
>> }
>>
>> *Compiler (v1.17) error:*
>> cannot use _cgo0 (type **_Ctype_void) as type *unsafe.Pointer in argument
>> to _Cfunc_open
>>
>> How to fix that?
>> Regards.
>>
>
--
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/d8ea9cef-4362-458b-afe0-1b07dfbeaf3an%40googlegroups.com.
[go-nuts] Re: cgo question
Correction: The Go function is:
func Open() {
var dev *C.device_t
C.open(&dev)
}
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 device_t;
> void open(device_t **dev) {
> }
>
> *Go Function*:
> func Open() {
>var dev C.device_t
>C.open(&&dev)
> }
>
> *Compiler (v1.17) error:*
> cannot use _cgo0 (type **_Ctype_void) as type *unsafe.Pointer in argument
> to _Cfunc_open
>
> How to fix that?
> Regards.
>
--
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/06c6a059-c55e-4ed8-9487-8950c91412c0n%40googlegroups.com.
[go-nuts] cgo question
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(&&dev)
}
*Compiler (v1.17) error:*
cannot use _cgo0 (type **_Ctype_void) as type *unsafe.Pointer in argument
to _Cfunc_open
How to fix that?
Regards.
--
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/f9c57be6-d22d-40cb-9e40-e8c7bf65eef2n%40googlegroups.com.
Re: [go-nuts] Type Parameters Proposal, few unimportant questions
> 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 := statement. SInce there is no
such f, that code would not
> compile (and if there were such an f, it would be the wrong one). See the
discussion at https://golang.org/issue/33167.
In the future I will read this discussion about closures and scoping,
before that I still plenty materials about Go to read, listen and watch.
> Thanks for the careful reading.
I'm glad if I can help. :)
Best
Kamil
piątek, 24 września 2021 o 19:34:43 UTC+2 Ian Lance Taylor napisał(a):
> On Thu, Sep 23, 2021 at 10:07 AM Kamil Ziemian wrote:
> >
> > On the beginning of "More on type sets" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#more-on-type-sets)
>
> we read "These are not additional rules or concepts, but are consequences
> of how type sets work.". And in the subsection of it "Composite types in
> constraints" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#composite-types-in-constraints)
>
> under second code is stated "For composite types (string, pointer, array,
> slice, struct, function, map, channel) we impose an additional restriction:
> an operation may only be used if the operator accepts identical input types
> (if any) and produces identical result types for all of the types in the
> type set.".
> >
> > I probably don't understand part of text that stated this rule before,
> but since I can't find it out, I wrote it down here to be sure.
>
> Thanks, I'll delete the sentence "these are not additional rules or
> concepts." It was true a while back but it clearly no longer is.
>
>
> > In "What happened to contracts?" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#what-happened-to-contracts)
>
> we have "Type sets appeared only in contracts, rather than on interface
> types.". My English is not good enough to decide should it be "on interface
> types" or "in interface types". I have the same problem with title "Why not
> put type parameters on packages?" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-put-type-parameters-on-packages).
>
> "On packages" or "in packages"?
>
> Will change "on interface types" to "in interface types". "On
> packages" is correct. Everything in Go can be described as being "in"
> a package. The idea being discussed in that section is to add type
> parameters to packages themselves, something like "package List[T
> any]".
>
>
> > Pure curiosity. Why in "Containers" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#containers)
>
> in body of definition (?) of method "func (m *Map[K, V]) InOrder()
> *Iterator[K, V]", we have
> > var f func(*node[K, V]) bool
> > f = func(n *node[K, V]) bool { ... }
> > instead of code:
> > f := func(n *node[K, V]) bool { ... }
>
> 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 := statement. SInce there is no such f, that code would not
> compile (and if there were such an f, it would be the wrong one). See
> the discussion at https://golang.org/issue/33167.
>
>
> > In "Type inference for composite literals" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference-for-composite-literals)
>
> in comment in the code (so this have no impact on the proposed code
> working) we have "inferred as Pair(int){1, 2}". Maybe I still don't
> understand this proposal enough, because I think it should be "Pair[int]{1,
> 2}".
>
> Thanks, will fix.
>
>
> > Finally, some hair splitting.
> >
> > In first code in "Both elements and methods in constraints" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#both-elements-and-methods-in-constraints),
>
> we have
> > "~int32| ~int64"
> > more consistent with rest of the code would be
> > "~int32 | ~int64".
>
> Thanks, will fix.
>
> > In section "List transform" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#list-transform)
>
> in method func (lst *List[T]) Push(v T) we have
> > lst.tail.next = &element[T]{val: v }
> > For my money, space before last bracket should be removed to be
> consistent with other examples.
>
> Thanks, will fix.
>
> Thanks for the careful reading.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
