[Hamlib-developer] Re: Kylix binding for Hamlib

[Francois R. <fgr...@su...>]

Hello Stephane,

Stephane Fillod wrote:
> > Included in the tests/ directory is a small demo/test program.
> > It can select a rigs and open a very primative frequency display
> > dialog box.  Will improve later..
> 
> Sorry, I won't be able to give it a try real soon, cause I don't
> have Kylix installed yet. Somehow, I have not seen any Makefile.am
> in your commit. Do you think it's too early to put it into dist?
> Since there's no support in automake for .pas sources, you'll have
> to specify the build process in the Makefile.am, unless this is all
> handled by Kylix itself.

Hmm, forgot about the Makefile.am.  Kylix has also has a command-line
compiler, but I have not used it yet.   Kylix handle it's own build 
process. The user has to include the hamlib_*api.pas files in his
project to use the binding.

> You're right. Hamlib is not checking for non-null rig pointers.
> But this is a tread-of. It depends how deep we trust the programmer
> using the library. Hamlib can very well not check for any error at all.
> However, we implicitly decided to test for initialization errors
> caused by null pointers, catching most probable bug.
> IMHO, verifying non-null rig pointer is a little bit paranoic,
> were are not in the Linux kernel.
> Anyway, it's fast, it's the C language. Adding code to check everything
> with C would advocate for rewritting Hamlib in Java.
> But we like to live dangerously, and avoid breeding bugs in our code :)
> 
> Hamlib only means to check for this:
> 
>         my_rig = rig_init(RIG_MODEL_DUMMY);
>             /* imagine malloc failed, my_rig==NULL */
> 
>         rig_open(my_rig);  /* seg fault... */
> 
> ..and not for random memory corruption within the RIG opaque structure.
> If the user program messes to much with it, it'll get what ít's looking for.
> 
> Now, thinking of it twice (sorry folks, I sometimes happen to not think twice
> when I write code :), Hamlib is not checking the right thing.
> It should check for rig_state.comm_state, preventing for example an app
> from doing rig_set_freq() on a rig handle that was not rig_open'ed.
> What do you all think?

I agree that the magic number testing is going a bit overboard, but 
it is helpfull during testing. I'll keep a seperate patch for testing.

> Btw Francois, you told me earlier you have a patch for the easycomm rotator.
> Is it spinning already? Do you have any plan to commit it before 1.1.3?
> I was thinking also that the rotator API lacks some capabilities,
> like the angular speed of the rotator (what units are best?),
> and also a call like rot_get_destination, useful when the rotator
> is still on its way.

Yes, it is working. Got a little distracted by the Kylix binding. 
Will submit it tonight. 


Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za