Go Bindings for Hamlib — feasible?

[xlab]

Go Bindings for Hamlib — feasible?

[dh1tw]

Hey Maxim,
thanks for catching up! Well, before I got to know c-for-go I already had written most of the binding by hand. There is still some stuff missing, but I had at least something to work with. It's still on my task list to complete the binding.
I don't recall the exact reason why I didn't pursue using c-to-go further. I think I was in a hurry at that time to get at least parts of the binding up and working, so I stuck with what I had already created.
I still prefer much more a binding which is at least in parts auto generated and before completing the hamlib binding by hand I will take again the time to thoroughly try to do it with c-for-go.

[xlab]

@dh1tw
Thanks, I wish more people were considering using c-for-go rather than manual labor!

The interface hamlib/rig.h looks like easy peasy, since I have a trained hand already, I quickly did a starter repo for you, feel free to clone and make all the required adjustments:

https://github.com/xlab/hamlib-go

It compiles and links fine under OS X (brew install hamlib beforehand), the header is not ideal, but feasible! You need to ensure that args are pointers where expected pointers and arrays where arrays are expected. Also you may add some getters/setters for raw structs. I left most structs raw because of too much inner state. A raw struct looks like this:

// RigCaps as declared in hamlib/rig.h:1135
type RigCaps C.struct_rig_caps

Later I can automate getter/setter in my generator, but for now it's one manual thing to do. I hope I didn't kill your fun :D

The library seems very usable though.
Good luck.

[xlab]

@dh1tw
Also, you may prefer ALL_CAPS constants for easy migration of C code. Just sayin

[dh1tw]

Cool! Thanks for your work! Awesome! I just checked it and wrote a tiny test program. With the execption of a few strings which are not exported correctly (hamlib_version / hamlib_copyright), the test of the binding actually works! Pretty cool!

I started writing now the PtrTips.

However I have one question - I would like to make the binding more go-stylish. Almost all functions take as the first argument a pointer to an instance of a rig (radio). For example:

extern HAMLIB_EXPORT(int) rig_get_freq HAMLIB_PARAMS((RIG *rig, vfo_t vfo, freq_t *freq));

which c-for-go translates into:

// RigGetFreq function as declared in hamlib/rig.h:1545
func RigGetFreq(rig *Rig, vfo int32, freq *float64) int32 {
	crig, _ := (*C.RIG)(unsafe.Pointer(rig)), cgoAllocsUnknown
	cvfo, _ := (C.vfo_t)(vfo), cgoAllocsUnknown
	cfreq, _ := (*C.freq_t)(unsafe.Pointer(freq)), cgoAllocsUnknown
	__ret := C.rig_get_freq(crig, cvfo, cfreq)
	__v := (int32)(__ret)
	return __v
}

However I would prefer a more go-style function signature:

func (rig *RIG) GetFreq(vfo int32) (float64, error) {
....
}

Would that be possible?

[xlab]

@dh1tw

This would be dream if we can do this automatically, but actually we can't.
There is a lot of pitfalls, for example, this transform introduces a state, and there is no way to guess that state automatically. And describing the state in YAML tips is harder than just write Go code.

I usually do high-level wrappers for small packages, for example:

generated: https://github.com/xlab/pocketsphinx-go/tree/master/pocketsphinx
handmade wrapper: https://github.com/xlab/pocketsphinx-go/tree/master/sphinx

generated: https://github.com/zenhotels/lmdb-go/tree/master/mdb
handmade wrapper: https://github.com/zenhotels/lmdb-go/tree/master/lmdb

As you may notice, some wrappers are there just to have OOP semantics, other wrappers manage the state, internal resources, mutexes and other stuff, also introducing a handy API.

The point of C bindings generation is to avoid handmade CGO calls, but making the API itself more idiomatic and handy will require some hands and soul of a human :)

[dh1tw]

ok, got it. I guess I asked for to much :-) In my particular case this means that I have to write actually again quite a log of code in order to wrap the entire hamlib-go API (as most of the functions are *rig related. If I understand it right I also have to wrap again all the CONSTs in order provide a unique interface to work with, right?

[xlab]

I also have to wrap again all the CONSTs in order provide a unique interface to work with, right?

That was my preference, you don't have to. And you just can copy that file over..

that I have to write actually again quite a log of code in order to wrap the entire hamlib-go API

Not much actually, but again, it's your preference to do so.

[xlab]

In my particular case this means that I have to write actually again quite a lot of code

@dh1tw kinda ironic how you decided to write the whole binding by hand :)
Were there any problems with automated process?