By including the stdint SWIG typemaps we can directly use types
derived from [u]int64_t etc.
Because Lua numbers are implemented using a double-precision floating
point type and also because SWIG when generating a Lua wrappings can
only define constants from #define and enum values that fit into an
'int' type we must hide any constants that require more than 32-bits
to represent themselves, as they cannot be represented in Lua. This
applies to rmode_t and the RIG_FUNC... defines at the time of
writing. By hiding them from the Lua binding they will get a 'nil'
value in Lua i.e. undefined so clients using the Lua binding will know
they are not there. This is a nasty hack but without major design
changes to the Hamlib API it is do this or drop the Lua binding.
I made a patch, you can see in that there is the solution, which
describe the error: if a function in hamlib looks 3 argument
(rig, vfo, any 3rd arg), the order of the 2nd and 3rd argument
were reversed, because the macro METHOD1 reversed them.
I've collected these functions, compared its arguments with
hamlib docs (http://hamlib.sourceforge.net/manuals/1.2.15/), and
where 1st arg is rig, 2nd arg is vfo, and 3rd is any kind of
type, changed to METHOD3, which is a new macro, and keeps the
correct order of original function - see the patch. (I didn't
find any info about the expected diff format, so I just created
the `diff -uprN ORIG NEW'.)
To check my theory, I've tested with another function, which uses
vfo type at 2nd argument, eg. rig_set_freq; here is the Python
code:
my_rig.set_freq(Hamlib.RIG_VFO_A, 7013200.0)
and the original code drop the exception:
my_rig.set_freq(Hamlib.RIG_VFO_A, 7012500.0)
File "/usr/local/lib/python2.7/dist-packages/Hamlib.py", line 2513, in
set_freq
def set_freq(self, *args): return _Hamlib.Rig_set_freq(self, *args)
TypeError: in method 'Rig_set_freq', argument 3 of type 'vfo_t'
As you can see, it's same as my original error above.
So, after I patched the source and recompiled it again, these two
function works correctly - I will test it at soon, but I think
_this_ is good and stable.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>